As user Selenium_user on beta labs enwiki, I have set my preference to opt-in to VisualEditor several times, but the preference then gets reset to default (opt-in not set) after a period of some hours.  

This causes failures in the browser tests and I wonder if it is a risk in the production environment.

--------------------------
**Version**: unspecified
**Severity**: major
The fix is to not do a global reset of preferences for the shared test user. :-) 

We will have the ULS tests create a user of their own.
Great!    Now got to find a fix, ideally the VE feature should set the optin preference.  I am not sure whether you have support for that already.

And sorry for the delay investigating this issue :/
ULS tests are doing it: 


tests/browser/features/support/pages/reset_preferences.rb 
Last indexed a month ago
1
2
3
4
class ResetPreferencesPage
	include PageObject
	include URL
	page_url URL.url('Special:Preferences/reset')
Ruby
tests/browser/features/step_definitions/common_steps.rb 
Last indexed 4 days ago
59
60
61
After('@reset-preferences-after') do |scenario|
	visit(ResetPreferencesPage)
	on(ResetPreferencesPage).submit_element.click
this really should not be happening for any test: 

0.2789   6.0M  Start request POST /wiki/Special:Preferences/reset

thanks for pointing that out.
What led me to suspect it is:

0.2789   6.0M  Start request POST /wiki/Special:Preferences/reset
HOST: commons.wikimedia.beta.wmflabs.org
HTTP HEADERS:
X-REAL-IP: ....  # Some IP address at saucelabs
X-FORWARDED-PROTO: https
...
REFERER: https://commons.wikimedia.beta.wmflabs.org/wiki/Special:Preferences/reset
COOKIE: ...centralauth_User=Selenium+user .... commonswikiUserName=Selenium+user...


See also "Update how VisualEditor's experimental config works"  https://gerrit.wikimedia.org/r/#/c/84433/  which got deployed on beta on Sep 18th.


hashar@deployment-bastion:~$ mwscript eval.php --wiki=enwiki
> return $wgDefaultUserOptions['visualeditor-enable'] ;
0
>
$


So you could add an exception in CommonSettings-labs.php or InitialiseSettings-labs.php to override that value for beta and make sure VE is always opted in.
I am wondering, isn't it that the default is to disable the opt-in preference on enwiki now?   Thus if the Selenium test rest the user preference, it would end up opting out of VE :(

Can you try in your test to explicitly set the user preference?
VisualEditor opt-in preference unset again overnight PDT Sept 27.
I have just enabled VE manually in beta labs for Selenium_user. I suspect it will become disabled soon. 

Is it possible that the automatic run of update.php (or whatever updates the db) would un-set that preference?
The Selenium_user on enwiki has the following preferences right now:

["visualeditor-enable"]=> int(0)
["visualeditor-enable-experimental"]=>  int(1)
["visualeditor-betatempdisable"]=> int(0)

So VE is actually disabled.

Maybe some test is disabling the option while other set it?   Tests relying on VE should probably set the user preference through the API before the test run.
Yeah, this was a bad bug - bug 54341. We fixed it on Tuesday, and back-ported it to production yesterday, so this shouldn't happen again; sorry!

*** This bug has been marked as a duplicate of bug 54341 ***
After successfully section-editing <https://en.wikipedia.org/w/index.php?title=Black_Mail_%281973_film%29&section=2&veaction=edit> using VisualEditor, I land at <https://en.wikipedia.org/w/index.php?title=Black_Mail_%281973_film%29&section=2>.

This shouldn't happen. &section=2 doesn't do anything with the implicit &action=view.

Possibly related to bug 53089.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 53089 ***
When an image caption on the first line of a page contains the string "page " (including the trailing space) followed by any text the right half of the VisualEditor toolbar disappears (everything right of "more"). This includes the save button so edits cannot be saved (hence the "major" severity)

This is likely related to either bug 54379 (same symptoms) or bug 53312 (same trigger).

Comments on the VE/F report at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=574608525#Odd_one suggest this might be restricted to FireFox.

Minimal test: https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox4&oldid=574608905
Real-world example: https://en.wikipedia.org/w/index.php?title=Clarke,_Irwin_%26_Company&oldid=574526057

To reproduce:
1. Create a page with any image on the first line of page
2. Give the image a caption containing the string "page " (including the trailing space) followed by any text.
3. Save the page
4. Load the page in VE and observe the right half of the editing toolbar.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53312
https://bugzilla.wikimedia.org/show_bug.cgi?id=54379
As far as I can tell this was fixed when bug 53312 was fixed (and for the same reason).

*** This bug has been marked as a duplicate of bug 53312 ***
Can't reproduce on Chrome, looks like Ff issue.
There may be regression involved with this: The toolbar presented properly with the "page " string included in the first line for several VE edits over August and September, then the problem was observed Sept. 25.  No change in machine, OS, or browser at the time.
'coz I likes it.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #2)
> So there was ' Enable VisualEditor (only in the main and user namespaces)'
> and
> ' Temporarily disable VisualEditor while it is in beta' in preferences, and
> they were both unchecked.
Hah, I wasn't aware it was possible to have both preferences visible at once. That's probably a bug. Either way, you need to both have the "enable" box checked and have the "disable" box unchecked.
So there was ' Enable VisualEditor (only in the main and user namespaces)' and ' Temporarily disable VisualEditor while it is in beta' in preferences, and they were both unchecked.
It already does...
subhead shows "2" in the wrong place

seen in Firefox not in Chrome:  

choose some text and pick a headings format.  Subheads with numbers show the number below the selectbox.  see screen shot.

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

**Attached**: {F12017}
This was the Linux-wrong-width-of-fonts bug that was fixed a few months ago.
Created attachment 13378
shows '3' in the wrong place

**Attached**: {F12018}
visualeditor browser tests don't use MEDIAWIKI_PASSWORD, they still use secret.yaml.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 53579 ***
If you click to use LaTeX, the "math editor" option, you cannot cancel or escape out of input.  VisualEditor adds the <math></math> tags regardless and this can only be removed by saving and going to source.

Ideally, a cancel [X] or keyboard options should work to remove this.

https://www.mediawiki.org/w/index.php?title=User:Keegan_(WMF)/sandbox&action=history

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed a long time ago; sorry for the slow triage.
Sikuli ( http://www.sikuli.org ) is a tool for testing desktop interactions, such as mouse clicks and keyboard typing.

This tool is needed for testing typing in different languages, because the usual WebDriver tests are not able to generate proper keyboard events that completely emulate typing in advanced input methods for Japanese, Chinese and Indic scripts. We have many bugs in this area in the VisualEditor (e.g. Bug 52716), so we need proper regression testing.

This week I worked with Željko in the WMF office and we built a prototype test that uses Sikuli to test typing in Japanese:
https://gerrit.wikimedia.org/r/#/c/83966/

This works on Željko's laptop. The next step is to get it working on the virtual clients that run our continuous integration tests.

Thank you!

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
You can also find other people discussing using Sikuli with xvfb, e.g. https://github.com/jatalahd/SikuliRobotLibrary/wiki/Hints-and-Tips
>>! In T56393#1087507, @zeljkofilipin wrote:
> @Mattflaschen the last time I have checked sikuli web page, it explicitly said running headless is not supported. Maybe something changed in the meantime.

I think it depends on how you define "headless".  Sometimes it means "without anything related to Xorg whatsoever", but oftentimes it just means "without a normal X server installation and associated drivers" or "without a physical monitor/physical video card".

https://answers.launchpad.net/sikuli/+question/248704#comment-1 is quite clear that he got it working on Amazon Web Services (presumably Elastic Compute Cloud) and Jenkins.  This is pretty similar to our setup, except we use OpenStack instead of AWS (of course there are other differences, but there doesn't seem to be any unsolvable issue).

[xvfb](https://en.wikipedia.org/wiki/Xvfb) ([Jenkins plugin](https://wiki.jenkins-ci.org/display/JENKINS/Xvfb+Plugin)) is an established tool for this, so the Launchpad comment makes sense.
@Mattflaschen the last time I have checked sikuli web page, it explicitly said running headless is not supported. Maybe something changed in the meantime.
Did anyone investigate using it headless with Xvfb?  People have gotten this working with Linux and Jenkins (see for example https://answers.launchpad.net/sikuli/+question/248704#comment-1 ).  Their setup differs, but it shows a fully automated headless installation can work.
Change 165204 merged by Dzahn:
contint: Sikuli is no longer used anywhere

https://gerrit.wikimedia.org/r/165204
Change 165204 had a related patch set uploaded by Zfilipin:
contint: Sikuli is no longer used anywhere

https://gerrit.wikimedia.org/r/165204
Change 83966 abandoned by Zfilipin:
[WIP] [BrowserTest] Testing typing in VisualEditor

Reason:
Sikuli is not the way to go. We will investigate another tool.

https://gerrit.wikimedia.org/r/83966
Resolving. See comment #9 for details. Please reopen if you think Sikuli is the way to go.
After further investigation with Amir today, looks like Sikuli does not work with headless machines: "The system running Sikuli scripts or any apps using SikuliX features must have a real screen connected. So called headless systems are not supported (Java restriction)."

1: http://www.sikulix.com/quickstart.html
No, it is not really active yet.
Amir, this patch was merged, can this be closed?
Change 102141 merged by ArielGlenn:
contint: install libsikuli-script-java for browser tests

https://gerrit.wikimedia.org/r/102141
I have deployed the package libsikuli-script-java on the integration-selenium-driver.pmtpa.wmflabs instance.  The script is available as /usr/bin/sikuli

Could you craft a simple change that would attempt to run a single browser test using sikuli ?
Change 102141 had a related patch set uploaded by Hashar:
contint: install libsikuli-script-java for browser tests

https://gerrit.wikimedia.org/r/102141
Good news: sikuli has been packaged for Debian/Ubuntu. There is a package libsikuli-script-java which seems to provide the needed material:

http://packages.ubuntu.com/precise/all/libsikuli-script-java/filelist

I have no clue how to launch the tests though. Maybe we just have to use /usr/bin/sikuli ?
Change 83966 had a related patch set uploaded by Zfilipin:
[WIP] [Browser test] Testing typing in VisualEditor

https://gerrit.wikimedia.org/r/83966
Moving from CI to QA
VE allows editing text between <pre>...</pre> tags.
That is, you seem to be able, for example, to add working wikilinks and references. Once you save though, everything is rendered as wikicode, as in [[France]] and <ref>France</ref>, and of course is not clickable.
Thryduulf argues that "VE shouldn't show it as working if it won't work after saving".

--------------------------
**Version**: unspecified
**Severity**: normal
Content that is pre-formatted is not wrapped in <pre> tags but with space-indented-preformatting, which does work with wikitext structures.
In some templates (e.g. Template:Infobox fornminne) on Swedish Wikipedia, the image in it is shown in full size when you enter VE. 

Article: https://sv.wikipedia.org/wiki/S%C3%B6dermanlands_runinskrifter_305
Screencast: https://dl.dropboxusercontent.com/u/8363895/out-8.ogv

It does not behave like that for all templates though. In an article with Template:Kommunfakta is seems to work fine. E.g. https://sv.wikipedia.org/wiki/Botkyrka_kommun

Behaviour is observed from two different users and in both Firefox and Chromium.

--------------------------
**Version**: unspecified
**Severity**: major
Given the above comment and lack of further reports, I'm marking this as a duplicate of bug 51628

*** This bug has been marked as a duplicate of bug 51628 ***
Yes probably, I did did this change: 

https://sv.wikipedia.org/w/index.php?title=Mall:Infobox_fornminne&diff=prev&oldid=23823659

and now it seems to behave correctly in articles using that template. If I find the same error on other articles, I'll try to se if this is it first.
Could this be bug 51628? i.e. an image size being specified as e.g. "250px" in a field that is expecting e.g. "250"

It seems very likely but I can't read the Swedish source code to check.
<<[...] When you edit an old version of a page, you get the "save page" at the top of the page, but a "restore page" button instead of the "save page" button at the edit summary page, even if you have made changes in the older version (and thus aren't simply restoring it). Why we have two different buttons (save and restore), when we have only one name otherwise, isn't clear. Beneath the "restore page " button, the small text says "By clicking the "save page" button, you agree...". It doesn't indicate what I agree to by clicking the "restore page" button though... Fram (talk) 14:08, 19 September 2013 (UTC) >>

--------------------------
**Version**: unspecified
**Severity**: normal
Reminding the user that they are editing from an old version and restoring it (with any changes they have made) over the top of the current version of the page is intentional. WONTFIXing.
Try clicking the commons template in https://pl.wikipedia.org/wiki/Omega_Centauri?veaction=edit for an example. This bug appeared a while back, and seems to have regressed.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50970
*** This bug has been marked as a duplicate of bug 51933 ***
This is because we wrap generated content in a div for ease of replacement. Arguably we shouldn't.
**Author:** `renukaalurkar`

**Description:**
1)Log into http://en.wikipedia.beta.wmflabs.org
2)Go to your user page
3)Click on Edit beta tab
4)Click on More
5)Click Media
6)Enter santa claus, select a image from the selection of images
7)Select the image(the image is displayed in light blue)
8)Again click on More, then Media and select another image.

Expected:The original/old image should be replaced by the new image.
Observed: The new image is added and the original image is also displayed.

Another observation: Also, suppose there are 4 images Image1, Image2, Image3, Image4 one below the other. If Image2 is selected and I try to replace it with a new image, the new image appears in the place of Image3(instead of Image2).

Observed on Firefox and Chrome.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51033
Yes, confirming that this is intentional; closing as "WONTFIX". I agree that changing in line with bug 51033 would make more sense.
I can confirm this is the current behaviour, and that both points are due to the same reason: new images are inserted immediately after a selected image.

However I'm not sure that this behaviour is incorrect though as it is consistent with what happens when a user inserts media or a template with text selected (the template/media is inserted after the selection rather than overwriting it) - see bug 52460.

There is an open request for the media settings dialog to allow an image to be easily changed though (bug 51033), which I think is a better way to handle this.
Which is something like '' this '' as opposed to something like ''that''. Of course this is also true for the source editor, but since the wikilink tool already gets rid of spaces at the beginning or at the end of a word, I wanted to make sure this can/should also be done when just formatting it (and it's being requested).

--------------------------
**Version**: unspecified
**Severity**: normal
This will be fixed by bug 52037.

*** This bug has been marked as a duplicate of bug 52037 ***
User Steven at fr.wp asks that VE somehow recognizes and avoids that formatting is applied to spaces, since this results in ugly wikitext.
He suggests that spaces get highlighted so that people can easily recognize them; they might become black (when "bold" is applied) or grey (when "italics" is applied).
It is not easy, but you can create an empty wikilink with VE, https://en.wikipedia.org/w/index.php?title=Ascending_cholangitis&curid=5544827&diff=572776141&oldid=566427601 (I was able to reproduce that somehow, I think I just added the link to an empty space).
I can't imagine a situation where this is desirable or useful, please correct me if I am wrong.
Thanks.

--------------------------
**Version**: unspecified
**Severity**: normal
Merging with bug 37835.

*** This bug has been marked as a duplicate of bug 37835 ***
I updated Flow, Parsoid, and VisualEditor on toro. Adding a new post worked fine and brought up VE (after a long delay during which the text area should probably be locked) and I could WYSIWYG. \o/

But existing summary and some posts on http://toro.wmflabs.org/wiki/Special:Flow/Sandbox_2 that have images and links in them show stuff like
  <a rel="mw:WikiLink" href=".//Subpage" data-parsoid="{"stx":"simple","a":{"href":".//Subpage"},"sa":{"href":"/Subpage"},"dsr":[89,101,2,2]}">

suggesting Flow is having problems figuring out Parsoid HTML content.

I had set $wgFlowUseParsoid=true, now I think obsolete. I tried setting $wgFlowContentFormat='html', didn't seem to change behavior.

Firebug reported some XHR errors, possibly from some VE API call, but now not.

If the issue is existing content doesn't render right, this is fine to mark WONTFIX. We haven't promised data compatibility yet.

--------------------------
**Version**: master
**Severity**: normal
(In reply to comment #2)
> This is due to us previously not tracking what kind of content was stored in
> the field.
Yup, flow_revision rev_flags had just 'utf-8'.

> UPDATE flow_revision set rev_flags = CONCAT(rev_flags, ',html' ) WHERE
> rev_flags NOT LIKE '%html%' and rev_flags NOT LIKE '%wikitext%';

It worked! (now Toro has other errors...)
This is due to us previously not tracking what kind of content was stored in the field.  We now store a value of either 'html' or 'wikitext' in the content flags of the revision.  Not highly efficient, but the following query would fix the issue:


UPDATE flow_revision set rev_flags = CONCAT(rev_flags, ',html' ) WHERE rev_flags NOT LIKE '%html%' and rev_flags NOT LIKE '%wikitext%';

Untested, but should work.  Not sure if its worthwhile to build out the proper maintenance script to migrate.
Prioritization and scheduling of this bug is tracked on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/185
Images that have thumbnail sizes that are larger than the original should be rendered at the specified size, not the size of the original.

MediaWiki core does this, but somewhere between MediaWiki/Parsoid/VisualEditor the specified dimensions are lost.


For example, on https://www.mediawiki.org/wiki/VisualEditor/Team there are various uses of [[File:Wikimedia_Foundation_office_camera_shy.png]] (of which the full size is 140px). The thumbnail size on that page is 150px, and when viewing the page normally it is rendered at 150px (browser scales up from 140px non-thumb url), but when editing in VisualEditor the node has a width attribtue of 140 instead of 150.

--------------------------
**Version**: unspecified
**Severity**: normal
Re-checked on https://www.mediawiki.org/wiki/VisualEditor/Team - seems to be fixed.
Fixed in 2013.
Using FF 23.0.1 and Google Chrome 29.0.1547.66 m. Try edit w:en:Ondine's curse from a section #Treatment and prognosis. When logged the page shows to be in process, but never allowes editing. Why I log of editing via VE is possible within seconds.

--------------------------
**Version**: unspecified
**Severity**: blocker
OK, thank you.
This sounds like you have a gadget or user script that is breaking VisualEditor - I can make an edit successfully: https://en.wikipedia.org/w/index.php?title=Ondine%27s_curse&diff=573233549&oldid=565577837

If you disable your scripts and gadgets one-by-one you should be able to discover which one causes the problem, which will allow you to notify the author that their code is broken and needs to be fixed.

Marking as "INVALID" as gadgets are not tracked in Bugzilla but on-wiki. Sorry for the disruption - if you need a developer to explain to the offending gadget's author how to fix their code, please direct the author to us in IRC at #mediawiki-visualeditor, on e-mail or here on Bugzilla.
Sorry for mispeling. "When I log off..."
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
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.
This is going to give you a headache

{{Infobox ship begin}}
http://en.wikipedia.org/wiki/Template:Infobox_ship_begin
is used in 26840 pages. I provides styling for tables used to make infoboxes relating to ships. It is used like

{|{{Infobox ship begin}}
{{Infobox ship image
|Ship image=[[File:Whydah-model.jpg|300px]]
|Ship caption=The ''Whydah Gally'' (1716–1717)
}}
{{Infobox Ship Career
...
}}
|-
|Commanded by:
|Cap't. [[Lawrence Prince]]
...
|}

The template transcludes {{WPMILHIST Infobox style}} which provides CSS styling
class="infobox {{#if:{{{2|}}}|{{{2}}}}}" style="float: right; clear: right; width: 315px; border-spacing: 2px; text-align: left; font-size: 90%;"
So the table start tag and its styling are separate.

Unsurprisingly VE fails to edit pages with this template correctly. The following was reported at 
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=572065469

Open the article in the visual editor, e.g. by visiting https://en.wikipedia.org/wiki/Whydah_Gally?veaction=edit
Observe the article now leads with the out-of-place text 
 <nowiki>class="infobox " style="float: right; clear: right; width: 315px; border-spacing: 2px; text-align: left; font-size: 90%;"﻿</nowiki>
try to click "save page" but note that it is not active
make a trivial change so that "save page" is active.  Click it
Click "review your changes", not that it says that
<nowiki>{{Italic title}}{|{{Infobox ship begin}}</nowiki>
was replaced with
<nowiki>{{Italic title}}{{Infobox ship begin}}
{|{{Infobox ship begin}}</nowiki>

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 53139 ***
Thanks for filing the report. We should have a fix for the edit corruption bug soon (it will be fixed as part of a patch that Arlo is working on). More later on the other parts of the bug, once we discuss how to handle this.
This is a strange edit, where a new editor inserted an image in the image description of an existing image. A bug or something that should be able to be done? 

https://sv.wikipedia.org/w/index.php?title=Dry_Martini&diff=prev&oldid=23709630

--------------------------
**Version**: unspecified
**Severity**: normal
Yeah, this is valid (if odd) wikitext, and so VisualEditor supports it.
I can't think where off the top of my head, but I have seen small inline images in image descriptions at en.wp before. I think it was being used as a key for the main image or something like that.

It's not common, but its the sort of thing that could be useful on occasion.
**Author:** `lionel.allorge`

**Description:**
In an infobox, items are in a certain logical order, for exemple, the image item and the caption are next to each other but the VisualEditor sort them alphabetically making it more difficult to find them.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC
Indeed, this is not optimal. I'm marking this as a duplicate of bug 51930 which offers a way to sort this. Unfortunately that depends on bug 53608 which is presently not assigned to anyone to work on.

*** This bug has been marked as a duplicate of bug 51930 ***
Bug pic

Should this happen or shouldn't it?
Btw, steps:
1*  Install AssessmentBar from https://en.wikipedia.org/wiki/User:YuviPanda/AssessmentBar
2* Go to an article.
3* Go down to a picture or find the infobox.
4* Click on the picture or infobox (when it's halfway through the AssessmentBar) and it will highlight the AssessmentBar (treating it like a picture or an infobox) AND/OR Click on the part of the AssessmentBar where the picture or infobox is getting highlighted and the infobox or picture will get selected instead of the AssessmentBar.

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

**Attached**: {F11559}
Thanks.
As we don't track specific gadgets in Bugzilla this should likely be reported under https://en.wikipedia.org/wiki/User_talk:YuviPanda/AssessmentBar instead.

Closing as INVALID because Bugzilla is not the right place to follow up on user scripts, not because there is no bug that should get fixed.
Moving out of VisualEditor; in general, gadgets have to be made to work with VisualEditor and not the other way around.
CC'ing Yuvi as this covers AssessmentBar
Try to start a line with a wikilinked word as you might do in the source editor.

1) Typing the opening double square brackets will not trigger the no-markup warning.
2) The opening brackets will immediately disappear, the closing ones will stay.
3) When you reach the second closing bracket, VE will also add another one on the following line. (If instead of moving to step 4 you use the keyboard arrows around the word, you will not be able anymore to type something outside the brackets, and will need your mouse to place yourself outside of them).
4) Keep typing something instead, then press Enter: whatever you added is automatically copied to the next line, while the "third" square bracket is furtherly moved onto the next line.
5) Now add the brackets to an already existing word, correctly triggering the warning. Save anyway.
6) Review the changes. The brackets that triggered the warning did not trigger the nowiki tags as well. An opening one and a closing one are gone, and what is left is weird anyway. (This can also be triggered before saving by hitting Back Space, but I can't say where).
The brackets that we added in the first place are all gone, the duplicated text is gone as well, just a lonely closing bracket stands still.

https://it.wikipedia.org/w/index.php?title=Utente%3AElitre_%28WMF%29%2FSandbox_VE&diff=61362482&oldid=61361463

Reminds me of https://bugzilla.wikimedia.org/show_bug.cgi?id=53079, actually.
Thanks.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57207
I think this may have been a cacheing error? I can't reproduce, but it feels a lot like bug 53079, yes.
A user at it.wp reports that he could not successfully replace a picture with this edit https://it.wikipedia.org/w/index.php?title=Castello_di_Serravalle_%28Bosa%29&diff=61339995&oldid=61339964, although he managed to do so on other occasions, so he knows how it works.
He just replaced Bosa Castle.jpg with Veduta del Castello.JPG, and correctly previewed the latter.
But upon saving, the pic was gone - the field is empty. He tried again later, and managed to reproduce this behavior.
Other users, including me, are not able to reproduce this.
He's using Chrome with Snow Leopard. Thanks.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=62366
I can't quite understand this bug report - the user edited the template, changed the parameter for the image name, but when they applied the changes, the parameter was removed (and so no image)?

I'm going to mark as WORKSFORME, but please re-open if anyone can reproduce.
en.wp user Fram reports:
"When I add something that VE decides needs "nowiki", it usually gives the warning "Wikitext markup detected". However, when I add <references/> to the bottom of a page, he wraps it in "nowiki"s, but no warning appears (while it does work with e.g. {{reflist}})"

My testing at https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox2&diff=571756019&oldid=570197356 shows that <i> and <small> also get nowikied without triggering the warning.

<!-- --> neither triggers the warning nor gets nowikied. I am about to start a discussion about whether that is desired or not.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56213
This is intentional; adding a complete set of wikitext detection would be very burdensome (i.e. slow VE down for users) without adding a lot of value.

People who know complex things like HTML or advanced wikitext like <references /> will quickly learn that it doesn't work; this functionality is an aide-memoire for  newbies and rare users.

Marking as WONTFIX, but happy to discuss.
The German template for quotes:

https://de.wikipedia.org/wiki/Vorlage:Zitat

eats refs, or rather their display at the end of the article, if the refs are inserted in it & the article is loaded in VE. Example articles:

https://de.wikipedia.org/wiki/Arvo_P%C3%A4rt -> ref 5 & 8

https://de.wikipedia.org/wiki/The_Rolling_Stones -> 26, 123-125

https://de.wikipedia.org/wiki/Chick_Corea -> ref 12

Report:

https://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=122231626#Einzelnachweise_am_Artikelende_werden_im_VE_nicht_angezeigt

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50474
Merging this with bug 50474 which I have managed to determine that this is the same as that.

*** This bug has been marked as a duplicate of bug 50474 ***
Updates:

Rolling Stones: The section Discografie

https://de.wikipedia.org/wiki/The_Rolling_Stones#Diskografie

includes another article inserted as template:

https://de.wikipedia.org/wiki/The_Rolling_Stones/Disko-_und_Videografie

However, the article isn't displayed in full but only relevant parts, picked by  onlyinclude-tags.

Shine a Light: The issue not included in a template is caused by something VE apparently can't handle in spelling out the ref name but Wikicode can: "_" vs " ":

https://de.wikipedia.org/w/index.php?title=Shine_a_Light&diff=prev&oldid=122747897

The other two are eaten by the template, i.e. the same source is also referred to in refs outside the template and VE simply doesn't count the template-inserted refs.
This looks like a side effect of the underlying problem in bug 50474.
Chances are this issue is systemic; three more examples:

1) Info box for movie articles:

https://de.wikipedia.org/wiki/Vorlage:Infobox_Film

includes three refs in 

https://de.wikipedia.org/wiki/Shine_a_Light

and they all get eaten if the entry is loaded in VE.

2) Info box for corporate entities:

https://de.wikipedia.org/wiki/Vorlage:Infobox_Unternehmen

see the first four refs in 

https://de.wikipedia.org/wiki/Sony

3) https://de.wikipedia.org/wiki/Vorlage:Infobox_Chemikalie

eats the two included refs in:

https://de.wikipedia.org/wiki/Magnesiumcarbonat
from the report:

* a) {{<ref>source a</ref>}} -> eats ref completely

in all other reported cases:

* b) {<ref>source b</ref>} 
* c) {{<ref>source c</ref>
* d) {<ref>source d</ref> 
* e) {{<ref>source a</ref>}.

VE tells the user once "This is Wikitext" but then carries on; see test page:

https://de.wikipedia.org/w/index.php?title=Benutzerin:Miss-Sophie/Spielwiese&oldid=122231700
See https://en.wikipedia.org/w/index.php?title=Epigram_%28programming_language%29&oldid=567048374&veaction=edit and click "save" (note that save box warns about corruption) and then "view changes" (ignoring the changes I have since made). The pre block has been corrupted.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC
*** This bug has been marked as a duplicate of bug 54083 ***
A De.WP user suggested to include a preview for the edit summary. Report:

https://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=122207411#Vorschau_f.C3.BCr_Zusammenfassung_und_Quellen

--------------------------
**Version**: unspecified
**Severity**: enhancement
*** This bug has been marked as a duplicate of bug 42139 ***
See https://it.wikipedia.org/w/index.php?title=Bisanzio_Lupis&diff=61160806&oldid=51778070 .

When creating a section for references and adding the relevant tag,
it will suppress the Related Articles section - just the heading, not the content.

I reproduced it easily in my sandbox by just adding the contents that you can see in the diff above.
Note that it is not related to the reference being added in the same edit; here for instance https://it.wikipedia.org/w/index.php?title=Utente%3AElitre_%28WMF%29%2FSandbox_VE&diff=61285258&oldid=61285224 it was added previously.

Thanks.

--------------------------
**Version**: unspecified
**Severity**: normal
Making resolved instead because it probably //was// a problem in 2013 :)
Making resolved instead because it probably //was// a problem in 2013.
Yup, can't reproduce this one.
Closing task as declined as per last two comments as nobody managed to reproduce.

Please reopen if this problem still happens and provide an URL/link to an example. Thanks!
> When creating a section for references and adding the relevant tag,

What I tried:
Write the text "Notes" right above "Voci correlate", mark that text, choose "Heading" from the formatting dropdown, then add a reference via "Cite > Basic" somewhere in the text, then click below the "Notes" heading and choose "Insert > References list" in VE.

No issues either. Let's close this soon if noone can reproduce (already set to Stalled status).
I've attempted to reproduce the two test cases in a sandbox on the Italian Wikipedia. In both cases ([[https://it.wikipedia.org/w/index.php?title=Utente:Neil_P._Quinn/test&diff=prev&oldid=70691767|full]] and [[https://it.wikipedia.org/w/index.php?title=Utente:Neil_P._Quinn/test&diff=next&oldid=70691826|reduced]]), adding the section heading and references list worked correctly.
The Wikitext warning is triggered in some circumstances without the user having entered Wikitext. The one cause I can reliably reproduce is where there is nowikied markup on the page from a previous edit.

To reproduce:
1. Load https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox3&oldid=571089410&veaction=edit
2. Click anywhere on the last line of Section number two (the line that contains "[[Manhatan]]" and an ISBN, both of which are enclosed in nowiki tags). 

It seems that the warning is triggered by the existence of wikitext markup in the VE editing surface, rather than by its addition.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 51751 ***
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
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).
Gah, sorry, wrong bug.
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 ***
In some odd circumstances the text immediately following an image is duplicated. You can see the effect in
http://en.wikipedia.org/w/index.php?title=Danny_Nalliah&oldid=570830443&veaction=edit
where the text '''Daniel (Danny) Nalliah''' is duplicated. 

To make things more confusing it does not occur for every revision 
http://en.wikipedia.org/w/index.php?title=Danny_Nalliah&oldid=570591483&veaction=edit
works fine.

To make things thoughly weird in this revision in my sandbox
http://en.wikipedia.org/w/index.php?title=User:Salix_alba/sandbox&oldid=570839025
the text '''Daniel (Danny) Nalliah''' does not appear. Yet it magically appear in VE
http://en.wikipedia.org/w/index.php?title=User:Salix_alba/sandbox&direction=prev&oldid=570839025&veaction=edit

This issues is discussed at 
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Still_looks_like_VE_Feedback_to_me

--------------------------
**Version**: unspecified
**Severity**: normal
Cannot reproduce the problem either with the given links and Firefox 35...
Assuming that this has magically fixed itself.
Hence closing this ticket as DECLINED as no-one else could reproduce so far, unfortunately.

@SalixAlba: If you can still reproduce this problem, please provide browser information. (Also, testing with the browser and having add-ons / extensions disabled or such might be welcome.)
Cannot reproduce. Was this fixed at some point?
I cannot paste text into the edit summary with Ctrl+V or right click and paste when I use Chromium Version 28.0.1500.71 Ubuntu 13.04 (28.0.1500.71-0ubuntu1.13.04.1). Nothing happens. It works fine in FireFox though.

--------------------------
**Version**: unspecified
**Severity**: normal
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.
en.wp user ToE further reports:
Upon upgrading to Google Chrome: 29.0.1547.76 (Official Build 223446) m, JavaScript V8 3.19.18.23, paste into edit summary works properly.
en.wp user ToE reports:
[this bug] also applies to Google Chrome, version "29.0.1547.66 (Official Build 220848) m", JavaScript V8 3.19.18.19, running on Windows 7 Home Premium, Service Pack 1. Paste into edit summary works fine on the same machine in Firefox version 23.0.1.
I'm observing the exact same problem in the same Chromium version on Ubuntu 13.04 (no error messages in the JavaScript console, works fine in Firefox).
**eliashedberg** wrote:

I had the same (or a similar) problem in Chrome 29.0.1547.62 under Mac OS X 10.6.8: when pasting the string "Lavoslav Ružička" into the edit summary the page behind the summary jumped down and back up (or the other way around) but there was no text inserted into the edit summary.

I can recreate the failed paste action in the edit summary of my sandbox, but the text behind the edit summary doesn’t move (potentially because that article is too short).

I can recreate the failed paste action with other strings too (in Chrome), i.e. no pasting works, no matter what string I try to paste.

In Firefox, pasting into the edit summary works fine (Firefox 23.0.1, also under OS X 10.6.8).
Hm, how do I find the browser's error console? If it's F12 and Console, then no, no messages there. 

I noticed that if the page I was editing is not scrolled to the top, when I try to paste, it behaves as if I press arrow up.
Is there any kind of output in the browser's error console when you try?
We have moved ULS and VisualEditor tests to their repositories. Delete the code from browsertests repository.

--------------------------
**Version**: unspecified
**Severity**: normal
Reopening until we decide if search.feature file should:

- stay in browsertests repo
- be moved to CirrusSearch repo
- be deleted
Change 88992 merged by Cmcmahon:
Flow tests are moved to Flow repository

https://gerrit.wikimedia.org/r/88992
Chris, did we move all tests from browsertests repository to relevant repositories? Should this bug be resolved?

The only remaining feature file that I see in browsertests repository that should be either deleted or moved to CirrusSearch repository is search.feature. Or, should we leave it in browsertests repository?
Change 88992 had a related patch set uploaded by Zfilipin:
Flow tests are moved to Flow repository

https://gerrit.wikimedia.org/r/88992
At the moment we have similar setup code for browser tests in 6 repositories:

https://github.com/wikimedia/qa-browsertests
https://github.com/wikimedia/mediawiki-extensions-CirrusSearch
https://github.com/wikimedia/mediawiki-extensions-MobileFrontend
https://github.com/wikimedia/mediawiki-extensions-UniversalLanguageSelector
https://github.com/wikimedia/mediawiki-extensions-VisualEditor
https://github.com/wikimedia/mediawiki-extensions-Wikibase

Figure out a way how to reduce code duplication. We should probably create a Ruby gem.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 53579 ***
README.md[1] file has information about Selenium tests in

https://github.com/wikimedia/mediawiki-extensions-MobileFrontend

Add links to:

https://github.com/wikimedia/mediawiki-extensions-CirrusSearch
https://github.com/wikimedia/mediawiki-extensions-UniversalLanguageSelector
https://github.com/wikimedia/mediawiki-extensions-VisualEditor
https://github.com/wikimedia/mediawiki-extensions-Wikibase

1: https://github.com/wikimedia/qa-browsertests/blob/master/README.md

--------------------------
**Version**: unspecified
**Severity**: normal
Change 90562 merged by jenkins-bot:
Relevant links

https://gerrit.wikimedia.org/r/90562
Change 90562 had a related patch set uploaded by Zfilipin:
Relevant links

https://gerrit.wikimedia.org/r/90562
.ruby-gemset and .ruby-version should be removed and RVM setup should be moved to Gemfile[1].

Repositories that are doing it right:
https://github.com/wikimedia/mediawiki-extensions-UniversalLanguageSelector
https://github.com/wikimedia/mediawiki-extensions-VisualEditor

Repositories that should be updated:

https://github.com/wikimedia/mediawiki-extensions-CirrusSearch
https://github.com/wikimedia/mediawiki-extensions-MobileFrontend
https://github.com/wikimedia/mediawiki-extensions-Wikibase
https://github.com/wikimedia/qa-browsertests

1: https://github.com/wikimedia/mediawiki-extensions-UniversalLanguageSelector/blob/master/tests/browser/Gemfile#L1-L2

--------------------------
**Version**: unspecified
**Severity**: normal
All repositories that have Selenium tests in Ruby now use mediawiki-selenium gem.
Change 87552 merged by jenkins-bot:
Moving shared code to mediawiki-selenium Ruby gem

https://gerrit.wikimedia.org/r/87552
Change 87581 merged by jenkins-bot:
[browser test] Moving shared code to mediawiki-selenium Ruby gem

https://gerrit.wikimedia.org/r/87581
Change 87563 merged by jenkins-bot:
Moving shared code to mediawiki-selenium Ruby gem

https://gerrit.wikimedia.org/r/87563
Change 87125 merged by Cmcmahon:
Moving code used in multiple repositores to a Ruby gem

https://gerrit.wikimedia.org/r/87125
Change 90560 had a related patch set uploaded by Zfilipin:
WIP Moved confing files from qa/browsertests repository

https://gerrit.wikimedia.org/r/90560
Change 90559 had a related patch set uploaded by Zfilipin:
WIP Moved config files to mediawiki/selenium repository

https://gerrit.wikimedia.org/r/90559
Change 88010 merged by Tobias Gritschacher:
Moving shared code to mediawiki-selenium Ruby gem

https://gerrit.wikimedia.org/r/88010
*** Bug 53581 has been marked as a duplicate of this bug. ***
*** Bug 54600 has been marked as a duplicate of this bug. ***
Change 88010 had a related patch set uploaded by Zfilipin:
Moving shared code to mediawiki-selenium Ruby gem

https://gerrit.wikimedia.org/r/88010
Change 87158 merged by jenkins-bot:
Moving shared code to mediawiki-selenium Ruby gem

https://gerrit.wikimedia.org/r/87158
Change 87542 merged by jenkins-bot:
Moving shared code to mediawiki-selenium Ruby gem

https://gerrit.wikimedia.org/r/87542
Change 87581 had a related patch set uploaded by Zfilipin:
Moving shared code to mediawiki-selenium Ruby gem

https://gerrit.wikimedia.org/r/87581
Change 87563 had a related patch set uploaded by Zfilipin:
Moving shared code to mediawiki-selenium Ruby gem

https://gerrit.wikimedia.org/r/87563
Change 87552 had a related patch set uploaded by Zfilipin:
Moving shared code to mediawiki-selenium Ruby gem

https://gerrit.wikimedia.org/r/87552
Change 87542 had a related patch set uploaded by Zfilipin:
Moving shared code to mediawiki-selenium Ruby gem

https://gerrit.wikimedia.org/r/87542
For more information see http://lists.wikimedia.org/pipermail/qa/2013-October/000509.html
Change 87158 had a related patch set uploaded by Zfilipin:
Moving shared code to mediawiki-selenium Ruby gem

https://gerrit.wikimedia.org/r/87158
Change 87125 had a related patch set uploaded by Zfilipin:
Moving code used in multiple repositores to a Ruby gem

https://gerrit.wikimedia.org/r/87125
Change 86838 merged by jenkins-bot:
Updated ULS repository to the latest version of shared test files

https://gerrit.wikimedia.org/r/86838
Change 86845 merged by Cmcmahon:
Updated the repository to the latest version of shared test files

https://gerrit.wikimedia.org/r/86845
Change 86845 had a related patch set uploaded by Zfilipin:
Updated the repository to the latest version of shared test files

https://gerrit.wikimedia.org/r/86845
Change 86838 had a related patch set uploaded by Zfilipin:
Updated ULS repository to the latest version of shared test files

https://gerrit.wikimedia.org/r/86838
Change 82039 merged by Tobias Gritschacher:
Updated test configuration to the latest version

https://gerrit.wikimedia.org/r/82039
Change 82035 merged by jenkins-bot:
Updated test configuration to the latest version

https://gerrit.wikimedia.org/r/82035
Change 82034 merged by jenkins-bot:
Updated test configuration to the latest version

https://gerrit.wikimedia.org/r/82034
Change 82033 merged by Cmcmahon:
Removed unused Rake Ruby gem

https://gerrit.wikimedia.org/r/82033
Change 82032 merged by Cmcmahon:
Removed unused HTML Cucumber formatter

https://gerrit.wikimedia.org/r/82032
Change 82039 had a related patch set uploaded by Zfilipin:
Updated test configuration to the latest version

https://gerrit.wikimedia.org/r/82039
Change 82035 had a related patch set uploaded by Zfilipin:
Updated test configuration to the latest version

https://gerrit.wikimedia.org/r/82035
Change 82034 had a related patch set uploaded by Zfilipin:
Updated test configuration to the latest version

https://gerrit.wikimedia.org/r/82034
Change 82033 had a related patch set uploaded by Zfilipin:
Removed unused Rake Ruby gem

https://gerrit.wikimedia.org/r/82033
Change 82032 had a related patch set uploaded by Zfilipin:
Removed unused HTML Cucumber formatter

https://gerrit.wikimedia.org/r/82032
Change 81929 merged by Cmcmahon:
Updating shared code to the latest version

https://gerrit.wikimedia.org/r/81929
Change 81929 had a related patch set uploaded by Zfilipin:
Updating shared code to the latest version

https://gerrit.wikimedia.org/r/81929
All repositories:

https://github.com/wikimedia/qa-browsertests
https://github.com/wikimedia/mediawiki-extensions-CirrusSearch
https://github.com/wikimedia/mediawiki-extensions-MobileFrontend
https://github.com/wikimedia/mediawiki-extensions-UniversalLanguageSelector
https://github.com/wikimedia/mediawiki-extensions-VisualEditor
https://github.com/wikimedia/mediawiki-extensions-Wikibase

Files to update:

config/config.yml
config/cucumber.yml
features/support/env.rb
features/support/sauce.rb
Gemfile
Gemfile.lock
README.md
Who gets e-mail notification is documented in jobs.md[1]. At the moment Chris and I get notification for all jobs. Michelle is added for MobileFrontend, Rachel and James for VisualEditor.

Nik Everett should be notified for CirrusSearch, Amir and Niklas for UniversalLanguageSelector.

1: https://github.com/wikimedia/qa-browsertests/blob/master/docs/jobs.md

--------------------------
**Version**: unspecified
**Severity**: normal
Change 88998 merged by Cmcmahon:
Updated Jobs and documentation who gets e-mail notification when a Jenkins job fails

https://gerrit.wikimedia.org/r/88998
Change 88998 had a related patch set uploaded by Zfilipin:
Updated Jobs and documentation who gets e-mail notification when a Jenkins job fails

https://gerrit.wikimedia.org/r/88998
I could not replicate this in LTR wikis (en.wiki or MediaWiki.org) but I suspect this is not so much ltr/rtl but floating behavior of the templates and images.

See example here:
https://he.wikipedia.org/wiki/%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9%D7%AA:Mooeypoo/%D7%A2%D7%95%D7%A8%D7%9A_%D7%97%D7%96%D7%95%D7%AA%D7%99/%D7%91%D7%93%D7%99%D7%A7%D7%95%D7%AA_%D7%95%D7%9E%D7%A9%D7%97%D7%A7%D7%99%D7%9D?veaction=edit

The top two images are regular images (not templates) - they are perfectly editable if you remove the template at the top. They got their shielded status after I inserted that template.

Steps to reproduce:
1. Edit a page
2. Insert some image (or more) to top
3. Save page
4. Edit again, insert template "{{עליות}}" just above the images. 
5. Save.
6. Edit again. Observe: The images jumped to the left (wrong float side) and are now uneditable. 
7. Interesting fact: Remove the template and save, then go back into the editor and the images are still uneditable.

--------------------------
**Version**: unspecified
**Severity**: normal
This seems to be fixed now with the change of images and the way we render shields.
Correction: images jump to the *right* (wrong floating side in RTL wikis) not left. Apparently my sense of directions needs its own bug report.
If you open https://fr.wikipedia.org/w/index.php?title=Anna_Mouglalis&oldid=95468238&veaction=edit you'll notice a weird order of paragraphs. This is due to an extra space in the ref tag for the second reference. VE might probably autocorrect similar situations.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 52430 ***
To reproduce:

1. Go to this page: https://he.wikipedia.org/wiki/%D7%90%D7%9C%D7%9B%D7%A1%D7%A0%D7%93%D7%A8_%D7%94%D7%92%D7%93%D7%95%D7%9C
2. Edit the infobox at the left side. 
3. Behold! Some parameters appear both at the left panel (used) and also on the right panel (unused). Specific example, look for the parameters "בן זוג" and "בת זוג" 
4. If you click the parameter "בת זוג" for example, on the left side (the used one) you will see data. If you click the one on the right side, it appears with empty textbox as if it's new.
5. Click on the right side (as if to add param again) on "בת זוג" 
6. Click again and again -- the parameter will keep being added to the list on the left in duplicates.

And if the page is saved, the parameter is now completely removed.


This has happened specifically in the hewiki but might be related to more than just RTL.

--------------------------
**Version**: unspecified
**Severity**: normal
This works for me on hewiki and local on rtl settings. If anyone discovers this anew, please reopen.
This seems to be fixed now.
Currently whenever a user enters a link when no text is selected the first character of the displayed link is always capitalised. This is often incorrect, e.g. in the middle of a sentence or for articles like [[iPhone]] or [[grep]].

Especially until bug 50678 is fixed, correcting this is not at easy or intuitive.

So, at least until bug 48789 and bug 50945 are fixed and the display text is settable in the dialog, and probably beyond that, it would be best if the displayed link used the same case as the search term entered. i.e.

User entry ->  wikitext equivalent of desired output
Green   ->  [[Green]]
green   ->  [[green]]
iPad    ->  [[iPad]]
HAMmer  ->  [[Hammer]]
london  ->  [[london]]

Yes, this will result in some wrong captialisations, but no more than at present and will only be temporary (as noted above)

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50678
https://bugzilla.wikimedia.org/show_bug.cgi?id=50745
*** This bug has been marked as a duplicate of bug 50452 ***
This is somewhat related to bug 50321.

Steps to reproduce:

1. Open your own sandbox/userpage (not a page in the mainspace) in VisualEditor.
2. Add a link to a word ("xxx").
3. Control-click/right-click/command-click the new link to open the link in a new tab or new window.
4. Discover that VisualEditor has sent you to an invalid URL:  http://en.wikipedia.org/w/Xxx or http://en.wikipedia.org/wiki/User:Whatamidoing_(WMF)/Xxx

--------------------------
**Version**: unspecified
**Severity**: normal
This is bug 48915 although the bug title "VisualEditor: Respect Parsoid's <base>" describes the solution not the effect so I'm not surprised you didn't find it.

*** This bug has been marked as a duplicate of bug 48915 ***
Requested by James Forrester at QA mailing list:

http://lists.wikimedia.org/pipermail/qa/2013-August/000339.html

--------------------------
**Version**: unspecified
**Severity**: normal
Change 81486 merged by jenkins-bot:
Moved VisualEditor Selenium tests from browsertests repository

https://gerrit.wikimedia.org/r/81486
Change 81490 merged by Cmcmahon:
Added support for running VisualEditor tests to Jenkins job template

https://gerrit.wikimedia.org/r/81490
Change 81490 had a related patch set uploaded by Zfilipin:
Added support for running VisualEditor to Jenkins job template

https://gerrit.wikimedia.org/r/81490
Resolved in https://gerrit.wikimedia.org/r/#/c/81486/
Change 81486 had a related patch set uploaded by Zfilipin:
Moved VisualEditor Selenium tests from browsertests repository

https://gerrit.wikimedia.org/r/81486
**Author:** `molly.white5`

**Description:**
Only show the edit summary input box after the user clicks "save" (sort of like in the VisualEditor).

--------------------------
**Version**: unspecified
**Severity**: normal
**molly.white5** wrote:

See above comment.
**mr.heat** wrote:

(In reply to comment #0)
> Only show the edit summary input box after the user clicks "save"

But clicking "save" leaves the editor and reloads the page. If the edit summary is hidden and only shown after you clicked "save" you will see it only for a fraction of a second and not be able to enter anything.

I guess you are suggesting to block the first click on the "save" button. First click shows the edit summary. Second click saves. I don't think this is useful for two main reasons:

1. I want to be able to type something in the summary field while I'm still editing. Hiding the field removes this feature. I can't use it when I want. It forces me to remember everything I did and recap it in the end. This will lead to more empty and less descriptive summary lines.

2. If I click a button labeled "save" I expect it to save and not to do something completely different. If you want to have this as an opt-in feature you can use the existing "Prompt me when entering a blank edit summary" setting or check my script [[de:User talk:TMg/forceEditSummary.js]]. Both do not hide the edit summary but block the "save" button one time if you forgot to enter a summary. The setting is server-side, my script is client-side and therefor a lot faster.

I suggest to close this as "works as expected".
At the moment there doesn't appear to be a way to replace media - that is, to click on a media element, and select a different piece of media for that element. That's not a big deal at the moment, but we're going to move to a world where media settings are more complex - where alignment can be specified, referencing can be specified and permitted, so on and so forth.

The result of this is that media elements will have a lot of data associated with them - media it's pretty hard to type out again if you find that the image (or video, or...whatever) needs to be replaced. It would be good to have a way of replacing images without losing the associated caption, size and alignment.

--------------------------
**Version**: unspecified
**Severity**: normal
I *knew* it's gotta be a dupe. ;)

*** This bug has been marked as a duplicate of bug 51033 ***
We need a search-and-replace feature in VisualEditor. This seacrh box should also support ULS

--------------------------
**Version**: unspecified
**Severity**: enhancement
Hi Pavanaja. Thanks for taking the time to report this!
This particular problem has already been reported into our bug tracking system, but please feel free to report any further issues you find.

*** This bug has been marked as a duplicate of bug 48368 ***
There should be a facility in VisualEditor for creating new table or edit an existing table

--------------------------
**Version**: unspecified
**Severity**: enhancement
Indeed there should be such a feature, and one has been requested at bug 52181 so I'm marking this as a duplicate.

*** This bug has been marked as a duplicate of bug 52181 ***
[New feature => setting the "Severity" field to "enhancement". 
Feel free to do so yourself when filing a report.]
User report:
<<So I put a space and then a backspace.  Go to save, review changes to check and make sure it is a null edit, then it goes to this "processing" dialogue but then it shows "Could not start the review because your revision matches the latest version of this page."  So then I press the little back link on the dialogue, but it just goes back to the processing dialogue.  If the page is small, the processing is really quick, so before I can even press back again, it goes back to the "Could not start" warning message.  Even if I do manage to press the back a second time quickly, it will only stay at the save dialogue for a split second and then again bring me to the warning message, although ''then'' pressing back does take me to the save dialogue securely.  FF 23.0.1 Win7.>>

I managed to reproduce this on Chrome as well, so which is the intended left button behaviour?
Thanks.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 53313 ***
**Author:** `ryuch`

**Description:**
VE not can be enabled by options in preferences for beta testing.
When I click 'edit' on an article, the progress bar appear but does not finish initialization.

--------------------------
**Version**: unspecified
**Severity**: normal
This bug appears to be fixed as I can see VE edits happening in the recentchanges feed.

https://ko.wikipedia.org/wiki/special:recentchanges?days=30&tagfilter=visualeditor
**ryuch** wrote:

Sorry, a critical typo I sent. 
VE "now" can be enabled by options in preferences for beta testing.
cucumber features/visual_editor_anon.feature:5 # Scenario: Basic edit fails 
because VisualEditor these days shows an introductory disclaimer:

  This is our new, easier way to edit. It's still in beta,
  which means you might find parts of the page you can't edit...
and so it fails with
  expected "You are not currently logged in. 
which isn't visible until you dismiss the popup.

I think the same explains a
  timed out after 5 seconds, Element was not visible in 5 seconds
that I'm getting in the similar
cucumber features/visual_editor_logged_in.feature:5 # Scenario: Basic edit
after applying gerrit 80709.

The popup is in a div containing an iframe containing more divs until class="ve-ui-mwBetaWelcomeDialog-content", and then tests have to click outside it to dismiss it; and some day it will go away.

Instead it seems better to set the ve-beta-welcome-dialog cookie to 1 upon visiting the site, which will turn off this disclaimer dialog.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
fixed
Chris, this is fixed, right? Is there anything left here to do? Should we close the bug?
Honestly, I would rather that VE behave the same on beta, test2wiki, and production. Preferably at more or less the same time.
(In reply to comment #5)
> Should this be closed since 80709 is merged into master?
No, that's a different problem breaking VE tests.

Please can you change the VE tests to have an
    If there is an introductory welcome message
      then dismiss it
stanza?
Should this be closed since 80709 is merged into master?
(In reply to comment #3)
> Why is VE using an iframe for this?  (and using iframes in general?)
For the welcome message, we don't technically need to use an iframe. In that case we just use an iframe because all of our other dialogs use iframes.

In general, we use iframes for dialogs and inspectors because we need to be able to have two selections at the same time. For instance, when you inspect a link, the link is selected, but you also have a cursor in the text field in the inspector. Because you can only have one selection in any given HTML document, we need the edit surface and the text field to be in different documents, and so we put the text field (along with most of the rest of the inspector) in an iframe.

Dialogs use iframes for similar reasons: when the user interacts with UI elements in the dialog, that needs to not affect their selection in the edit surface. The welcome dialog doesn't have any elements that can steal the focus or selection so it's not an issue there, but since it uses the generic dialog code it's automatically in an iframe.
When it shows up on test2 and/or beta I'll dismiss it in the test. 

Why is VE using an iframe for this?  (and using iframes in general?)
Also note that the beta welcome message will be rolled out to all wikis soon.
I've been running these tests against test2wiki, which doesn't have that problem.  https://gerrit.wikimedia.org/r/#/c/80709/ should make it possible to run these against beta labs now that VE seems to be deployed there reliably
User report following:
<<If I start with a blank page, type in "<br>", select the entire text, press the link icon, select say "France" as the link, upon exiting the link dialog I am left with a link to [[France]] but the anchor is shortened to "<b".</nowiki>  I don't get any "Wikitext markup detected" warning. >>
This is true for other tags as well (I tried with <b>).

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed ages ago; sorry for not mentioning it here. (Please re-open if you can reproduce.)
(Sorry, that </nowiki> shouldn't be there, of course.)
While I was fixing a simple grammatical error, VE threw in a > sign at the start of a template further down the page thus breaking the template.

https://en.wikipedia.org/w/index.php?title=Tesla_Model_S&diff=next&oldid=569876875

--------------------------
**Version**: unspecified
**Severity**: normal
I /believe/ that this was a Parsoid selser bug, long-since fixed; marking as WORKSFORME for now.
If I focus on the save button using [tab] from textarea, [enter] don’t save the page.

Apparently the focus goes on the <div role="button"> while the click event is listened on the span.

--------------------------
**Version**: unspecified
**Severity**: normal
No, this bug as filed was indeed a duplicate of bug 51918. There's the subsequently-filed bug 62337 which tracks your comment.

*** This bug has been marked as a duplicate of bug 51918 ***
I'm reopening this rather than creating a new one, because it's not exactly a problem with the tab order.

Here's how to reproduce this:  Open the Save dialog.  Type your edit summary.  Press the tab key seven times.  Everything tabs beautifully, in exactly the order I wish for.  Really:  Bug 51918 is resolved as far as I'm concerned.  The problem is not the tab ORDER.  

The problem is that when I have successfully tabbed to the Save button, the Save button is BROKEN.  The Save button is selected.  There is a lovely blue box around it.  But it refuses to actually save the page when you press return.  It just sits there until, having pressed return twenty or thirty times, gone away in the hope that the server is just being slow, come back and hit the return key another dozen times or so, you finally conclude that it is not actually possible to save the page without taking your hands off the keyboard.  

That's the problem:  "Unable to use save button using keyboard".  No amount of rearranging the deck chairs, I mean the tab order, is going to solve this problem.  The button itself is broken, not the tab order.

The tick boxes for "Minor edit" and "Watch this page" can be tabbed to and toggled with the spacebar.  The links to the GFDL and other license stuff can be tabbed to and opened by pressing return.  But the "Review your changes" and "Save" buttons are broken.  There is no way to "click" those buttons without actually using a mouse/trackpad.
Merging with bug 51918.

*** This bug has been marked as a duplicate of bug 51918 ***
**swalling** wrote:

I also have this issue in Chrome 29 on OSX. Tabbing to Save page then hitting Enter does nada.
Seems I had written about it in an unrelated bug, sorry. This happens on itwp: in order to do this
http://it.wikipedia.org/w/index.php?title=DNasi_attivata_da_caspasi&diff=60101664&oldid=60089990
I had to delete the word and link it back again. Our guidelines about style
require pages in that section to appear with the capital letter, so we need to be able to fix that easily.

It is also reported on en.wp, the user states <<When trying to correct a lower-case letter to a capital letter at the beginning of a link, I deleted the lower-case letter and found I couldn't type a capital letter and have it become part of the link, nor could I seem to extend the link over the capital. Eventually, I typed the capital after the lower-case letter and then deleted the lower-case letter. It might be good to have some way to extend a link over adjoining letters/words/text. Mount Flatten (talk) 05:31, 22 August 2013 (UTC) >>
Thanks.

ps. Might be related to https://bugzilla.wikimedia.org/show_bug.cgi?id=50745 .

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50745
*** This bug has been marked as a duplicate of bug 50678 ***
*** Bug 53193 has been marked as a duplicate of this bug. ***
pps. Also to https://bugzilla.wikimedia.org/show_bug.cgi?id=53193 .
See http://en.wikipedia.org/w/index.php?title=User:Christian75/sandbox2&oldid=569697466 .
If you edit the page with VE you won't see the broken template at all.
Thanks.

--------------------------
**Version**: unspecified
**Severity**: normal
Essentially the problem here is "broken wikitext produces confusion"; there's not really anything that we can do except encourage people to use VisualEditor rather than wikitext where such errors are possible.
Currently there is no way to use {{subst:DATE}} in a template invocation in VisualEditor. If you try to paste it into the value of a date field, it won't work because you get

|date = date=August 2013

which won't parse.

VisualEditor should actually set the date automatically, always, for such templates (e.g. refimprove).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52345
Yes(In reply to comment #0)
> Currently there is no way to use {{subst:DATE}} in a template invocation in
> VisualEditor. If you try to paste it into the value of a date field, it won't
> work because you get
> 
> |date = date=August 2013
> 
> which won't parse.

Yes. This is by design; templates that are designed around wikitext's structure won't work in general for editing. Note that "{{subst:CURRENTDAY}} {{subst:CURRENTMONTHNAME}}" works fine; auto-inserting this would solve the problem.

> VisualEditor should actually set the date automatically, always, for such
> templates (e.g. refimprove).

I agree; that is bug 51428 (and its corresponding implementation in VisualEditor).
If I add an unprefixed link to [[Main Page]] on

https://www.mediawiki.org/wiki/Wikimedia_Engineering/WMF_Tech_Days_2013

using VisualEditor, the link points to [[Wikimedia Engineering/Main Page]] when previewed in VisualEditor (by right-clicking and opening in a new tab). "Review changes" suggests that the correct link will be added when saving the page, so this issue may be limited to the editing surface.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 48915 ***
On de.WP, a user tried to replace an outdated link within an existing ref via VE and ran into a nowiki. 

diff:

http://de.wikipedia.org/w/index.php?title=Kin-dsa-dsa%21&diff=121506430&oldid=117367043

report:

http://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=121759646#nowiki_bei_unbeschriftetem_Link

I could reproduce that; the previous is showing it prior to saving, too.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to Amir E. Aharoni from comment #2)
> I cannot reproduce this with the current version of the article, which has
> similar content.

I can confirm that I could previously reproduce and this is now fixed; not quite sure where or when.

> When trying to edit the old version of the article I get a strange result: I
> don't see the external links in the reference editor at all.

Yeah; that's very odd. Have filed bug 71652.
I cannot reproduce this with the current version of the article, which has similar content.

When trying to edit the old version of the article I get a strange result: I don't see the external links in the reference editor at all.
Confirmed

Steps to reproduce:
1. https://de.wikipedia.org/w/index.php?title=Kin-dsa-dsa!&oldid=117367043&veaction=edit
2. open the ref dialog for the last ref in the first paragraph of section 'Video'
3. open link dialog for the first external link
4. replace http://kinocenter.rsuh.ru/Dan2.htm with http://wayback.archive.org/web/20080603185657/http://kinocenter.rsuh.ru/Dan2.htm

Expected results:
Only the URL changes

Actual results:
<nowiki>[1]</nowiki> is inserted

Reproduced on a much smaller test case here:
https://de.wikipedia.org/w/index.php?title=Benutzer:John_Vandenberg/test&diff=123052743&oldid=123052686
When I add a reference and add a template of type "cite web" in the reference, the template only allows me to enter a single author last name and a single author first name. To enter multiple authors I'm supposed to use the attributes "last1, first1 through last9, first9 for up to nine authors", but VisualEditor doesn't seem to offer the possibility of adding these attributes.

There is an "others" field, but this is only supposed to be used for people who are neither authors nor editors, e.g. illustrators.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC
This is a failing in the TemplateData that has been written for the template - it seems that the author of the template's hinting didn't bother to put in last1-9 or first1-9.

However, despite the lack of hinting, you can enter these in VisualEditor (just manually type in 'first1' as a parameter, add it, set a value, repeat for 'last1', and so on for each additional author). It's very laborious, which is why this should be fixed in the template's TemplateData, but not an issue with VisualEditor.
Screencast

When trying to add a new section and a reference list an existing template (defaultsort) gets removed, see screencast attachment.

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

**Attached**: {F11699}
Cannot reproduce. This must have been fixed at some point. I wonder if it was a Parsoid issue...
Does this still happen?
**Author:** `sumanah`

**Description:**
On mediawiki.org, I have enabled the "Add an [edit] link for the lead section of a page" gadget and the "Enable section editing via [edit] links" Preference (in the Editing tab).

If I go to a wiki page on mediawiki.org and click "edit" or "edit source" next to the title of an article (e.g., on https://www.mediawiki.org/wiki/Wikimedia_Labs ), then the VisualEditor link correctly thinks I want section 0, the lead section:

https://www.mediawiki.org/w/index.php?title=Wikimedia_Labs&veaction=edit&section=0

but the "edit source" link thinks I want section #1 and thus brings me to edit the "Background" section:

https://www.mediawiki.org/w/index.php?title=Wikimedia_Labs&action=edit&section=1

This may be a problem with the gadget rather than with VE, but it only started recently, so I think it might be a VE-related issue.  (I have looked at Bug 51030 - "Edit link for lead section no longer works" which sounds sort of separate.)  I shall also mention this bug in the talk page of the relevant gadget.

--------------------------
**Version**: unspecified
**Severity**: normal
Definitely a problem with the gadget.
**Author:** `sumanah`

**Description:**
close-up of error message and greyed button

1. Try to use the VE to create a page at https://test2.wikipedia.org (while logged in, if that makes a difference).

2. Click "Save page" button.

The "Save page" button greys out and "Error: Unknown error" shows up to its left.  The user assumes that the page has not been saved.  But it has been created, e.g., https://test2.wikipedia.org/wiki/Kim_Stanley_Robinson .

By the way, if the user reacts to the error by clicking Review changes and then getting back to Save, everything works fine.

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

**Attached**: {F11279}
I think this was due to a bug in the save dialog that we fixed last month; closing. If it re-occurs, please re-open this bug so we can fix this issue too.
**sumanah** wrote:

Also, as you can see in https://test2.wikipedia.org/wiki/Special:Contributions/Sharihareswara_%28WMF%29 and (for instance) https://test2.wikipedia.org/w/index.php?title=Kim_Stanley_Robinson&oldid=57690 , those creation edits don't get the "VisualEditor" tag.
This does not affect Firefox, from what I saw - I used Chrome.
I'd add a screenshot but it is really just as the summary says, 
the number is there and it is working but you can not see it because the equivalent for "Watch this page", which is "Aggiungi agli osservati speciali", overlaps it (only the last word, of course).
Thanks.

--------------------------
**Version**: unspecified
**Severity**: normal
This was I think fixed some time ago. Sorry for the very slow triage.
Screenshot 1

https://de.wikipedia.org/wiki/Knebel transcludes https://de.wikipedia.org/wiki/Konrad_Knebel

Only 2 lines are transcluded but the VisualEditor does not detect the end of the transclusion, see screenshot 1.

The other 3 lines are handled as content of this "template", see screeshot 2.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://de.wikipedia.org/wiki/Knebel

**Attached**: {F11960}
*** This bug has been marked as a duplicate of bug 51119 ***
Created attachment 13094
Screenshot 2

**Attached**: {F11961}
Input in VisualEditor and Output after saving (+ Parsoid Server output)

MediaWiki:
1.22alpha (ffa9b0a) 19:02, 11. Aug. 2013

VisualEditor (Version 0.1.0)(0e76b1b)20:01, 11. Aug. 2013

ParsoidServer:
commit 808cc39c81df83daaec458c81edbd126fd1dd19a
Author: Subramanya Sastry <ssastry@wikimedia.org>
Date:   Mon Aug 12 16:15:24 2013 -0500


Adding more than one empty line isn't possible in the VisualEditor extension. Is this a desired behaviour?

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

**Attached**: {F11917}
Multiple sequential blank paragraphs are collapsed to one by design (we provide an HTML editor, not a desktop publishing system).
Still happening with the following VE-commit

commit c98a964d5f8495f0d16af9229abbeb0449042d1e
Merge: 3d01a5b e7aed52
Author: jenkins-bot <jenkins-bot@gerrit.wikimedia.org>
Date:   Wed Sep 18 01:11:46 2013 +0000
Merge "Fix check for preformatted when stripping whitespace"

Browser: Chrome 29.0.1547.66 m W764bit
Confirmed this is still happening on en.wp (wmf 15) and mediawiki.org (wmf 16)
I've tested it with the VisualEditor on the official mediawiki-page. Here it works: Im able to enter more than one line break. Can you guys reproduce my problem with my version?

I updated my VE to the latest master-branch-commit: 

commit 2c4e9d832374f095d3fa9d43b845ac7c7083aeb4
Merge: c84c47a 7673a39
Author: jenkins-bot <jenkins-bot@gerrit.wikimedia.org>
Date:   Wed Aug 14 22:00:12 2013 +0000
Merge "Support previews and concurrent updates in ce.GeneratedContentNode"

Browser-Information: Chrome on Windows 7 64bit 28.0.1500.95 

>>> Still the same problem.
Sounds like VE, as we'll produce empty lines fr p/br content just fine. Moving to VE.
Is this a question about the VE interface (in which case you should either file this against the VE component OR show up on IRC and ask on #mediawiki-visualeditor) or the wikitext that is generated?
Pages started with a copy/paste of layouts (i.e. http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Football/Players ) are very, very common. VE does not seem to support this right now, making VE a very secondary choice to create articles. Probably related to https://bugzilla.wikimedia.org/show_bug.cgi?id=33105 , please feel free to mark this as a dupe if needed. Thanks.

--------------------------
**Version**: unspecified
**Severity**: enhancement
I'm going to merge this with bug 52091, which would fix the issue (you could copy-and-paste from the read HTML without needing to do anything special).

*** This bug has been marked as a duplicate of bug 52091 ***
All the references adding in this edit: https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox&diff=568232613&oldid=568231803 were added using the "use existing reference" option. 

It seems that only when I added the same reference on the same line (trying to reproduce a different bug) did it reuse the existing ref rather than creating a duplicate one.

--------------------------
**Version**: unspecified
**Severity**: normal
I'm not sure I understand this bug report – surely it's obvious that if you re-use a reference, we need to modify the original reference to have a name (if it doesn't already have one) so we can re-use it? That's how MediaWiki's referencing system works. Please re-open if I've missed something.
user Biosthmors at en.wp reports that this bug is frustrating his efforts to recruit a campus ambassador because they are getting so frustrated at trying to get VE to do what it claims it will do.
See https://pl.wikipedia.org/w/index.php?title=Wikipedysta:G%C5%BCdacz/brudnopis&oldid=37221362&veaction=edit for an example; only one citation appears as insertable.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 50474 ***
**Author:** `hagurganus`

**Description:**
When typing an edit summary in the Edit Summary window, I was unable to backspace. It seemed to let me highlight and _replace_ text, but even then, I could not highlight and hit the backspace key to _remove_ the text, I had to highlight and hit spacebar to simply enter a space, etc.

It could be that this is intentional, but I highly doubt this.

--------------------------
**Version**: unspecified
**Severity**: major
I believe that this is the same as bug 50722, yes.

*** This bug has been marked as a duplicate of bug 50722 ***
I think this is likely to be bug 50722?
I've been encountering this for a while and just worked out how to reproduce this:

1. Edit a page in VE
2. Enter an edit summary (doesn't matter what) but don't save
3. Review your changes.
4. Return to editing the page without saving (e.g. using the ^ button). It doesn't matter if you make any more changes or not.
5. Click save page again

Expected behaviour
* The edit summary input box works like a normal text entry field

Actual behaviour
* The delete, backspace and cursor keys do not work.
* Text can only be selected using the mouse
* Selected text can be removed by overwriting, by "delete" or "cut" from the RMB menu, or by using the ctrl+x shortcut to cut.

This bug was originally reported on Safari/MacOS X, I encountered it using Firefox 23/Linux
An editor reports that he lost his work when an extensive edit unexpectedly triggered the "wikimarkup" popup and - after he dismissed it - the "save" button became unresponsive. The button appeared as normal but did not react to being selected.

He was using Windows 7 and Firefox.

I reproduced this using Windows 7 and Chrome (didn't matter if I removed the wikimarkup or not), and on further investigation found that the "save" button will respond as expected after a delay.

The issue, of course, is that if this editor aborted his edit because he thought the system would not save, others are likely to think that as well.

Not sure if anything can be done to make the save button immediately responsive or to figure out why it wouldn't be or to make it apparent to editors that the option to "save" will return.

The conversation can be found here:
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=567809017#Wikitext_error_message

--------------------------
**Version**: unspecified
**Severity**: normal
Is this still occurring? I think we've fixed it, so am marking as FIXED, but would prefer to get confirmation.
en.wp user GermanJoe reports a probably related problem:

After dismissing the wikitext warning the "upper third and right corner" of the save and cancel buttons are not clickable." and that "Those partial locks are only released, after you clear your browser cache (stopping VE is not enough) "

GermanJoe was using Windows XP, FF 22, vector.js and a 1280 x 1024 resolution for test. He did not experience the problem in 800x600 resolution.

Elitre was able to reproduce this and added that "this behavior changes if you zoom in or out (that is, if the buttons get bigger or smaller)"

I reproduce this using Monobook in Firefox 23 on Linux, but zooming the page did not result in changed behaviour for me.
en.wp user Ruud Koot suggests that certain tools, such as underline and font colour (bug 52645) that are not normally wanted/needed in articles shouldn't be available to new editors.

Personally I think everything should be available (this avoids the need for new classes of editor permissions) but just not shown by default. What is shown/not shown by default needs to be configurable on-wiki per wiki (and possibly per namespace).

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49617
This has been somewhat overtaken by changes to the toolbar; closing as INVALID.
en.wp user Ruud Koot reports that occasionally he gets " weird, random and unexplainable corruptions of wikitext on save" when using the VisualEditor.

The only example he gives is "e.g., a __NOTOC__ being replaced with a copy of the categories"

Bug 48231 might have something to do with this, but I confess to not understanding all the technical language there.

--------------------------
**Version**: unspecified
**Severity**: normal
Never mind.  I found it here.  https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=prev&oldid=567395325 .. No diffs there.  

Looks like his experiments here are at least 3 weeks old.  https://en.wikipedia.org/w/index.php?title=User:Ruud_Koot/Computer_science/Lambda_calculus&action=history

Lot of things have been fixed in the last couple weeks including instances of wikitext getting duplicated.  But 48231 is not related to this.  I am going to close this ticket for now.  We can open new bugs against specific bad diffs when we encounter them.

Thanks for your diligent work in reporting bugs!
Can you point me to his bug report (was this on the feedback page)?  It would be easier to debug with a diff if you have easy access to one.
en.wp user Ruud Koot reports:

"Occasionally, after a medium-sized editing session, the visual editor will silently refuse to save my edits. When clicking the save button the progress bar appears, disappears, and you stay in editing mode, with no new revision appended to the history. Trying again sometimes resolves the problem, sometimes it requires edit operations to be done in a different order or be broken up into smaller increments, saving in-between." 

He also asks, "Do you keep any statistics on how often an editor presses the save button versus how many times this actually results in a new revision being saved?"

Bug 51423 might be related.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51243
No subsequent reports or steps to fix; marking as WORKSFORME.
Sorry that possibly related issue is bug 51243
en.wp user Ruud Koot reports:
"When performing structural editing tasks (i.e. things which are slight more complex than changing typos or adding a sentence in the middle of an existing paragraph) it is very easy to get the editor into some weird state where it is impossible to get out of other than aborting the edit session and trying again more carefully. This includes things like introducing "bulleted headers" and "bulleted bullets", which cannot possibly be represented as wikitext."

He notes that "Copying and pasting around text and editing pages with tables [is a] fairly reliable method" to reproduce it.

--------------------------
**Version**: unspecified
**Severity**: normal
>>! In T54639#1091705, @Thryduulf wrote:
> I don't see a need to keep this open any longer, if something similar is reported again a more specific bug can be opened. 

Thank you for the quick reply! Sounds reasonible, closing as declined (as we cannot reproduce anymore).
I don't recall this error, and I too can't reproduce anything now using Firefox 30.  Given that it's been ~18 months since the report, it's likely this has been fixed by some other update in the meanwhile.

I don't see a need to keep this open any longer, if something similar is reported again a more specific bug can be opened.
Hi @Thryduulf! Sorry that nobody has taken a look at this report yet and given feedback.

I tried copying bullets around on https://en.wikipedia.org/wiki/User:AKlapper_%28WMF%29/Sandbox?veaction=edit but could not reproduce anything weird in Firefox 36 on Fedora 21.

Are there any specific steps to reproduce these problems, or edits / diffs that could be linked to? Any specific browser involved?

Setting task status to STALLED for the time being; please reset task status once there are clearer steps to reproduce. Thanks!
If a page starts with a bulleted list, there's no way to put the cursor "in front of" the list styling.  If you want to add a non-list paragraph, you have to make a new, blank first bullet item and then remove the list formatting from the paragraph.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52032
Seems to be resolved - checked on the page https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox4&oldid=575308394. 
The text is easily added on a new line before the first bullet.
Sorry, that last line should reference bug 52032.
To reproduce:
1: Load a page in VE that starts with a bulleted list e.g. https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox4&oldid=575308394
2: Try to add text before the first bullet.

It is possible that fix for bug 52302 might also resolve this issue.
Today's Featured Article edit notice displayed in Firefox 22/Linux/Monobook on a 481px high window

Edit notices should scroll when they are larger than the height of the window. Presently the bottom of the message is unreadable. The screenshot attached shows en.wp's "Today's featured article" edit notice displayed in a 581px high window (which is what I normally use for browsing).

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51755
https://bugzilla.wikimedia.org/show_bug.cgi?id=52667

**Attached**: {F11480}
*** This bug has been marked as a duplicate of bug 50885 ***
A couple of users have reported this also happening with "the notice specifically for VE", which I presume is the beta welcome dialog. They are unable to scroll through and read it all.
**Author:** `gnu`

**Description:**
The unusually buggy deployment of the VisualEditor has caused large numbers of English Wikipedia editors to have bugs to report.  But the process of reporting bugs is a cumbersome many-step process -- starting with a requirement to "log in" using a credential that most editors do not have.

The rest of the Wikipedia universe uses a universal login system in which you log in with the same username and password to everything, and it all works together.  Somehow Bugzilla didn't get integrated with that.

So instead anyone with a bug report for Visual Editor -- assuming they can even find Bugzilla, perhaps from a comment in an RFC about disabling the Visual Editor, as I found it -- then has to get through the "New User" process, which includes providing an email address, checking mail at that address, and accessing a URL which then demands that a new password be created and remembered.
This step should be avoided for logged-in Wikipedia users.

I'm sure that many, many Visual Editor bugs are noticed by editors, but are never reported due to the pain of the reporting process.  This shortage of bug reports may serve the political purposes of the WMF in attempting to ram the new editor down the throats of the community, but it is not a good management practice, nor will it result in eliminating the bugs that make the Visual Editor too troublesome for naive use at this point.

(The remaining process of bug reporting is also cumbersome and complex -- but 
in this bug report I have no suggestions on how to fix that.)

--------------------------
**Version**: wmf-deployment
**Severity**: normal
(In reply to comment #0)
> The rest of the Wikipedia universe uses a universal login system in which you
> log in with the same username and password to everything, and it all works
> together.  Somehow Bugzilla didn't get integrated with that.

That's bug 14487. If you don't want to create a Bugzilla account you can report issues at http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback .

*** This bug has been marked as a duplicate of bug 14487 ***
From en.wp user Cryptic C62:
The beta button on the toolbar "should not be labelled "Beta", not "BETA". The latter looks like it might be a mysterious acronym. "

--------------------------
**Version**: unspecified
**Severity**: minor
This label no longer exists, but instead is just the help "(?)" icon.
(In reply to comment #1)
> Can I work on this bug? I know it has been assigned to someone but looks like
> nothing has happened here for sometime.

It looks like that's the default assignee for bugs in this component. In general it should be fine to do these.
**aravikn** wrote:

Can I work on this bug? I know it has been assigned to someone but looks like nothing has happened here for sometime.
Where articles use the {{ref}} and  {{note}} pair of templates to generate footnotes, e.g. [[List of highest points of Canadian provinces and territories]], it is impossible to edit the contents of the notes in VisualEditor.

The {{ref}} template is editable in the transclusion editor, and works as expected.

The {{note}}-generated notes are apparently one block. No transclusion icon or indication of uneditablility (green stripes) appears on mouseover or when the block is clicked. 

If a link in the notes is clicked it functions as a link would in read mode- ie. the link is followed and you leave the page. VE gives no warning about unsaved edits (although Firefox does).

If the backlink to the location of the {{ref}} template is clicked it functions as above - i.e. it loads the page in read mode at the position of the note, exactly as if you had followed a link to that anchor from any other page on the internet.

It is possible to select the block when selecting content before and after the block, although no indication is given that it has been selected. Once selected it is possible to apply bold/italic formatting to the block and other selected text using the B/I buttons, but it is not then possible to remove it using these buttons while the note block is selected. It is possible to remove bold/italic using the clear format button. The clear format button does not remove any links in the notes block, but does remove links from any other text selected at the same time.

--------------------------
**Version**: unspecified
**Severity**: major
Cite.php is designed a certain (bad) way. It has issues, and we will replace it at some point, but the way to fix its issues is not to make horrible hacks in wikitext using loopholes over-looked when the code was written to try to re-design in.

This is one of those cases, and is not sanely supportable in VisualEditor, so I'm going to mark this as WONTFIX.
cklim: Not sure what your random HTML and image posted here has to do "VisualEditor: Cannot edit notes that use {{ref}} and {{note}} system".
Please file a separate ticket as this seems unrelated to this bug report.
**cklim074** wrote:

<head><meta content="width=device-width; height=device-height;" name="viewport"><link href="resource://gre/res/ImageDocument.css" rel="stylesheet"><link href="resource://gre/res/TopLevelImageDocument.css" rel="stylesheet"><link href="chrome://global/skin/media/TopLevelImageDocument.css" rel="stylesheet"><title>attachment.cgi (PNG Image, 1247&nbsp;×&nbsp;669 pixels)</title></head><body><img class="decoded overflowing" alt="http://bug-attachment.wikimedia.org/attachment.cgi?id=14163" src="http://bug-attachment.wikimedia.org/attachment.cgi?id=14163"></body>
**cklim074** wrote:

<head><meta content="width=device-width; height=device-height;" name="viewport"><link href="resource://gre/res/ImageDocument.css" rel="stylesheet"><link href="resource://gre/res/TopLevelImageDocument.

<head><meta content="width=device-width; height=device-height;" name="viewport"><link href="resource://gre/res/ImageDocument.css" rel="stylesheet"><link href="resource://gre/res/TopLevelImageDocument.css" rel="stylesheet"><link href="chrome://global/skin/media/TopLevelImageDocument.css" rel="stylesheet"><title>attachment.cgi (PNG Image, 1247&nbsp;×&nbsp;669 pixels)</title></head><body><img class="decoded overflowing" alt="http://bug-attachment.wikimedia.org/attachment.cgi?id=14163" src="http://bug-attachment.wikimedia.org/attachment.cgi?id=14163"></body>

**Attached**: {F11426}
When a user has installed a gadget that relies on data from an external server, VisualEditor appears to wait indefinitely for that server to respond. Normally this is OK, but when that server is down VE will apparently wait forever (or at least longer than the 5 minutes I was prepared to wait) for a response.

The source editor appears to give up after a wile (2 minutes?), and loads as if the gadget was not called. VE should exhibit this behaviour too.

Tested with the HAPPI gadget ([[User:EpochFail/HAPPI]]). As of 21:52 UTC 05 August 2013 that gadget depends on a server at wikipedia.grouplens.org that is not responding

--------------------------
**Version**: unspecified
**Severity**: normal
Surely this is the responsibility of the gadget's author?

Also, not sure if the wikitext editor executes poorly-responding gadgets, or it's just apparent happenstance. Either way, 120 seconds is about an order of magnitude too high.

Sorry for very slow triage.
At line 42 of https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox&diff=567254040&oldid=566841354 attempting replace what appeared to be an empty image caption with "The [[Sun]]" (using ctrl+k for the link, no wikicode) resulted in the insertion instead of:
The <a style="white-space:nowrap" data-mw="{&quot;target&quot;:{&quot;wt&quot;:&quot;val&quot;,&quot;href&quot;:&quot;../Template:Val&quot;},&quot;params&quot;:{&quot;1&quot;:{&quot;wt&quot;:&quot;4.6&quot;},&quot;ul&quot;:{&quot;wt&quot;:&quot;byr&quot;}},&quot;i&quot;:0}" rel="mw:WikiLink" href="Sun">Sun</a>

The images were left over from testing for Bug 52341 and so that bug may be related.

--------------------------
**Version**: unspecified
**Severity**: normal
I'm pretty sure this was a horrible artefact of a nasty bug we fixed back in September; provisionally marking as WORKSFORME. Sorry for the ludicrously-slow triage.
visual editor easily doubles mouse clicks and key presses. this can be seen, amongst others, on section editing, saving, adding a reference. to avoid bug reports in the line of "please remove one mouse click while creating a reference" create a (visual) design guideline mandatory to follow for all developers to minimize mouse clicks and key presses, and maximise screen estate available for editing/viewing the article.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Again: This won't be handled in Bugzilla, however pointing to a better place where to discuss would be very good.  Playing the "I know it's the wrong place but still I want to discuss it here" card isn't much better either though. :)

Please don't reopen as a sign of disagreement. Thanks.
james, let me reopen this one please. there is a big difference between "it is our intention" (whoever "our" is) and a crystal clear guideline having as primary target:
* minimize clicks and key presses
* response time <3 sec
this would make it so much easier for new developers as well. and so much easier for testers to point out that something is against the goal. 

as i tried to point out above with examples, people were and still are allowed to increase key presses and mouse-clicks considerable compared to the existing solution. i tried to look for design documents or mail references on some tech list to find a justification for this, but could not find one. 

you as a software developer surely know that nothing is more expensive than fixing a design bug. and nothing is more expensive than finding a bug late. just to take an arbitrary url to support this: http://blog.bootstraptoday.com/2011/12/25/early-detection-of-bugs-can-save-up-to-22-billion-yearly/ 

so, please do not play the "a good thing but not the right place" card. which then ends up nowhere. you can close the ticket if you either create this guideline, or successfully have a (public verifyable) decision in whatever place you consider right for a decision like this.
Of course, this is already our intention. There is nothing to "create".

Bugzilla is not really the right place to suggest user experience improvements like this - though walk-through data like you've given is hugely valuable, and if you have more I would love for you to share it.
for bug48429, section editing, i tried VE at https://en.wikipedia.org/wiki/Jos%C3%A9_Mourinho. to repeat the clicks and key presses here:
* 1 click and 15 secs to edit
* 1 click to make go a away a note (see attachment)
* 1 click to edit summary
* 1 click and 20 secs to review changes
* 1 click to return to save form
* 1 click and 40 secs to save
* 5* pg down to go to the section just edited

while text editor sections can be edited with:
* 1 click and 2 secs to open
* 1 click and 2 secs to preview
* 1 pg-down to find the save button (could be avoided by re-placing the button)
* 1 click and 10 secs to save

old is ideally 3 clicks, new is 6 clicks + 5 key presses.

but, there are other cases as well. to add a category with hotcat is one click and a key press to confirm. It auto-corrects even the spelling to upper case. VE takes 8 clicks, a refresh, and scrolling down, if i counted correctly.
Which exact problem do you see with the current situation, that made you file this bug report?
Currently, De.WP talk, user talk, Wikipedia, Wikipedia talk..pages show for the last section not [Edit source] as En/Es/xy.WP do but [Add section / Edit source code / Add section] (Abschnitt hinzufügen Quelltext bearbeiten Abschnitt hinzfügen). It neither breaks anything technically as far as I can tell right now nor does it mix in VE interface but, where ever it might come from, it should be fixed asap

http://de.wikipedia.org/w/index.php?title=Diskussion:Immanuel_Kant&oldid=120880638

http://de.wikipedia.org/w/index.php?title=Benutzer_Diskussion:JEissfeldt_(WMF)&oldid=120853192#VisualEditor_.2A_Projektseiten

--------------------------
**Version**: unspecified
**Severity**: critical
This is an issue with a script at [[de:MediaWiki:Common.js]].

In the section "erzeuge einen "Neuen Abschnitt"-Link an der letzten Überschrift", replace "$( 'span.mw-editsection:last a' )" with "$( 'span.mw-editsection:last a:last' )". That should be enough to fix it.
It would be helpful to be able to selectively disable VisualEditor (we should to indicate to a user who'd otherwise see VisualEditor that it is disabled, to reduce confusion). This would enable users to shield pages where VisualEditor/Parsoid cause roundtrip issues.

A hidden blacklist category could be included in a page or template to achieve the desired effect, and could be used by developers to prioritize roundtripping issues.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 52141 ***
If one opens the VE editing interface, the user experience in relation to image formats varies significantly. The report: 

http://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=121153156#Bilder_werden_im_VE_kleiner_angezeigt

has several examples with different browsers like 

FF 22 / Win 7: edgewise images smaller; rest bigger.
Chrome 28 / Win 7: all significantly smaller.

See also screenshots in perma link.

--------------------------
**Version**: unspecified
**Severity**: normal
Merging with bug 47804.

*** This bug has been marked as a duplicate of bug 47804 ***
When viewing a page, images that are specified as [[File:Foo.jpg|thumb|Caption]] render as 220px wide (en.wp)/180px wide (de.wp), regardless of dimensions or aspect ratio.

In visual editor, images specified the same way render so as not to exceed 190px wide by 212px high. 

This means that images can appear at very different sizes in the VE editing surface to how they appear on the rendered page. This is especially true for very tall images.

Example to better illustrate this, compare the two views of this page
View mode: https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox4&oldid=575350620 
VE edit mode: https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox4&oldid=575350620&veaction=edit
The displayed table (Firefox 22/Ubuntu)

See [[fr:Special:redirect/revision/95505705#Pr.C3.A9sidents_de_l.27universit.C3.A9]]

The lines of the table using {{ligne grise}} are uneditable because of {{ligne grise}} (which just adds bgcolor="#F2F2F2"…). But they are displayed wrong (see attachment) because the <tr> is wrapped in a <span>. Not really WYSIWYG…

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

**Attached**: {F11257}
Yes, merging with bug 50607.

*** This bug has been marked as a duplicate of bug 50607 ***
I think this might be a duplicate of bug 50607
**Author:** `kwwilliams`

**Description:**
http://en.wikipedia.org/wiki/User:Kww/singlechartreftest is a simple test case for accessing references created by the singlechart template.

Singlechart directly creates references when called, using #ref (it cannot use <ref></ref> tags because of issues involving the parsing sequence of templates and references). It will either create them with a default name that it generates algorithmically, or it will use the value of the "refname" parameter.

When editing http://en.wikipedia.org/wiki/User:Kww/singlechartreftest, if the editor attempts to insert reference and chooses the option to "use an existing reference", three of the existing named references (sc_BillboardHot100_The Hollies, sc_Norwegian_The Hollies, and sc_Dutch100_The Hollies) aren't displayed at all. These are references that are available for the editor to use, but have not been currently reused in the article text. An examination of http://parsoid.wmflabs.org/en/User:Kww/singlechartreftest shows that Parsoid did pick up these names so VE should be able to display them.

sc_UK_Hollies is displayed, but no text is associated with it. Similarly with germancharts. Attempting to include these references works. Both of these references should have the full reference text displayed, although the editor should not be permitted to alter it.

{{Certification Table Entry}} and {{albumchart}} should have identical problems.

--------------------------
**Version**: unspecified
**Severity**: normal
Is {{#tag:ref}} something that is part of MediaWiki or something user-generated? If it's part of MediaWiki, presumably its creation and deployment is an indication that it's meant to work.
**kwwilliams** wrote:

That response is beyond the pale. Please retract it, and concentrate on building an editor that functions within the environment that exists, not the environment that you wish existed.
This is a duplicate of bug 50474 - in general, any reference created by a template shouldn't work, deliberately. Hacks using {{#tag:ref}} which was never meant to work are a nightmare for users and VisualEditor alike.

*** This bug has been marked as a duplicate of bug 50474 ***
http://en.wikipedia.org/wiki/.tl for instance,
if you click on the Edit tab, nothing will happen.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 51308 ***
(I believe I just duplicated https://bugzilla.wikimedia.org/show_bug.cgi?id=51308, sorry about that).
Toolbar mixed with #p-personal

See the image. And I got the opposite, the toolbar staying at top of the article.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52504
https://bugzilla.wikimedia.org/show_bug.cgi?id=52326

**Attached**: {F11123}
This is a duplicate of Bug 52441 which is fixed but not yet deployed

*** This bug has been marked as a duplicate of bug 52441 ***
1. Got to [[fr:Disjonction logique]]
2. Edit it with VisualEditor
3. Try to modify the table. You will get a big blue rectangle allowing to edit {{clr}}, but you can’t edit directly (clicking on headings and using ↓ works) the <td>.

Of course, there is no reason why this article uses float & {{clr}}, but I know some similar cases where it is useful to have floating tables + {{clr}}.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 50551 ***
This is related to bug 51933 - an excessively large transclusion box prevents accessing an item it overlaps. It's not identical though as that bug relates to other templates and this to tables, so I'll leave the decision whether to merge up to someone more knowledgeable.
Sometimes when entering a link in the link input widget the first suggested target is automatically inserted, even before you finish typing, making it very difficult to choose a different target.

Steps to reproduce:
1.Load a page in VE
2.Press ctrl+k to enter a link
3.Try to enter a link to [[Portable Document Format]], [[Classic (album)]] or [[Thing (assembly)]].

--------------------------
**Version**: unspecified
**Severity**: critical
Elitre was 25 seconds faster than you ;)

*** This bug has been marked as a duplicate of bug 52420 ***
- Chrome 30 (canary)
- https://en.wikipedia.org/w/index.php?title=Narayana_Gosain_Temple&oldid=565414421&veaction=edit


When selecting the following:

> <selected>
> h2.Transport
> p.It is situated within 20km from NH5 running between Chennai and Howrah. Nearest railhead is Jajpur Keonjhar Road or Byasanagar.
> h2.References
> references.
> \n
> </selected>
> \n
> h2.External links

.. and cutting it, and then ctrl-Z. It restores both content and selection properly 



When selecting the following:

> 
> h2.Transport
> p.It is situated within 20km from <selected>NH5 running between Chennai and Howrah. Nearest railhead is Jajpur Keonjhar Road or Byasanagar.
> h2.References
> references.
> \n
> \n
> h2.External</selected> links

.. and cutting it and then ctrl-Z. It restores the content properly, but the selection is restored only within the first paragraph:

> 
> h2.Transport
> p.It is situated within 20km from <selected>NH5 running between Chennai and Howrah. Nearest railhead is Jajpur Keonjhar Road or Byasanagar.</selected>
> h2.References
> references.
> \n
> \n
> h2.External links

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed in the selection re-writes.
Screenshot: 2 extra bullet points & template content edited

Browser: Firefox 24

When editing this page[1] on sv-wp two weird things happen:

1) The bullet point on the bottom of the page duplicates into three bullet points

I expect it to show one bullet point, like when viewing the article.


2) I can edit the text of the template used in the list[2], though when I check the diff, it hasn't detected that I edited the template text

I expect the text of the template to show a blue background when clicking on it and *not* be editable.


[1]  https://sv.wikipedia.org/w/index.php?title=Byrackorna&oldid=22981861
[2]  https://sv.wikipedia.org/wiki/Mall:IMDb-titel

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/User:Skalman/bullet_point_test

**Attached**: {F11912}
This is a known tidy issue, so marking as a duplicate.

*** This bug has been marked as a duplicate of bug 47673 ***
This is a duplicate of a Parsoid bug that has been WONTFIX'ed, I believe (but I can't find right now) - Gabriel, can you remember which one?

(In reply to comment #4)
> FWIW, even Special:ExpandTemplates seems to be affected by this bug!

… which is a sign that you're abusing wikitext, and should stop trying to get this to work. :-) Special:ExpandTemplates has nothing to do with VisualEditor or Parsoid.
I believe I found the root cause - demonstrated by a minimal test case: https://www.mediawiki.org/wiki/User:Skalman/bullet_point_test

Wikitext of template:
* {{{1}}}

Wikitext of page:
* {{template|Hello there}}

Expected output (the way the traditional parser handles it):
* Hello there

Note that a naive wikitext template expander would produce:
* * Hello there

To me, this now seems to be a problem with the data model.


FWIW, even Special:ExpandTemplates seems to be affected by this bug!
Reproduced in Chrome 28 and Opera 12.16.
And further weirdness:

When I add the text 'ABC' to the first of the now three bullet points I get the following wikitext:

* {{IMDb-titel|id=0105928}}ABC
* ''[ackorna''' (originaltitel ''2 Stupid Byrackorna]'' på [[Internet Movie Database]] <span style="font-size:.95em;font-weight:bold;color:#555;">(engelska)</span>
*
This is probably a ContentEditable problem.
Request to introduce drag and drop for text passages; there are also bugs for images around (obviously).

Report:

http://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=121095343#Drag_.26_Drop_von_Textabschnitten

--------------------------
**Version**: unspecified
**Severity**: enhancement
There's already bug 49981 for drag-and-drop of content in general; I don't think this is sufficiently different (drag-and-drop of text is not sufficiently distinct from drag-and-drop of non-text to be worth splitting out), so merging.

*** This bug has been marked as a duplicate of bug 49981 ***
https://pl.wikipedia.org/w/index.php?title=Octan_etylu&curid=217010&diff=37144425&oldid=37144363

This may be a template that got subst'd in VisualEditor.  It produces this text:

 <div class="do-not-make-smaller refsection references-column-count references-1column">
 <references />
 </div>

Something sensible ought to be done with this, but I'm not sure what the right answer is.  (Yes, that's in English, even though it's not an English-language project.)

--------------------------
**Version**: unspecified
**Severity**: normal
I believe all these issues were fixed months ago (sorry for very slow triage).
That's the contents of the {{Przypisy}} template. It looks like they "spilled out". Parsoid issue?
Image of issue

Upon loading VE in Thai wikipedia in an article with a bulleted list, spaces are added after bullets in the edit view.  Attempts to remove the spaces remove the preceding bullet.  Spaces are not added upon Save, but will lead to confusion for editors.

Duplicated in FF, Chrome.  Ubuntu, OS 10.6.8

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

**Attached**: {F11736}
This is because the Thai Wikipedia has this CSS in its Common.css:

| /* A request by octahedron80 19:13, 7 ธันวาคม 2554 (ICT) */
| .mw-content-ltr dd, .mw-content-rtl .mw-content-ltr dd {
|     margin-left: 2.5em;
| }
| .mw-content-ltr ul, .mw-content-rtl .mw-content-ltr ul {
|     margin-left: 2.5em;
| }
| .mw-content-ltr ol, .mw-content-rtl .mw-content-ltr ol {
|     margin-left: 2.5em;
| }

There's no justification for it beyond who requested it, so I can't judge whether the purpose it serves is sufficient, but it's deliberate.

As this is based on local wiki configuration, marking as INVALID.
**KaewWiki** wrote:

(In reply to comment #0)
> Created attachment 13022 [details]
> Image of issue
> 
> Upon loading VE in Thai wikipedia in an article with a bulleted list, spaces
> are added after bullets in the edit view.  Attempts to remove the spaces
> remove
> the preceding bullet.  Spaces are not added upon Save, but will lead to
> confusion for editors.
> 
> Duplicated in FF, Chrome.  Ubuntu, OS 10.6.8

Also in the same image, at the end of reference section
(in Thai {{รายการอ้างอิง}}) and immediately before {{stub}} (in Thai
{{โครงกฎหมาย}}), VE displayed additional blank line where it should
not do so.

**Attached**: {F11736}
Example page on th.wp:
https://th.wikipedia.org/wiki/กฎหมายปิดปาก?veaction=edit

I can't reproduce this with Thai text on en.wp. See for example https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox4&oldid=575310209&veaction=edit
link target takes over media settings dialog

If text has a size specified, e.g <font size=12>, then you cannot edit it in VE at present. The bar that notifies you of this is fixed to standard line height so you can click on links that extend above or beyond this, e.g. <font size=12>text with a [[link]]</font>.

If such a link appears in body text, then clicking it takes you to the link target in the same window (i.e. exactly the same as if you clicked on it in read mode). If you ctrl+click to open in a new window/tab then you get the same behaviour as described for section links in bug 51122.

If such a link appears in an image caption, then ctrl+clicking has the same effect as in the paragraph above/bug 51122. Left clicking does take you to the linked page, but instead of using the main window it uses the media settings dialog's frame (see screenshot). You cannot close this frame - the close button has been replaced by the link target and it doesn't respond to escape.

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

**Attached**: {F11727}
This has the same root cause as bug 51778, despite the names; merging.

*** This bug has been marked as a duplicate of bug 51778 ***
Cryptic C62 and en.wp has noted that he can replicate this in Firefox 22 and Chrome 28 running on Windows Vista. Both they and I use the monobook skin.
Steps to reproduce:

1. Edit https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox2&oldid=566460073#New_section in VE
2. Click on the last image and open the media settings dialog
3. Left click the link above the "can only edit in source" bar.

This happens in Firefox 22 on Linux, I can't test in other browsers/OSes.
A user at en.wp comments that VisualEditor looks best in the Vector skin, but that it would be better if "manual CSS theming" were supported.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**gryllida** wrote:

I understand you expect folks to either 1) look into having existing themes change the VisualEditor appearance to fit their style, or 2) to look into using CSS. As the latter is not user-friendly for non-technical users I will look into the former. Thank you.
(In reply to comment #8)
> [...] when the rest of MediaWiki is designed to be consistent.

:-)
(In reply to comment #5)
> My original query was in making different styles available for an average
> user, who has no CSS experience.

Then that's a question for MediaWiki core, not VisualEditor; VisualEditor just inherits its styling from MediaWiki.

Certainly, we are not going to build a custom-styling tool just for VisualEditor when the rest of MediaWiki is designed to be consistent.
Hey James,
I am reopening this to understand whether Gryllida's concerns can/should be addressed, and because the user understands, from the logs of a recent office hour, that you welcome feedback from users about this topic. Gryllida is asking for a set of themes for the Toolbar from which the user can choose the one he/she wants (and provided examples in comment #2).

Other users instead were hoping that graphic solutions that are now possible by changing one's CSS are made more easily accessible in VE itself. I for one am not really good at editing my CSS page, but I could easily check a box that lets me choose a different background color that makes it more obvious when I'm VEditing (and would gladly do so).

So there are probably 2 different requests here, and I can split them if one of them can be worked on.
Thanks :)
**gryllida** wrote:

Elitre, please file a new bug, my query you pasted does not belong here.
**gryllida** wrote:

My original query was in making different styles available for an average user, who has no CSS experience.
I'm entirely unsure what this is asking for. VE already inherits users' CSS, which lets people change the CSS as they see fit - as John Broughton's script shows.

Marking as "INVALID", but happy to re-open if people can explain what different from the above this is asking for.
An example of how users might want to change the way they see VE:
https://en.wikipedia.org/wiki/User:John_Broughton/common.css
(an easier way to set a background color for VE is being requested).
**gryllida** wrote:

( Illustrations: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=570246873#Toolbar_icons_style )
Gryllida adds,
<<To be quite honest, the first thing that I see wrong in the visual editor is the black-and-white style of icons, similar to what Google products uses. It is not 1980s when everything was black-and-white, nor it is 1990s when people used 256-color icons; it is 2013. [...] I believe it is important for accessibility to at least let users choose from a set of themes for the VisualEditor toolbar, if not alter the default theme.>>
References 5-8 were not saved

At https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox&diff=566402676&oldid=566401436 only four of the 8 references I added were saved.

The second references for each statement had the same title as the first but were a different URL. They appeared in the editor as being there (see attachment) but were silently not saved.

--------------------------
**Version**: unspecified
**Severity**: critical

**Attached**: {F11698}
I can't reproduce this now, so it seems likely this was a duplicate of now-fixed Bug 52228

*** This bug has been marked as a duplicate of bug 52228 ***
At line 138 of https://en.wikipedia.org/w/index.php?title=Wikipedia&diff=566045928&oldid=566042453 parsoid (presumably) has added nowikis around around a space following a HTML comment. I don't know whether the comment containing references is relevant or not.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 50758 ***
The wikitext insertion warning now works, and is visible regardless of the position of the user on the page.

However, its color scheme is the same as other regular, confirmation-type notifications like "you've added this page to your watchlist".

Wikitext insertion is an actual problem, rather than "just" a confirmation or feedback notification. We need it to be more visible, possibly by using a different color scheme. Maybe not a big red blinking bubble, but something more noticeable than a white bubble with a light blue border.

--------------------------
**Version**: unspecified
**Severity**: normal
WONTFIX. It's currently blocking save, doesn't disappear until clicked, and in the standard place for interactive notifications in MediaWiki; moving these around for the mouse (or cursor) could get very ugly and confusing, and the advantage isn't so significant that it's worth doing.
Maybe closest to the mouse would be better. If someone edits at the bottom of the displayed content with a large screen, I’m not sure he will see the warning, too far.
Labeled Section Transclusion (<section begin="2012-07-monthly"/>Text here<section end="2012-07-monthly"/>) is not supported.  This is used for status reports on MediaWiki.org.  The first step is to alienate it.  Currently it is treated as raw text.

--------------------------
**Version**: unspecified
**Severity**: normal
LST is heavily used in wikisource, where most parts of pages are wrapped in section tags. Alienation and / or an extension-like visual edit experience would not be ideal there, which is why we are considering supporting <section> natively as the HTML5 element it is.

Closing as duplicated of bug 47936 for that reason. Please respond there if you feel that this is the wrong approach.

*** This bug has been marked as a duplicate of bug 47936 ***
Related: bug 51562
Related: bug 47936

We probably need a single bug that merges all these three.
whoops. misfire.
*** This bug has been marked as a duplicate of bug 51462 ***
For VisualEditor to alienate something, all that is required is for Parsoid to mark it up as something VisualEditor doesn't recognise; right now, Parsoid and VisualEditor are both entirely dumb to the issue. :-)
An example is https://www.mediawiki.org/w/index.php?title=Editor_engagement_experiments/status&oldid=750533
Screenshot of problem

See screenshot.

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

**Attached**: {F11666}
*** This bug has been marked as a duplicate of bug 50898 ***
One of the biggest interface issue is the new reference dialog. The use is presented with a window and no real guidance on what to do. 

Some brief instructions guiding the user to choose an appropriate citation template would be good. This obviously needs to be customisable on a wiki basis. For en.wikipedia you could have something like

"To add a reference please choose a citation template like {{cite web}}, {{cite journal}}, {{cite book}} or {{cite news}}. Click the jigsaw icon to insert one of these templates."

The message could be specified by a page in the MediaWiki: namespace.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This feels like the wrong approach. In general, if you have to prompt a user with text telling them what to do, your interface has failed.

Bug 50110 (which we want to work on soon) would give users some buttons (or something similar) for a few, recommended templates for the context - and yes, that would be wiki-localised.

Consequently, I'm marking this as WONTFIX so we can focus on bug 50110.
The Behavior switches like __TOC__, __NOTOC__ are occasionally useful in the article space and __NOINDEX__ is a useful in the user namespace. Some way to insert these in visual editor would be handy.

Bug 49996 and Bug 50855 also address magic words, but don't seem to cover the Behavior switches.

This was discussed at http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Some_ideas_for_29_July

--------------------------
**Version**: unspecified
**Severity**: normal
This was later created as bug 56865, but I'm only just triaging this now. Up-merging (unusually) given the history on that one - sorry!

*** This bug has been marked as a duplicate of bug 56865 ***
See https://en.wikipedia.org/w/index.php?title=Cruz_Azul&diff=564888460&oldid=564725284 - very strange.

--------------------------
**Version**: unspecified
**Severity**: normal
This was a recurring Parsoid bug which is now fixed; closing. Sorry for slow triage.
Inserting media, namely images, into complext tables leads to problems. A user tried to put an image into a table listing Intel CPU sockets on De.WP and the search function went back and forth in being able to find the image he knew was on Commons and how it is labeled.

Table:

http://de.wikipedia.org/wiki/Prozessorsockel#Intel

Image:

http://commons.wikimedia.org/wiki/File:Intel_Socket_1150_IMGP8593_smial_wp.jpg

The file fails to show up, if you put its name in manually once you reach "5"

Report:

http://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=121004381#Bildeinbindung

--------------------------
**Version**: unspecified
**Severity**: normal
This is actually a duplicate of bug 52782, which has been marked as WONTFIX as the Wikimedia search system is being replaced. Sorry for the slow response.

*** This bug has been marked as a duplicate of bug 52782 ***
Confirmed.
Typing 'Intel Socket 11' gives a list of images, but not this image.
Typing 'Intel Socket 115' gives zero results.

The image description is 'Intel core socket 1150, open.'

Typing in 'Intel core socket 1150' does show this, and other images, so it doesnt appear to be bug 50018.
If one tries to move a reference using Ctrl + X to pick it out, Ctrl + V doesn't work, i.e. the reference doesn't seem to be stored in the clipboard. 

If one selects the sign to the left of the reference as well, Ctrl + V provides the reference number but not the content, which gets lost.

If one selects the sign to the right of the reference as well, Ctrl + V provides the sign to the right but the reference gets lost.

If one selects a sign to the right and to the left of the reference, it works.

Report: http://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07&oldid=120995561#Einzelnachweise_in_der_Zwischenablage

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 49396 ***
Screenshot of VE on an iPad (3rd gen, iOS 6, en.wikipedia.org)

Dimensions   Dim.. without OS menu bar
iPhone / iPod     320 x 480    320 x 460
iPh?o.. Retina    640 x 960    640 x 920
iPad (portait)    768 x 1024   768 x 1004
iPa.. (landscape) 1024 x 768   1024 x 748


So that means at least under 1024px (not accounting for MediaWiki sidebar, that is to be subtracted from that)

Measuring on my MacBook Pro in latest Chrome I measure exactly 1281px as the minimum window width to have the toolbar be one line. 1331px to account for vector-hd mode and allow a bit of breathing room between the left and right half of the toolbar.

When at 1281px, the width of just the toolbar (subtracted the mw sidebar) is 1103px.

So, a lot to cut down on. Any ideas?

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

**Attached**: {F11563}
Yes, this is; merging.

*** This bug has been marked as a duplicate of bug 51000 ***
Same as bug 51000?
Created attachment 13387
Screenshot of two side-by-side VE windows on 1080p screen

I see the exact same problem when sizing a window to half of a 1080p HD screen -- circa 960px window width is not uncommon...

**Attached**: {F11565}
Per http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Content_transclusion_causes_WTF_mode

If trying to add a template, only adding content (empty) and click apply, following error is thrown:

TypeError: content is undefined
http://bits.wikimedia.org/static-1.22wmf11/extensions/VisualEditor/modules/ve-mw/dm/nodes/ve.dm.MWTransclusionNode.js
Line 192

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #5)
> Doesn't give a error anymore, but API is returning: 
> 
>  {"warnings":{"main":{"*":"Unrecognized parameter:
> 'token'"}},"visualeditor":{"result":"success","content":"<p>x</p>\n\n"}}

That warning is unrelated. We're passively passing the authentication token to API requests, even though some API requests don't require a token. This is technical debt we should clean up.

Closing bug as fixed/worksforme.
(In reply to comment #1)
> 1. Insert Transclusion
> 2. Ignore "New template" panel in the dialog and go to "+ [] Add content"
> 3. Type "x"
> 4. Apply changes

5. Show changes
6. Review your changes

  Foo
+ x
  Bar

All works as expected on latest master, and no errors.
Doesn't give a error anymore, but API is returning: 

 {"warnings":{"main":{"*":"Unrecognized parameter: 'token'"}},"visualeditor":{"result":"success","content":"<p>x</p>\n\n"}}
(In reply to comment #3)
> (In reply to comment #2)
> > > > >      if (content.params) {
> > 
> > If we had used coffescript instead of plain JS, it would be so simple to
> > write
> > that as:
> >  if content?.params
> >    ...
> > 
> > Now I assume we'll need to do it manually as
> >   if (typeof content !== "undefined" && content !== null && content.params) {
> >     ...
> >   }
> It's much easier than that, you can just do if ( content && content.params )
> .
> No need to use typeof and string comparisons and all that :)
> 
> Really, though, content shouldn't be undefined in the first place.

Indeed, guarding it with an if statement for content? itself is undesirable because the error is elsewhere.
(In reply to comment #2)
> > > >      if (content.params) {
> 
> If we had used coffescript instead of plain JS, it would be so simple to
> write
> that as:
>  if content?.params
>    ...
> 
> Now I assume we'll need to do it manually as
>   if (typeof content !== "undefined" && content !== null && content.params) {
>     ...
>   }
It's much easier than that, you can just do if ( content && content.params ) . No need to use typeof and string comparisons and all that :)

Really, though, content shouldn't be undefined in the first place.
> > >      if (content.params) {

If we had used coffescript instead of plain JS, it would be so simple to write that as:
 if content?.params
   ...

Now I assume we'll need to do it manually as
  if (typeof content !== "undefined" && content !== null && content.params) {
    ...
  }
1. Insert Transclusion
2. Ignore "New template" panel in the dialog and go to "+ [] Add content"
3. Type "x"
4. Apply changes
5. > Uncaught TypeError: content is undefined
http://bits.wikimedia.org/static-1.22wmf11/extensions/VisualEditor/modules/ve-mw/dm/nodes/ve.dm.MWTransclusionNode.js:192

>    ve.dm.MWTransclusionNode.prototype.getWikitext = function() {
>        var i, len, part, template, param, content = this.getAttribute('mw'), wikitext = '';
> >      if (content.params) {
>            content = {'parts': [{'template': content}]};
>        }

Uncaught TypeError: Cannot read property 'params' of undefined
ve.dm.MWTransclusionNode.getWikitext
ve.ce.MWTransclusionNode.generateContents
ve.ce.GeneratedContentNode.onUpdate
VeCeGeneratedContentNode
VeCeMWTransclusionNode
VeCeMWTransclusionInlineNode
ve.Factory.create
ve.ce.BranchNode.onSplice
ve.ce.ContentBranchNode.onSplice
oo.EventEmitter.emit
ve.dm.BranchNode.splice
ve.insertIntoArray
ve.dm.Document.rebuildNodes
ve.dm.DocumentSynchronizer.synchronizers.rebuild
ve.dm.DocumentSynchronizer.synchronize
ve.dm.TransactionProcessor.process
ve.dm.Document.commit
ve.dm.Surface.change
ve.dm.SurfaceFragment.insertContent
ve.ui.MWTransclusionDialog.onClose
ve.ui.Window.close
(anonymous function)
proxy
Unlike the standard source editing windows, VE doesn't confirm closing the page if you have made changes, making it very easy to accidentally close a tab and lose all of your edits.

--------------------------
**Version**: unspecified
**Severity**: normal
Yeah I can confirm as well. Not sure when it started working again.
For the record: going to
https://en.wikipedia.org/wiki/Mykola_Labovskyy?veaction=edit
and typing anithing, and then closing the browser tab causes the warning "Are you sure you want to go back to view mode without saving first?"
I'm going to close this as WORKSFORME because it does (and always has), and the bug report gives no details of how to reproduce. Please re-open if you have steps to reproduce.

Sorry for very slow triage.
"Wikitext markup detected" message should disappear automatically when there's no more wikitext. Now the user must click it to make it go away.

--------------------------
**Version**: unspecified
**Severity**: normal
%%%*** This bug has been marked as a duplicate of bug 51701 ***%%%
Tested on Firefox 22, Monobook and Vector skin. DOES NOT seem to affect Chrome 28 on Vector.

Steps to reproduce:
- Open the [[Olive Branch High School]] in the visual editor.
- Press CTRL+A to select everything on the page.
- Press Delete.

The result will be that the entire document becomes uneditable since there is no editable section anymore that the user can click. The console will report the error:
- "TypeError: node is null"

If you don't click anywhere else after pressing delete and start typing the visual editor will behave extremely wonkey. I have seen behavior that ranged from adding an unending steam of pawns to cursor focus jumping all over the page. Additionally, the console will fill with a hailstorm of errors (Below is just a small sample). 
- Error: ve.dm.Document.getNodeFromOffset(): offset -1 is out of bounds 
- TypeError: parent is null 
- Error: Unbalanced set of replace operations found 
- Error: Unbalanced input passed to document
- Error: Invalid retain length, cannot retain backwards

The above is likely just a consequence of the deletion . If i look at firebug's output it seems that Ctrl+A will delete these lines:

<p data-parsoid="{&quot;dsr&quot;:[0,45,0,0]}" class="ve-ce-branchNode">
<span class="ve-ce-branchNode-slug ve-ce-branchNode-inlineSlug">&#65279;</span></p>

--------------------------
**Version**: unspecified
**Severity**: normal
This is a duplicate of bug 50947 - merging.

*** This bug has been marked as a duplicate of bug 50947 ***
On Firefox I can get pawns too, or keypresses causing the character to appear twice, if I do
1. Control-A
2. Delete
3. type 'a'

But the page becomes unusable if I follow these steps:
1. Control-A
2. Delete
3. Click on the link icon, or anything else
4. type a- doesnt work
Slight alteration: Chrome 28 does seem to be affected after all, though the problem is less severe.

(Chrome)
- Open the [[Nodeulseom]] in the visual editor.
- Press CTRL+A to select everything on the page.
- Press Delete.

Chrome will place a pawn (♙) in the article as soon as one starts typing after the deletion. Often this pawn is also a hyperlink. Firefox will behave in a similar fashion on this specific page.

Both Chrome and Firefox report a single error in the console:
"Error: Offset could not be translated to a DOM element and offset: 3"

This is probably because the article in this instance isn't blanked entirely. Ctrl+a followed by delete doesn't seem to delete the categories present in the article.
en.wp editor DragonsFlight reports a strange diff at https://en.wikipedia.org/w/index.php?title=Axial_precession&diff=next&oldid=565790907 where a <br clear=all> was duplicated minus the leading <

Possibly related to bug 51304?

--------------------------
**Version**: unspecified
**Severity**: normal
Can't reproduce; probably a transient Parsoid DSR and off-by-one error, given the issue. Marking as "WORKSFORME", but please re-open if it recurs or further information is available.
Given the proximity of the image, im guessing this is bug 52107.
(Tested on Firefox 22)

It seems that the "&editintro=Template:BLP_editintro" URL is accidentally reversed on Monobook. 

Steps to reproduce:
(Vector - Working correctly)
- Navigate to [[Martin J. Silverstein]].
-- The "Edit" link will be: https://en.wikipedia.org/wiki/Martin_J._Silverstein?veaction=edit
-- The "Edit Source" link will be: https://en.wikipedia.org/w/index.php?title=Martin_J._Silverstein&action=edit&editintro=Template:BLP_editintro

(Monobook - Working incorrectly)
- Navigate to [[Martin J. Silverstein]].
-- The "Edit" link will be: https://en.wikipedia.org/wiki/Martin_J._Silverstein?veaction=edit&editintro=Template:BLP_editintro
-- The "Edit Source" link will be: https://en.wikipedia.org/w/index.php?title=Martin_J._Silverstein&action=edit

As far as i can see only the source editor can load a template when using the "EditIntro" parameter in the URL. In monobook, it seems that the EditIntro parameter is accidentally added to the Visual Editor link instead of the Edit Source link.

--------------------------
**Version**: unspecified
**Severity**: normal
Marking as INVALID, as per standard practice for issues with on-wiki code. (Has this been fixed?)
Confirming problem exists.  The fix probably needs to be made at [[MediaWiki:Common.js]]
See https://en.wikipedia.org/w/index.php?title=Karma_in_Hinduism&diff=564615505&oldid=564615290 and https://en.wikipedia.org/w/index.php?title=Karma_in_Hinduism&diff=565801063&oldid=565800169

Reproduced at https://en.wikipedia.org/w/index.php?title=User:John_Vandenberg/test&diff=565853026&oldid=565852620, https://en.wikipedia.org/w/index.php?title=User:John_Vandenberg/test&diff=565853312&oldid=565853264

--------------------------
**Version**: unspecified
**Severity**: normal
Sorry for getting to this bug so late.

I can't reproduce this bug at all. However, I have a number of confusions and questions about the bug report such that I don't know if that's because the bug has been fixed, was never present, or I just can't understand it… :-(

"In VE, the image is not editable."

What does "not editable" mean? You can't move? Can't resize? Can't add a caption? Can't delete? Doesn't appear?

"(note the diff is a mess)"

Is it? What kind of mess? Details help a lot in a complex system so we can tell whether we can reproduce or not. Is the VE still the same VE that you had open in step 2 (with the changes made to the text line into "abc def gh", and the WT changes made in step 3 also made but in parallel to the edit)?

See https://www.mediawiki.org/wiki/VisualEditor:Bug_52107 for my testing page.

Am provisionally marking this as "WORKSFORME", which is very unsatisfactory. :-( Happy to review if we can have further information.
Here is another case that looks similar:
https://en.wikipedia.org/w/index.php?title=Persian_language&diff=prev&oldid=566108307
Steps to reproduce:
1. Create a page with

"
abc

def gh

[[File:Andrew-W.K.-The-Party-All-Goddamn-Night-EP-2011.jpg|thumb|right]][[Sambanthar|Thirugnana Sambanthar]] of the [[Shaiva Siddhanta]] school.
"

2. In VE, the image is not editable.  Place the cursor at 'c', press space and then delete: converting the first line to "abc def gh" - press save, review changes.

(note that the diff looks good.  Do not save.)

3. In Source Editor, after gh add ' ij' and save

4. In VE, repeat step 2

(note the diff is a mess)

Confirmed any image does this; and tested in Chrome and Firefox.
This looks like a string buffer problem, as it inserts different pieces of text into the same spot.  And it appears to only happen every second edit.

https://en.wikipedia.org/w/index.php?title=User:John_Vandenberg/test&action=history&offset=20130727021955&limit=4

The testcase is  fairly small now
https://en.wikipedia.org/wiki/User:John_Vandenberg/test

My process for reproducing the bug is to open the page in VE, merge the first two paragraphs (i.e. bring 'other Hindu views' up to the 'and').  Review.
If that doesnt trigger it, edit source, remove a word further down in the page, save, and remove the process in VE.
Reported at: https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Link_formatting_trick

Simplified test cases here:

[subbu@earth lib] echo "[[Foo|'foo']]" | node parse | sed "s/foo/<i>foo<\/i>/g;" | node parse --html2wt
[[Foo|'''foo''']]

[subbu@earth lib] echo "[[Foo|'foo']]" | node parse | sed "s/foo/<b>foo<\/b>/g;" | node parse --html2wt
[[Foo|''''foo'''']]

--------------------------
**Version**: unspecified
**Severity**: normal
Deployed and tested in production.
Change 76467 merged by jenkins-bot:
Take #2: (Bug 52103) nowiki escaping when quotes surround i/b tags

https://gerrit.wikimedia.org/r/76467
Change 76467 had a related patch set uploaded by Subramanya Sastry:
Take #2: (Bug 52103) nowiki escaping when quotes surround i/b tags

https://gerrit.wikimedia.org/r/76467
Change 76162 merged by jenkins-bot:
(Bug 52103) <nowiki/> escape when single quotes wrap new i/b tags

https://gerrit.wikimedia.org/r/76162
Change 76162 had a related patch set uploaded by Subramanya Sastry:
(Bug 52103) <nowiki/> escape when single quotes wrap new i/b tags

https://gerrit.wikimedia.org/r/76162
I am a bit disappointed by this closing, although it was only a suggestion of generalisation of the Wikimedia configuration for progressive deployment on third-party wikis. But it’s not very important.
On-wiki configuration management is a much bigger piece than just for VisualEditor; I think it's probably marking this as WONTFIX within the context of VE, but instead suggest that the RfCs for this (as a piecemeal approach seems worse than nothing).
(In reply to comment #0)
...
> I point out the default messages visualeditor-preference-enable/disable
> should
> have a general-wiki phrasing, and any Wikimedia customisation (about
> namespaces
> where it is enabled, about the time the parameter is available before
> possibly
> hide the preference) should be customised in the WikimediaMessages extension
> (see my comment https://bugzilla.wikimedia.org/show_bug.cgi?id=50929#c34 ).

About this, see also bug 52188.
In the proposed scenario the default values of the two preferences visualeditor-enable and visualeditor-disable would be false: in a beta environment the default is "not enabled by default=false", and in the production environment the default is "not disabled by default=false".
I saw bugs that are similar to this one, for example Bug 51289, but nothing exactly like this one.

References that are added by templates are not recognized by the references tool. I am not talking about templates like the English Wikipedia's {{cite web}}, which go inside the <ref> tag, but about template that add the <ref> tag itself (with {{#tag:ref}}).

This can be in infoboxes (Bug 51289) or in any other template. The Hebrew Wikipedia, for example, uses such a template, {{הערה}} very extensively, because mixing right-to-left text with left-to-right XML tags like <ref> is very hard to edit. This means that most of the references there are not usable for reusing in the "Use an existing reference".

(This also means a bunch of other things, but I'll report them separately.)

--------------------------
**Version**: unspecified
**Severity**: normal
The problems with references created by templates are numerous, and possibly impossible to fix ({{#tag:ref}} was never meant to work and this is an example of it not working). :-(

In general they are part of bug 50474, but I'll expand that to be clearer.

*** This bug has been marked as a duplicate of bug 50474 ***
A5b writes:

Edit page, then click save to get "Edit summary" Window. Don't touch mouse, put some description, using the keyboard.  Then we want to change checkboxes "minor edit" or "watch page", without using the mouse. Press <nowiki><Tab></nowiki> key, and you will be directed to the link "minor edit" not to the checkbox. second Tab - is "Save Page" button. Next - "review changes". Next three tabs - for links in the footer of this windows. 

Is it possible to change tab order to this (e.g. using tabindex argument or via rearranging divs and other elements): 
*1. "description"
*2. "minor edit checkbox"
*3. "watch page checkbox"
*4. "Save page"
*5. "review changes"
*6. anything else
Or even move "save page" and "review" to be just after "description".

http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback#Wrong tab-order on the "Edit summary" window

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 51918 ***
*** This bug has been marked as a duplicate of bug 50047 ***
When I select text that ends in the middle of the word and add a link, only the selected part is linked. Also, <nowiki/> is added after the link.

For example, in https://en.wikipedia.org/w/index.php?title=Ramat_Yohanan&diff=565789129&oldid=553919950 I selected "South Africa" and added the link. I saw an AbuseFilter warning when I was saving, but saved anyway to report the bug :)

Being a seasoned Wikipedian, I expect the whole word to be linked, although now that I think of it, I can imagine that linking a part of the word can be useful, too. So I'm not completely sure whether it's a bug or a feature.

This may be related to Bug 50127, though the description is not the same.

--------------------------
**Version**: unspecified
**Severity**: normal
This is not a 'bug', but intentional behaviour.

If you actually want to produce [[Foo]]ian as opposed to [[Foo|Fooian]], VisualEditor/Parsoid doesn't have a way to guarantee that (right now Parsoid creates piped links even when it could do link trails/heads, but this could change in the future), because it's irrelevant to the reader and to editors.

Consequently I'm marking this as "WONTFIX", but see bug 37939 for a wider discussion of the usability issue.
See https://en.wikipedia.org/w/index.php?title=User:Octalpuss/sandbox&oldid=565273394, which, blanked, turns into https://en.wikipedia.org/w/index.php?title=User:Octalpuss/sandbox&oldid=565667534

I appreciate with the lack of comment-editing (or comment viewing) preserving these is usually A Good Thing, but we do need a better way of handling them.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60830
*** This bug has been marked as a duplicate of bug 49603 ***
Providing new link since that user's sandbox is gone:
https://it.wikipedia.org/w/index.php?title=Utente%3AElitre_%28WMF%29%2FSandbox_VE&diff=63959567&oldid=63959556 .
PamD at the English Wikipedia reports that there is no easy way to add new content between a reflist and a template that follows it before you save the page.

This is a problem if your workflow is to add the stub template before adding the external links, which is entirely reasonable.

Steps to reproduce (option 1): 
1. create page with references and a reflist.
2. add a template (e.g. a stub template) after the reflist
3. add content between the references list and the template (e.g. an external links section).

Steps to reproduce (option 2):
1. Go to a page with no content between a reflist block and a template (e.g. https://en.wikipedia.org/w/index.php?title=Tyson_R._Roberts&oldid=565739822&veaction=edit )
2. Delete all content after the reflist:
3. Add a template (e.g. a stub template)
4. Add content between the references list and the template (e.g. an external links section).

There is a workaround: select the reflist, press the right cursor key once, press enter. This gets you a blank line with which to work from.

Desired behaviour: 
There should be somewhere to click between the reflist and the stub template, just as there is after the page has been saved and reopened in VE.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52620
This is caused by bug 49784; if we knew that the template you'd just added was a block, we would insert a slug above the template (which exists precisely for this reason). Merging.

*** This bug has been marked as a duplicate of bug 49784 ***
Whatamidoing comments that the issue is that there is no way easy to select a line starting with a template:

So someone added a book to a ==Further reading== section.  Book #1 used a citation template.  Book #2 did not.  Neither had bullet list formatting.

Selecting them was hard.  I ended up selecting the header, the template, and the plain-text citation.  Then I clicked the 'list' button.  Then I went back and repaired the formatting for the section heading.  This isn't necessary, but it was easier than trying to figure out the exact stop to place the cursor. 

[...]

[The] problem is that it's hard to select just the line that contains the template.  You have to find the magic spot in the middle of "==Heading==<nowiki>{{template}}</nowiki>" to select the template without picking up the entire section heading.  I managed it later in testing, but only if I'm selecting text with arrow keys.  With the trackpad, it's still beyond me.
TemplateData should allow some parameters to have default values which are prefilled when using the VisualEditor transclusion manager. 

An example would be the current date for accessdate in citation templates.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 51428 ***
**Author:** `lovefilms`

**Description:**
The screen shot of the missing Production section trying to edit

When click on Edit to edit a section of an article, for example, 
https://en.wikipedia.org/wiki/Blue_Jasmine#Production
the result page https://en.wikipedia.org/wiki/Blue_Jasmine?veaction=edit#Production appears to be a huge toolbar on top, and the section of "Production" is almost invisible - see attached screen shot. 

Also, the toolbar should be clearly marked with visible borders to distinguished from the contents of an article. Now it's almost blurred into the article and very confusing.

--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Windows 7
**Platform**: PC

**Attached**: {F11047}
**lovefilms** wrote:

I am in FF23.0.1 and the VisualEditor is working as intended now. I go ahead to mark it as Resolved - since people can always use the new version of FF.
Firefox 23.0 for Ubuntu:

Everything works fine when clicking the "Edit (beta)" link at https://en.wikipedia.org/wiki/Blue_Jasmine#Production - fullscreen window as well as small window.


Chromium 28.0.1500.71 for Ubuntu 

Same thing a above. It just works.
**lovefilms** wrote:

I am using Firefox 22 as well (on Windows 7). 

The IE9 doesn't seem to have the VisualEditor, the edit link will simply goes to https://en.wikipedia.org/w/index.php?title=Blue_Jasmine&action=edit&section=3
(e/c) I can reproduce on Firefox 22/Linux and Windows, and on Chrome/Windows to a lesser degree when using https://en.wikipedia.org/wiki/Blue_Jasmine?veaction=edit#Production or when loading https://en.wikipedia.org/wiki/Blue_Jasmine?veaction=edit and click the 'edit' link beside 'Production' (the bug doesnt occur if middle-clicked, as that open the url with 'vesection=3' added).

Most times I do this, it is possible to see the viewport position itself correctly at the anchor, but then then toolbar appears covering the section heading and a half of the first line of text.
I think is is related to screen resolution \ the size of the browser window. If you have a low resolution (Or resize the browser window to be small enough) Firefox 22 and Chrome 28 will place the "ve-ui-toolbar-actions" element on a second line in the edit toolbar.

If you edit a section in the small-size browser it will scroll to the section as it normally would, but doesn't take the twice-as-high-as-usual edit toolbar into account when determining where to stop. As a result the section header is actually positioned under the second toolbar line. If you resize the browser afterwards to a size that allows for a single-line edit toolbar the section header will be correctly positioned.
Which Firefox version is this about? 
Can you reproduce the problem with other browsers?
If you type, say, 'cite w' into the template selector, it drops down a list of possible templates. Hitting return inserts the one that was selected from that dropdown. Great!

Hitting 'add template', however, does not; it returns 'cite w', a non-existent template. It would be good if 'add template''s behaviour could mimic that of the return key.

--------------------------
**Version**: unspecified
**Severity**: normal
This was done some time ago as part of the tweaks to the input box.
**Author:** `l736ewiki`

**Description:**
I'm an user on it.wiki, where VisualEditor is now enabled by default on the whole ns0.

I was trying to modify a long article, on a specific section, and needed to introduce wikicode (namely {{...}} for a paragraph replaced by an empty section).


VisualEditor forced me to switch to legacy mode, but whenever I try to edit the specific section, through the local "Edit" command at section level, the legacy editor always opens in the basic editor the whole article and not just the selected section.

This is heavily annoying when dealing with very long articles, with plenty of sections.

--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Mac OS X 10.8
**Platform**: Macintosh
**l736ewiki** wrote:

I'm using vector. The issue appeared both on Safari/OS X (Mountain Lion, 10.8) and on Firefox/Windows XP Pro.


However, I was apparently able to overcome the issue. I read in the FAQ that it's recommended to disable the QuickEdit extension to avoid undesired effects with VE, so I checked in my preference pane that this extension was actually disabled (and it was).


However, in my vector.js fiel, inside the "toLoad" variable, there was a reference to QuickEdit gadget (qed). Looks like the presence of that string inside vector.js actually caused the extension to be loaded anyway. Removing that string from the vector.js and refreshing the browser's cache overcame the issue. Now I'm able to open VE directly over single individual sections.

So the results are:
* it's not enough to verify in the preference pane that the QuickEdit extension is disabled
* any reference to QuickEdit shall be removed also from the local vector.js (or monobook.js, I assume then)
I can't reproduce this on it.wiki, using vector skin and Firefox/Linux.

Does this happen on every article for you?  Which skin are you using?
http://it.wikipedia.org/w/index.php?title=Pieve_di_San_Giovanni_Battista_%28Pieve_Fosciana%29&oldid=60196986

If you tried to edit with VE, the missing image link would just disappear.
Thanks.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 50788 ***
Confirming. To make the description more clear: even if in view mode you can see the name in red of the missing image and the caption, with VisualEditor you won't see a thing, and therefore it's impossible to edit or delete the image object.

There is a test page at

http://test2.wikipedia.org/wiki/MissingImageVEtest

I found about this while trying to remove the captions in an article of two images that had been deleted at Commons: 

http://ca.wikipedia.org/w/index.php?title=Remedios_Varo&oldid=11208969

The only way to do this is editing source the old way.
I actually moved the above comment to https://bugzilla.wikimedia.org/show_bug.cgi?id=52575 . Thanks.
http://en.wikipedia.org/w/index.php?title=Walton_%28company%29&diff=567155604&oldid=565055473 This might be related (not sure how they managed to remove the bracket!)
It disappears in VE for me too.

1. modify the page (add a ' ' anywhere) 
2. 'Save page' and 'review your changes'

The diff 'inserts'

[[File:Pieve San Giovanni.jpg|thumb|200px|San Giovanni Battista]]
An anonymous editor at en.wp reports:
"I was attempting to correct a minor error at [[Class 455]].  Although I was only attempting to change one word, the editor changed, 

:...in common with the Classes 313 / 314 / 315 / 507 / 508 units."

into 

:<nowiki>...in common with the Classes <a href=tel:313 / 314 / 315">313 / 314 / 315</a> / 507 / 508 units.</nowiki>

and then complains of a formatting error and refuses to allow the change to be saved.  The editor seems to be interpreting the list of class numbers as a telephone number."

I have been unable to reproduce this using Firefox 22 on Linux, including editing the article in question.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53315
This might be default behavior in the Safari iOS contenteditable. In that case we probably need to file a bugreport upstream.
Just for reference, the original reporter subsequently noted that they use Ipad IOS6 with Safari
This is almost certainly due to a browser plugin that thinks it's being "helpful". Certainly, nothing in VisualEditor or Parsoid understand href=tel: links, so it's not going to come from us. I also can't reproduce locally in Firefox, Safari or Chrome.

Marking as INVALID (but we are seeing a small number of these consistent due to people having broken plugins; we're investigating whether there's a way to stop them).
This may be a VE issue if you are seeing a-href showing up in wikitext on serialization.
User Atethnekos at en.wp reports:
"If in the source code there is <<nowwiki/>blockquote>, and in VE I select "<blockquote>" and delete it, when I save the <nowiki/> is left behind in the source code." 

See https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox2&diff=565596201&oldid=565596137 for an example in by sandbox. Further testing shows that it also happens with other tags and even with plain text:
https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox2&diff=565596772&oldid=565596703

--------------------------
**Version**: unspecified
**Severity**: normal
This is the same as bug 47678, which now fixed in some code we created this week, but unfortunately that has an issue, bug 51948 which is preventing wider deployment. Hopefully we'll get that fixed next week.

*** This bug has been marked as a duplicate of bug 47678 ***
This is related to Bug 51741, which is about adding support for <references>...</references>

If the page already has <references>..</references>, and the last use of a named reference is removed, the entry inside <references>..</references> needs to be removed otherwise an error is generated after save.

Steps to reproduce:
1. https://de.wikipedia.org/wiki/This_Is_War?veaction=edit
2. Delete one of the named references, e.g. [16] at present
3. Save & Review your changes.

Expected results:
The reference is removed from the content and the references list.

Actual results:
The reference is removed from the content, but it remains in the references list, and if saved the error is:
"Cite error: <ref> tag with name "rockspot_1" defined in <references> is not used in prior text."

--------------------------
**Version**: unspecified
**Severity**: normal
This was done some time ago; sorry for the slow triage.
Steps to reproduce:
1. https://nl.wikipedia.org/wiki/Dolichognatha_petiti?veaction=edit
2. Click on infobox and edit translusion
3. In the first parameter (afbeelding), add 'blah', and apply changes
4. 'Save' & 'Review your changes'

Result:
 | afbeelding = 
-| afbeeldingtekst = 
+| afbeelding = 
+blah| afbeeldingtekst = 

Expected results:
-| afbeelding = 
+| afbeelding = blah

p.s. [[nl:Dolichognatha petiti]] is currently on the parsoid topfail list
http://parsoid.wmflabs.org:8001/topfails/15

Regarding the actual bug, I saw a similar diff ~20 hrs ago:
https://en.wikipedia.org/w/index.php?title=List_of_Sam_%26_Cat_episodes&curid=39469556&diff=565437324&oldid=565416618

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed some time ago; sorry for the slow triage.
And another one reported on en:VEF in case it helps
https://en.wikipedia.org/w/index.php?title=Rebel_Beat_%28Goo_Goo_Dolls_song%29&diff=566058910&oldid=565340967
English Wikipedia user PamD comments:
"Editing [[Pikku-Vesijärvi]] I noticed that VE's suggested DEFAULTSORT was exactly the title. VE should be set to drop the diacriticals when suggesting DEFAULTSORT - should have been "Pikku-Vesijarvi" with a plain "a"."

Looking at some other wikis it seems some do use diacritics in DEFAULTSORT (at least the Czech and Estonian ones do at [[cs:Édith Piaf]] and [[et:Édith Piaf]) so this seems like something that should be configurable based on each wiki's policy.

--------------------------
**Version**: unspecified
**Severity**: normal
VisualEditor is not "suggesting" a default page sort - the placeholder text informs the user what the page is currently sorted as (i.e., the page's name).

Marking as INVALID.
**Author:** `jduranboger`

**Description:**
screenshot of the bug

Does not appear "insertar multimedia" button (insert multimedia), and can't inser image selecting from the dialoge box in the spanish version. This problem happen in firefox 22.

Attached:Screenshot

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows 7
**Platform**: PC

**Attached**: {F11730}
Closing this as no confirmation of report as written. Bug 51911 gets the gist of the issue.
Sorry for confirming; the UI design should be a separate bug.
It does look very bare, and many users will be thinking "do I need to double click"? (we have MS to thank for that)

I would prefer to select an image, be prompted for a caption (an overlay appears), and then apply changes.  That would partially solve bug 51911, as the user would feel more confident that they had inserted the image, and they would go looking for it.
Bug/enhancement reported as bug 51911.
Maybe you are inserting the image somewhere out of your field of view? For example if there is an infobox in the article, or many pictures aligned to the right, the image you are inserting may be inserted BELOW all this, where you cannot see it.

Regardless of whether this is the actual problem in this particular case, I think that it is a potential problem for others. I tried inserting an image in an article with an infobox, and indeed the image was inserted below it, out of my field of view. This could lead to puzzled users and even unintended bad edits, and I think that the solution is fairly simple: making the VisualEditor scroll the screen down to wherever the image is inserted. I'll report this to the VisualEditor team.
That button was removed on purpose. You should be able to insert an image by simply clicking on the image.
A user - Cryptic C62 - reports on English language Wikipedia:
**
If I click directly on a collapse box (created with {{collapse top}} and {{collapse bottom}}), the transclusion button appears and works correctly. If I highlight a collapse box by clicking and dragging my cursor through it, one of two things happens:

A: A transclusion button does not appear
B: A transclusion button does appear. Clicking on it opens a new template window, rather than editing the existing collapse box.

Occurs in Firefox v21.0, cannot replicate in Chrome v28.0
**

I attempted to replicate this myself and found that I sometimes got result A and sometimes a transclusion button that *did* edit the existing collapse box. I could not get his result B.

I tested it on other templates, and it did not seem that dragging through other templates ever brought up the transclusion button, but never say never. :)

--------------------------
**Version**: unspecified
**Severity**: normal
AFAICT this is now fixed, I believe due to the changes in selection handling in Firefox. Sorry for the slow triage.
I've noticed quite a few edits going to the VE feedback page http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback page which don't really seem to be VE feedback. If you follow through the new editor experience its quite obvious why they are being directed there:
1)New editor finds a page, they want to edit and clicks "Edit"
2) They have a question, they see the big ? in the top bar and click it
3) There are two options: "user guide" and "Leave feadback", the second is obviously the one for questions so they click that
4) There is some complicate text which is tldr and a nice box to ask your question. The user types in that and
5)Bingo, a new section on the feedback page

This senario probably explains why we are getting a few simple signature with no comments. As the ? is much more prominent than the Help in the left sidebar its grabbing the users attention so diverting users away from our main help system. This showing up to be a continuing problem with about one such post a day. A way needs to be found to direct users to the right place.

--------------------------
**Version**: unspecified
**Severity**: minor
Marking this as "WORKSFORME", though really we should consider the broader ramifications for us and think about adding a prominent help button for users who clearly want it.
Presumably the solution is to provide a proper help link for users for general concerns, rather than burying it where they never see it?
Both MW-Vagrant and Labs have cases where a simple single-machine MW+Parsoid+VisualEditor setup is desired.  Vagrant currently has this, but Labs does not.  We should find a way to factor it out so the two environments can share it (possibly with a git submodule).

This is a proof of concept for doing this more broadly.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54160
Yeah.  It's not integrated with the normal Wikitech interface, but my understanding is it gets the job done (I haven't really used Labs-Vagrant, but I have a general understanding how it works).
Does ::role::labs::vagrant satisfy this request? Applying it via the wikitech interface provisions the labs host with a copy of MediaWiki-Vagrant and then the `labs-vagrant` command can be used to manipulate roles and run puppet.
[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.]
Edits that would trigger this error silently break VE:
"Sorry! We could not process your edit due to a loss of session data."

On save, it shows animation indicating it is saving, but then does not save, leaving you in the editing screen.  It doesn't refresh to update your session data, so the edit will never succeed; and it doesn't show you the error message.

To reproduce: start an edit, then logout, and try to complete; or v-v (and more common) start one as an anon, then log in.

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed some while ago as part of the save dialog re-write; sorry for the slow triage.
From https://pl.wikipedia.org/wiki/Wikipedia:VisualEditor/Opinie#Krytyczne_zaniedbanie_interfejsu:_wersje_przejrzane

The Polish Wikipedia uses FlaggedRevisions or PendingChanges and has deployed both notices upon opening a page and a different text on the "Save" button to reduce confusion by new editors.  These notices are not appearing in VisualEditor.

--------------------------
**Version**: unspecified
**Severity**: major
Yeah, this isn't good; we've actually just-about fixed it and will deploy it the morning (San Francisco time).

*** This bug has been marked as a duplicate of bug 49699 ***
That's not the real issue.

FlaggedRevs are enabled globally, for all pages, and *all non-autoreviewed edits require review before they are shown*; the only groups exempt from review are reviewers themselves and bots. (You can choose to view the so-called 'unstable' versions of pages instead of 'stable' ones in preferences.)

Information about this is shown to viewers before, during and after editing (using the messages pointed out in the issue report WhatamIdoing linked) – but VE shows it in none of these contexts.

I would consider this a blocker to deployment to anonymous users at least.
Long <pre> blocks rendered in Firefox 22 on Xubuntu Linux. Monobook skin.

When <pre> blocks contain lines longer than the width of the page, the <pre> block formatting finishes at the right edge of the page but the text continues. Shortly afterwards the page background finishes and the text continues onto a plain grey background. The html page though is rendered much wider than is needed to show all the text though (very approximately double the required width).

Example page: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=565361164#save_page

Firefox 22, Xubuntu Linux, Monobook skin.

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

**Attached**: {F11594}
*** This bug has been marked as a duplicate of bug 260 ***
That really wouldn't surprise me, but I couldn't find anything when searching and nothing relevant popped up when I entered the summary. If it is a dupe then the other bug describes it using completely different words, probably describing the cause rather than the symptom.
This is surely a dupe of something.
1. Visit any page on Wikipedia today.
2. Click "Edit" to enter VisualEditor.
3. Find a section heading and highlight it.
4. Press the DEL key on your keyboard to delete it.
5. Click "Save Page" then "Review your changes."

The heading text has been removed, but the following wikitext has been left in its place.

==<nowiki/>==

Cancel the save, go back to the empty heading, and place your cursor in it. Press DEL in an attempt to delete the empty heading. As a result, the entire paragraph below the old heading turns into a heading.

So how on earth do you delete a heading? I canceled my edit, re-edited, and this time, I highlighted the heading AND the first line of the paragraph beneath it, and pressed DEL. Regardless, the whole paragraph turned into a heading again.

I finally managed to delete a heading by placing the cursor at the end of the preceding paragraph (after the last character of the paragraph) and dragging all the way to the end of the heading, then pressing DEL. Now, the heading was gone and nothing else turned into a heading.

In short, you must delete some kind of invisible character on the LINE ABOVE the heading, in order to delete the heading. This is not expected behavior.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 50100 ***
At the English Wikipedia, a user requests that the tooltip which is shown when hovering over a link (shows the link target) also be shown when the link inspector icon is shown (i.e. when the cursor is in the middle of the link).

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51824
WONTFIX. Display of tooltips is native behaviour, and though we *can* over-ride the browser and do it instead when we think we know better, we shouldn't (because we'll always miss something).
Screenshot from [[pt:TV TEM]]

In the page
https://pt.wikipedia.org/wiki/User:Helder.wiki/Testes?veaction=edit
the image is a lot bigger than it is on view mode
https://pt.wikipedia.org/wiki/User:Helder.wiki/Testes?action=edit&oldid=36476193&preview=yes


This is a minimal example for the problem reported at
https://pt.wikipedia.org/w/index.php?title=Wikip%C3%A9dia%3AEditor_Visual%2FComent%C3%A1rios&diff=36476052&oldid=36474378#Logo_desproporcional
which can be seen on this article:
https://pt.wikipedia.org/wiki/TV_TEM?veaction=edit#footer
The screenshot provided was this:
http://s22.postimg.org/owzuay0jl/image.jpg

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://pt.wikipedia.org/wiki/?oldid=36476128&veaction=edit
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51628

**Attached**: {F11577}
*** This bug has been marked as a duplicate of bug 51628 ***
Parsoid keeps the code as is:
http://parsoid.wmflabs.org/_rt/pt/?oldid=36476193
It seems to be caused by the extra "px" in the wikicode:
[[Image:Globo TV logo.svg|25pxpx]]
Thanks - as the editor who reported this bug in the first place. I didn't notice it had been fixed because AFAIK there was no report to say so, and I'm not using VE regularly until some other issues have been fixed to make it usable. (Glad to notice that there's some action on redlinks, but the dialog box hiding all article content is still the dealbreaker for me).
*** Bug 58933 has been marked as a duplicate of this bug. ***
This was fixed by Trevor in January.
Though I spent a lot of time reporting these, both these are cases of the system behaving oddly rather than things which seriously affect editing. I reported them more in the sense of "The system is doing these odd things which I'm telling you about in case it's symptomatic of something significant you should know about" rather than "Please fix them now".

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

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

I wouldn't like any effort to go into these bugs which could be used to address really important things like the {{Bug|49603}} on the invisibility of hidden comments and templates, or {{Bug|49969}} on dialog boxes hiding all article content: now those really do seriously affect editing.
Note I've been unable to reproduce this using Firefox 22 on Linux, so it might be OS-specific.
If the only template is removed, the dialog is almost entirely blank.  It should reset back to the 'New template' form, or do something with all that white space.

Steps to reproduce:
1. Open Transclusion dialog
2. Add 'cite web'
3. Remove 'cite web'

Result:
Stare at the whiteness

Expected results:
Something, anything, except a sea of white

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 50281 ***
Bug 50281 (which I think this duplicates) wins for mildly amusing title though - "VisualEditor: Empty transclusion editor is empty, needs some kind of reassuring message"
Creepy; I was about to submit this with the title "VisualEditor: removing a template creates a blank dialog" ;p.
Screenshot of the table

See the link above and the attached screenshot.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://pt.wikipedia.org/wiki/La_Liga_de_2006%E2%80%9307?oldid=36362539&veaction=edit

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

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

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

works properly with the correct wikitext.
Parsoid bug: http://parsoid.wmflabs.org/pt/La_Liga_de_2006%E2%80%9307?oldid=36362539 (you'll have to scroll down quite a bit)
The page https://www.mediawiki.org/wiki/Help:VisualEditor/User_guide/he was created by the Translate extension. It's impossible to translate it using the source editor and trying to do this gives the user a link to the translation interface. But it seems to be possible to edit it using the VisualEditor. I didn't actually try to change anything, because I was afraid of breaking something badly.

I'm also not completely sure whether it's a VE or a Translate issue; I file it under VE because there are other issues in which VE behaves differently from the regular edit action, such as Bug 51459. But it may also be on the Translate side; CCing Niklas and Siebrand.

--------------------------
**Version**: unspecified
**Severity**: major
It's never actually been able to bypass the Translate extension's system-level protection of the page - but the problem is you shouldn't be able to trigger VE on the page in the first place, which is bug 50284.

*** This bug has been marked as a duplicate of bug 50284 ***
Urged by Niklas, I tried to save and got: "Unsuccessful request: Unknown error: "tpt-target-page"."

So at least it doesn't ruin anything, but it should be more intuitive.
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}
Change 75083 abandoned by Rillke:
Adding important to overflow:auto on scrollable elements

Reason:
Fixed by If2d5ec3168a874eb4f856450583d6c89967513df

https://gerrit.wikimedia.org/r/75083
I'm pretty sure it's the same issue as on bug 51739.

*** This bug has been marked as a duplicate of bug 51739 ***
Change 75083 had a related patch set uploaded by Rillke:
Adding important to overflow:auto on scrollable elements

https://gerrit.wikimedia.org/r/75083
Many templates are redirects from a short name to a long name. An example is
http://en.wikipedia.org/wiki/Template:Commons_cat which is a redirect to
http://en.wikipedia.org/wiki/Template:Commons_category and has 68742 pages transcluding it. Even though Commons_category has template data specified, and http://en.wikipedia.org/wiki/Template:Commons_cat/doc redirects to http://en.wikipedia.org/wiki/Template:Commons_category the visual editor does not pick up the correct parameters in the template dialog box. 

There should be a way of making the dialog work for redirecting templates without having to duplicate the documentation.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 50964 ***
Discussed at http://en.wikipedia.org/wiki/Wikipedia_talk:VisualEditor/TemplateData#What_about_redirected_templates
Reported on English Wikipedia by User:Cryptic C62:

"Upon opening the transclusion editor, or upon moving a component up/down using the arrows in the bottom left, the Wikipedia search box and accompanying buttons occasionally appear in front of the transclusion editor. The behavior does not occur consistently.

Occurs in Firefox v21.0, cannot replicate in Chrome v28.0"

See image:
http://en.wikipedia.org/wiki/File:VE_Searchbox_Passthrough.jpg

--------------------------
**Version**: unspecified
**Severity**: normal
This was caused by some issues with how the dialogs interacted with the Monobook skin, which have been subsequently fixed. Sorry for the slow triage.
No reproduction steps; likely caused by an old issue in alien content blocks, fixed ages ago.
Which article did this occur on?
In the visual editor, the button to remove formatting activates if the cursor is placed on a formatted (bold or italic) character. However clicking the button has no effect unless text is selected.

Either the button should be disabled when no text is selected, or clicking it when no text is selected should have an effect (probably remove formatting from the current word).

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed by only showing it as enabled when there's a pre-annnotation stack.
Although the interface doesn't clearly indicate this, when the cursor is inside bold text, the toolbar shows "Bold" active. When you then click "Clear formatting", nothing inside the document will change (since no text is selected) however it does affect text entered from this point on.

Basically when your cursor is inside or against bold text, you'd expect text entered after it will also be bold. Clearing formatting at that point means it will unbold your cursor (if you know what I mean).
The English [[Barack Obama]] article has dozens of categories. When editing the categories using Page settings, only the first few of them are visible and editable, and it's impossible to get to the rest of them, because there is not scrollbar.

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed in August; sorry for the slow triage.
As reported on the Swedish feedback page:
http://sv.wikipedia.org/w/index.php?title=Wikipedia%3AVisualEditor%2F%C3%85terkoppling&diff=22695791&oldid=22693792

When there are blank lines before and after HTML comments, it seems like it is not possible to remove all of them. 

Ideally it should pe bossible to edit this version:

http://sv.wikipedia.org/w/index.php?title=Abrostola_major&oldid=21896423

in a way that it gets like this:

http://sv.wikipedia.org/w/index.php?title=Abrostola_major&diff=22695707&oldid=21896423

But in VE editing mode it is not possible to format it like that without accidentaly deleting templates on the page. Is it perhaps because of the HTML comments?

--------------------------
**Version**: unspecified
**Severity**: minor
Yes, this is caused by the lack of ability to edit HTML comments making it impossible for users to understand what they're doing; though there are slightly distinct issues here, I'm going to merge it with that feature request.

*** This bug has been marked as a duplicate of bug 49603 ***
js/lib/pegTokenizer.pegjs.txt currently contains the following:

    var base_urls = {
            'RFC'  : '//tools.ietfs.org/html/rfc%s',
            'PMID' : '//www.ncbi.nlm.nih.gov/pubmed/%s?dopt=Abstract'
        }

base_urls['RFC'] is wrong; the hostname should be tools.ietf.org .

I spotted this when looking at Firebug's HTML tab while VisualEditor was
open on https://en.wikipedia.org/wiki/MD4#Security .

--------------------------
**Version**: unspecified
**Severity**: normal
Change 75118 merged by jenkins-bot:
(Bug 51726) Fixed typo in url base for RFCs

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

https://gerrit.wikimedia.org/r/75118
At the moment, categories are pushed right to the bottom of the page. This is mostly useful, but not always; it causes policy issues if there are stub templates around. While this is not something we can or will support, the fact remains that we're essentially imposing a structure on wikis by saying "categories will always go at the bottom".

What would be a nice way around this problem, at least with existing articles, is to have newly-added categories stuck immediately after existing categories - wherever they are in the page. We get some degree of consistency within articles that would otherwise be lacking.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This is a duplicate of the (heretofore-confusingly-named) bug 50882.

*** This bug has been marked as a duplicate of bug 50882 ***
If you add multiple templates in one transclusion it is possible to rearrange them. Once rearranged, once cannot select the parameters from the first template anymore.

Steps to reproduce:
- Open any random page in the visual Editor.
- Open the "Transclusion" window. Select the "Cite web" template and click the "Add template" button. It should be added with two default parameters.
- Click the + icon in the bottom left of the Transclusion dialog, and click the button to add another template.
- Add another "Cite web" template as described in step 2. Again it should come with two default parameters.

Right now you should have a transclusion window containing two cite web templates.

- Click the bottom template, and press the ^ icon to move that template to the top of the list. 
- Now try to click the default "Source Title" or "URL" parameter in the top template. It is no longer possible to select or alter them. 
- Extra: If you move the other template as well the same problem occurs; In that case both template's parameters can no longer be edited.

Tested on Firefox 22 and Chrome 28 on Windows 7.

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed as part of the transclusion dialog re-write in August; sorry for the slow triage.
Also happens on Linux.
Addendum: It seems that this does not only affect parameters. If you try to move the templates around more then once it will no longer be possible to rearrange them (The buttons for this no longer work). Also, any template "Corrupted" by moving them around will not be added to the page when one presses "Apply Changes".
**Author:** `ignatzmice.wiki`

**Description:**
The button to cancel edits and return to read mode is labeled "cancel"; clicking it brings up a dialog box with buttons "OK" and "cancel". Clicking *that* "cancel" cancels the cancel and returns to editing mode—not blatantly wrong, but confusing. Perhaps the first button should be renamed "discard edits" or similar?

Original thread: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564868353#Ambiguity_in_.22Are_you_sure_you_want_to_cancel.22_dialog.3F See also bug 47676, closed as WONTFIX.

--------------------------
**Version**: unspecified
**Severity**: normal
Merging with bug 50955.

*** This bug has been marked as a duplicate of bug 50955 ***
The confirmation dialog should have more descriptive buttons, such as [Discard edits] [Continue editing], or [Leave editing mode] [Return to editing], etc.

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

In fact, VE shouldn't use native confirm() dialogs; the implementation in most browsers is crappy.
Steps to reproduce:

1) Open https://en.wikipedia.org/wiki/Jam,_Iran?veaction=edit

2) Double-click repeatedly inside one of the templates (e.g. infobox)

The following JavaScript error appears on the console:

Uncaught Error: Offset could not be translated to a DOM element and offset: 442 

Chrome 28/Ubuntu

See also: bug 51526

--------------------------
**Version**: unspecified
**Severity**: normal
I can't reproduce this now' provisionally closing as WORKSFORME. Please re-open if you can still reproduce.
The "leave feedback" link renders in grey, which might suggest to users that is not a functional element. Issue raised by English Wikipedia editor Hhhippo.

--------------------------
**Version**: unspecified
**Severity**: normal
This design was fixed some time ago but I forgot to tag this bug; sorry!
Using Firefox 22.0 on Ubuntu 12.04, English Wikipedia User:Hhhippo notes that "I see an empty line between ''User guide'' and ''Leave'' and another one between ''Leave'' and ''feedback''. My very first thought was that ''Leave'' would be the switch for signing out of the beta test (note that I didn't click it ;-)"

The culprit, evidently is "Ubuntu's default font: DejaVu Sans. That's a bit wider than e.g. Arial, so it causes a linebreak in the link. Maybe one could make that space non-breaking and have the flyout widen instead?"

http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564802026#Follow-up

--------------------------
**Version**: unspecified
**Severity**: normal
This was already reported as bug 51335 (sorry!).

*** This bug has been marked as a duplicate of bug 51335 ***
The image from [1] and is not rendered on VisualEditor [2].

[1] https://pt.wikipedia.org/w/index.php?oldid=36419116
[2] https://pt.wikipedia.org/w/index.php?oldid=36419116&veaction=edit

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51248
I believe that this was a dupe of bug 51248.

*** This bug has been marked as a duplicate of bug 51248 ***
At https://en.wikipedia.org/w/index.php?title=List_of_American_Dad!_characters&curid=2082680&diff=564675517&oldid=564302759 a user added a link using wikitext. The VisualEditor added <nowiki> tags around it (correct according to apparent design, incorrect according to desired behaviour). 

However, it also added <nowiki> tags around every other bit of pre-existing markup in the paragraph. This is incorrect according to my understanding of the design because even if they did want to include a literal string surrounded by square brackets they did not want to alter the existing markup.

Bug 5069 comment 5 suggests to me that this isn't that bug but a different one, but not what number that other bug is.

--------------------------
**Version**: unspecified
**Severity**: normal
This seems to have been fixed (I now can't reproduce) in the re-write of nowiki-ing code; sorry for the bug.
Really sorry, but I meant Bug 50659 comment 5 
Dyslexia + typos to blame so entirely my fault.
Sorry, typo in that last line. It should refer to Bug 50569 comment 5
Using Firefox 24, Ubuntu 13.04

What I did:
1. I was editing a page[1], made several small changes (fixing typos, rephrasing)
2. I clicked "Save page" which brings up the save dialog
3. I wrote a summary and clicked "Save page" again
4. The blue throbber line appears, disappears and leaves me with the save dialog still open (not saving anything)
5. I open the JS console and when I try to save again I see:
  a. The HTML is submitted to the API
  b. Before the response arrives (?) a JS error appears: "TypeError: editApi is undefined"[2]
  c. The API responds with a "200 OK" which includes a JSON error[3]

When I open the JavaScript console I see the following: 1) The HTML is submitted to the API, and while that request to the API is in transit a JS error appears: 

[1] https://www.mediawiki.org/wiki/VisualEditor/Portal/sv
[2] File: https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=en&modules=ext.visualEditor.base%2Cmediawiki%2CviewPageTarget%7Cjquery.visibleText%7Coojs%7Cunicodejs.wordbreak&skin=vector&version=20130717T024027Z&* Line: 85
[3] {"servedby":"mw1203","error":{"code":"unknownerror","info":"Unknown error: \"tpt-target-page\""}}

--------------------------
**Version**: unspecified
**Severity**: normal
%%%*** This bug has been marked as a duplicate of bug 50284 ***%%%
...and when I try to edit it using the traditional "Edit source" I actually get a real error message: "This page cannot be updated manually. This page is a translation of the page VisualEditor/Portal and the translation can be updated using the translation tool."

That message should be shown also when trying to edit with the VisualEditor.
If you place the cursor after the last character of a link and start typing then your text becomes part of the displayed text for that link: [[Fish]] → [[Fish|Fish and chips]] rather than the inte.nded [[Fish]] and chips or [[Fish and chips]] which would be expected from a WYSIWYG editor (even if it isn't what is wanted).

There is no way to edit part of a link at all, the only way around it is to unlink the whole phrase and relink the part you want linked.

This is not usually a problem, as you can work around by starting from after the space after the link.

However, this is counter intuitive if you want to add punctuation after the link (add it after the space, delete the space, add space after the punctuation). It also means it is impossible to add unlinked text when the link ends the line, as happens often on disambiguation pages. For example try adding context to the links at Mandi#People. Apparently a workaround is to insert a line break, add the text and then delete the line break. I've not tested this myself though

It is possible this is the same as bug 50945 but I don't think it is.

--------------------------
**Version**: unspecified
**Severity**: normal
This is actually the same as bug 51463 which we just fixed and are deploying now. Sorry for the inconvenience.

*** This bug has been marked as a duplicate of bug 51463 ***
**JohnCD67** wrote:

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

[[:en:WP:VisualEditor/Feedback#You have to type something after a word before attempting to wikilink it]]
Editor HHHIPPO on English Wikipedia notes that the tab key does not increase indentation (as promised in the greyed out icon on the ribbon) but rather jumps from citation to citation. (For me, it also lands on wikilinks in templates.)

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 48010 ***
On English Wikipedia, a user reports the following:
*Added leading whitespace to paragraph in VE. Text appears fine in VE, with leading whitespace as an indentation.
*Saved. VE adds nowiki tags before the whitespace and after the first few words. Text displays without indent.
*Tried removing the whitespace in VE.
*VE won't allow the whitespace to be removed, but instead will only permit the first few words to be deleted.
This is with Chrome 28 + Windows 7. I'll see if I can work out the conditions that would have created the first problem. - Bilby (talk) 02:37, 16 July 2013 (UTC)
VEspaceremoval.png

I tried to replicate this myself.
*Added whitespace to the lead of an article, and it nowikied. http://en.wikipedia.org/w/index.php?title=Quadrangle_%28architecture%29&diff=564486949&oldid=563578917

*It turned the first word into an uneditable element. See image: http://en.wikipedia.org/wiki/File:VEspaceremoval.png 

*Curious as to what the nowikis would do to formatting, I found an article that had formatting on the first word. It added space, no "nowiki." http://en.wikipedia.org/w/index.php?title=Marloth_Park&diff=564487138&oldid=557816381

* It allowed me to remove the space in VE.


(Also using Chrome on 7.)

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed in July; sorry for the slow triage.
I meat an annoying problem. I tried to upgrade my wiki from 1.20.6 (0727d6a) to 1.22wmf9 in order to use VisualEditor. (nginx/1.2.5 php_version5.3.23 on Linode VPS)

The serves running few wikis using one set mediawiki software. I tried to php update.php the largest 1.5G Chinese version, but the script simple give no response.

example: 
 [root@moegirl maintenance]# php  update.php
 [root@moegirl maintenance]# 
I tried other smaller site, it react like this:
<pre>
MediaWiki 1.22wmf9 Updater

Going to run database updates for enwiki
Depending on the size of your database this may take a while!
Abort with control-c in the next five seconds (skip this countdown with --quick)
 ... 0
[root@moegirl maintenance]#
</pre>
The web updater works good for small wiki, but the 1.5G one will receive "Timeout"

The most annoying thing is when I tried to upgrade same database to 1.22wmf9, all of then works as normal. Only the major linode VPS we are using have this problem.

Anyone had ever meet same problem? Is this a new bug? How to solve it?

--------------------------
**Version**: unspecified
**Severity**: normal
Find out reason. For some unknown reason, the php does not shows error message. When one of my friend tried 

php -n update.php

it showed the error message and we fix it very soon according to it.
The most annoying thing is when I tried to upgrade same database to 1.22wmf9 on other vps, all of then works as normal.
BTW, I tried 1.20.6 and 1.21.1 as well. None of them work in that server.
Dunno why but:

https://en.wikipedia.org/w/index.php?title=Fish&veaction=edit loads VE-edit mode

https://zh.wikipedia.org/w/index.php?title=%E9%B1%BC&veaction=edit doesn't.

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

Well it works for me now on zhwiki.
Do you perhaps have the VE preference enabled on enwiki but not on zhwiki? veaction=edit will only work if VisualEditor is available, i.e. you didn't disable it and it didn't detect some problem with your browser that made it disable itself.
I cant reproduce this now.
From http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#How_did_it_go_to_Vedit_mode.3F

"After saving an V-edit on Shiva, I saved the page. From contents, I clicked on a section. Instead of going to the section, it went in Vedit mode. --Redtigerxyz Talk 09:48, 14 July 2013 (UTC)"


The problem was replicated in at least two articles, and only appears when reorganizing or removing sections.  The editor is running Chrome Version 28.0.1500.72 m and Windows 7 Home edition.  I couldn't replicate it using either Safari or Firefox on a Mac.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows 7
I still cannot replicate this; possibly a transient caching bug?

Marking as INVALID. Please re-open if it recurs.
fwiw, I also tried to replicate it back in July and failed.
Screenshot

Multiple uses of a references are shown in the reference list:

Default: is "1.0 1.1 1.2 1.3" etc.

Some wikis, like dewiki, uses "a b c" etc. 


VE rendering always use the default.

This is configured onwiki with [[MediaWiki:Cite references link many format]]. It depends on usage of $2 or $3:

Default content: [[#$1|$2]]. $2 responsible for showing "1.0 1.1 1.2 1.3" etc

dewiki content: [[#$1|$3]]. $3 is responsible for showing "a b c" etc

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

**Attached**: {F11692}
This is covered by bug 49346 which is assigned and prioritised, so I'm marking this as a duplicate.

*** This bug has been marked as a duplicate of bug 49346 ***
(In reply to comment #1)
> (Are the letters in ref.1 at
> https://en.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/
> Sandbox&diff=next&oldid=570373191
> different from what you describe?)

In read mode I see

1. ^ a b pippo

In VE edit mode I see:

1.   1.0 1.1 pippo

The latter is wrong. I except to see in VE edit mode the same letters a b as in read mode
(Are the letters in ref.1 at https://en.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&diff=next&oldid=570373191 different from what you describe?)
I was surprised to find that I couldn't add any categories with the Visual Editor. I'm sure if we can add images, references, and templates, we should be able to add categories without too much trouble. Is this feature in beta or something?

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

Changing bug summary.
Can't reliably reproduce but I was turning text into a link, enter a url but didn't save the new link target (so it was saved as an internal link with the label as link target), then when entering the Save dialog and saving, this exception was thrown.


> Uncaught TypeError: Cannot read property 'end' of null
  load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cexperimental%2…ageTarget.icons-vector%7Crangy&skin=vector&version=20130716T133516Z&*:9463
* ve.ui.Context.updateDimensions
  load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cexperimental%2…ageTarget.icons-vector%7Crangy&skin=vector&version=20130716T133516Z&*:9463
* (anonymous function)
  load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cexperimental%2…ageTarget.icons-vector%7Crangy&skin=vector&version=20130716T133516Z&*:9499
* proxy
  load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20130715T175253Z:10

--------------------------
**Version**: unspecified
**Severity**: normal
Provisionally closing as WORKSFORME.
*** This bug has been marked as a duplicate of bug 53973 ***
Here's a link that shows one of the main problems with the current approach:  https://hif.wikipedia.org/w/index.php?title=Akbar_the_Great&diff=194531&oldid=194146

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

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

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

There is also no reason for you to suspect that the problem is due to a hidden piped link, because there is no visual cue that you need to go into the link inspector to address the hidden/piped link.
I think this duplicates Bug 50945
We shouldn't put a label input in the link inspector because:

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

Some steps towards a better approach:

1. We could decorate the "linked" portion of a link differently than
   the link trail portion - at lease during certain interactions.
2. We could add extra cursor positions on each side of a link to indicate being
   next to or inside the link tag, decorate the link when you are inside those
   boundaries.
XML file of syndicated watchlist, slightly modified

MediaWiki creates Atom feeds for watchlists. I use a feed reader to read a few on Wikia as well as en.wp. The feeds from Wikia are all sensible and useful but the one from en.wp includes edits that do not exist. Attached is an XML file that I generated with wget (through the assistance of persons on #mediawiki) which I have slightly redacted to remove my watchlist token. Edits which did not occur can be found c. line 229 where the syndication claims that User:FelGru edited the page Everything That Happens Will Happen Today and starting around line 373 there are a spate of edits to categories by User:InMontreal which also did not occur.

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

**Attached**: {F11634}
This seems fixed now for me.
Core should exclude RC_EXTERNAL by default for feeds or the extension has to provide a feed formatter for that row, but should also respect the setting, that external not always include in the result.

You can use wltype=edit|new|log to exclude the external edits.
Problem solved? This user edited d:Q3977961 (several times in a row: https://www.wikidata.org/w/index.php?title=Q3977961&diff=60842173&oldid=37167299 ). Evidently, related items from Wikidata cause these phantom changes to occur...
Recent changes for this article (according to toolserver.org):

mysql> select * from recentchanges where rc_namespace = 0 and rc_title = 'Everything_That_Happens_Will_Happen_Today' order by rc_id desc limit 2 \G
*************************** 1. row ***************************
        rc_id: 590682778
 rc_timestamp: 20130715213627
  rc_cur_time: 20130715213627
      rc_user: 0
 rc_user_text: FelGru
 rc_namespace: 0
     rc_title: Everything_That_Happens_Will_Happen_Today
   rc_comment: 
     rc_minor: 1
       rc_bot: 0
       rc_new: 0
    rc_cur_id: 18622850
rc_this_oldid: 562841657
rc_last_oldid: 562841657
      rc_type: 5
 rc_patrolled: 1
   rc_old_len: 131636
   rc_new_len: 131636
   rc_deleted: 0
     rc_logid: 0
  rc_log_type: NULL
rc_log_action: 
        rc_ip: 
    rc_params: a:1:{s:20:"wikibase-repo-change";a:13:{s:2:"id";i:56980275;s:4:"type";s:20:"wikibase-item~update";s:4:"time";s:14:"20130715213627";s:9:"object_id";s:5:"q6336";s:7:"user_id";i:180688;s:11:"revision_id";i:58328008;s:11:"entity_type";s:4:"item";s:9:"user_text";s:6:"FelGru";s:3:"bot";i:0;s:7:"page_id";i:7449;s:6:"rev_id";i:58328008;s:9:"parent_id";i:58327906;s:7:"comment";s:23:"wikibase-comment-update";}}
*************************** 2. row ***************************
        rc_id: 588688216
 rc_timestamp: 20130704145433
  rc_cur_time: 20130704145433
      rc_user: 205121
 rc_user_text: Koavf
 rc_namespace: 0
     rc_title: Everything_That_Happens_Will_Happen_Today
   rc_comment: fmt
     rc_minor: 1
       rc_bot: 0
       rc_new: 0
    rc_cur_id: 18622850
rc_this_oldid: 562841657
rc_last_oldid: 562815320
      rc_type: 0
 rc_patrolled: 0
   rc_old_len: 131440
   rc_new_len: 131636
   rc_deleted: 0
     rc_logid: 0
  rc_log_type: NULL
rc_log_action: 
        rc_ip: 
    rc_params:
Also, checking https://en.wikipedia.org/wiki/Special:Watchlist does not display these non-existent edits nor does the page history of the individual articles and categories mentioned.
See http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=564459649#Italicizing_wikilinks

When someone italicizes (or bolds) a wiki link instead of placing quote marks around the link itself (like ''[[link]]'' ) it pipes a link with the same text but with quotes (for example [[link|''link'']] ) creating unneeded wikitext.

--------------------------
**Version**: unspecified
**Severity**: normal
This is the same as bug 50098, yes; merging.

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

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

*** This bug has been marked as a duplicate of bug 50098 ***
As I wrote in 50098, to avoid [[Foo|''Bar'']] you should italicize first, and link only after
that. I added this to the Italian User guide and I am looking for other similar tips I might be missing.
Thanks.
It has been noted today that VE still has issues with large pages, so it really shouldn't be adding unnecessary bytes to a page like this.
Reported here: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&curid=37904286&diff=564438586&oldid=564436653

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

Diff:https://en.wikipedia.org/w/index.php?title=Best:_The_Greatest_Hits_of_S_Club_7&curid=3428260&diff=564438205&oldid=564438086

--------------------------
**Version**: unspecified
**Severity**: normal
%%%*** This bug has been marked as a duplicate of bug 50100 ***%%%
Copied from English language Wikipedia:

When the user edits for example, a {{Legend}} template, color picker may be very useful. We should also think about adding there a table of basic colors. --Rezonansowy (talk) 13:32, 15 July 2013 (UTC)

http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564427033#Color_picker

--------------------------
**Version**: unspecified
**Severity**: enhancement
*** This bug has been marked as a duplicate of bug 52645 ***
How can we Disable VisualEditor completely to have old style (for example in en.wikipedia which is activated how can we disable completely the too and make it like old style)?

--------------------------
**Version**: unspecified
**Severity**: normal
In general, VE questions should be filed on [[WP:VE/F]] as that is the best place to give feedback for the VisualEditor.

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

*** This bug has been marked as a duplicate of bug 50929 ***
See https://en.wikipedia.org/w/index.php?title=Wormshill&diff=564367057&oldid=557770558 for example.

--------------------------
**Version**: unspecified
**Severity**: normal
This is caused by an unbalanced <blockquote> in the infobox, which "works" (ish) in MediaWiki's PHP parser but didn't in Parsoid at the time; this is subsequently worked around. Closing as WORKSFORME.
**Author:** `brunsa2`

**Description:**
I currently have VisualEditor running on an Ubuntu Server with Nginx, MediaWiki version 1.22alpha, Node.js 0.8.22. I get timeouts (504) when trying to use the VisualEditor (running Parsoid in debug often gives messages such as:

T:html: {"type":"TagTk","name":"body","attribs":[],"dataAttribs":{}} {
 "0": "WARNING: RETRY:",
 "1": {
   "code": "ETIMEDOUT"
 }
} Retrying Page Fetch request for null, 4 remaining {
 "0": "WARNING: RETRY:",
 "1": {
   "code": "ETIMEDOUT"
 }
}

Retrying Page Fetch request for null, 3 remaining ). I've tried with as many possible headers from a REST client and do not get any errors from Parsoid with that.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC
**Whiteboard**: aklapper-moreinfo
**brunsa2** wrote:

I've upgrades both VisualEditor and Parsoid, after converting wiki installation to  use SSL and then turning it off, Parsoid spontaneously started working.
See http://www.mediawiki.org/wiki/MediaWiki_on_IRC for information on IRC.
Please come on #mediawiki-parsoid IRC channel to debug these issues.  It appears that Parsoid might be having trouble connecting with your mediawiki instance.
When editing a page the editor seems to ignore the "&oldid=prev" parameter entirely. Instead of editing the old revision, the editor loads the most recent revision.

Steps to reproduce:

* Navigate to http://en.wikipedia.org/w/index.php?title=Baylor_University_Institute_for_Oral_History&diff=540967084&oldid=prev
* Press "Edit this Page"

I would except that the editor would load the page currently displayed on the screen. Instead it seems to omit &oldid=prev entirely, and loads the most recent revision instead. 

(Tested on Firefox 22, Monobook skin. Possibly related:50615)

--------------------------
**Version**: unspecified
**Severity**: normal
This seems to now be fixed. Please re-open if you think I'm wrong!
Preference 'Do not show page content below diffs' also affects this bug.

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

If disabled, the diff block on the page should be deleted and the html on the page should be editable as-is.
Hi,

In VisualEditor pagesettings>>languages below MediaWiki:Visualeditor-dialog-meta-languages-section the option button should be available 'Visit ULS language settings' for current {{contentlanguage}}wiki >> Then dialog box of ULS language settings should open up


*To understand further the need for above request,please do refer to survey
data and analysis provided at
http://www.mediawiki.org/wiki/Talk:Universal_Language_Selector#feature_to_make_content_language_input__default_28864

	

Thanks and Warm Regards

--------------------------
**Version**: unspecified
**Severity**: enhancement
Closing as invalid for now. I think what is implicit here, is present explicitly in other, unreferenced issues.
(In reply to comment #5)

What Mr. Amir discussing higher end facilities are welcome.

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

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

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

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

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

**Attached**: {F11465}
(In reply to comment #0)
> In VisualEditor pagesettings>>languages below
> MediaWiki:Visualeditor-dialog-meta-languages-section the option button should
> be available 'Visit ULS language settings' for current
> {{contentlanguage}}wiki
> >> Then dialog box of ULS language settings should open up

Please provide a screenshot of the current problem that you would like to
solve, plus a link to reproduce. 
Also see https://www.mediawiki.org/wiki/How_to_report_a_bug

> 
> *To understand further the need for above request,please do refer to survey
> data and analysis provided at
> http://www.mediawiki.org/wiki/Talk:
> Universal_Language_Selector#feature_to_make_content_language_input__default_2
> 8864

Please summarize the points made there instead of making me read a long thread.
All wikis,other than english wikipedia ULS input options for input should be availabe as dropdown menu on VisualEditor toolbar [[:File:VisualEditor.toolbar.png]] just below the page settings [[File:VisualEditor - Toolbar - Page settings.png|80px]] with sign [[File:WMF-Agora-Input settings-000000.svg]] + enable input methods/'select input method'/name of current selected input method as heading.  



*To understand further the need for above request,please do refer to survey
data and analysis provided at
http://www.mediawiki.org/wiki/Talk:Universal_Language_Selector#feature_to_make_content_language_input__default_28864 


Thanks and Warm Regards

--------------------------
**Version**: unspecified
**Severity**: enhancement
Hi Mahitgar. Thanks for taking the time to report this!
This particular problem has already been reported into our bug tracking system, but please feel free to report any further issues you find.

*** This bug has been marked as a duplicate of bug 49569 ***
Created attachment 12855
Example Needed ULS input method dropdown menu at VisualEditor.toolbar

**Attached**: {F11453}
(In reply to comment #0)
> All wikis,other than english wikipedia ULS input options for input should be
> availabe as dropdown menu on VisualEditor toolbar
> [[:File:VisualEditor.toolbar.png]] just below the page settings
> [[File:VisualEditor - Toolbar - Page settings.png|80px]] with sign
> [[File:WMF-Agora-Input settings-000000.svg]] + enable input methods/'select
> input method'/name of current selected input method as heading.  

It is unclear to me what is requested here. Could you please provide steps to reproduce as a numbered list, click by click, plus the current outcome, and the outcome that you expect?
Also see https://www.mediawiki.org/wiki/How_to_report_a_bug

> *To understand further the need for above request,please do refer to survey
> data and analysis provided at
> http://www.mediawiki.org/wiki/Talk:
> Universal_Language_Selector#feature_to_make_content_language_input__default_2
> 8864 

Please summarize the points made there instead of making me read a long thread.
It would be very usefull if VE added the title of the section automatically to the edit summary, if the user only changed contents in one section. This is not the same request as bug 48429, the section should be added even if the user edited the whole page, but only changed contents of one section.

Rationale: The automatic section in the summary is very usefull if you check edits of other users. Two examples:

1. A user adds a new external link (without summary). Without the section you have to look at the diff, but if the edit summary contained a /* External links */ you can guess what the user did even without summary.

2. You want to find the user who added the image to section "Foo". Even if there are summaries like "+image" this doesn't help you much, but the summary /* Foo */ +image does help you. The section is also usefull if no additional summary is given, in the worst case you have to look at all changes to the whole article and to the section "Foo" to find the author.

Pseudo-algorithm:

1. Find the position of the first and the last change in the new text (i.e. find the common initial and final strings in the old and the new text).
2. Find the first headline above the last change (a line that starts with that character or before it and matches the pattern for headlines).
3. If this headline is before the first change, you found the section.
4. Else look for the next headline before it of higher level.
5. If there is such a headline, go to step 3, else more than one section was changed.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This is the same as bug 50872; merging.

*** This bug has been marked as a duplicate of bug 50872 ***
**ignatzmice.wiki** wrote:

I agree with Michael, this would be very useful.
Screenshot

If you double-click "create reference", having clicked "insert new reference", it generates...well, see the screenshot. Even when the window is closed, this persists for all subsequent loadings of the references tool on that page.

Windows 7, Firefox 22.

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

**Attached**: {F11430}
This has been fixed since July; sorry for slow update.
Reported on EnWiki by John Broughton:

Steps to Reproduce:
(1) Click the "transclusion" icon
(2) In the lower left of the resulting dialog box, hover over the "+" sign until the bracket pair  ("[ ]") is visible; click on that.
(3) Click on "[ ] Content"
(4) Click on "Apply changes"

Now none of the "insert" icons work, and a number of other icons on the tool bar also don't work. (The user guide is silent as to what these brackets are ''supposed'' to do.)

I can confirm the same issue also occurs for me on Firefox 22, Monobook interface.

--------------------------
**Version**: unspecified
**Severity**: normal
We fixed this quite some time ago; apologies for the slowness of updating this bug report.
*** Bug 51437 has been marked as a duplicate of this bug. ***
Galleries are not supported yet (bug 43037), however it is possible to select a gallery object and press delete.  However that operation doesnt appear to work correctly all the time.

Steps to reproduce
1. Go to a page with a gallery (https://en.wikipedia.org/wiki/Branford,_Florida?veaction=edit)
2. Click on the gallery
3. Press delete

Expected results:
The gallery is removed

Actual results:
The gallery object remains, and the object after the gallery is affected.
In the case of [[Branford,_Florida]], the "See also" changes from being a section to being a piece of normal text placed above the gallery.

However, the same procedure at on [[Lip]] results in the 1) gallery being removed (yay!), 2) the two section titles being merged together (not so good).

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed in the re-work of selection and deletion recently; sorry for the slow triage.
When trying to describe complex template parameters there is a need to be able to link to a specific documentation page. For instance in in the Taxobox  there is a need to link to the main doc page
http://en.wikipedia.org/wiki/Template:Taxobox/doc
as there are lots of subtitles in using the template.

Further there is also a need for links in some of the individual parameter. 
For the "name" parameter the description currently reads 

For plants, see [[Wikipedia:Naming conventions (flora)]]. For all other living things, the name should be the most common vernacular name, when one is in widespread use, and a scientific name otherwise.

as the precise policy on whether plants should be given common or latin names is quite involved. There other places where there is a need to provide links to further information: [[Wikipedia:Conservation status]], [[APG III system]] of classification of flowering plants, [[virus classification]], [[Template:Species list]] and [[Template:Taxon list]] for some sub templates used. 

Good documentation requires sufficient detail, more than can be provided in one line. 

I've a few thoughts on how this could be implements, the whole template could have a "documentation": "Template:Taxobox/doc". You could allow wikilinks inside the "description" or provide an optional "link" parameter.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49772
*** This bug has been marked as a duplicate of bug 50656 ***
*** Bug 50656 has been marked as a duplicate of this bug. ***
At [https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564196505#Quotes_in_template_data] there is a related request to allow wikitext generally in Template Data documentation. 

The specific request for the example given there is the <code> tag to all better distinguishing of '' (two apostrophes for italic markup) and " (double quote) by rendering them in a monospace font.
Here in VE, the {{Discogs master}} template usage at the bottom of the page in the external links does not render.

Escaping the ampersand in the page name seems to make it work: https://en.wikipedia.org/w/index.php?title=Bossalinis_%26_Fooliyones&diff=564046051&oldid=564034183

So possible entity escaping problem

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=Bossalinis_%26_Fooliyones&oldid=564034183
confirmed
I think this has been subsequently fixed - can you confirm?
**Author:** `jduranboger`

**Description:**
In Wikipedia in spanish its neccesary tranaslate the interface for link of edit section still apear "edit surce" it should be "editar fuente".

En Wikipedia en español es necesario traducir la interface para el enlace de Editar secciones, sigue apareciendo como "edit source", lo correcto es "editar fuente"

--------------------------
**Version**: unspecified
**Severity**: trivial
[Sorry for bad auto-translation.]

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

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

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

Estoy de acuerdo en que hay demasiados mensajes sin traducir.

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


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

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

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

I agree that there are too many untranslated messages.

To become a translator yourself, please go to:

  https://translatewiki.net/w/i.php?title=Special:UserLogin&returnto=Special%3AFirstSteps&type=signup&uselang=es
Compare
1) https://pt.wikipedia.org/wiki/?oldid=36380720&action=edit&preview=yes
2) https://pt.wikipedia.org/wiki/?oldid=36380720&veaction=edit

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

--------------------------
**Version**: unspecified
**Severity**: normal
Per http://parsoid.wmflabs.org/pt/Usu%C3%A1rio:Helder.wiki/Testes?oldid=36380720 the images have been replaced by Parsoid with <meta typeof="mw:Placeholder" data-parsoid="…"> which is why they don't appear. This is apparently caused by bug 48900 - merging with that.

*** This bug has been marked as a duplicate of bug 48900 ***
Parsoid just adds a missing space in the [link syntax]:
http://parsoid.wmflabs.org/_rt/pt/?oldid=36380720
Sorry if this turns out to be a duplicate - a search trough the bugs containing the words "copy paste" doesn't seem to turn anything up though. 

The problem is as the title says: Cut and Pasting a section in the visual editor will remove all the formatting provided that section contains an image. Tested on Firefox 22, Mono skin.

Steps to reproduce:
- Navigate to https://en.wikipedia.org/w/index.php?title=Microsoft&oldid=563598458 and edit the page with the visual editor.
- Cut the "1972–83: Founding and company beginnings" section entirely. Eg, anything between the "1972–83:" in the section header, and the "Hodgkin's disease.[4]﻿:231﻿" in the section content. (This will also select the image in the section)
- Click the location where the section used to be and paste the text - technically speaking pasting anywhere causes the problem though.

The text that is pasted will be stripped of all formatting, and the image that was selected will be gone as well.

--------------------------
**Version**: unspecified
**Severity**: major
And marking as a duplicate of bug 33105, which is about supporting this functionality.

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

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

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

*** This bug has been marked as a duplicate of bug 33105 ***
Confirming your example.
See also https://bugzilla.wikimedia.org/show_bug.cgi?id=50721
Compare the result of the wikitext
#1
#
#
#
#
#6
in the following URLs:
1) https://pt.wikipedia.org/wiki/?oldid=36373624&veaction=edit
2) https://pt.wikipedia.org/wiki/?oldid=36373624&action=edit&preview=yes

Visual Editor show us a list with 6 elements, but MediaWiki will only display two items.

Maybe this is related to Tidy?

--------------------------
**Version**: unspecified
**Severity**: normal
It would be difficult to sanely edit undisplayed list items. We would basically have to pretend those list items were never there. They would not be editable in the VE. 

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

So overall I am very doubtful that this would be worth it. IMO it is better to fix the wikitext, possibly with a bot. I'm closing this as wontfix for now. Please reopen if there are good reasons why correcting this with bots is not feasible.
This is in Parsoid: http://parsoid.wmflabs.org/pt/Usu%C3%A1rio:Lechatjaune/Testes?oldid=36373624
Copied from English Wikipedia:

I was trying to edit a template in a table after the bug of the references inside template was fixed, but the edit broke the whole table. This was also happening before with the references bug. I don't know if the two bugs were reported together...maybe not. [http://en.wikipedia.org/w/index.php?title=Defiance_%28TV_series%29&diff=563767420&oldid=563763824 Here] is what happened.
<br>When I edited the template with the 12th episode, the cite error didn't appear. But when I clicked to save it, the 12th episode moved at the top of the table when it should be at the bottom. I reverted the edit and re-made it using "edit source". Can this be reported? Thank you [[User:TeamGale|TeamGale]] ([[User talk:TeamGale|talk]]) 16:58, 11 July 2013 (UTC)

**

This one has been around a while, but I think perhaps it wasn't properly reported earlier. I can't fidn it.

--------------------------
**Version**: unspecified
**Severity**: normal
This was the Parsoid complex templates / VisualEditor dirtying edits bug that got fixed months ago; sorry for the very slow triage.
See http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=563842762#Reference_Issues:_Omnibus_Edition

User Joe Decker has detailed the steps necessary to add a reference to an article using a citation template. While I have as per his request entered some of these as separate bugs or enhancement requests, I am opening this one to note the complexity of the process. As he describes it, it is 73+ steps to achieve in VE what can be achieved in 11 in the older processes.

--------------------------
**Version**: unspecified
**Severity**: normal
Merging this in with bug 50768.

*** This bug has been marked as a duplicate of bug 50768 ***
Another editor has created a potential workflow for references. See http://en.wikipedia.org/wiki/User:Looie496/VE_Reference_editor
Unclear why the second option is bolded. An editor on English Wikipedia suggests that if only one of them is going to be bolded (create new source/use an existing source), it should be the other way around.

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed some months ago in the re-work of the transclusion dialog; sorry for the slowness of reply.
**Author:** `kwwilliams`

**Description:**
There have been some bug reports focusing on the ordering of template arguments, but there's also a problem with changing the basic layout of the templates. Look at http://en.wikipedia.org/w/index.php?title=Raven-Symon%C3%A9&diff=563794138&oldid=563793891 where a vandal changed the birthname. The parameter order has been maintained, but the diff is still virtually useless because of the spurious formatting change. If the editor changes the value of one parameter to a template, that change is all that should be made to the source.

--------------------------
**Version**: unspecified
**Severity**: normal
**kwwilliams** wrote:

It's 51150.
You have a choice of bug here, but it will be either 51150 (dirty diff) or 51003 (match style for new parameters and use appropriate style for new transclusions).

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

VE recent changes on enwiki:
https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&limit=100&tagfilter=visualeditor
**kwwilliams** wrote:

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

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

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

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

*** This bug has been marked as a duplicate of bug 51003 ***
The dirty diff is not the question here. Clarifying title.
**wicke** wrote:

Looks like VE bug 51150. Closing as duplicate.

%%%*** This bug has been marked as a duplicate of bug 51150 ***%%%
I think the idea of a TemplateData tag as to whether to keep new lines seems like a good one, if Parsoid would be interested.
Agreed; this is true for existing templates, but it's also an issue when adding a long infobox to a page, for example.

It was suggested by French Wikipedians to add a tag to TemplateData (like '"collapsed" = false') that would indicate to VisualEditor that the community consensus for a given template is to have one parameter per line, instead of cramming everything together (which could remain as the default behavior, and makes sense for many short templates).
In http://en.wikipedia.org/w/index.php?title=Renewable_energy_in_Seychelles&diff=prev&oldid=563530801, the contributor says that he selected the words "diesel generators" for linking, but the editor inserted the nowiki to prevent the plural being part of the display. 

See http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=563816729#Changing_link_text_often_results_in_bad_code.2C_wrong_links_and_unmatched_.3C.2Fnowki.3Es for this and other cases. I'm afraid i'm not quite sure how to report this, since I'm not sure what's happening.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=33091
If the user selects "diesel generator" (i.e., misses the 's'), the resultant HTML would be

  <a href=foo>diesel generator</a>s 

The correct wikitext version of this is indeed

  [[diesel generator]]<nowiki />s

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

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

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

  [[diesel generator|diesel generators]]

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

We could always expand users' selections to what we think they should have selected, but this would make it impossible for users to do some things that they may want to do, albeit less frequently. I'm not sure that preventing users from doing things that they can do in wikitext would be a good solution, in general.
The screenshot is the result of the following:

1. go to article
2. blank article, removing everything
3. type "1"
4. type "2"
..and what you end up with is:

1
12

The text is, in addition, impossible to delete.

--------------------------
**Version**: unspecified
**Severity**: normal
This is the same as bug 50947, I believe - merging.

*** This bug has been marked as a duplicate of bug 50947 ***
I'm seeing something very slightly different to this - see https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=563808463#Odd_bug_after_blanking_page

If it matters I'm using Firefox 22 on Xubuntu Linux. I don't have another browser to test it in (Konqueror is apparently blacklisted from VE).
I reported something similar in Bug 50947, though there I couldn't type at all. Roan asked for JS console output there, so I guess that it would be useful here, too.

This may also be browser-specific.
Screenshot

**Attached**: {F11062}
It would be nice if double-clicking a parameter name in the template inspector - in the 'insert' view - inserted it, to minimise scrolling and such.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Per my previous comment I'm marking this as a duplicate of bug 51143. Feel free to reopen if this is still not working anywhere.

*** This bug has been marked as a duplicate of bug 51143 ***
I think this can be marked as a duplicate of resolved bug 51143 they seem similar and double-clicking a parameter name does insert the parameter for me.
(I think I had reported something similar, but still :) )
Users @itwp also ask for drop-down menu or similar solution in order to choose between values (i.e. gender (M/F) and so on).
Finding the categories under page setting is non intuitive. Adding another icon next to references would help usability.

This is discussed at http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Icons_are_incomprehensible

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50239
We now split this out into the page settings menu, so closing as INVALID given the evolution of the interface.
So hard to find that I assumed it wasn't implemented yet. Now I've seen it.

Why another icon on the top and not direct manipulation at the bottom? Show the categories at the bottom of the page and allow adding / editing / deleting from there. More or less the way HotCat got us used, if possible with a cleaner UI.
See also:
https://www.mediawiki.org/wiki/Thread:VisualEditor/Feedback/Categories
and
https://www.mediawiki.org/wiki/Thread:VisualEditor/Feedback/Smaller_popup_dialog_for_Category_labeling_on_pages?
*** Bug 51452 has been marked as a duplicate of this bug. ***
English Wikipedia user PamD reports that sometimes after replacing one stub template with another she is unable to open the page settings dialog unless she saves and then reedits the page.

I have done a small amount of testing and can confirm that the following steps will reproduce the bug, but only intermittently:

1. Open a page in VE that has one or more stub templates (e.g. any article in [[Category:England stubs]])
2. Delete the/one stub template by selecting it and then pressing the delete key
3. Launch the transclusion tool from the toolbar
4. Enter a different stub template (e.g. Wales-stub), select it from the list and then click "Add template"
5. Add the template to the page by clicking the "Apply changes" button. In my testing I never entered any parameters or options, PamD has not specified whether she does or not.
6. Click the "page settings" button on the tool bar.

If the dialog opens, choose a different article and try again. In my testing it failed to open just under 50% of the time, PamD implies it happens less frequently to her but doesn't specify. 

A bit more detail is at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=563709233#Can.27t_open_.22Page_settings.22_after_changing_stub_template

--------------------------
**Version**: unspecified
**Severity**: normal
I can't reproduce this now; provisionally marking as WORKSFORME.
I've just tried reproducing this again, and it is still happening and still only intermittently (2 of 4 articles I tried)
VisualEditor appears to be inserting "null" into external links occasionally.

Examples:

https://en.wikipedia.org/w/index.php?title=Carrie_(musical)&curid=7695755&diff=563576490&oldid=563235599

at [[Ithaca College]] in [[Ithaca, New York]] by the Macabre Theatre Ensemble,<ref>[null http:///www.icmacabre.blogspot.com]</ref>

----

https://en.wikipedia.org/w/index.php?title=Embarcadero_Delphi&curid=349208&diff=563574811&oldid=561383018

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

--------------------------
**Version**: unspecified
**Severity**: normal
This was an icky bug that we fixed some time ago; sorry for the bug, and for the slowness of triage.
Copied from En Wikipedia:

***
When editing a template, when I click remove template, and then without closing the dialog, click add -> content and enter some text, the template is not removed and the editor hangs on saving and reviewing changes. --WS (talk) 11:47, 9 July 2013 (UTC)

***
Tested with the same result.

Maggie

--------------------------
**Version**: unspecified
**Severity**: normal
Bug 51340 is essentially the same issue, and both are now fixed I believe.
Some users add [[links]] to edit summaries, which can be really helpful; unfortunately as markup it needs checking to ensure that it isn't borked. Accordingly, would it be possible to render the edit summary in the 'review changes' pane, if one has been provided?

--------------------------
**Version**: unspecified
**Severity**: enhancement
(In reply to comment #1)
> I think this duplicates bug 42139

Yeah; merging.

*** This bug has been marked as a duplicate of bug 42139 ***
I think this duplicates bug 42139
De.WP often uses "{{:Target page}} in its disambiguation pages and VE produces two problems: 1) The subsequent non-template disambiguation entry in the list gets sucked into the content of the previous template-entry; 2) the template blocks the option to edit the entries surrounding it. See:

http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=563687401#Transcluded_pages

--------------------------
**Version**: unspecified
**Severity**: normal
Opened Parsoid bug 53368 for the issues described in comment #12 above.
A deeper investigation revealed additional issues:

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

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

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

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

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

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

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

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

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

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

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

John: can you clarify what could be done here? 

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

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

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

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

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

ruwp uses noinclude instead of onlyinclude.

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

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

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

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

ruwp uses noinclude instead of onlyinclude.

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

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

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

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

svwp: 250, all dab pages

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

ruwp uses noinclude instead of onlyinclude.

My SLQ on dewp:
select count(*)
from   templatelinks tl inner join page p on (tl.tl_from = p.page_id)
where  tl_namespace = 0
and    page_namespace = 0
and    tl_from in 
  (select cl_from from categorylinks where cl_to =  'Begriffsklärung')
;
Relevant wikitext excerpt:

| {{:Christian Delius}}
| <!-- Änderungen bitte dort vornehmen, siehe unterhalb des Bearbeitungsfensters -->
| * [[Christina Rau]], geb. Delius (* 1956), deutsche Politologin

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

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

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

Possibly because the onlyinclude on
https://de.wikipedia.org/w/index.php?title=Christian_Delius&action=edit
When a raw URL with no markup (e.g. http://www.sucs.org/~cmckenna/photos/quizes/tq2012/July/Jun03key.png﻿ ) ends in .png, .jpg, .svg or .gif [capitalisation variants not tested] but does not work (e.g. it gives a 404 error) then only the filename portion of the URL (Jun03key.png in this example) is displayed in the visual editor. Visual editor cannot then edit this URL to correct it, meaning that typos, etc cannot be corrected without using the source editor.

Links to other image formats (e.g. tif), html pages, .txt files and pdf files, and all urls enclosed in single bracket markup work as expected and are editable in the Visual editor. See https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox2&oldid=563642435 for my sandbox testing.

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

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

Marking as a duplicate.

*** This bug has been marked as a duplicate of bug 51092 ***
I just attempted to make https://www.mediawiki.org/w/index.php?title=Lua_scripting&diff=728272&oldid=728271 with VisualEditor and got https://www.mediawiki.org/w/index.php?title=Lua_scripting&diff=728270&oldid=664107 instead.

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

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

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

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

Reclosing.
How would the addition be the plugin's fault? It isn't added in the normal edit box, or in any other boxes at that.
From a quick Google, this is a faulty browser plugin of some kind, FoxLingoJs.
Screenshot of ripped-apart link inspector

I can consistently reproduce the following:

* Select an unlinked word
* Create the insert link button (with intention to turn the word into a link)
* If you hit Return immediately after (before it has finished opening) it will replace the focussed node with a new line. Though that is a separate bug and arguably an invalid use case (why would one be pressing Return at this point, the user hasn't even seen the options yet. It interpreting it as intend to replace the node isn't entirely unreasable, but that's a separate bug - bug 51075).
* At this point the link inspector dom has blown up. Part of it is gone, and the other part is left half-way across the screen at a seemingly arbitrary offset (see attachment).

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

**Attached**: {F11776}
*** This bug has been marked as a duplicate of bug 49941 ***
**Author:** `FT2.wiki`

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

http://en.wikipedia.org/w/index.php?title=XFS&diff=563579994&oldid=562618140

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

--------------------------
**Version**: unspecified
**Severity**: normal
Closing as INVALID (this is not a bug, this is exactly expected behaviour). Please re-open if we have mis-judged.
Did you type the text "{{cn}}" into the editor directly? In that case this is correct behavior: we did what was needed to make the literal text "{{cn}}" appear.

To insert a template in VE you'll need to use the puzzle piece icon in the toolbar. Typing wikitext directly into the editor is deliberately not supported.
corrupt <class> identifier in DOM for Link

see screenshot

what is this "class"?

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

**Attached**: {F11753}
It's not corrupt, it's just empty.

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

I don't think this is a real problem - if you have code that takes a different path based on whether the class attribute is set, has a non-empty value, or has a value, I suspect the first two cases should just be folded together.
Reference editing on, for example, https://en.wikipedia.org/wiki/Friedrich_Nietzsche?veaction=edit, sometimes takes you to the wrong citation. I'm not sure what the problem is. My only current theory, as a luddite, is that the difficulties the VE/Parsoid has with references in templates may be responsible for a numbering screwup somehow between read and edit mode.

--------------------------
**Version**: unspecified
**Severity**: normal
Merging this with bug 50474.

*** This bug has been marked as a duplicate of bug 50474 ***
The observation: I was trying to make this edit - http://en.wikipedia.org/w/index.php?title=Friedrich_Nietzsche&curid=10671&diff=563544089&oldid=562894275 - Opened article in VE, saw the "as as" was in footnote 134 ... couldn't edit there ... went up to reference 134, clicked on it to edit, and it was the wrong reference link. It actually gave me the reference that's numbered 220 (in that version) to edit!
See https://en.wikipedia.org/w/index.php?title=User:Okeyes_%28WMF%29/sandbox&diff=next&oldid=563541289 for example; It should be [[''death'' metal]].

--------------------------
**Version**: unspecified
**Severity**: normal
Merging with bug 50098.

*** This bug has been marked as a duplicate of bug 50098 ***
With the sole exception of plaint text followed by italic text, it seems that a separate link is created for each part of the link that has a different bold/italic status:

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

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

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

Expected behaviour: One link is created, e.g. [[link|''one'' two]]
Actual behaviour: Two links are created, e.g. [[link|''one''']] [[link|two]]
Is this still happening? 
In my sandbox just now, VE changed [[Ancient Carthage]] to [[Ancient Carthage|''Ancient'' Carthage]] as I would expect.

https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox2&diff=570143239&oldid=568345382
a screenshot with the problem

To reproduce:

1. Go to https://en.wikipedia.org/wiki/Boris_Ponomarev?veaction=edit
2. Click the template at the bottom of the article.

Observed: The transparent bluish color that shows the template tool (puzzle piece) goes all the way up to the paragraph that precedes the page, even though there's a lot of spacing between them because of the infobox on the side.

Expected: The transparent color must only cover the template itself and not other elements.

See the screenshot.

Tested on Firefox 22.

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

**Attached**: {F11723}
This is caused by the phantom starting from the logical position of the content, rather than the rendered position (due to the width being 100%). Merging with bug 50395.

*** This bug has been marked as a duplicate of bug 50395 ***
Possibly the most vanilla dirty diff ever, if it is a dirty diff - in https://en.wikipedia.org/w/index.php?title=The_Painted_Bird&diff=563388980&oldid=544897993 the VE has added an extra space (before "novel").

--------------------------
**Version**: unspecified
**Severity**: normal
This seems to be bug 48570

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

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

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

I notice that in these 2 cases, as well as in the case reported in comment 1, there's an adjacent colon. Dunno if it's related.
Talking about spaces: https://en.wikipedia.org/w/index.php?title=Genie_%28feral_child%29&diff=564429158&oldid=564425048
Same thing here after "équipes": http://fr.wikipedia.org/w/index.php?title=Mafia_%28jeu%29&diff=94892395&oldid=91395852
On enwiki, at least. If you highlight a link, format-clearing does nothing; if you click on the link to the point where the system registers (i.e., the link icon pops up), ditto.

--------------------------
**Version**: unspecified
**Severity**: normal
Yeah, this is a really irritating regression; merging with the other.

*** This bug has been marked as a duplicate of bug 50461 ***
Yes, the toolbar button ("No" symbol) gives the impression that it should remove every skerrick of formatting from the text, including links.
See https://en.wikipedia.org/w/index.php?title=Vicarious_Visions&diff=563488422&oldid=563388782 and https://en.wikipedia.org/w/index.php?title=Vicarious_Visions&action=edit&oldid=563488422 for how the markup for that appears.

--------------------------
**Version**: unspecified
**Severity**: normal
This is now fixed (and has been for some time, I believe). Sorry for the disruption.
Ditto - https://pl.wikipedia.org/w/index.php?title=Wikipedysta:Sir_Lothar/brudnopis2&diff=prev&oldid=37137604
I don't think that this is just a problem with browser extensions misbehaving over links.  This edit:

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

involves no links, and yet the data is still placed after a line break and smashed up against the following parameter, instead of up on the previous line where it belongs.
Some broken browser extension sometimes adds lots of  <a class="ktg6us78hf8vdu7" href="javascript:void(0)">...</a> tags around items which is tracked by and edit filter. Attempting to clean these up with the VE worked well in the main text but failed in the templates changing

{{Infobox company
...
| foundation     = [[1990 in <a class="ktg6us78hf8vdu7" href="javascript:void(0)"><a class="ktg6us78hf8vdu7" href="javascript:void(0)">video</a></a> gaming|1990]]
| products       = [[Crash Bandicoot|''Crash Bandicoot'' series]] (2002-2004) (2013- )<br>[[Skylanders|''Skylanders'' series]] (2011-2013)0)">Guitar</a></a> Hero|''Guitar Hero'' series]] (2007–2010) 
...
}}

Into
{{Infobox company
|<nowiki>1990]]</nowiki>
|''Guitar Hero''<nowiki> series]] (2007–2010) </nowiki>
...
| foundation     = <nowiki>[[1990 in video gaming</nowiki>
| products       = [[Crash Bandicoot|''Crash Bandicoot'' series]] (2002-2004) (2013- )<br>[[Skylanders|''Skylanders'' series]] (2011-2013) Guitar Hero
...
}}
splitting the foundation and product parameters.
There appears to be an elusive bug in the references editor where, when a reference contains a template, the blue highlight surrounding the template in the reference is sometimes misplaced outside the references editor and therefore not usable. 

I've seen this myself a couple of times (in Chrome/Ubuntu), and it usually just stopped happening after a while and I'm not able to repro it now, so it may be some kind of timing issue. Robert Rohde also reported this today (July 8) and provided a screenshot of the bug here:

https://upload.wikimedia.org/wikipedia/en/5/5f/Bad_Ref_Edit.png

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 50913 ***
1) Open an article such as
https://en.wikipedia.org/wiki/Convex_function?veaction=edit
2) Click in a non-linked word "function"
3) Click in the link button (CTRL+K)

The list of matching pages will include the disambiguation page "[[Function]]", which should actually be avoided.

Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g. by having a section in the dropdown menu labeled "Already used links...")

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50160
This is a duplicate of bug 50240; yes, this would be a nice enhancement to get done soon.

*** This bug has been marked as a duplicate of bug 50240 ***
See also gerrit change 70564.
PS: this was inspired by the commit message of
https://gerrit.wikimedia.org/r/#/c/72646/
How to reproduce:
* Go to https://www.mediawiki.org/wiki/Extension:TimedMediaHandler/Client_download?veaction=edit
* Set the caret behind "supported by the Timed Media Handler extension"
* Try to drag and drop "Support for Ogg Theora and WebM" directy to where you have set the caret.

Current behaviour:
* Selecting not possible (Dropping mode starts immediately like if something is selected but the caret suggests that nothing was selected)

Expected behaviour:
* I can select "Support for Ogg Theora and WebM"

----
You receive this bug's description kindly in English.
Rainer Rillke

--------------------------
**Version**: unspecified
**Severity**: major
Hey, sorry for the confusion; merging with bug 50643 which is about disabling Firefox's misleading interface.

*** This bug has been marked as a duplicate of bug 50643 ***
Selecting text works at the page you provided but drag and drop does not work.
(In reply to comment #3)
> try it on another page like
Selecting text work at the page your provided but drag and drop does not work.
----
You receive this bug's description kindly in English.
Rainer Rillke
(In reply to comment #3)
I tried editing 2 pages on MediaWiki wiki so far and it did not work as I expected. If it can't deal with <translate> tags, it must be disabled on these pages. Thank you.
It seems related to the <translate> tag, try it on another page like https://www.mediawiki.org/wiki/VisualEditor/Basic_example_worksheet
As selecting text is a basic operation, bumping to a major issue.
FF 22
There are so many things that do not work, I suggest to test the software better before deploying. I will open a second ticket for a new recent issue.

--------------------------
**Version**: unspecified
**Severity**: normal
> especially as you are not forced to use it.
If a button ("Edit") that previously did something else, now shows VE, it is "forcing" IMHO.

I think VE will be a great tool but as with UploasWizard please understand the community is not a playground.
(In reply to comment #0)
> There are so many things that do not work

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

I suggest to test the software better before deploying.

See above - testing has taken place for months.

There are no plans to turn VE off currently, especially as you are not forced to use it.
If there is a link to an non-existent article or page it shows up in red when viewing a page.  When you click to edit with VisualEditor, the redlink shows up as blue which makes it appear that it is linking to a page that has already been created. 

For example, in my sandbox I created a link to the non-existent page "testinggg" using [[testinggg]] in source.  After saving the page I returned to the sandbox and saw the link in red.  I clicked to edit the page with VisualEditor, and the link turned blue.  It should remain red if the page has not yet been created.  You can try this for yourself in my sandbox:

https://en.wikipedia.org/wiki/User:Keegan_(WMF)/Sandbox

This may be a Parsoid issue?

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 37901 ***
I tried to copy text from a plain text file (in the Kate editor). The line endings were not preserved and the whole text was copied as one big paragraph.

You can see an example here:
https://www.mediawiki.org/w/index.php?title=Language_portal/Definition_of_Done&oldid=726988

It's the first version of a page that I created in the VisualEditor. I formatted the first few lines manually, but left the blob in the end as is.

--------------------------
**Version**: unspecified
**Severity**: normal
This should be fixed up by the fixing of bug 33105.

*** This bug has been marked as a duplicate of bug 33105 ***
This is a WONTFIX; VisualEditor is not specific to the English Wikipedia, and it is neither appropriate nor sane to create specific dialogs for each of the thousands of templates on hundreds of wikis.
screenshot of CE after transclusion editor

https://en.wikipedia.org/wiki/Luton?veaction=edit

Edit the infobox template. Don't do anything, but apply changes. A lot of the blue links in the infobox are now rendered as black pipe code, for example [[List of towns in the United Kingdom|Town]] instead of Town.

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

**Attached**: {F11424}
*** This bug has been marked as a duplicate of bug 50801 ***
Take a page with a reasonably sized infobox.
Make your browser window 11" size or something
Scroll down a bit
Click the infobox

The infobox has become selected, but the anchor for the editor, being in the top right, is often out of view well under the toolbar. This leaves the user without a proper hint.

--------------------------
**Version**: unspecified
**Severity**: normal
@Chris, yes, they are the same.

*** This bug has been marked as a duplicate of bug 49922 ***
Is this the same as bug 49922?
In some respects the save dialog is partially modal, which is a strange and unfamiliar concept to some.

The content is not editable, and partly blurred. Yet I can click links inside the content. The buttons in the toolbar have a functioning look, but don't actually work. Also, when clicking outside this dialog, I would expect it to dismiss, but it doesn't.

--------------------------
**Version**: unspecified
**Severity**: normal
This is an artefact of not being a "proper" dialog, which is bug 48566 - we hope to fix that in the next week or so. Sorry for the delay in triaging.

*** This bug has been marked as a duplicate of bug 48566 ***
Oh, and you can select and copy and paste text from the disabled edit surface, when the save dialog is open.
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
*** Bug 50724 has been marked as a duplicate of this bug. ***
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 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 72230 merged by jenkins-bot:
(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

https://gerrit.wikimedia.org/r/72230
If a user triggers the abusefilter through the VE, they're informed "'''Error:''' The modification you tried to make was aborted by an extension hook".

Probably not helpful.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 50472 ***
With VisualEditor enabled the shortcut alt+shift+e no longer works, which previously opened the "edit source" page.  Considering many users work without a mouse on a laptop, it would be beneficial to have this enabled.

--------------------------
**Version**: unspecified
**Severity**: normal
Sorry about this; we fixed this just a few hours ago. Merging with the other report.

*** This bug has been marked as a duplicate of bug 50725 ***
Try removing the whitespace at the top of https://en.wikipedia.org/wiki/Burr%E2%80%93Hamilton_duel and see what happens.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://parsoid.wmflabs.org/en/User:Jdforrester_(WMF)/Bug_50797?oldid=564303673
http://en.wikipedia.org/w/index.php?title=Burr%E2%80%93Hamilton_duel&oldid=561095260&veaction=edit shows the whitespace, and it also seems to be possible to delete a line there by focusing it and pressing 'delete'. Newlines that don't produce a paragraph are also preserved in HTML, but are not editable in wikitext.

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

Closing as worksforme. Please open a bug against VE if you have trouble with focusing or deleting the <br>.
So, to understand this bug - this is about where is some (mistaken/wrong) wikitext with an extra new line in front of a block template that gets swallowed by Parsoid into the template that follows it (but can't be removed from there as Parsoid quietly hides that)?

(Note that the second extra whitespace is a normal <br> and so shown in VisualEditor as a "↵" and can be removed in-line.)
Permanent link to the relevant page revision:

http://en.wikipedia.org/w/index.php?title=Burr%E2%80%93Hamilton_duel&oldid=561095260
This is NOT a duplicate of 47790

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

If you look at https://en.wikipedia.org/wiki/Burr–Hamilton_duel you will see that the first line is slightly below the infobox. In VE mode, https://en.wikipedia.org/wiki/Burr–Hamilton_duel?veaction=edit they look to be at the same height. The linebreaks at the top of the source seem to have been 'compressed' and are ignored in VE, while they do have effect in render mode.
*** This bug has been marked as a duplicate of bug 47790 ***
We very deliberately have user-specific preferences for default image sizing, rather than specify a fixed size in each article - it compensates for varying screen sizes. The VE isn't factoring default size preferences into account.

--------------------------
**Version**: unspecified
**Severity**: normal
Related to bug 47804 too.
*** This bug has been marked as a duplicate of bug 50379 ***
In the case of an edit conflict, the structure of the VE means that the common workaround (taking discrete wikimarkup changes, copying them, opening the newly revised article, pasting them in) doesn't work. What's the plan to handle ECs in the VE?

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #0)
> In the case of an edit conflict, the structure of the VE means that the
> common workaround (taking discrete wikimarkup changes, copying them, opening
> the newly revised article, pasting them in) doesn't work. What's the plan to
> handle ECs in the VE?

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

It's been this way for months. There are enough bugs filed without adding ones. :-)
Copied from English Wikipedia:

When I've added one template using the transclusion icon, please offer me a button which says "Add another template", rather than insisting I click on various totally non-intuitive bits of the window to achieve this! I've just managed to add two separate stub templates, but it was still an uphill struggle. PamD 07:32, 4 July 2013 (UTC)

--------------------------
**Version**: unspecified
**Severity**: enhancement
Re-worded the summary; I don't think that this is a route we want to go, so marking as a WONTFIX.
Maggie: Feel free to drop "Enhancement request:" from the report summary and to set severity to "enhancement" instead. Thanks. :)
See https://en.wikipedia.org/wiki/File:VisualEditor_-_Cite_template_layout_issue_%28TemplateData%29.png - Firefox 22, Monobook.

--------------------------
**Version**: unspecified
**Severity**: normal
%%%*** This bug has been marked as a duplicate of bug 50728 ***%%%
If you add categories to a page and save, the newly-loaded version does not include the new additions.

--------------------------
**Version**: unspecified
**Severity**: normal
Yeah, this would be a good one to fix; merging with duplicate.

*** This bug has been marked as a duplicate of bug 48560 ***
An additional note about this on English Wikipedia, with the sensible suggestion that editors are likely to think they have done something wrong when they save the page and their changes do not appear to have worked.
This edit:

https://en.wikipedia.org/w/index.php?title=Percy_Jackson:_Sea_of_Monsters&diff=562794756&oldid=562792500

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

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 50835 ***
Other example:
http://en.wikipedia.org/w/index.php?title=Beximco&diff=562685500&oldid=562676888
I can't seem to find a way to add alt text to images, which is pretty important from an accessibility POV. Any mechanism I'm missing?

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 38129 ***
This came from the VisualEditor feedback page in Hebrew. I couldn't replicate, but the problem is evident in this diff:

http://he.wikipedia.org/w/index.php?title=%D7%A2%D7%96%D7%99_%D7%90%D7%99%D7%96%D7%91%D7%99%D7%A6%D7%A7%D7%99&diff=14341709&oldid=14341704

The user only changed the link at line 20 (blue, left) but VE seemed to have injected a bunch of wikitext into the template box above.

--------------------------
**Version**: unspecified
**Severity**: normal
After talking to gwicke, this seems to be a temporary bug either related to some caching problem or an issue that was resolved, since it cannot be replicated and a lot of other updates were done that fixed related problems.

Closed as likely fixed.
I couldnt reproduce it on
https://he.wikipedia.org/wiki/User:John_Vandenberg/test

I cant find any bug for visualeditor dumping in a subst:ed copy of a template.  Very strange.
This null edit to an article (https://en.wikipedia.org/w/index.php?title=List_of_Sam_%26_Cat_episodes&diff=562710419&oldid=562703260) made the category hidden inside of a template in use on the page (template in question: http://en.wikipedia.org/wiki/Template:Episode_list) visible in the editor. It should not be visible.

--------------------------
**Version**: unspecified
**Severity**: normal
This was a bug in DM/Parsoid interaction that we fixed months ago; apologies for the slowness of updating.
Another example: https://fr.wikipedia.org/w/index.php?diff=94601807
**Author:** `wikipedia`

**Description:**
Using the [edit] next to the lede (section=0) only allows invoking the source editor.

Ideally there should be consistency, and VE options should either be always shown, or never shown.

--------------------------
**Version**: unspecified
**Severity**: normal
ve.init.mw.ViewPageTarget.prototype.setupSectionEditLinks in /modules/ve/init/mw/targets/ve.init.mw.ViewPageTarget.js in mediawiki/extensions/VisualEditor.

(It's painful to look at.)
I recall the pertinent gerrit revision as being https://gerrit.wikimedia.org/r/#/c/69984/ which should give some pointers.
Can someone point me to the code that is building the VE edit section links ?
**wikipedia** wrote:

Forwarded to:

  http://en.wikipedia.org/wiki/User_talk:TheDJ#edittop.js:_VisualEditor
The gadgets are maintained by volunteer developers (in this case, TheDJ). It's the responsibility of gadget authors to ensure compatibility with MediaWiki, not the responsibility of MediaWiki developers to ensure compatibility with gadgets. We have ~700 projects, many of which will have their own gadgets; ensuring everything we deploy is always compatible with every one of them is to tie us into knots.
**wikipedia** wrote:

As of 2013-07-03 11:42 BST, there were 22,009 accounts with gadgets-edittop enabled.
See https://en.wikipedia.org/wiki/File:Visual_Editor_-_Implosion_screenshot_for_bugreport.png - it only seems to appear if you have previously resized a different image.

--------------------------
**Version**: unspecified
**Severity**: normal
[17:29] <Excirial> Could anyone mark bug 50651 as resolved? I think some new rollout fixed the issue since it no longer occurs (Ironholds reported it for me, so i cannot edit its status).
[17:30] <Technical_13> Resolved fixed?
[17:30] <Technical_13> !b 50651
[17:30] <wm-bot> https://bugzilla.wikimedia.org/50651
[17:30] <Excirial> Yes, confirmed that the problem no longer occurs.
[17:30] <Technical_13> Kk
There are currently two similar, but distinct post-edit notifications on some Wikimedia wikis. I'll attach screenshots from <https://test.wikipedia.org> momentarily.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**swalling** wrote:

The current plan is to convert VE to use the same notification style as Extension:PostEdit previously did, now that it's been fully migrated to core (bug 48276)

%%%*** This bug has been marked as a duplicate of bug 39632 ***%%%
Created attachment 12739
Post-edit notification using wikitext (source) editor on test.wikipedia.org

**Attached**: {F11760}
Created attachment 12738
Post-edit notification using VisualEditor on test.wikipedia.org, 2013-07-03

**Attached**: {F11759}
There seem to be several dirty ref sections in this diff:

https://en.wikipedia.org/w/index.php?title=God_of_War_%28series%29&diff=prev&oldid=562631132

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 48570 ***
To reproduce

1. Click puzzle piece
2. Type cn ([[Template:cn]] redirecting to [[Template:Citation needed]])
3. Press enter twice.

(I was experimenting see if there is a quick way to get out of the template dialog; this would be useful for templates like Template:cn that are commonly added without parameters).

4. Type 'foo'
5. Click 'Apply changes'
6. It shows 'Template:Fooifsubst'
7. Code is generated as '{{Cn| = foo}'

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed quite some time ago; many apologies for being so slow to reply.
Upon re-opening it, though, it shows part_0/.
I forgot to add: It shows part_1/ on the left where the parameter names go.
**Author:** `wikipedia`

**Description:**
To reproduce:

1. http://en.wikipedia.org/wiki/High_Speed_2?veaction=edit&vesection=6
2. Wait, hopefully the VisualEditor loads, and does not hang
3. Click "BETA"
4. Click Leave.
5. Try to type in this dialogue box

What happens:

6. The window scrolls around with each and every keypress.
7. The Leave BETA dialogue is very hard to complete.

What should happen:

6. The window should not scroll
7. The process of leaving should be easy and reliable.

--------------------------
**Version**: unspecified
**Severity**: normal
Sorry about this bug; we fixed it a few days ago and deployed it to the servers - merging with that report.

*** This bug has been marked as a duplicate of bug 50538 ***
**wikipedia** wrote:

Video of VisualEditor jumping around while typing in Leave dialogue.

Third attempt at video attachment of issue (failed on creation).  Truncated with 'dd if=visual-editor-madness.ogv of=visual-editor-madness-10240kB.ogv bs=1k count=9999'

**Attached**: {F11691}
When editing a section with VisualEditor the page loads and saves just fine.  However, if you next edit a different section *without refreshing the page*, VisualEditor does not recognize the version of the page you just saved as what you are editing and loads the last revision and warns you that you are editing an old revision.  This occurs in Chrome and Firefox using Windows 7 as I've tested it.

From https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Editing_section_results_in_dirty_page_cache_--_have_to_reload_page_before_doing_additional_edits

--------------------------
**Version**: unspecified
**Severity**: normal
This is a really irritating bug, yes; sorry about this - merging with the wider report at bug 50441.

*** This bug has been marked as a duplicate of bug 50441 ***
New editors are likely to edit a page, save it, have an afterthought, see this message, and panic. It just keeps on happening: experienced editors know the work-round (hit "refresh").

Until the problem is fixed, could the error message in that pink box be amended to include "Please click "Cancel" to close the editor, then reload/refresh the page, then try again. We apologise for this temporary problem and are working on a solution."?
It's not just after section editing: see many reports on feedback page. I edit a page in VE, save page, have an afterthought, reopen in VE, get told it's an old revision. Then cancel VE, refresh page, reopen VE, no problem. But shouldn't need to do that refresh.
Not sure if this is possible, but a user raises concerns about the behavior of VE opening the whole page for editing instead of editing specific sections, given that it increases the load time.

See:
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=562566677#edit_one_section_only

--------------------------
**Version**: unspecified
**Severity**: normal
Looks like it, yes!

%%%*** This bug has been marked as a duplicate of bug 48429 ***%%%
Is this a dupe of bug 48429?
It also means that more bandwidth is consumed than the user asked for, which could be a problem in some cases (particularly on slow connections).

On busy pages it is likely to lead to more edit conflicts, due to increased load times and encouragement to edit multiple sections.
Note that this constitutes the interface basically lying about what it's going to do, hence its disconcerting nature.
**wikipedia** wrote:

To reproduce:

1. Visit a page, eg. http://en.wikipedia.org/wiki/High_Speed_2#Legal_challenges
2. Hover over the section "[ edit ]"
3. Expands to "[ edit | edit source ]" (both with equivalent URLs)
4. Observe that the link is: http://en.wikipedia.org/wiki/High_Speed_2?veaction=edit&vesection=6
5. Click the link.

What happens:

6. The page jumps
7. The page freezes
8. The page is partially whited-out
9. (If it happens to complete loading).  A massive toolbar obscures where the cursor was.

What should happen:

6. The page should remain exactly where it was, it should not move
7. The page should remain interactive
8. The page should remain readable
9. The editor (visual or textedit) should correspond to only that section.
Similar to bugs 50093 and 50527; users need to be warned when they're using markup in the VE. This is a source of a pretty large amount of corruption on enwiki, and I'm not sure how sustainable the community's patience for that is.

--------------------------
**Version**: unspecified
**Severity**: normal
%%%*** This bug has been marked as a duplicate of bug 49820 ***%%%
I strongly advise that this be made pretty high-priority (See above).
**Author:** `warnckew`

**Description:**
Screenshot showing infobox DIV HTML code

Launching VisualEditor to edit http://en.wikipedia.org/w/index.php?title=United_Nations_Security_Council_Resolution_1693&oldid=541044487 makes the heading of the infobox show some unexpected HTML contents, as shown in the attached browser screenshot.

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

**Attached**: {F11621}
This is the same as bug 50366 - merging with that one.

*** This bug has been marked as a duplicate of bug 50366 ***
I have noticed an unexpected behavior while tesing Visual Editor with Malayalam Wikipedia. Describing the steps below:-

1. Added the following text on a page

ഡിസ്രയേലി

2. When pressing a backspace immediately after the above text, it becomes

ഡസരയ

ie. many characters in between the original text disappeared. The expected result was ഡിസ്രയേ

--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Windows 7
**Platform**: PC
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50507
Now the problem has been solved. You may mark this bug as resolved.
(In reply to comment #1)
> @vssun: Any specific browser? Can't reproduce it in Chrome.

I could able to reproduce with Chrome (Version 27.0.1453.116 m)/windows 7
The bug 50507 is very much related to this. There, the reporter says that the characters ്, െ etc are not allowed to type.

Here the case is different but the characters are same. Characters, ി, ് and േ  (the vowel symbols of malayalam, which are joined together with preceeding consonants) are disappearing when pressing the backspace.
Browser was Firefox 22.
@vssun: Any specific browser? Can't reproduce it in Chrome.
Steps to reproduce:
* edit a page with VE; save
* edit the same page with VE

Expected result: normal editing, no warning
Actual result: there's a warning telling the user they're editing an old version of the page

--------------------------
**Version**: unspecified
**Severity**: normal
Yeah, really sorry about this - this is bug 50441. Very high priority in getting this fixed.

*** This bug has been marked as a duplicate of bug 50441 ***
See http://en.wikipedia.org/w/index.php?title=Michala_Petri&diff=562483360&oldid=562482770

It looks like VE inserted categories and default sort at some random place in the DOM, potentially cutting encapsulated transclusion content in two?

The Parsoid template encapsulation and round-tripping for this page looks fine:

http://parsoid.wmflabs.org/_rt/en/Michala_Petri?oldid=562482770

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 50120 ***
Same issue:
https://en.wikipedia.org/w/index.php?title=Richard_Mouw&curid=1175244&diff=562498507&oldid=562498198
I've observed this myself:

Clicking "Page settings", or the reference, image, and category buttons in the top right brings up a dialogue box for input. To close this box there is an X in the top right. However, when I am not at the top of the page, this dialogue box pops up beneath the standard editing options. This makes it impossible to close the box without adjusting the screen magnification.

In addition, the opening of these boxes freezes scrolling of the underlying page, which not only furthers the problem above, but is also simply annoying and unnecessary, as I can no longer move to another part of the article I wish to see without closing and reopening the box. Reywas92Talk 03:00, 2 July 2013 (UTC)

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed earlier this month as part of the general clean up of positioning; sorry for the slow response.
This edit was flagged by VE as DOM-differing, and looks like a dirty ref/transclusion:

https://en.wikipedia.org/w/index.php?title=Abolitionism&curid=38894&diff=562492192&oldid=560500423

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed in Roan's DOM dirtying fixes drive in July.
(In reply to comment #1)
> Only difference is the removal of two spaces after equals signs.

In which part of the DOM is this change? An attribute value?
Only difference is the removal of two spaces after equals signs.
**Author:** `Shirudo`

**Description:**
While filling out the feedback form, the form jumps down the screen with every keystroke, until it's mostly out of view.  Once there, only the current line that I'm typing in is visible right above the edge, and every few keystrokes (seemingly randomly) make the entire screen jerk up and down quickly.  If I scroll down or drag the form back up so that it's centred again, it just jumps back down once I begin typing again.

If it makes a difference, I'm using Firefox 22 on Fedora 18, with Gnome 3 Fallback.

--------------------------
**Version**: unspecified
**Severity**: normal
*** Bug 50533 has been marked as a duplicate of this bug. ***
*** Bug 50602 has been marked as a duplicate of this bug. ***
Sorry about this bug; we've fixed this and just deployed it live.
Change 71844 merged by jenkins-bot:
Listen to keypress in ve.ce.surface.$ rather than window

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

https://gerrit.wikimedia.org/r/71844
This has also been reported on Firefox 22/Windows 7, and by a third user who hasn't specified browser/OS.
This sounds really unhelpful; sorry about this.
Enter a wiki with VE and ULS. (Enable ULS in preferences if needed.)

Start editing a page using VE. Press the headings style dropdown.

Observed: IME selector appears near the dropdown.

Expected: IME selector must not appear. It's not a place for writing things.

Background: there's an <input> element hiding there to capture click events (according to Roan).

https://gerrit.wikimedia.org/r/#/c/68339/ may be able to fix it (though some modifications may be needed).

--------------------------
**Version**: unspecified
**Severity**: normal
**Whiteboard**: ve
Change 72356 merged by jenkins-bot:
Remove unnecessary ULS IME selector from VE headings menu

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

https://gerrit.wikimedia.org/r/72356
I tested, and my assumption is correct: If https://gerrit.wikimedia.org/r/#/c/68339/ is merged, then this bug can be fixed by adding:

$wgULSNoImeSelectors[] = 'ul.ve-ui-menuWidget input';
I note that if an editor uses old markup in VE (like [[link]]), it gets enclosed in <nowiki> tags

Could we have an additional tag added to the Edit summary, (similar to the Visual Editor tag we have?) which states somethine like "Old wiki markup"

That way, we can keep track of, and rectify all the cases where the old wiki markup is used while using VE, and remedy it rather than clutter dozens of article with nowiki tags which might not be removed for days

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49820
**nykevin.norris** wrote:

Removing self from CC.  Tired of spam.  Bug is dead, people.
**kwwilliams** wrote:

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

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

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

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

That is bug 49686, not this one.  Why are we discussing it here?
**kwwilliams** wrote:

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

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

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

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

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

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

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

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

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

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

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

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

None? None ever? Not even when a user of VisualEditor creates a bolded or italicised possessive? :-)
**kwwilliams** wrote:

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

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

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

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

There are many cases where nowiki's are ment from the wikitext. In code samples documentation of templates etc. they always explicitly typed indication an intention from the user.
**nykevin.norris** wrote:

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

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

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

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

[1] http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070253.html
There is now an edit filter to detect insertion of nowiki's
http://en.wikipedia.org/w/index.php?title=Special:AbuseLog&offset=&limit=500&wpSearchFilter=550
FYI, in the meantime, I've requested an edit filter to be added to identify nowiki tags in the main namespace on the English Wikipedia:
https://en.wikipedia.org/w/index.php?title=Wikipedia:Edit_filter/Requested&oldid=562811538#nowiki_in_main_namespace

There's now also one on the French Wikipedia.
**nykevin.norris** wrote:

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

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

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

https://en.wikipedia.org/wiki/Wikipedia:Help_desk#Problems_editing_with_beta_versions.3F
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#.22Submit.22_button_doesn.27t_show_up

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

--------------------------
**Version**: unspecified
**Severity**: normal
Given that it's been 25 days without further reports or information about the original issue, I'm marking this as INVALID.
Can they take a screenshot and attach to this bug? It'd be helpful to understand what it now showing up looks like.
Pamd reports:
If I open [[Queen Anne Grammar School]] in VE, I can see two superscripts linking to references - and 29 references in the reflist. Some of them perhaps most, are the refs which were deleted in a [http://en.wikipedia.org/w/index.php?title=Queen_Anne_Grammar_School&diff=562382386&oldid=562381869 series of edits] 9 hours ago while the article was being moved from AFC to mainspace. If I open it in Edit Source, it's a respectable little stub with two refs and no sign of the other stuff.

Full report at http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#VE_picking_up_old_version_of_file.3F_-_27_ghost_references.21 .

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

--------------------------
**Version**: unspecified
**Severity**: normal
Yes, same issue as bug 50380.

*** This bug has been marked as a duplicate of bug 50380 ***
I cant reproduce this using the example given.

It looks like this may be a dup of bug 50380.
When marking all content on a page, and hit «delete», then, while the content is removed, also the input marker is removed, so you can't input anything new directly.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #1)
> Is this the same as Bug 50947 and/or Bug 51169?

Yes; merging.

*** This bug has been marked as a duplicate of bug 50947 ***
Is this the same as Bug 50947 and/or Bug 51169?
**Author:** `harshanh1979`

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

https://ml.wikipedia.org/wiki/%E0%B4%AC%E0%B5%BC%E0%B4%A4%E0%B5%8D%E0%B4%A4%E0%B4%B2%E0%B5%8B%E0%B4%AE%E0%B4%BF%E0%B4%AF%E0%B5%8B_%E0%B4%A1%E0%B4%AF%E0%B4%B8%E0%B5%8D

I tried to correct the text ൻറെ to ന്റെ. But the editor doesnt allow to input the characters ് െ etc. Unwanted changes happens somewhere else in the paragraph while trying to input the above mentioned characters.

--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Linux
**Platform**: PC
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50566
I had this problem earlier with Ubuntu/Firefox 22. Now it is found that the problem was rectified.
Screenshot

See screenshot, from https://en.wikipedia.org/wiki/Jitter_%28disambiguation%29?veaction=edit - that line near the top shouldn't be there.

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

**Attached**: {F11385}
Created attachment 13766
No thick line

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

See the screenshots attached.

Therefore changing the status to Resolved-worksforme for now,if you get this problem again,please do reopen the bug.
Screenshot

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

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

**Attached**: {F11382}
Fixed for some time due to changes in Parsoid. Sorry for the slowness of updating.
If I open the VisualEditor and add a link to say, "Edward Coke (politician)" in my sandbox, and then right click on the link and open it in a new tab, it takes me to https://en.wikipedia.org/wiki/User:Okeyes_%28WMF%29/Edward_Coke_%28politician%29

This seems somewhat suboptimal.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 48915 ***
We have users reporting errors when trying to save on https://en.wikipedia.org/wiki/Colorado_14ers - can someone take a look at the log and work out what's happening? They were only adding text and a reference.

--------------------------
**Version**: unspecified
**Severity**: normal
Performance issue, fixed some time ago; sorry for slowness in replying.
It should be the same happening here http://en.wikipedia.org/w/index.php?title=U.S._Route_377_in_Texas&diff=562454441&oldid=506596182 although the user reports seeing the message _and_ still, the edit was saved.

http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Received_error_though_edit_was_saved
Can something - perhaps a faint background color or an outline - be added to make clear when one is in editing mode?

Copied from http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Make_editing_view_more_distinctive_from_article

I like the visual editor, and I predict that more people will edit WP when it's introduced. However, there is one thing that bugs me: After I clicked the "Edit" Tab, the view of the article does change only slightly - so sometimes I do not know that I am already editing, especially when I scroll down the article. I'd suggest a visual hint: A modal popup, a slim outline of the editing area or a more distinctive design of the tool bar, for example. Mateng (talk) 12:00, 30 June 2013 (UTC)

Hear, hear! Perhaps a (faint) background colour? There needs to be some visual clue. JohnCD (talk) 12:17, 30 June 2013 (UTC)

--------------------------
**Version**: unspecified
**Severity**: normal
These are already covered by bug 48008 ("There is not enough UI difference between reading and editing mode").

*** This bug has been marked as a duplicate of bug 48008 ***
Another related request: 

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

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

It was working fine previously. I can reproduce this on both fr.wp and en.wp. See screenshot.

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

**Attached**: {F11359}
*** This bug has been marked as a duplicate of bug 50471 ***
I twice got the error alert box when saving.  However, it turns out that it did save both times.  The first time, it did the intended edit (https://en.wikipedia.org/w/index.php?title=Participants_in_World_War_II&diff=562174851&oldid=561500927).  The second time, it did a dirty diff for a pipe character (&#124; -> <nowiki>|</nowiki>) in a section of the page I didn't edit.

--------------------------
**Version**: unspecified
**Severity**: normal
We have tweaked the time-out code so this shouldn't happen in future; sorry for the disruption. Please re-open if it recurs…
The following HTML does not seem to properly round-trip through VE:

<p><a rel="mw:WikiLink" href="././Foo">./Foo</a></p>

While the ././ prefix is not ideal (see Parsoid bug 50426) VE should still preserve the href on unmodified content. Instead, it seems to prefix another ./, which then results in diffs like this one:

https://en.wikipedia.org/w/index.php?title=DreamWorks_Animation&curid=1509817&diff=562129988&oldid=562129729

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

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

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

introduced the bad markup and that was only a couple of hours ago.
It worked at http://en.wikipedia.org/wiki/User:Catrope/Shrek?veaction=edit though, so closing as working.
This seems to also seem to replace spaces with underscores, and mangles category links. EG changing [[Category:House (season 7) episodes]] to [[./Category:House_(season_7)_episodes]]
https://en.wikipedia.org/w/index.php?title=Out_of_the_Chute&diff=prev&oldid=562623071
Those prefixes actually seem to have been inserted by VE:
https://en.wikipedia.org/w/index.php?title=DreamWorks_Animation&curid=1509817&diff=562129729&oldid=562106766
Taken from VisualEditor feedback page:

Trying when editing articles to think "Could I use VE for this?" I came on an article where the {{AfD}} template had been removed and needed to be restored. The easiest way to get that right is to call up from the history a version with the template in place, and copy it from there to the current version. This doesn't seem possible in VE: after selecting the template so that it is highlighted, Ctrl-C doesn't copy it, and right-click doesn't offer a "Copy" option. JohnCD (talk) 21:29, 28 June 2013 (UTC)

--------------------------
**Version**: unspecified
**Severity**: normal
This will be solved by bug 41193 when that is fixed; merging to that.

*** This bug has been marked as a duplicate of bug 41193 ***
I believe Maggie means copying the VisualEditor representation of a template, not copying wikitext.
Even if you could paste it in, that wouldn't do any good as the VE would surround the template with <nowiki> tags. Entering any form of wikisyntax in the VE currently results in the editor thinking that you want the literal text to be displayed. This bug therefore (partly) depends on that bug being fixed too.
If a header line is preceded by an empty line, and one tries to remove that empty line by placing the cursor at the beginning of the header line and hitting Delete, the empty line is removed as expected, but the header line turns into Paragraph formatting, which is unexpected and incorrect.

Note that the behavior is correct if the line preceding the header line is *not* empty: in that case we want to merge the header line with the previous line, and the header formatting should be removed.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50995
The initial behaviour was, I believe, fixed some time ago; the rest of the bug (as now stated in the title) is intentional behaviour. Marking as FIXED.
Sorry: I should have said "Backspace", not "Delete".
Change 71174 merged by jenkins-bot:
Make loading VE work on Opera again, attempt two

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

https://gerrit.wikimedia.org/r/71174
I know why it only fails when debugging: because the fix in https://gerrit.wikimedia.org/r/#/c/61560/ is only applied when not debugging. Apparently the document there is *still* not a document evenif it appears to be one.
And that is because #cloneNode is returning `undefined` for those elements (probably because they come from some weird dynamically-generated document). Which is clearly an Opera bug, but it'd be nice to work around it somehow.
And this is because ve.copyArray() is losing data, always returning an array of undefineds there.
Hey, it's even better – all of the arrays in store.valueStore apparently consist only of varying number of undefineds.
If an infobox contains an image that is wider than the infobox's natural size, then editing the page cause the infobox to expand, without properly wrapping the adjacent text.  The result is that the infobox covers up the adjacent text.

See http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Text_appearing_behind_infobox_.2F_behaviour_after_editing on 28 June 2013 for the initial report.  The report came from a user running Chrome (version 27.0.1453.116) on Windows XP; I confirmed it in the en.wp article on Southampton using Safari 6.0.5 (7536.30.1) and Firefox 22.0 on Mac OS 10.7.5.

--------------------------
**Version**: unspecified
**Severity**: normal
Congrats on your first bug report; sadly it is a dupe. Took me a while to find  bug 49925 though, so you are forgiven :)

*** This bug has been marked as a duplicate of bug 49925 ***
https://en.wikipedia.org/wiki/Birbal has 3 references; https://en.wikipedia.org/wiki/Birbal?veaction=edit has 24.

--------------------------
**Version**: unspecified
**Severity**: normal
*** Bug 50521 has been marked as a duplicate of this bug. ***
Fixed a few months ago; sorry for late reply.
They both have 21 references now. :P

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

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

(bug 50521 looks similar, and might provide some clues on how to cause the renderer to get into this odd state)
screenshot

I'm not sure if this is bug 49514 ; feel free to dupe if it is.

See attached screenshot: the toolbar appears on top of the save dialog, which makes it difficult or impossible to save changes.

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

**Attached**: {F11157}
I think this is 50324 instead.

*** This bug has been marked as a duplicate of bug 50324 ***
Screenshot

Try modifying the infobox in https://en.wikipedia.org/wiki/Defiance_%28TV_series%29?veaction=edit for example - see the screenshot.

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

**Attached**: {F11137}
*** This bug has been marked as a duplicate of bug 49854 ***
Users expect to be able to select, drag and drop most elements of the page, including snippets of text, templates & other transclusions, and references, just like they can do with images.

--------------------------
**Version**: unspecified
**Severity**: normal
Actually, bug 49981 is meant to cover everything; merging.

*** This bug has been marked as a duplicate of bug 49981 ***
While for text there's 49981 open, itwp users also request this for templates.
It is usual to use [square brackets], [...] inside quotes to cut or complete sentences in quotes. As for today, VisualEditor will add <nowiki> tags like this:

<nowiki>[Square brackets]</nowiki>

<nowiki>[...]</nowiki>

This is not a big deal since the users will keep seeing the same in the published article, but it adds unnecessary cruft in edit source mode and it's wrong.

Also, according to Bug 47678 this means that editors won't be able to edit the content inside those brackets with VisualEditor, because of the <nowiki> tags.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
{T54268}
This bug was about single square brackets ([ ... ]), not wikitext links. 

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

from
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Strange_result_with_a_.3C.2Fnowiki.3E_tag_inserted .
Thanks.
Looks like we are either still have a problem or it may have resurfaced; last section of:

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

and follow up edits.
We have refined the nowiki escaping in Parsoid so that external link like syntax that does not have a valid target is no longer escaped.
Fairly self-explanatory.

--------------------------
**Version**: unspecified
**Severity**: normal
This is bug 50100.

*** This bug has been marked as a duplicate of bug 50100 ***
Removing a paragraph and header does the same - https://en.wikipedia.org/w/index.php?title=Idlib_Governorate_clashes_%28June_2012%E2%80%93present%29&curid=39240723&diff=562677456&oldid=562663343

Can this please be prioritised and assigned?
The history page of any article has an 'edit' link on it; this currently takes you to source editing, which seems highly likely to confuse users.

--------------------------
**Version**: unspecified
**Severity**: normal
How very strange. Slightly slower loading time giving a false impression, probably; thanks :).
Do you mean the diff page - e.g. https://en.wikipedia.org/w/index.php?title=Barack_Obama&diff=561813443&oldid=561813311 - the history page e.g. https://en.wikipedia.org/wiki/Barack_Obama?action=history - or the oldid page - e.g. https://en.wikipedia.org/w/index.php?title=Barack_Obama&oldid=561813443 ?

'Cos the second two work for me; the first one isn't a history page, though. :-)
This is what Alberobello looks like under VE

When trying to edit http://it.wikipedia.org/wiki/Alberobello (tested with MonoBook on FF and Vector on Chrome) a few "carriage returns" appear in the first lines. I'd also add that I spot these in https://www.mediawiki.org/wiki/VisualEditor/Basic_example_worksheet : the line which says "Test split on multiple lines"? It isn't.

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

**Attached**: {F11918}
(In reply to comment #0)
> Created attachment 12662 [details]
> This is what Alberobello looks like under VE
> 
> When trying to edit http://it.wikipedia.org/wiki/Alberobello (tested with
> MonoBook on FF and Vector on Chrome) a few "carriage returns" appear in the
> first lines.

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

> I'd also add that I spot these in
> https://www.mediawiki.org/wiki/VisualEditor/Basic_example_worksheet : the
> line
> which says "Test split on multiple lines"? It isn't.

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

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

**Attached**: {F11918}
When VisualEditor is enabled there is no option to enable ULS, where I could type in Odia in the search bar using ULS.

When VIsualEditor is enabled there typing is possible only in English. There is no option to change the language using ULS where as it works normally in the search bar. I have tested it for Odia Wikipedia for the article on Colombo: https://or.wikipedia.org/wiki/Colombo on Mac OS X 10.7.5 using browser Firefox 21.0.

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

**Attached**: {F11913}
*** This bug has been marked as a duplicate of bug 49569 ***
See https://en.wikipedia.org/wiki/Mitochondrial_DNA?veaction=edit - the links appear, via source editing, to be perfectly normal, and yet you can't interact with them and they display oddly.

--------------------------
**Version**: unspecified
**Severity**: normal
This would have been bug 48900 in Parsoid.

*** This bug has been marked as a duplicate of bug 48900 ***
Fairly self-explanatory. The reason this is important; being able to copy references across is crucial when using multiple references from one source item. If I have a book by Jones, from 2003, and I have a reference that reads <ref>Jones (2003) p.23</ref> for one statement, and want to cite page 57 for another, it's a lot easier to change the page number than it is to type everything out again.

--------------------------
**Version**: unspecified
**Severity**: normal
This should be addressed when bug 33105 is fixed.

*** This bug has been marked as a duplicate of bug 33105 ***
When you add a category to a page using the page settings dialog, it gets added as a wikilink [[:Category:xyz]], not a category inclusion [[Category:xyz]].

Seen on testwiki and enwiki.

--------------------------
**Version**: unspecified
**Severity**: normal
This was a Parsoid bug, since fixed.
Screenshot of bug

When scrolled down the page, the top of the save dialog is obscured by the toolbar. See screenshot.

See also other z-index bugs: bug 49514 and bug 49275.

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

**Attached**: {F11882}
*** This bug has been marked as a duplicate of bug 50324 ***
See https://en.wikipedia.org/wiki/Microorganism?veaction=edit#See_also for example; that should be divided into 3 columns.

--------------------------
**Version**: unspecified
**Severity**: normal
This is almost certainly the same as bug 50036.

*** This bug has been marked as a duplicate of bug 50036 ***
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
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 ***
Duplicated here: http://test.wikipedia.org/w/index.php?title=VisualEditor%3ATestingGrounds&diff=174932&oldid=174931
When you use 'become' to log into a shared account, ~/.bashrc isn't run.

catrope@tools-login:~$ become visualeditor
local-visualeditor@tools-login:~$ cat ~/.bashrc
# Shortcuts
alias ..='cd ..'
alias ll='ls -ahlF --color=auto'
alias l='ll'

# Environment
export PATH=$HOME/bin:$PATH;

local-visualeditor@tools-login:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
local-visualeditor@tools-login:~$ . ~/.bashrc
local-visualeditor@tools-login:~$ echo $PATH
/data/project/visualeditor/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin

Adding $HOME/bin to $PATH would probably be a nice thing to do in general.

--------------------------
**Version**: unspecified
**Severity**: normal
Works as designed.

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

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

A thing many users may want to do to simplify things is to have a ~/.profile that sources ~/.bashrc (in addition or instead of login-specific behaviour) so that the latter gets sourced regardless of how the shell was invoked.
catrope@tools-login:~$ become visualeditor
local-visualeditor@tools-login:~$ screen
Cannot open your terminal '/dev/pts/97' - please check.


However, running screen as myself and then running 'become visualeditor' in each screen window does work.

--------------------------
**Version**: unspecified
**Severity**: normal
valhallasw@tools-login:~$ chown valhallasw:tools.tsreports /dev/pts/164
valhallasw@tools-login:~$ chmod g+r /dev/pts/164
valhallasw@tools-login:~$ become tsreports
tools.tsreports@tools-login:~$ screen

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


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

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

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

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

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

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

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

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

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

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

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

Whereas:

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

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

The hack with script is exactly that -- a hack: it creates a new shell, a new terminal pair, and has a process running busy shuffling the data between both sides of the pipe, with a copy to /dev/null.  At best, it is horribly wasteful and doubles context switches.
According to <https://wiki.toolserver.org/view/Multi-maintainer_projects#Using_screen>, it is possible on the Linux hosts, but not on the Solaris hosts. I just confirmed: dbreps@willow.toolserver.org (Solaris) gets the same error as above while dbreps@nightshade.toolserver.org (Linux) has no issue starting screen.

The Toolserver folks had a workaround for Solaris hosts (using `ttyallow`), but now we've reached a new question: what did the Toolserver do on its Linux hosts to resolve this issue that Labs hasn't done?
Then you almost certainly* remember incorrectly.  Screen can only operate on the terminal you are connected to (obviously), and that is necessarily owned by the user you have logged in with.

Chances are this scenario (start a screen session /after/ having switched to another user) would have been less common on toolserver since most people ran only as their login user except for the infrequent multi-maintainer project -- which all projects are in Tool Labs.

* (I say almost here because it /is/ possible to set screen suid to root; but that's on the same list as "chmod 777 your home", "set your password to '1234'", or "allow telnet" -- something a user might find convenient but a sysadmin should be fired for).
I don't remember the Toolserver having this issue. This doesn't seem like a wontfix to me. This is pretty awful behavior currently. Surely we can do better.

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

I kept getting this. I checked <https://wikitech.wikimedia.org/wiki/Screen> to no avail. On IRC, I was told (by a bot, no less) that running "script /dev/null" is a workaround. It seems Roan found another workaround.

At a minimum, this needs to be documented (which I'll do momentarily) and the error message could be hacked to be clearer what the hell is happening ("check /dev/pts/50" is pretty much an online equivalent of "go fuck yourself"). Re-opening this for further thought and consideration.
That's a limitation on how screen functions (i.e., it needs to have ownership of the terminal, which only the actual login process grants); sudo cannot circumvent this as it does not alter tty permissions.

While it's a little annoying, the workaround you describe provides full functionality during interactive sessions (and it bears reminding here that tools should not be running interactive processes in detached screen sessions in any case).
Adding a template to a page (say, https://en.wikipedia.org/wiki/Eugene_Lies ) for some reason blocks the opening of the page settings dialogue.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #1)
> (In reply to comment #0)
> > Adding a template to a page (say, https://en.wikipedia.org/wiki/Eugene_Lies )
> > for some reason blocks the opening of the page settings dialogue.
> 
> Is this in Monobook or in Vector? AFAICS this works for me in Vector fine; in
> Monobook, there's the bug 50241 issue but that's it.

Aha, tracked it down:

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


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

*** This bug has been marked as a duplicate of bug 47947 ***
(In reply to comment #0)
> Adding a template to a page (say, https://en.wikipedia.org/wiki/Eugene_Lies )
> for some reason blocks the opening of the page settings dialogue.

Is this in Monobook or in Vector? AFAICS this works for me in Vector fine; in Monobook, there's the bug 50241 issue but that's it.
What "not working" means is that templates, links, references and images cannot be interacted with, at all. References and templates don't acknowledge they're there, images bug out, and the link inspector does not appear for links. I've had a group of users test this, and they've all reported wildly inconsistent results; this is happening for some but not for others, with no correlation in OS, browser or even skin.

--------------------------
**Version**: unspecified
**Severity**: major
**Whiteboard**: aklapper-moreinfo
(In reply to comment #2)
> I assume this is obsolete now?

Sorry, yes, we got this fixed; thanks Sam, and thanks for the follow-up, Andre.
I assume this is obsolete now?
I think we fixed this with a touch on ve.js by Reedy - please confirm? (Gah, forgot to say this 3 hours ago.)
VE rendering of [[WUEC#External_links]] does not match MW rendering.

--------------------------
**Version**: unspecified
**Severity**: minor
This is a slightly-faulty use of wikitext on the page - it dereferences to

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

->

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

… and gets displayed as such, in case you want to edit that otherwise-inexpliably-hidden bullet. Marking as INVALID (but yeah, eww at that wikitext).
screenshot

When floats (like images or templates) are located at the same level as references, the blue rectangle of the references prevents the user from selecting (and editing) the floats. See attached screenshot.

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

**Attached**: {F11749}
Entirely-confusingly, this is the same as bug 50395 (which is more detailed, so I'll up-merge this into that one). Sorry for the slow update.

*** This bug has been marked as a duplicate of bug 50395 ***
screenshot

Steps to reproduce:
* Click on the heading format drop-down menu. Don't close it.
* Click on the Page settings menu.

Expected result:
* The heading format drop-down is closed before the Page settings dialog shows up.

Actual result:
* The heading format drop-down remains open (and selectable) on top of the Page settings dialog (see attached screenshot).

Observed in Firefox 21.

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

**Attached**: {F11748}
This is still true (and deliberate), but since our major re-vamp of how windows stack on top of one another, no longer an issue; closing as FIXED.
See [[testwiki:VisualEditor:Little or big]].

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 49696 ***
**Author:** `swalling`

**Description:**
Looking at the logs for the latest GettingStarted schema (GettingStartedNavbar_5496876) I am not finding a page-save-success event since June 6th. 

This may have something to do with the VisualEditor split test or maybe not. I am seeing very few events (28 total) of any kind being logged on enwiki after 2013-06-20 when logging for the VE split test was enabled. This is obviously wrong, since there were more than 150 revisions tagged as gettingstarted-edit yesterday alone.

--------------------------
**Version**: unspecified
**Severity**: normal
Looks properly fixed with the 2013-07-18 rollout of wmf10 to enwiki that included this fix, plus and later that day the changes to restore GettingStarted after CentralAuth/SUL2 changed.

SELECT LEFT( timestamp, 8), COUNT(*) FROM GettingStartedNavbar_5588671 WHERE wiki = "enwiki" AND event_action = "page-save-success" AND event_funnel = "returnto" GROUP BY 1;

+---------------------+----------+
| LEFT( timestamp, 8) | COUNT(*) |
+---------------------+----------+
| 20130702            |        1 |
| 20130718            |       17 |
| 20130719            |      235 |
+---------------------+----------+
**swalling** wrote:

https://gerrit.wikimedia.org/r/#/c/71575/ was scheduled to be deployed last week, but we flubbed a bit and it did not go out to 1.22wmf9 until today. 

I am still seeing only one page-save-success in the returnto funnel as of today, so the patch not getting deployed may be the likely culprit.
There are still no page-save-success + returnto events in prod, so there may be an RL issue.

Re-opening until we're sure it's fixed.

A relevant query is:

SELECT COUNT(*) FROM GettingStartedNavbar_5588671 WHERE wiki = "enwiki"
AND event_action = "page-save-success" AND event_funnel = "returnto";
*** Bug 51208 has been marked as a duplicate of this bug. ***
S's patch fixes the post-edit issue locally, which I believe is the same one I mentioned in comment 1.
Change 71575 merged by jenkins-bot:
postEdit needs to run before GS logging

https://gerrit.wikimedia.org/r/71575
Change 71575 had a related patch set uploaded by Spage:
postEdit module needs to run before openTask

https://gerrit.wikimedia.org/r/71575
GettingStarted only logs page-save-success if wgPostEdit is true. On my local wiki I printed log messages from the two routines, and they sometimes came out:
   about to log returnto page-impression
   postEdit.js set wgPostEdit true!

So the postEdit.js is running *after* openTask.js and that's why the wrong event is logged. On enwiki with resourceLoaderDebug cookie it did log a page-save-success event (go look at GettingStartedNavbar_5588671 where event_userId = 19275523), but without the RL debug in regular operation GS logs page-impression.

RL loads postEdit first in its mw.loader.load() call at the end of the page body, but I don't know what RL's guarantee of code execution ordering is.

Adding a dependency to ext.gettingstarted.openTask:
        'mediawiki.action.view.postEdit', // need this to run prior

seemed to fix it locally; another fix would be to use 
        mw.hook( 'postEdit' ).add( function ()
as VE does instead of changing the action from page-impression to page-save-success.

I don't know how VE affects this, this was all clicking [Edit source].
**swalling** wrote:

(In reply to comment #1)
> The latest GettingStartedNavbar table is GettingStartedNavbar_5588671
> (easiest
> way to see is SHOW TABLES).
> 
> However, that doesn't convincingly explain why the latest (by timestamp)
> enwiki
> entries in GettingStartedNavbar_5496876 are a long string of
> page-save-attempt
> (the last of which is on 2013-06-26), but the latest page-save-success is
> 2013-06-06.
> 
> It could be a coincidence, but it's worth looking into.

Okay, you were correct, this is worth looking in to. In the most recent logs (GettingStartedNavbar_5588671) it seems we are not logging any page-save-success events for the returnto funnel. Logging for other events in the returnto funnel seem normal, and page saves all gettingstarted funnels (copyedit, clarify, addlinks) are normal.
**swalling** wrote:

(In reply to comment #1)
> The latest GettingStartedNavbar table is GettingStartedNavbar_5588671
> (easiest
> way to see is SHOW TABLES).
> 

Resolving as not a bug, accordingly, because there's no RESOLVED STEVENISDUMB. ;)
The latest GettingStartedNavbar table is GettingStartedNavbar_5588671 (easiest way to see is SHOW TABLES).

However, that doesn't convincingly explain why the latest (by timestamp) enwiki entries in GettingStartedNavbar_5496876 are a long string of page-save-attempt (the last of which is on 2013-06-26), but the latest page-save-success is 2013-06-06.

It could be a coincidence, but it's worth looking into.
Specifically, a lot of JS-dependent things simply don't seem to work. Mostly those are gadgets (no big deal) but on reload, section edit links take you to the source editor. This is probably the most critical; I can imagine a workflow in which a newbie makes a change in the VE, saves, sees something else to tweak, goes to edit...ack! Broken the site!

--------------------------
**Version**: unspecified
**Severity**: normal
Yeah, sorry about this bug, and my tardiness in replying; this was bug 49620, which we fixed just before you posted this, but only deployed the next day.

*** This bug has been marked as a duplicate of bug 49620 ***
Normally I would rewrite the bug description for bz, but JohnCD has given a very good demonstration on-wiki of strange cursor movements when navigating using arrow keys:

http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=561499916#Some_funnies

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=561499916#Some_funnies
This is a duplicate of bug 48847, which we fixed last week; sorry for not getting to this bug until now.

*** This bug has been marked as a duplicate of bug 48847 ***
In general,

{{foo
bar = 
* 1
* 2
* 3
}}

… is RT'ing to 

{{foo
bar = <nowiki>* 1
* 2
* 3</nowiki>
}}

Examples: 

* https://en.wikipedia.org/w/index.php?title=Riddler&diff=561149660&oldid=561096940
* https://en.wikipedia.org/w/index.php?title=Schuylar_Oordt&diff=561438828&oldid=561406705

VisualEditor bug (to prevent dirty-DOMing and so hide this bug on RT) is bug 50070, but this will still occur when users edit the template unless this is recognised as valid.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50070
*** This bug has been marked as a duplicate of bug 50144 ***
After modifying site.pp and provisioning, I got:

notice: /Stage[main]/Role::Eventlogging/Mediawiki::Extension[EventLogging]/Git::Clone[mediawiki/extensions/EventLogging]/Exec[git clone mediawiki/extensions/EventLogging]/returns: fatal: unable to access '/root/.config/git/config': Permission denied                                                                                                                       
resulting in:

err: /Stage[main]/Role::Eventlogging/Mediawiki::Extension[EventLogging]/Git::Clone[mediawiki/extensions/EventLogging]/Exec[git clone mediawiki/extensions/EventLogging]/returns: change from notrun to 0 failed: git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/EventLogging.git /vagrant/mediawiki/extensions/EventLogging returned 128 instead of one of [0] at /tmp/vagrant-puppet/modules-0/git/manifests/clone.pp:40

--------------------------
**Version**: unspecified
**Severity**: normal
[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.]
As of git 1.8.1.1 and above, if the home directory can't be accessed, it results in a fatal error. That was the cause of the error. I fixed it in gerrit change 71165.
Change 71165 had a related patch set uploaded by Ori.livneh:
Set $HOME when git-cloning

https://gerrit.wikimedia.org/r/71165
Happens to me too. I did `git pull --ff-only` on my host, added "include role::visualeditor" to puppet/manifests/site.pp, and tried to run vagrant for the first time in weeks. I tried vagrant up, vagrant reload, and vagrant provision, and all failed early on with variations of the same error as above:

[default] Running provisioner: puppet...
Running Puppet with site.pp...
info: Applying configuration version '1372472629'
notice: /Stage[main]/Role::Visualeditor/Mediawiki::Extension[VisualEditor]/Git::Clone[mediawiki/extensions/VisualEditor]/Exec[git clone mediawiki/extensions/VisualEditor]/returns: fatal: unable to access '/root/.config/git/config': Permission denied

I can `vagrant ssh` and the wiki is running on http://127.0.0.1:8080/ , but Special:Version says I don't have VisualEditor installed. I'm running Ubuntu 13.04.
[Not urgent.]

Frameless images are special; the caption is meant to be the alt text, unless alt= is also set, in which case it's ignored - but Parsoid outputs a <figcaption> for images regardless of type (thumb, framed or frameless) - and doesn't output the alt at all, which is bug 45208.

There's a hack in VisualEditor to ignore <figcaption>s for these as part of bug 50113, but Parsoid should fix these in due course.

--------------------------
**Version**: unspecified
**Severity**: minor
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
This is by design. See http://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Images for documentation and rationales.
https://en.wikipedia.org/w/index.php?title=History_of_Delta_Air_Lines&curid=38607247&diff=561387547&oldid=557734729

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 50012 ***
[[File:Delta logo.svg|right|200px]] --> [[File:Delta logo.svg|right|200px|]]

I've seen this in a few other diffs as well.
https://en.wikipedia.org/w/index.php?title=Laura_Pannack&diff=561375041&oldid=561336738

The change should have only italicized a few publication names. Instead it changed...

* Winner, Magenta Foundation award<ref>{{cite book |last= Pritchard | first= Lisa |authorlink= Lisa Pritchard|title= Setting Up a Successful Photography Business: How to be a Professional Photographer |url= http://books.google.co.uk/books?id=Nn4Zt5SBcswC&pg=PA134&lpg=PA134&dq=laura+pannack++Setting+up+a+Successful+Photography+Business&source=bl&ots=jPQTB9IuYE&sig=7xtX-t9WFQYB76Xo_ZlU06BnIrE&hl=en&sa=X&ei=QehaUZGZCJSa1AWR_oCICw&ved=0CC8Q6AEwAA#v=onepage&q=laura%20pannack%20%20Setting%20up%20a%20Successful%20Photography%20Business&f=false|accessdate= 2 April 2013 |year= |publisher= A & C Black Publishers Ltd|location= London|isbn= 978-1-408125-77-9|page= 134| quote = Laura Pannack ... twice winner of the Magenta Foundation Award}}</ref>

to...

* Winner, Magenta Foundation award<ref>{{cite book |last=Pritchard | first=Lisa |authorlink=Lisa Pritchard|title=Setting Up a Successful Photography Business: How to be a Professional Photographer |url=http://books.google.co.uk/books?id=Nn4Zt5SBcswC&pg=PA134&lpg=PA134&dq=laura+pannack++Setting+up+a+Successful+Photography+Business&source=bl&ots=jPQTB9IuYE&sig=7xtX-t9WFQYB76Xo_ZlU06BnIrE&hl=en&sa=X&ei=QehaUZGZCJSa1AWR_oCICw&ved=0CC8Q6AEwAA#v=onepage&q=laura%20pannack%20%20Setting%20up%20a%20Successful%20Photography%20Business&f=false|accessdate=2 April 2013 |year=|publisher=A & C Black Publishers Ltd|location=London|isbn=978-1-408125-77-9|page=134| quote =Laura Pannack ... twice winner of the Magenta Foundation Award}}</ref>

--------------------------
**Version**: unspecified
**Severity**: normal
Closing "bugs" which consist of multiple issues.
https://en.wikipedia.org/w/index.php?title=Save_Rock_and_Roll&curid=38419944&diff=561416388&oldid=561387755
https://en.wikipedia.org/w/index.php?title=Ivan_Tan&curid=39767321&diff=561408770&oldid=561406619
(In reply to comment #9)
> This remains a duplicate of bug 50066; that is merged on VE end. There are
> some artefacts due to Parsoid which are different bugs (which are also fixed
> and being deployed this afternoon, hopefully) [...]

Let's do this: mark this bug as resolved when it's actually resolved. Not when it may be hopefully resolved in the future.
https://en.wikipedia.org/w/index.php?title=United_States_presidential_election,_1844&curid=40514&diff=561407211&oldid=559883253
https://en.wikipedia.org/w/index.php?title=Sela_(Saudi_Arabia)&curid=26371208&diff=561403748&oldid=561269241
https://en.wikipedia.org/w/index.php?title=Kamelot&curid=1161493&diff=561402036&oldid=560661945
This remains a duplicate of bug 50066; that is merged on VE end. There are some artefacts due to Parsoid which are different bugs (which are also fixed and being deployed this afternoon, hopefully), but Bugzilla doesn't have "dupe of these seven bugs" as an option.

*** This bug has been marked as a duplicate of bug 50066 ***
https://en.wikipedia.org/w/index.php?title=19th_Virginia_Infantry&curid=25759369&diff=561398799&oldid=561398641
https://en.wikipedia.org/w/index.php?title=Dan_Penteado&curid=13006822&diff=561396894&oldid=561392351
https://en.wikipedia.org/w/index.php?title=Low_Orbit_Ion_Cannon&curid=28240388&diff=561396775&oldid=560499820
https://en.wikipedia.org/w/index.php?title=MTV&curid=18856&diff=561395466&oldid=561389102
https://en.wikipedia.org/w/index.php?title=Wappingers_Falls,_New_York&curid=126391&diff=561394799&oldid=561394670
https://en.wikipedia.org/w/index.php?title=Wild_Pack&curid=29143457&diff=561394555&oldid=561394449
Re-opening this for now. This doesn't appear to be fixed:

https://en.wikipedia.org/w/index.php?title=Paul_Evans_(footballer_born_1973)&curid=15575267&diff=561390930&oldid=561390588
*** This bug has been marked as a duplicate of bug 50066 ***
https://en.wikipedia.org/w/index.php?title=Laura_Pannack&diff=561336738&oldid=557984097

<ref name="telegraph"/> --> <ref name="telegraph"></ref>

Weird.

--------------------------
**Version**: unspecified
**Severity**: normal
https://en.wikipedia.org/w/index.php?title=Save_Rock_and_Roll&curid=38419944&diff=561416388&oldid=561387755
https://en.wikipedia.org/w/index.php?title=Daniel_Kahneman&curid=165492&diff=561411461&oldid=560179630
*** This bug has been marked as a duplicate of bug 50066 ***
https://en.wikipedia.org/w/index.php?title=Christopher_Walken&curid=167790&diff=561335042&oldid=560573850

https://en.wikipedia.org/w/index.php?title=Complement_fixation_test&diff=561335484&oldid=540954235

https://en.wikipedia.org/w/index.php?title=List_of_first-class_cricket_records&curid=5507023&diff=561342472&oldid=560120426

--------------------------
**Version**: unspecified
**Severity**: normal
Closing "bugs" which consist of multiple issues.
This is still happening:

https://en.wikipedia.org/w/index.php?title=Wappingers_Falls,_New_York&curid=126391&diff=561392322&oldid=560081821
*** This bug has been marked as a duplicate of bug 50066 ***
https://en.wikipedia.org/w/index.php?title=Paula_Deen&diff=561368754&oldid=561308417

I did a section edit to link "Food Network". This was the resulting diff.

--------------------------
**Version**: unspecified
**Severity**: normal
Sorry about this; fixed by bug 50066 which we'll deploy in a few minutes.

*** This bug has been marked as a duplicate of bug 50066 ***
Screenshot of bug

The "review changes" flyout looks broken and doesn't actually do anything.

There's a script error:

SCRIPT70: Permission denied 
load.php, line 18 character 453

With "format JavaScript" enabled (a real godsend of IE's dev tools) we see that the error is occurring on the first line of this for statement:

for(i=0,len=oldDoc.head.childNodes.length;
        i<len;
        i++){

I tried to get a better output using debug=true, but this seems to totally break VE (in IE10 at least).

--------------------------
**Version**: unspecified
**Severity**: critical

**Attached**: {F11482}
This is bug 49187 (and yes, it's critical, hence we've re-blacklisted IE until we can get this fixed). :-(

(IE has a hard limit on how many scripts it will take for a given page; debug=true suspends ResourceLoader, meaning all ~200 VE files come individually - along with the dozens of non-VE MW scripts - which IE ignores after the first ten or so, breaking everything. This is a known IE-is-terrible bug.)

*** This bug has been marked as a duplicate of bug 49187 ***
It's also impossible to save the page; same script error occurs. Upping to critical.
See https://en.wikipedia.org/w/index.php?title=Royal_Lancaster_Infirmary&diff=561254127&oldid=560972172 for example.

--------------------------
**Version**: unspecified
**Severity**: normal
This is still happening: https://en.wikipedia.org/w/index.php?title=Genie_%28feral_child%29&diff=564429158&oldid=564425048 Can you please check? Thanks.
This particular one is (entirely cryptically) bug 50066, which is going to be fixed in the next few minutes and deployed tomorrow morning PDT.

*** This bug has been marked as a duplicate of bug 50066 ***
If a user hits edit, removes a category and saves, the read-only article they're then presented with still includes the old category - or at least, does on https://en.wikipedia.org/wiki/Sumali

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 48560 ***
In the following edit, VE saved the internal page representation instead of the wikitext:

https://nl.wikipedia.org/w/index.php?title=Eurosong&diff=prev&oldid=38007082

--------------------------
**Version**: unspecified
**Severity**: normal
This was due to the caches being mis-configured; really sorry about this issue.

*** This bug has been marked as a duplicate of bug 49577 ***
When viewing [[testwiki:Visualeditor_image_captions]] in VE, the images cannot be seen. They are still "known" though - they don't vanish on save.

(My testing of this issue led to the filing of bug 50008, but the issue there seems to have gone away now. However, this one is still showing up for me, so I think this is a separate bug.

Please close this bug if it turns out to have fixed itself.)

--------------------------
**Version**: unspecified
**Severity**: normal
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
*** This bug has been marked as a duplicate of bug 48900 ***
Related: Bug 48900
*** Bug 50008 has been marked as a duplicate of this bug. ***
This is because Parsoid is converting the images to placeholders for some reason: http://parsoid.wmflabs.org/mw/User:Catrope/Bug_50035

Moving to Parsoid
Assuming we do not yet have something like this, it'd be awesome if this Jenkins plugin could be installed:

https://wiki.jenkins-ci.org/display/JENKINS/Embeddable+Build+Status+Plugin

I want to be able to embed such a build status image on some website.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
I have installed the plugin and restarted Jenkins. Please try it out, if it does not work simply reopen this bug :)
Note that due to the way we currently separate larger build steps into separate jobs, you'd need to display about a dozen status badges to have the complete picture (e.g. mediawiki-core-lint, mediawiki-core-jslint, mediawiki-core-phpunit-groupA, mediawiki-core-phpunit-groupB, mediawiki-core-databaseless etc.).


If we do want to display this somewhere (for the unlikely event that someone bypassed Jenkins), we would need to have a post-merge job that runs on master only (so that it isn't affected by failing tests from proposed changes in Gerrit).

The closest we have for that is the post-merge job for phpunit regressions:

https://integration.wikimedia.org/ci/view/MediaWiki/job/mediawiki-core-regression-master/

This one only runs for master and only post-merge.

Note though that this doesn't include phplint, jshint and qunit. Only phpunit.
Installing that plugin won't be very useful because we use Jenkins pre-merge, not post-merge.

The builds you see in Jenkins are for patch sets in Gerrit. The latest build of those jobs have no meaning in correlation to the state of a repository as those builds are just an arbitrary sequence of builds on proposed changes.

The build status of our branches (incl. master) is always passing because you can't merge a change if it would result in the build failing.

Thus we don't need a status badge because our workflow (unlike most typical projects with e.g. Travis-CI set up on GitHub) makes it impossible not to be passing because we force every change to be pushed for review first, and is only merged after it is Verified by a passing build[1].

[1] Unless someone with the appropriate user permissions bypasses Jenkins manually, which is frowned upon and would break Jenkins for every submitted patch set after that.
I have tryed to add {{Commonscat|Saint Robert of Molesme}} to the article w:cs:Robert z Molesme using VE. VE adds "=" behind parametr in the code. See this revision: https://cs.wikipedia.org/w/index.php?title=Robert_z_Molesme&oldid=10436403

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://cs.wikipedia.org/w/index.php?title=Robert_z_Molesme&diff=10436403&oldid=10436394
But anyway, thx for explanation and sorry for disturbing!
(In reply to comment #1)
> ...the parameter name in this case is "1"...

Isnt this tricky? How the newbie should know, that "parametr name is 1"?
This was caused by you adding "Saint Robert of Molesme" as the parameter name rather than value - the parameter name in this case is "1", which wikitext can hide (the formal wikitext you were intending to add was "{{Commonscat|1=Saint Robert of Molesme}}".

In English the label (<visualeditor-parameter-input-placeholder>) is "Parameter name", which I believe is shown as "Jméno parametru" in Czech. I think the addition of the help documentation at https://www.mediawiki.org/wiki/Help:VisualEditor/User_guide and linked from the help menu in the interface will reduce this occurring, but sorry for the confusion in the first place. :-(
After loading the Visual Editor on
https://pt.wikipedia.org/wiki/Quadrado?veaction=edit&debug=1&uselang=pt&useskin=vector
and clicking in the template which shows the text "Wikicionário", in the bottom right corner of the page, I get the following error on console (Google Chrome 28.0.1500.52):
----
Uncaught TypeError: Cannot read property 'description' of undefined 
----

It comes from the line 
----
if ( data.description !== null ) {
----

of the following script:
https://bits.wikimedia.org/static-1.22wmf7/extensions/VisualEditor/modules/ve/dm/models/ve.dm.MWTemplateSpecModel.js

--------------------------
**Version**: unspecified
**Severity**: normal
This is the same as bug 49493 which is fixed in master and now in production; sorry for the disruption.

*** This bug has been marked as a duplicate of bug 49493 ***
A user suggested at
https://pt.wikipedia.org/wiki/WP:Editor_Visual/Coment%C3%A1rios?oldid=36175459#Alternar_entre_editores_sem_sair_da_p.C3.A1gina
which there should be a way to alternate between the two edit methods (visual/source), to avoid having to do two edits, when e.g. we are not able to finish our edit using the Visual Editor (maybe because we underestimate its difficulty, and changed our mind while using VisualEditor).

--------------------------
**Version**: unspecified
**Severity**: normal
Already suggested as bug 47779.

*** This bug has been marked as a duplicate of bug 47779 ***
When I open
https://pt.wikipedia.org/wiki/Jorge_VI_do_Reino_Unido?veaction=edit
I see several warnings like this on Google Chrome:

The page at https://pt.wikipedia.org/wiki/Jorge_VI_do_Reino_Unido?veaction=edit displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/4/4a/Commons-logo.svg/22px-Commons-logo.svg.png.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 43015 ***
Screenshot

See associated screenshot; that's the VE, in edit mode, on it.wiki. You can apparently still type into the window, but aren't given the toolbar or, for that matter, the ability to save. Erica is currently testing it.wiki's default gadgets one by one to see if any of those are causing the problem.

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

**Attached**: {F11224}
Cool; marking as resolved. I'd suggest speaking to the QE author quickfast, then :D.
Confirming it's QE's fault, http://it.wikipedia.org/w/index.php?title=Wikipedia%3AVisualEditor%2FCommenti&diff=59583884&oldid=59583801
I need to point out that I'm testing gadgets I added, I'm pretty sure defaults are ok :) http://it.wikipedia.org/w/index.php?title=Utente%3AElitre_%28WMF%29%2FSandbox&diff=59583614&oldid=59581474 tells me QuickEdit might cause the trouble here, since I managed to edit with VE without it.
At present, VisualEditor is invoked when clicking on the Edit link of sections. Please provide 'Edit Source' link in addition to that for each section.

--------------------------
**Version**: unspecified
**Severity**: normal
This is a duplicate of bug 49666 which we hope to do very soon.

*** This bug has been marked as a duplicate of bug 49666 ***
When I edit https://en.wikipedia.org/wiki/Golden_tortoise_beetle in VE, the template names at the top and bottom are suddenly in Uzbek ("Turkum:Biologik turlar" and "Andoza:Chrysomelidae-stub") and parts of the contents of the rendered infobox are in Uzbek as well ("Kingdom:" becomes "Olam:" etc.).

More evidence of VE's growing self-awareness? Caffeine-induced hallucination on the reporter's part? Inquiring minds want to know.

Chrome/Ubuntu and FF/Ubuntu.

--------------------------
**Version**: unspecified
**Severity**: normal
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
Caffeine-induced hallucination on the reporter's part would have been a better explanation.  Yes, 49411 again.

*** This bug has been marked as a duplicate of bug 49411 ***
Looks like a Parsoid caching issue: bug 49411 again?
Screenshot of problem. Compares VE view and MWParser view.

Wikitext [[/Foo/]] should be interpreted as a link to ./Foo with label "Foo". This is likely a bug in Parsoid but I'm filing it in VisualEditor for now (feel free to make dependant on a Parsoid bug, or if it requires no action from our end, re-purpose and move there).

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

**Attached**: {F11096}
*** This bug has been marked as a duplicate of bug 48081 ***
In particular it appears that the |pictured parameter in a file link is not being recognised. Take a look at https://en.wikipedia.org/wiki/User:PamD in the VisualEditor.

--------------------------
**Version**: unspecified
**Severity**: normal
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
This is a dupe of bug 48387 which is fixed and deployed as of a few minutes ago but Parsoid's cache needs to be purged for this to show up.

*** This bug has been marked as a duplicate of bug 48387 ***
Aha,
No, it's the : in front of the Image:name, that isn't being recognized.
If one creates two list items and then tries to bold them at the same time, the items are removed and replaced with a pawn symbol. This is reproducible on the version currently deployed on the English Wikipedia.

--------------------------
**Version**: unspecified
**Severity**: normal
Dupe of bug 49732 which is fixed in master and wmf8; will get that pushed to production wmf7 tonight.

*** This bug has been marked as a duplicate of bug 49732 ***
In the following edits, images that were already in the article were duplicated on save, and the duplicate was truncated:

https://fr.wikipedia.org/w/index.php?diff=94163829
https://www.mediawiki.org/w/index.php?diff=713109

--------------------------
**Version**: unspecified
**Severity**: normal
This is 49729.

*** This bug has been marked as a duplicate of bug 49729 ***
(sorry, just saw the first edit.)
One more: https://www.mediawiki.org/w/index.php?title=VisualEditor%2FFAQ&diff=713663&oldid=713655
See https://en.wikipedia.org/wiki/User:Kephir/acid

In the VE: https://en.wikipedia.org/wiki/File:MediaWiki_acid_markup_-_VisualEditor.png
In the normal, rendered page: https://en.wikipedia.org/wiki/File:MediaWiki_acid_markup_-_native_rendering.png

--------------------------
**Version**: unspecified
**Severity**: normal
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
Note that the use of HTML comments mid-token was WONTFIXed: bug 49750.

*** This bug has been marked as a duplicate of bug 49753 ***
Tracking bug; the VisualEditor doesn't seem to work in IE8 (this may be a feature as well as a bug). I'm going to recommend that people upgrade, and mark this as an enhancement, but: it would be nice to have an official statement on if this is coming, if so, when, if not, why, etc.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Great! Thanks.
(In reply to comment #4)
> Makes a lot of sense. Any specific technologies that are problematic? Just
> so I can avoid coming off as "we're not doing it, it's hard".

Primary technologies:
* HTML 5, most notably with ContentEditable (IE8 has basic support; IE in general has major issues with elements that aren't editable inside ones that are - e.g. templates inside pages - though we've found a way to hack around it in IE9&10 for now)
* Javascript (ECMAScript) 5 (not all of it, which is good as IE9 doesn't do that either, but more than IE8 supports)
* Selection interaction (IE's support is... Quixotic, to be polite)
* Key detection/over-riding (same as for selection)
Makes a lot of sense. Any specific technologies that are problematic? Just so I can avoid coming off as "we're not doing it, it's hard".
This is a WONTFIX; Internet Explorer in general doesn't support many of the key technologies that VisualEditor relies upon, and this becomes more acute the further back from IE10 you get.

Supporting "just" IE9 and IE10 has been approximately 90% of our browser-specific workload; for IE8 support, we would need to write an entirely parallel implementation of VisualEditor just for that (and even then, most things wouldn't work).

We cannot justify spending a very significant amount of donors' funds on IE8, which is (as of May) less than 5% of all our readers, and likely even less than that for editors. See [[mw:VisualEditor/Target browser matrix]] (which needs to be updated) for detail about which browsers we actively support.
That's an en_INTERNET idiom. Do you want me to sic the internationalisation team on you? Cuz I will.
Kill it with fire!
https://en.wikipedia.org/?diff=560548908

Step to reproduce:
1. Click on the "Media" button on VisualEditor toolbar
2. Choose a media to insert
3. Click "Insert media"
4. Save page

--------------------------
**Version**: unspecified
**Severity**: normal
Same thing?

*** This bug has been marked as a duplicate of bug 49596 ***
Screenshot

Check out the top left of the screen; interacting with an image, in a resize-y way, causes resize-like highlighting to appear in monobook.

Windows 7, Firefox 21.0

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

**Attached**: {F11696}
This is a duplicate of bug 50074 (despite the naming, it was a wider issue with phantoms), which is now fixed.

*** This bug has been marked as a duplicate of bug 50074 ***
See (ferinstance) https://en.wikipedia.org/w/index.php?title=User:JohnCD/draft&diff=560430675&oldid=560430611

--------------------------
**Version**: unspecified
**Severity**: normal
%%%*** This bug has been marked as a duplicate of bug 49755 ***%%%
If you explicitly declare positional parameters in a template, and then edit it with the Visual Editor, the Template Inspector converts it to implicitly declared positional parameters - i.e. {{some template|1= foo |2= bar }} becomes {{some template|foo|bar}}.

Now, if an explicit positional parameter contains an equals sign, then the Template Inspector puts nowiki tags around it. So {{some template|1= foo=bar |2= baz }} becomes {{some template|<nowiki>foo=bar</nowiki>|baz}}. However, "foo=bar" and "<nowiki>foo=bar</nowiki>" are not equivalent wikitext. For example, nowiki tags will break wikilinks.

There's an example of the difference in this diff:
https://www.mediawiki.org/w/index.php?title=VisualEditor:Template_test&diff=712906&oldid=712905

See the effects for the revisions before and after (look at the "Inline template" section).

Before: https://www.mediawiki.org/w/index.php?title=VisualEditor:Template_test&oldid=712905
After: https://www.mediawiki.org/w/index.php?title=VisualEditor:Template_test&oldid=712906

--------------------------
**Version**: unspecified
**Severity**: normal
Change 72876 merged by jenkins-bot:
Bug 49739: Use named parameter if value contains '='

https://gerrit.wikimedia.org/r/72876
Change 72876 had a related patch set uploaded by GWicke:
Bug 49739: Use named parameter if value contains '='

https://gerrit.wikimedia.org/r/72876
This feels like a Parsoid bug, but I'm not sure? The user creating the equivalent of {{foo|1=foo|2=bar=foo}} should serialise to {{foo|foo|2=bar=foo}} instead of  {{foo|foo|bar<nowiki>=</nowiki>foo}}.
See also bug 49743.
Screenshot

See associated screenshot. This was an attempt to include "foo" in a string-based parameter in the infobox on https://www.mediawiki.org/wiki/VisualEditor:Template_test

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

**Attached**: {F11624}
This is a dupe of bug 49854.

*** This bug has been marked as a duplicate of bug 49854 ***
If I want to track a bug, I can just vote for it. This is pretty common practice, as I understand it. 

But voting seems to be disabled in the VisualEditor product. Can we have it please?

--------------------------
**Version**: wmf-deployment
**Severity**: normal
The voting system is worse than valueless; it has absolutely impact on prioritisation (we use judgement and actually talking to the community for that), which is bad enough, but it gives users the entirely-false expectation that we even notice, let alone act upon, their "votes".

The "voting" system should be removed from Wikimedia's Bugzilla instance for all products, but at the very least, I think it's dangerously disrespectful to our users - who can't be expected to know this works in practice - to add its rot to any more places.

Marking as WONTFIX.
(In reply to comment #1)
> Voting is not for tracking a bug, voting is to express that you'd like to
> see a
> bug fixed. The CC field is for tracking a bug.

See some of the comments in bug 25321 and bug 28385...
Voting is not for tracking a bug, voting is to express that you'd like to see a bug fixed. The CC field is for tracking a bug.


It's correct that some products have it enabled, others have not.

In general (not a topic for this bug report), if voting is NOT used as an input channel for planning by developers (and hence part of the process to define priorities), it should be disabled.
I cannot make that decision for another team, hence CC'ing James.
My personal preference currently is to completely disable voting for above reasons (not used by management as one input channel to set priorities).
Go to <https://test.wikipedia.org/wiki/IPod?veaction=edit>.

Click "Page settings", enter "hello" for the default sort key, click "Apply changes".

Click "Page settings", clear the default sort key, click "Apply changes".

Review your changes. VisualEditor wants to insert "{{DEFAULTSORT:}}" into the page. I don't think we want this behavior.

--------------------------
**Version**: unspecified
**Severity**: normal
Merged and will be deployed very soon.
Related URL: https://gerrit.wikimedia.org/r/69850 (Gerrit Change Ie3caaf4811f87911444462f83d511c0cc46c0716)
The URL was served for me in 22.766 s and contain spurious entries (without visualeditor tag) like
    21:47, 17 June 2013 . . (0)‎ . . Feedback: Wikipedia:File Upload Wizard . . DenakiPanos70 (talk) 

This practically equivalent search was served in 1.645 s: <https://en.wikipedia.org/w/index.php?limit=500&tagfilter=visualeditor&title=Special%3AContributions&contribs=newbie&target=&namespace=8&nsInvert=1&tagfilter=visualeditor&year=2013&month=-1>

--------------------------
**Version**: master
**Severity**: major
**URL**: https://en.wikipedia.org/w/index.php?limit=500&tagfilter=visualeditor&title=Special%3AContributions&contribs=newbie&target=&namespace=&tagfilter=visualeditor&year=2013&month=-1
Merged.
https://gerrit.wikimedia.org/r/#/c/69152/ & https://gerrit.wikimedia.org/r/#/c/69153/ should fix this.
**Author:** `rachelqa99`

**Description:**
On this page, we cannot create a reference:   https://www.mediawiki.org/wiki/User:Cmcmahon%28WMF%29/references_bug

We can create a reference on this page: https://www.mediawiki.org/wiki/User:Rachel99/VisualEditor_Feature_Test_Charter/refs_demo

--------------------------
**Version**: unspecified
**Severity**: major
Chris, it's possible that we accidentally fixed the bug? We updated to master yesterday afternoon, though I don't think we were doing anything in this area.
This seems to have been an anomaly. A strange anomaly because Rachel and I both were unable to create a reference on this page.  Upon clicking "Apply changes" in the Reference UI, nothing at all appeared on the page. Now it does.
Maybe you want bug 45132.
Works for me: https://www.mediawiki.org/w/index.php?title=User:Cmcmahon(WMF)/references_bug&diff=712793&oldid=712613 . Am I missing something?
A user reported this edit
<https://pt.wikipedia.org/w/index.php?title=CMM_-_Canal_Meninos_e_Meninas&diff=36129698&oldid=36129686>, where he just meant to delete a sentence. However the content was duplicated and templates were substituted in this duplicated version.

--------------------------
**Version**: unspecified
**Severity**: normal
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
This is now fixed in production - really sorry about this bug. If it happens again, please re-open this.
See https://en.wikipedia.org/wiki/Daryle_Singletary?veaction=edit - the first three (but strangely, not the last) discography tables.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #5)
> (In reply to comment #4)
> > This is a Parsoid bug. The PHP parser does not generate a <tr> for this
> > wikitext, and Parsoid does.
> 
> Does the PHP parser create it but it then gets tidied away?
That's possible, I haven't checked what happens when Tidy is disabled.
(In reply to comment #4)
> This is a Parsoid bug. The PHP parser does not generate a <tr> for this
> wikitext, and Parsoid does.

Does the PHP parser create it but it then gets tidied away?
This is a Parsoid bug. The PHP parser does not generate a <tr> for this wikitext, and Parsoid does.
(In reply to comment #2)
> Makes sense. Alternately would it be possible to add it in as a rule to
> Parsoid's voodo wikimarkup-fixing stuff? If a |- is followed by nothing and
> then a |}...

But some gadgets might rely on that meaning something special for some users. Everything we change or "fix" potentially breaks things for some (other) users. :-(
Makes sense. Alternately would it be possible to add it in as a rule to Parsoid's voodo wikimarkup-fixing stuff? If a |- is followed by nothing and then a |}...
This is not a bug (well, it's not a bug with VE :-)) - the three "broken" tables all have 

  |-
  | <content>
  |-
  |}

… at the end, which is not the case for the third "working" one. What you see is the result of broken wikitext.

VE is good, but it can't be psychic about what you wanted to do with that that extra table row (maybe you wanted to expand the table and were half-way through?) so behaviour is "as intended". Marking as INVALID; in general broken wikitext like this can't be trivially fixed by a bot, due to wikitext's complexities, but it might be worth exploring.
See the bottom of https://en.wikipedia.org/wiki/Chad_Griffin for example - it also occurs at https://en.wikipedia.org/wiki/3rd_Brahmans and https://en.wikipedia.org/wiki/In_re_Estate_of_Gardiner (each time in a different language; Russian, Vietnamese and French respectively).

I have no idea what's going on, but this seems pretty important to solve for.

--------------------------
**Version**: unspecified
**Severity**: normal
This is previously reported (and also they think fixed).

*** This bug has been marked as a duplicate of bug 49411 ***
An example is https://en.wikipedia.org/w/index.php?title=Valotte&diff=559961373&oldid=559939306 - another is https://en.wikipedia.org/w/index.php?title=The_Day_the_World_Gets_%27Round&diff=559962523&oldid=559851975 where the VisualEditor seems to have taken it upon itself to drop content and convert templates into pure reference tags

--------------------------
**Version**: unspecified
**Severity**: normal
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
The {{#tag:ref|…}} issues should now be fixed in production.

The specific issues of adding <nowiki>s around wiki-able elements of tables is also, I believe, fixed in production.

<nowiki>s around wikitext are, of course, intentional.
Nowiki tags are also being entered around elements of tables - see https://en.wikipedia.org/w/index.php?title=Guy_McKenna&curid=1748898&diff=560026334&oldid=560026013
See the tabs on https://en.wikipedia.org/wiki/User:Panpog1 for example.

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed.
**Author:** `bellayet`

**Description:**
At bn Wikipedia ULS does not working with recently added VisualEditor beta.

--------------------------
**Version**: unspecified
**Severity**: normal
True, thanks for reporting. Despite the mysterious bug summary, this is known as bug 49569 :) and is being actively worked on as GSoC project.

*** This bug has been marked as a duplicate of bug 49569 ***
**bellayet** wrote:

ULS Input tool is not supporting VisualEditor.
I failed to find it under extensions where I was expecting it to be.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #6)
> To be fair the bug summary is rather generic. It would make sense to have a
> placeholder under "MediaWiki extensions", or maybe a mention of the product
> somewhere.

The plan is to split the codebase after the beta deployment in a few weeks' time into "VisualEditor core" and "a MediaWiki plug-in that uses this foreign library called VisualEditor".

At that point, it might make sense to re-activate "MediaWiki extensions > VisualEditor", if only because that's where people might look for it; I'm happy to triage bugs in two places. In practice you'd likely have most bugs for MW-VE be dependent on VE-core bugs, but that's still manageable.

@Andre, thoughts on this?
To be fair the bug summary is rather generic. It would make sense to have a placeholder under "MediaWiki extensions", or maybe a mention of the product somewhere.
The visual editor backend for MediaWiki, once split out, will actually be a MediaWiki extension, and for that one a component will be created under "MediaWiki extensions" in Bugzilla.
The VisualEditor product itself will be MW-independent and hence a product on its own. Like now.

> I don't see why VisualEditor can't have an entry in MediaWiki extensions.

Because the VE product has components in Bugzilla, and Bugzilla does not allow subcomponents (components that are part of a component).
If I make the VE product a component under the "MediaWiki extensions" product in Bugzilla, VE will have to lose all its components. And we don't want that because it's complex enough to have components.
I don't see why VisualEditor can't have an entry in MediaWiki extensions. It's a MediaWiki extension. This is a reasonable place to look for it. You can add a note in the description about filing the bugs under a different product, but we certainly don't to lose bugs because people can't figure out where to file them.
I doubt many will understand the difference between VE and VE backend (the extension?) .I don't. They shouldn't be called the same.
...and Bugzilla bugs should be filed under Bugzilla. Moving.
The VE backend for MediaWiki, once split out, is expected to become an extension on its own (also codewise) soon, but VE itself will stay as a toplevel product.

Plus Bugzilla's three levels (classification, product, component) do not allow having subcomponents under components hence not feasible.
The preference "Use the wikitext editor for editing sections while VisualEditor is in beta" should be enabled by default.

More generally, users have the option to use or not to use the VisualEditor at the top of the page, but not at the section level. Some users in the Hebrew Wikipedia complained that it's disruptive, and I agree with them.

Another possibility is to have two section edit links, like it is at the top of the page.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49666
Thanks. I like the chosen solution.
In the end we've gone with a solution to have both links, as requested, so closing this option on the default as INVALID (the option itself doesn't make any sense given the change in the product design).
**brassratgirl** wrote:

Agreed that having two links would be super. Visual editor for section-editing by default is driving me crazy on the English Wikipedia.
--------------------------
**Version**: unspecified
**Severity**: normal
This was done by Ori in gerrit 69161 for VisualEditor only; if we want to put this into core, we'll want to do that later, but for now marking this as closed.
Coordination card on Trello: https://trello.com/c/xCkMEAY0

Reminder: anonymous editors are excluded from logging (we'll instrument the edit funnel for anons in July in preparation for the global launch).
--------------------------
**Version**: unspecified
**Severity**: normal
Roan implemented this in code rather than as a config of $wgVisualEditorEnableSectionEditLinks; INVLAIDing.
Currently links with mw:WikiLink/Interwiki get alienated

--------------------------
**Version**: unspecified
**Severity**: normal
I'm a fool to myself.

*** This bug has been marked as a duplicate of bug 49316 ***
The link inspector shows valid links as red in the autocomplete function. This is potentially very disruptive and confusing for editors, new and old alike, who pattern-match 'red' to 'this page does not exist'.

--------------------------
**Version**: unspecified
**Severity**: normal
Yes, this is specifically that it's filtering out redirects in its suggestions (good) but then assuming that if it's not a non-redirect, it doesn't exist (bad). We'll get this fixed.

*** This bug has been marked as a duplicate of bug 49502 ***
https://en.wikipedia.org/w/index.php?title=User:TheDJ/sandbox&oldid=559712952

Try adding a gallery that was made using <Gallery></Gallery>

Anything following the opening <Gallery> tag seems to be enclosed inside it. Also when saving, the following might apparently occur: https://en.wikipedia.org/w/index.php?title=British_Rail_Class_50&diff=prev&oldid=559199747


Discussion: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=559712784#Spurious_gallery_tags

--------------------------
**Version**: unspecified
**Severity**: normal
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
https://gerrit.wikimedia.org/r/68727 (Gerrit Change I288f6ec9e4117ce58e2f445e73868937be1654af) | change APPROVED and MERGED [by jenkins-bot]
Related URL: https://gerrit.wikimedia.org/r/68727 (Gerrit Change I288f6ec9e4117ce58e2f445e73868937be1654af)
*** Bug 49579 has been marked as a duplicate of this bug. ***
Argh, yes, this looks like a Parsoid issue. (I would have thought that all wikitext syntax should be case insensitive?)
See https://en.wikipedia.org/w/index.php?title=Breast_cancer&diff=558696523&oldid=558695500 and https://en.wikipedia.org/w/index.php?title=Downward_causation&diff=prev&oldid=558735268 for example; I have...no idea what's happening.

--------------------------
**Version**: unspecified
**Severity**: normal
I think that we've fixed this bug, but if it recurs please re-open.
As requested at https://en.wikipedia.org/w/index.php?title=Wikipedia%3AVisualEditor%2FFeedback&diff=559578396&oldid=559577689

Whether this is something there will be a generalised use case for, I can't say, but it's kinda a nifty idea in theory. I'd stick it on the "we'll consider it when everything else works" list.

--------------------------
**Version**: unspecified
**Severity**: enhancement
bug 41150 was changed to be media objects only; text drag and drop is yet to come.

*** This bug has been marked as a duplicate of bug 49981 ***
Neat! Thanks :)
Good news - we've already got this planned as part of the beta - see bug 41150. Marking as a dupe.

*** This bug has been marked as a duplicate of bug 41150 ***
When editing for example http://pt.wikipedia.org/wiki/Rana with the VisualEditor, all the red links are shown as blue links.

--------------------------
**Version**: unspecified
**Severity**: normal
Hey, this is a duplicate of bug 37901 - unfortunately, this depends on hinting in Parsoid (bug 37902) which is not yet done.

*** This bug has been marked as a duplicate of bug 37901 ***
The number of browser tests and the number of browser test builds have both increased to the point that our original idea of a mid-day build and a late-day build (Pacific time) no longer serves us well.  The builds take long enough that they run essentially back-to-back all afternoon every day.  

I suggest we run all the builds at 11:00 Pacific time to have timely build information available around deployment time during the US working day. 

Then I suggest that we run all the builds once at 19:00 Pacific time (GMT-8) so that the results will be available for analysis in the morning Croation time (GMT-1)

--------------------------
**Version**: wmf-deployment
**Severity**: normal
Fixed in https://gerrit.wikimedia.org/r/#/c/69865/

If there is still something to be done here, reopen the bug.
Actually, upon reflection, I think we can support the weekly releases better, and move toward even faster release cycles perhaps by something like this: 


Builds for beta labs to run several times per day. Possibly run Chrome/FF builds more often than IE builds for speed. 

Builds for test2 to match deployments to test2/mw.o depending on features tested e.g. VisualEditor.

Builds for production to match deployments to prod. "Sufficiently advanced testing is indistinguishable from monitoring."

Builds for mobile TBD.
The image is loaded

editing article [[:zh:港鐵都城嘉慕電動列車_(直流電)]]

if there exists a wikilink to a file, then the file will be loaded which should not happen.

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

**Attached**: {F11725}
*** This bug has been marked as a duplicate of bug 48387 ***
To edit an article using the VE, the URL is "...?veaction=edit".

But, by loading the page with the VE, the URL is changed and becomes the same than the one to display the article.

There is consequently an inconsistency between the URL and the page content.

"?veaction=edit" and all other URL parameters should not be changed/removed.

--------------------------
**Version**: unspecified
**Severity**: normal
This is being done as part of bug 43844.

Instead of letting it stay, we're going to enforce it even when not there.

veaction=edit was originally (and still is) only used to start VisualEditor by url.

When starting it from within MediaWiki by clicking "Edit" when reading an article, it never used veaction=edit.

Bug 43844 asks for consistent url reflection of state in both directions.

*** This bug has been marked as a duplicate of bug 43844 ***
VisualEditor's new features should be exposed for testing outside of our local development environments.

--------------------------
**Version**: unspecified
**Severity**: normal
Done on 2013-06-06.
(In reply to comment #1)
> And the test and MW.org wikis.

Per Timo's comments, only on MW.org not test.
And the test and MW.org wikis.
I updated the translations of several VisualEditor messages in translatewiki.net. The changes were committed to Gerrit, and it looks like LocalisationUpdate ran several times since then, but I still don't see them on the Hebrew Wikipedia.

For example, let's take the message Visualeditor-linkinspector-suggest-matching-page:

1. Update in transatewiki.net: https://translatewiki.net/w/i.php?title=MediaWiki%3AVisualeditor-linkinspector-suggest-matching-page%2Fhe&diff=4721642&oldid=4682586

2. Commit to Gerrit: https://gerrit.wikimedia.org/r/#/c/63552/1/VisualEditor.i18n.php (line 1661)

3. Still not updated in he.wikipedia: https://he.wikipedia.org/w/index.php?title=Special:AllMessages&prefix=visu&filter=modified&lang=he&limit=5000

--------------------------
**Version**: wmf-deployment
**Severity**: normal
The issue is on Gerrit side.   The check-sync.sh of mediawiki/extensions.git let us detect such issue.

Follow up on bug 49846 mediawiki/extensions.git does not update some extensions

*** This bug has been marked as a duplicate of bug 49846 ***
So VisualEditor was fixed with some manual database poking, and a number of the others seem to have been fixed too. Thanks ^demon!

On the other hand, a number of others seem to be newly broken. The current list is: AutoCreateCategoryPages Bootstrap Campaigns CirrusSearch CommunityTwitter CoreEvents EImage Less OpenStreetMapSlippyMap PerPageLicense QuickResponse TimelineTable WikibaseDataModel WikibaseQueryEngine


If you have a fully checked-out version of mediawiki/extensions (git pull && git submodule update --init --recursive), this bash script should tell you the submodules that aren't at master:

  for m in `sed -n 's/\[submodule "\(.*\)"\]/\1/p' .gitmodules | sort`; do (
      cd $m;
      A=`git log -1 --format="%h %ci %s"`;
      B=`git log -1 --format="%h %ci %s" origin/master`;
      [ "$A" = "$B" ] || echo $m
  ); done

Of course, that won't catch anything that hasn't had a commit since being broken, if such a state is possible. If you want to see info on the actual commits, BTW, you can change 'echo $m' in there to something like 'echo -e "$m\n  $A\n  $B"'.
(In reply to comment #0)
> For example, let's take the message
> Visualeditor-linkinspector-suggest-matching-page:

That one arrived.

(In reply to comment #2)
> Also, I did some further checking and found some other submodules also
> affected. The full list is: EImage MagicNoCache MyVariables
> NamespaceRelations
> OpenStreetMapSlippyMap PHPExcel PerPageLicense TimelineTable VisualEditor

I don't know if it's related, but the most obvious place where I saw recent changes being unreported is https://github.com/wikimedia/mediawiki-extensions which at some point reported a bunch of extensions as last edited "6 months ago" when they obviously weren't.
(In reply to comment #1)
> 
> We'll see if Gerrit change #65818 (manually updating the submodule to master)
> will convince the automatic updating to start working again.

It didn't.

Also, I did some further checking and found some other submodules also affected. The full list is: EImage MagicNoCache MyVariables NamespaceRelations OpenStreetMapSlippyMap PHPExcel PerPageLicense TimelineTable VisualEditor

It'll probably take someone either checking Gerrit's logs or digging through Gerrit's code to find out what exactly is making it not update these modules.
The problem seems to be that the VisualEditor submodule in mediawiki/extensions hasn't been being automatically updated for some reason.

We'll see if gerrit change 65818 (manually updating the submodule to master) will convince the automatic updating to start working again.
**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
*** This bug has been marked as a duplicate of bug 48387 ***
**swalling** wrote:

Screenshot of markup

**Attached**: {F10438}
**swalling** wrote:

Edit mode, with incorrect thumbnails

**Attached**: {F10437}
(This is only for action in the immediate run-up to VisualEditor deployment as beta.)

The section edit links should point to VE rather than the wikitext editor as part of the 'being the default editor' schtick. This should only apply to wikis with VE on 'beta' rather than remaining on 'alpha'.

--------------------------
**Version**: unspecified
**Severity**: normal
Done today.
Feedback gets submitted to a page given by the message MediaWiki:Visualeditor-feedback-link. The link can differ from language to language.
But feedback gets submitted to the link for the user-chosen interface language, not the wiki/content language and so hitting different pages.

ex.:
german interface: https://de.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/R%C3%BCckmeldungen&diff=prev&oldid=118691535
english interface: https://de.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=prev&oldid=118691557

This may apply to other messages as well

--------------------------
**Version**: unspecified
**Severity**: minor
*** This bug has been marked as a duplicate of bug 47730 ***
Screenshot of the English Wikipedia using VisualEditor, 2013-05-18

VisualEditor seems to be expanding certain image links. Screenshot attached.

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

**Attached**: {F11087}
*** This bug has been marked as a duplicate of bug 48387 ***
Not sure how to proceed on this one.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Apparently it does and MW was just being unhelpful. Ignore.
1. Edit http://en.wikipedia.org/wiki/Refrigerator
2. Look at the list in paragraph "Production by country"

The list has extra empty lines, some with a bullet, some without.

The saved wikicode is OK, though.

--------------------------
**Version**: unspecified
**Severity**: normal
Oh, I see, my bad, I should have checked the wikicode! :-)
This is not a bug; the actual wikitext of the article has multiple lists with (admittedly hard-to-notice) gaps between them:

> […]
> *20 South Africa	 	711,000<ref name="statinfo.biz"/> (2003)
> *21 Sweden	 	639,000<ref name="statinfo.biz"/> (2004)
> 
> *22 Ukraine	 	562,000<ref name="statinfo.biz"/> (1995)
> *23 France	 	544,000<ref name="statinfo.biz"/> (2003)
> *24 Australia	 	423,000<ref name="statinfo.biz"/> (1995)
> 
> *25	Portugal	 	399,000<ref name="statinfo.biz"/>	(2004)	
> *26	Bulgaria	 	353,000<ref name="statinfo.biz"/>	(2005)
> […]

In VisualEditor these gaps between lists are much more prominent because we need to give the user somewhere obvious to insert their cursor, but this is "behaviour as expected". Closing as INVALID.

(BTW, I just went and fixed the wikitext in a personal capacity, because it was so awful. :-))
VisualEditor is currently unable to display the parameters in the template editor in the same order as the wikitext because they are provided as a plain object.

And per the JSON specification (and as proven by inconsistent behaviour in different browsers), objects are "an unordered set of name/value pairs"[1].

And even if JSON would support it, once in javascript, we have the for-in statement and Object.keys() which do not have a reliable cross-browser logic for the order of the keys.

Though Parsoid is able to roundtrip the order (since it has the original wikitext and can put them in the right order), we can't.

I'd recommend the output is updated to output an array of some kind.

So instead of :
 { foo: bar, bar: quux }

It'd be something like this:

 [ { foo: bar }, { bar: quux } ]

or (Trevor's idea):

 { keys: ['foo', 'bar'], values: ['bar', 'quux' ] }


[1] http://json.org/

--------------------------
**Version**: unspecified
**Severity**: normal
Only the name of parameters is significant, the order is a syntactic detail. You can do a numeric sort on numeric parameter names for UI purposes, but generally our API only talks about named parameters.
If you try to change a link anchor by pasting plain text over the old anchor (or part of the old one), it won't work.  The new text will just stay plain.

You can't use the link dialog for this either, since there is no anchor field.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**jiabao.foss** wrote:

That's very nice of you! I would love to investigate this bug.
(In reply to comment #4)
> Sorry that I did not know the link inspector could be rich text. Now looking
> forward to the new deployment of VE. It will be nice to read the solution, on
> the problem which I have worked on but did not get a good solution. Thank you
> for the reviews and explanations. I learned a lot from this attempt. :)

Thank you for trying! If you want to get your teeth into something in VisualEditor relatively self-contained, but still touching on a considerable amount of the codebase (and which would be really great to have done), bug 47328 could be a good challenge. Will leave a comment there suggesting an approach.
**jiabao.foss** wrote:

Sorry that I did not know the link inspector could be rich text. Now looking forward to the new deployment of VE. It will be nice to read the solution, on the problem which I have worked on but did not get a good solution. Thank you for the reviews and explanations. I learned a lot from this attempt. :)
Yeah, sorry about this; I was behind in triaging bugs and didn't get to this in time. It's in fact actually a duplicate of an already-fixed bug that went out in wmf4 (but isn't yet deployed on enwiki - that will happen on Monday 20 May).

*** This bug has been marked as a duplicate of bug 48195 ***
Unfortunately this bug didn't get triaged in time, and I worry that you may have spent a lot of time working on a solution for a no-longer-existing problem.

The bug here has to do with pasting into the middle of a link not taking on the proper annotations. This appears to be fixed in master, and production is somewhat behind that.

The solution being offered here ( I9ae4aeed6099cbe9affdc2aa83045121bc0b8669 ) adds a "display text" input to the inspector - but I think this patch overlooks some important UX and technical issues.

We deliberately do not want to have a text field in the inspector for the display text, for a couple of reasons.

1. The "display text" isn't just plain text, it could include formatting, templates, images, etc. This isn't going to work in a single line text input.

2. Users already have a way to change the display text (or non-text) content, and if there are bugs there, we should resolve them there.
**jiabao.foss** wrote:

I have investigated this bug. When looking at the use case for pasting text as you insert it into the hyperlink you need to also consider other formatting being pasted in. In other editors you can see that the link also splits leaving the text plain. This is because if you pasted for example a table or a section into the center of a link it cant accept this as part of the link itself and must be split. 

The solution I will work on is add a way to edit the displayed hyperlink text while the linkinspector dialog is open. this will allow users to paste box complex links and displayed text when using visualeditor.
**Author:** `the.anonymouse.wikimedia`

**Description:**
screenshot of editing my .js file with VisualEditor

When editing user skin .js and .css page ([[Special:MyPage/skin.js]] and [[Special:MyPage/skin.js]]), line returns are replaced with ↵ symbols. I attached a screenshot to this bug report of editing my .js page with VisualEditor.

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

**Attached**: {F10832}
Happily, we've just last week disabled editing of JS and CSS pages (the code will be deployed to enwiki on Monday 20 May).

*** This bug has been marked as a duplicate of bug 47456 ***
VisualEditor link dialog box incorrectly showing red text, 2013-05-13

Go to <https://www.mediawiki.org/wiki/Sysadmin_hub>. Click "edit". Highlight the word "wiki" and click the link icon in the toolbar. A dialog box pops up incorrectly showing "wiki" in red text (indicating that the article does not exist). Screenshot attached.

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

**Attached**: {F10762}
Also reported by Timo; given work us underway, DUPEing up rather than down.

*** This bug has been marked as a duplicate of bug 48476 ***
VisualEditor message key exposed on mediawiki.org, 2013-05-13

URL: <https://www.mediawiki.org/wiki/MobileFrontend/Photo_upload/Analysis>

Error: see attached screenshot

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

**Attached**: {F10756}
Now fixed.
Looks like <visualeditor-diff-nochanges> is not in MW.org's message file; need to do a message purge?
When the VisualEditor replaces the normal "Edit" tab with "Edit source" it deletes any selected/active state on the tab. This results in an active edit tab becoming non-active when you are on &action=edit.

Additionally on a non existent page "Create" gets replaced with "Edit source" instead of something like "Create source".

--------------------------
**Version**: unspecified
**Severity**: normal
This is a dupe of three different bugs, but I'll settle for the obvious one. :-)

(A prior search when you're reporting a bug does help avoid this! :-))

*** This bug has been marked as a duplicate of bug 47452 ***
As per Subbu's report. (The corrupted table is going to be a different bug.)

--------------------------
**Version**: unspecified
**Severity**: trivial
**URL**: http://parsoid.wmflabs.org/_rt/en/BMW_801
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
Fixed in production.
Related URL: https://gerrit.wikimedia.org/r/62546 (Gerrit Change If16dda01058715acee8df347b2b9c4da84609113)
I am still getting a clean diff with Chromium (and &debug=true to work around current VE breakage). Can you point out any pages that have a dirty diff both in FF and Chrome?
(In reply to comment #5)
> Those were FF-specific, which points to client-side issues. Are they now an
> issue independent of the browser?

Actually, that bit wasn't FF-specific, it was happening in Chrome as well (and I can confirm that it still does).
Those were FF-specific, which points to client-side issues. Are they now an issue independent of the browser?
(In reply to comment #3)
> Can you link to the original report?

The midden of bug 47712.
Can you link to the original report?
(In reply to comment #1)
> I get a JS error when trying to preview the diff in that page using FF:
> [13:44:04.016] Error: toDomElements() failed to return an array when
> converting
> element of type alienBlock @
> http://bits.wikimedia.org/en.wikipedia.org/load.
> php?debug=false&lang=en&modules=ext.visualEditor.core%2Cicons-raster%7Cext.
> visualEditor.viewPageTarget.icons-raster%7Crangy%7Cunicodejs.
> wordbreak&skin=vector&version=20130506T190432Z&*:130

Bug 48181.
I get a JS error when trying to preview the diff in that page using FF:
[13:44:04.016] Error: toDomElements() failed to return an array when converting element of type alienBlock @ http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cicons-raster%7Cext.visualEditor.viewPageTarget.icons-raster%7Crangy%7Cunicodejs.wordbreak&skin=vector&version=20130506T190432Z&*:130
In MW, annotations loaded from the document will have data-parsoid attributes, and so will have difference store indexes to new annotations. If two words with differently indexed bold annotations are placed side-by-side they converter will close the first one before opening the second, e.g.:

<b>Bold on load text</b><b>added text</b>

Which Parsoid converts to

'''Bold on load text''''''added text'''

--------------------------
**Version**: unspecified
**Severity**: normal
Merged into master.
Related URL: https://gerrit.wikimedia.org/r/62352 (Gerrit Change I93586919002c78732228e08b134e67e1a94f8ad7)
https://zh.wikipedia.org/w/index.php?title=Team_A_6th_Stage%E3%80%8C%E7%9B%AE%E6%93%8A%E8%80%85%E3%80%8D&diff=26390481&oldid=25589213

All change done manually is the insertion of "编辑器测试" at the first diff, then those extra </span> and </table> got added automatically.

Where's that "partial serialization" mentioned before?

--------------------------
**Version**: unspecified
**Severity**: normal
The main part of this bug (the extra </span> and </table>) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May.

The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor).

Marking as a dupe.

*** This bug has been marked as a duplicate of bug 47737 ***
I have "1 notice", "You are using an alpha version....".

1. Clicking the notice, it pops up.
2. Click the message contents, the popup hides.

"1 notice" remains.  Maybe it will go away when I save the page I'm editing?

3. Save the page, and edit again.

The notice is still there, and even expands when the editor is started.  Blargh!

--------------------------
**Version**: unspecified
**Severity**: minor
(In reply to comment #0)
> I have "1 notice", "You are using an alpha version....".
> 
> 1. Clicking the notice, it pops up.
> 2. Click the message contents, the popup hides.
> 
> "1 notice" remains.  Maybe it will go away when I save the page I'm editing?
> 
> 3. Save the page, and edit again.
> 
> The notice is still there, and even expands when the editor is started. 
> Blargh!

The notices are urgent notifications about the page, not about the user. They're intended to always display, just like the editnotices they replace.

Theoretically we could have per-user nullification of these, but that'd be messy. Another idea (perhaps?) is to not auto-display the OMG-this-is-so-important-all-users-must-acknowledge nature of editnotices and the like. However, this seems to fly against the underlying purpose of the notices.

Marking as WONTFIX.
Add RTL support for page-, paragraph- and block-level elements in VisualEditor, as well as support for multi-language use in articles.

Full proposal (GSoC2013 project) is available here: http://www.mediawiki.org/wiki/User:Mooeypoo/GSOC_2013_Proposal:_RTL_Support_in_VisualEditor

--------------------------
**Version**: unspecified
**Severity**: normal
This is indeed a duplicate of bug 33126. mooeypoo please update your proposal linking to that bug.

No worries, these things happen to veteran bug submitters as well. :)

*** This bug has been marked as a duplicate of bug 33126 ***
I'll tentatively reopen it and mark it as blocking 33126 instead.
Not sure though, maybe James knows. :)
It's a bug for tracking a GSoC proposal. I think that it should be reopened.
As this seems to be a tracking bug covering several aspects, marking as duplicate of bug 33126.

Please see the list of specific issues blocking bug 33126 in the "Depends on:" section of bug 33126, and if some of the specific issues that you mention are not covered (means: do not have a bug report), please file separate bug reports for each item. Thanks!

*** This bug has been marked as a duplicate of bug 33126 ***
CSS and JS pages shouldn't be editable using the VisualEditor, but only using the regular source editor. These pages should only have the "Edit source" tab.

(It may make sense to have them editable using the source code editor that is used for Lua, but that's a separate issue.)

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 47456 ***
**Author:** `benedix`

**Description:**
One of the feedback-mechanisms in the VisualEditor is broken:

'visual editor' -> 'review and save' -> 'something is wrong' -> 'report problem'

I made a little test:
http://www.youtube.com/watch?v=Zzt_2CBfTNI (35 seconds)

The feedback is sent to http://parsoid.wmflabs.org/_bugs/ but the request is canceled after a few seconds. 


Btw. There is no visual feedback to the user that shows him to wait while the request is pending.


Lukas

--------------------------
**Version**: unspecified
**Severity**: normal
Not actually broken, see bug 42974.
See the URL for a demo.

The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.

In the output page it is shown as "1. 1. 1. 1. 1. 1. 1. A".

In the VE it is shown as
1.
 1.
  1.
   1.
    1.
     1.
      1. A

This is an edge case but it should should probably be identical in any case.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes
Confirm that this is intentional behaviour. There are a number of ways in which VisualEditor is deliberately not merely a WYSIWYG editor, and we should probably explain them so it's less confusing.
As far as I know it is supposed to be that way - otherwise you wouldn't be able to add content to list item at each level. James - please confirm (and reopen if I'm wrong).
**Author:** `mh87`

**Description:**
I tried to add a link to a word. The page containing this word already exsists so the Editor tells me "Matching pages" and lists the word.

When I click the matching word to add the Hyperlink the word says "undefined". After clicking ok the whole line gets deleted

MediaWiki Alpha 1.22
VisualEditor 0.1.0 (latest snapshot)
Chrome 26.0.1410.64 m

--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Windows 7
**Platform**: PC
*** This bug has been marked as a duplicate of bug 47413 ***
**mh87** wrote:

After click on the matching link item it says undefined

**Attached**: {F10658}
Performing small edits on pages with citations like http://en.wikipedia.org/wiki/JRuby results in a clean diff in Chrome, but produces a dirty diff when using Firefox.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 47417 ***
Example edit:
https://en.wikipedia.org/w/index.php?title=User:Fluffernutter/Kinne&curid=37842561&diff=551148728&oldid=551148307
Cursor correctly appear and blinks in slug, but surface completely does not know about it, so when user start typing it does not convert slug into paragraph (for block level slug) or delete slug (for inline slug).

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed here: https://gerrit.wikimedia.org/r/#/c/59199/
Currently we can't use the UnicodeJS.wordbreak library to emulate word skipping (ctrl+arrow / alt+arrow) functionality as wordbreaks appear either side of whitespace and between multiple whitespaces:

|One| |Two| | |Three|

Moving forwards we expect the cursor to stop in the following positions:
One| Two| Three|

Moving backwards we expect:
|One |Two |Three

--------------------------
**Version**: unspecified
**Severity**: normal
Now fixed.
Related URL: https://gerrit.wikimedia.org/r/58868 (Gerrit Change I6b2700d65476c4d34ba4a01a88382d7af8e736fb)
Actually Ed is still working on it.
I have added better support for skipping white spaces in 4th patch set: https://gerrit.wikimedia.org/r/#/c/57076/
Looking at other implementations, sepcifically OpenOffice, they have an "ignore whitespace" mode in their nextWord function:

https://svn.apache.org/repos/asf/incubator/ooo/symphony/trunk/main/i18npool/source/breakiterator/breakiterator_unicode.cxx

which calls an is_whitepsace function, which is defined as:
http://www.icu-project.org/apiref/icu4c/uchar_8h.html#a5cef869b23e8d8e649963457cccca68e
DM nodes should be able to handle their own children, rather than having the converter do it for them.

This means we need a .static.handlesOwnChildren flag or something similar, and a way for .toDataElement to recursively invoke the converter to convert a sub-DOM to a sub-linmod.

Reflecting this, CE nodes should be able to take control of the rendering of their children as well.

--------------------------
**Version**: unspecified
**Severity**: normal
Done in https://gerrit.wikimedia.org/r/#/c/58645/ and related commits.
Currently VisualEditor users can't touch infoboxes. It would be great to have edit access to the text fields of infoboxes.

Being able to update images would be a plus.

Modification of the infobox itself (e.g. addition of new fields) is out of scope here.


I'm filing this request in relation to 

"Wikidata provides data for Wikipedia's infoboxes. The goal of this project is easy editing of the data for a given infobox on the Wikipedia, without having to go to Wikidata."
http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#On-site_editing

By the time those Wikipedia infoboxes would be filled with Wikidata data, 
"easy editing" should be provided by VisualEditor.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Very much on the roadmap already.

The Wikidata integration is another issue; will talk with Denny and see about opening distinct bugs for that stuff.

*** This bug has been marked as a duplicate of bug 39598 ***
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
**molly.white5** wrote:

From my brief look at pandoc, it appears that it can do it. As always, it's roundtripping that's the issue.
I agree. If we wind up supporting Markdown, it will be because we've found a way to do HTML <--> Markdown, or at least one direction or t'other. Converting to HTML is simple enough, at least.
**molly.white5** wrote:

I agree that LaTeX to wikitext would not be terribly useful. I wonder if the community would benefit from having some other formats be two-way, though. I'm sure there are people out there who would rather write their articles using Markdown... Then again, if we're trying to make the switch to the VisualEditor anyway, the ability to write articles in Markdown would be of only temporary value.
I think we could call that "of dubious usefulness", but you're the one who's going to have to implement it, so I probably shouldn't dictate anything. In any case I think LaTeX and HTML have a much closer 1:1 ratio than WT and HTML, so it should be much easier to add in, even if it winds up being an afterthought.

And as ever, we're in IRC if you'd like any help or guidance :)
**molly.white5** wrote:

Alright, that sounds fine as long as you're not concerned with the speed. I'm not familiar with pandoc, but I'll read up on it. I'm curious to see how they perform wikitext <-> LaTeX and HTML <-> LaTeX.

Have you discussed whether or not we'll want to be able to roundtrip wikitext and LaTeX?
We're chatting on IRC currently, and I think the rough consensus is something like..."HTML should be the common format, and the rest can deal with it." This makes some amount of sense, though it does mean that, temporarily at least, we'll have to deal with parsing WT to HTML before going to other formats. Since anything beyond that is relatively fast, in terms of performance, we can live with that issue for now.

So Molly, we'll throw out the insane charts and maps we've drawn up (which really just consists of one chalk scribble at Harvard) and see what HTML can offer as an intermediary format - to that end, I guess gwicke's suggestion of pandoc is a good place to start.
Reg. 1. the DOM post processor cannot run before the DOM is built, it requires information that is available only after the DOM is fully built.
I just ran a quick serialize to see what the timing was like in comparison to a parse - in case we decide to convert HTML into an intermediary format that would translate into whatever other format we want to use. I think the two seconds that it takes to serialize wouldn't be greatly affected by an extra step in the serializer process, and I think the benefits of having a general solution for converting between formats would be greatly useful.
Steps:

1) Go to http://en.wikipedia.org/wiki/Jean_Nicolas
2) Click VisualEditor
3) Without moving the cursor or anything, enter the following character: a
4) Click "Review and save"
5) The whole content of the article has been replaced with just the character.

--------------------------
**Version**: unspecified
**Severity**: major
*** This bug has been marked as a duplicate of bug 43103 ***
Steps:

1) Go to http://en.wikipedia.org/wiki/Nicolas
2) Click VisualEditor
3) Left-click any link
4) A small popup with only one item appears, click on it
5) Click outside of the popup, for instance on a blank area of the article behind
6) Link has disappeared

Step 5 is what many users do to cancel.

--------------------------
**Version**: unspecified
**Severity**: major
This was fixed in bug 46025 which is bundled in MediaWiki 1.21wmf12 which should be deployed to enwiki tomorrow. Sorry for the delay!

*** This bug has been marked as a duplicate of bug 46025 ***
--------------------------
**Version**: unspecified
**Severity**: normal
Related URL: https://gerrit.wikimedia.org/r/54991 (Gerrit Patch-Set: I249a5d48726093d1cb3e36351893f4bff85f52e2/1)
Before I go breaking things, I've added tests for AnnotationSet: https://gerrit.wikimedia.org/r/54640
We have a job that sanity-checks our API server, which is a primary part of our ability to communicate with the VisualEditor. It fails because the process forks off several workers to handle requests, which sets off big red blinking alarms in Jenkins.

Do we need to add in an option to not fork? Do we need to add in some other method of doing this (like a "start a background process" Jenkins builder)? Or can we work around the file descriptor issue?

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://integration.mediawiki.org/ci/view/All/job/parsoid-server-sanity-check/
Job got deleted, I guess we can forget this bug for now.
Yeah, we disabled it because there was no point in keeping it around.

There's some hacky workaround, but it seemed really complicated and not worth the work at that time.
The tests seem to be working now. Has this been fixed or have certain testing paths been disabled?

Is there something we can do on our end?
daemon seems to have broken it further, though I'm not sure why. I tried letting the server get set up, and I tried making sure my options were correct, but the parsoid server doesn't seem to like being run with daemon.
The job dashboard is https://integration.mediawiki.org/ci/view/All/job/parsoid-server-sanity-check/

An example console is https://integration.mediawiki.org/ci/view/All/job/parsoid-server-sanity-check/65/console 

After the worker have been forked, Jenkins detects some file descriptor leakage and cancel the build:

Process leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information

They point to http://software.clapper.org/daemonize/ .  But maybe we can use /usr/bin/daemon for the same effect.
Screenshot of {{disambiguation}} on [[Loco]] at en.wikipedia.org

Using {{disambiguation}} on a page and editing it with VisualEditor shows an incorrect rendering.

Attached are screenshots and dumps of the active DOM for the PHP parser and Parsoid/VisualEditor.

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

**Attached**: {F10462}
A reasonable resolution of this issue. :)
Indeed. The following edit by me fixed it for Parsoid:

https://en.wikipedia.org/w/index.php?title=Template%3ADmbox&diff=540384230&oldid=466538335

Seems like a reasonable change to make. Not sure how common this is but I think in most cases editors will understand as in most cases this is already how it is. Leading space after a line break causes a <pre>. The reason the line break is there is probably by mistake, and nothing broke so it was forgotten/left.

Lets hope it is not too common.
This can be narrowed down to the difference between these two table cells.  Look at PHP parser output for these two tds in the table:

<table>
<tr>
<td>
  a</td>
<td>
 b
</td>
</tr>
</table>

"a" is not wrapped in a pre-tag, but "b" is.  

http://www.mediawiki.org/wiki/User:Ssastry/Tests:Odd_pre_in_td_behavior

Parsoid wraps both in a pre-tag which is the reason why Parsoid output is different from PHP output.  This seems a PHP parser bug to me, not a Parsoid bug.  I imagine we want to be bug-to-bug compatible, but I am not sure what the correct behavior for this is.
This might be a bug in https://gerrit.wikimedia.org/r/#/c/32405/ or a regression.  The <pre> is coming from an #if parser function which should not have as per that commit message.

Will investigate.
Created attachment 11841
HTML of {{disambiguation}} from Parsoid

The main problem is the presence of a <pre> that shouldn't be there.

**Attached**: {F10465}
Created attachment 11840
Screenshot of {{disambiguation}} from Parsoid

**Attached**: {F10464}
Created attachment 11839
HTML of {{disambiguation}} on [[Loco]] at en.wikipedia.org

**Attached**: {F10463}
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
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.
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
(In reply to comment #0)
> POST /localhost/VisualEditor%3AMetastuff HTTP/1.0
> Host: localhost:8000
> Content-Length: 3
> 
> HTTP/1.1 500 Internal Server Error
> X-Powered-By: Express
> Content-Type: text/html; charset=utf-8
> Content-Length: 66
> Connection: close
> 
> ParserError: Failed to parse the JSON response for Page Fetch null
> 
Ignore this one, this is due to a misconfiguration on my end.

> POST /en/Talk%3AWQKO HTTP/1.0
> Host: localhost:8000
> Content-Length: 3
> 
> Foo
> 
> [Parsoid closes the connection without sending anything]
> 
> Parsoid log:
> There was an error in the HTML5 parser! Sending it back to the editor.
And this behavior occurs on the command line but not from my browser, for some reason.
**Author:** `phil`

**Description:**
I created a page using the normal editor that was


<gallery>
File:Example.jpg|Caption1
#REDIRECT [[Target page name]]
</gallery>


Trying to load this page in VE gives an error message
" Error loading data from server: Server error. Would you like to retry? "

--------------------------
**Version**: unspecified
**Severity**: normal
Phil,

I've checked and this is now fixed (in part - there's the wider question of Parsoid and redirection which is covered in bug 45808) - am marking as closed. Thank you again for your bug report!

James.
**phil** wrote:

Selecting the OK option to Retry brings the error dialog back up so the only option is to Cancel unless you want to spend all day pressing OK

thanks for the extra info on how redirect works - or is meant to work
Phil, did this happen when you retried? That error message (which sucks, and we're going to fix as part of bug 44354) just means that it couldn't hail the Parsoid server at the time, and normally means that nothing went wrong other than the server availability.

More generally, when you edit a page which as has a redirect OR a redirect-like string that isn't a redirect because it's not at the top of the page, Parsoid follows the redirect and returns the document that the redirect points to, which is a pair of bugs (we'll need to be able to edit #REDIRECT statements, so it shouldn't return the redirected page, and it should behave the same way as the PHP parser with regard to what is considered a redirect).
**Author:** `mwalker`

**Description:**
On chrome 24 and firefox 18.0.2 -- rapid switching between the edit tab and the view tab will cause multiple toolbars to be displayed on both the edit tab and view tab.

I note that the page DOM becomes more and more unusable as I keep switching.

As I am switching when I still see the 'loading' indicator; I am guessing that this is caused by a non complete initialization of the editor.

--------------------------
**Version**: unspecified
**Severity**: normal
Now merged.
Whoops, not yet merged.
Merged.
Patch in: https://gerrit.wikimedia.org/r/48491
**Author:** `phil`

**Description:**
Selecting some text and applying Header 6 to it has no affect

The normal editor does not offer this option so it seems inconsistent for it to be an option in the Visual Editor

--------------------------
**Version**: unspecified
**Severity**: normal
Levels of headings available will need to be tweakable for local integrations - for example, we probably don't want to allow H1s in the article namespace on our content wikis.

However, H6s do in fact work and should be made available in general to HTML editors; not sure whether we should provide them in article space.

Am marking this as a duplicate of bug 43334 which talks about H1s; will adjust that one.

*** This bug has been marked as a duplicate of bug 43334 ***
Created attachment 11760
Screenshot showing H1 to H6 in VisualEditor mode

**Attached**: {F11017}
Created attachment 11759
Screenshot showing H1 to H6 in read mode

**Attached**: {F11015}
**Author:** `phil`

**Description:**
Link includes the word 'and'

I edited the space after a link so that the word following was right next to the link. I then realised this was not what I wanted so added the space back
The preview indicated all was well with the space included but after saving the word after the link became part of the link

Example:
The text I had was
"A page about a test pilot and his job"
'test pilot' was a link

I edited the page and put the cursor before the 'a' in 'and' and pressed delete.
I then pressed Space to move the word back to its original position
Saved - the preview indicated all was well
After saving - 'and' had become part of the link

Looking at the page in the normal editor it seems the space has not been put back - the Visual Editor display indicates that it has

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

**Attached**: {F11010}
Ah, couldn't find the bug; thanks, Gabriel.

*** This bug has been marked as a duplicate of bug 33091 ***
To me it seems that the VE should produce a DOM including the space: 

<a href="foo">bar</a> baz

If that is not the case, then this is a bug in VE. Escaping for legitimate link trails was fixed in bug 33091, which is not yet deployed.

So either way, I don't think there is a bug in Parsoid here.
This appears to be a problem in Parsoid.

In VisualEditor the user has (effectively) created <a href="foo">bar</a>baz; it is unexpectedly converted into [[foo|bar]]baz instead of [[foo|bar]]<nowiki />baz, hence the confusion.

Gabriel, thoughts?
Open stand alone editor.  Trigger LinkInspector with cmd/ctrl+k or LinkInspector button.

Uncaught TypeError: Cannot read property 'data' of undefined ve.ui.LinkTargetInputWidget.js:84
ve.ui.LinkTargetInputWidget.getTargetFromAnnotation ve.ui.LinkTargetInputWidget.js:84
ve.ui.LinkTargetInputWidget.setAnnotation ve.ui.LinkTargetInputWidget.js:63
ve.ui.LinkInspector.onOpen ve.ui.LinkInspector.js:95
ve.ui.Inspector.open ve.ui.Inspector.js:206
ve.ui.Context.openInspector ve.ui.Context.js:355
ve.InspectorAction.open ve.InspectorAction.js:44
ve.Surface.execute ve.Surface.js:193
ve.Surface.execute ve.Surface.js:186
ve.ce.Surface.onDocumentKeyDown ve.ce.Surface.js:330
proxy jquery.js:775
jQuery.event.dispatch jquery.js:3063
elemData.handle.eventHandle

--------------------------
**Version**: unspecified
**Severity**: normal
Now merged.
Patched in https://gerrit.wikimedia.org/r/#/c/47615/
nowiki tags

edit a line in VE such that it starts with a space

VE unexpectedly inserts <nowiki> tags on the text of the line

edit a line in VE such that it starts with a text, and add bold or italic to the middle of the line somewhere

VE inserts <nowiki> tags up to the formatted character and leaves the rest of the line alone

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

**Attached**: {F10444}
... but when you save " le'''''adi'''''ing space" in the wikitext editor, you get <pre>le'''''adi'''''ing space</pre>, not <p> le'''''adi'''''ing space</p>. The <nowiki> tags are necessary to get the latter, which is what the VE user actually typed.

Closing as WONTFIX.
Created attachment 11719
normal editor vs. VE on save

**Attached**: {F10447}
Created attachment 11718
normal editor vs. VE preview

**Attached**: {F10446}
Maybe I'm missing something. 

I've attached a screen shot comparing preview in the normal editor to preview in VE where both are doing exactly the same operation:  editing the string " leading space" where the "adi" part of the string is made both bold and italic. 

The normal editor does not add <nowiki> tags to this string.  VE adds <nowiki> tags. 

The normal editor does not save the text with <nowiki> tags.  VE saves the text with <nowiki> tags. 

It may be that VE adds <nowiki> tags by design, but they seem unnecessary.  Again, I could be wrong.
No, this is expected behaviour. A line that starts with " " in wikitext is a pre-formatted block. If VE just let users save <P> Foo</P> as " Foo" they'd get very unexpected results.

We don't (and won't) expect users to understand that certain characters are magic and can't be used in certain places, and instead we need to escape character sequences they've entered that happen to be 'magic'.

Unless I'm missing something?
look what happens in the regular editor.  I think VE is doing something really strange here.
I'm not entirely convinced what the expected behaviour is - should it be just the leading ' ' character that is wrapped in <nowiki> elements?
Created attachment 11706
nowiki tags with formatted text

**Attached**: {F10445}
**Author:** `mail`

**Description:**
Hi,

when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error:

    {"error":{"code":"parsoidserver","info":"Error contacting the Parsoid server"}}

My config is as following:

    require_once("$IP/extensions/VisualEditor/VisualEditor.php");
    define( 'NS_VISUALEDITOR', 2500 );
    define( 'NS_VISUALEDITOR_TALK', 2501 );
    $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor';
    $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk';
    $wgVisualEditorNamespaces = array( NS_MAIN );
    $wgVisualEditorNamespaces = array();
    $wgVisualEditorNamespaces[] = NS_VISUALEDITOR;
    $wgDefaultUserOptions['visualeditor-enable'] = 1;
    $wgHiddenPrefs[] = 'visualeditor-enable';
    $wgVisualEditorParsoidURL = 'http://parsoid.wmflabs.org/';

I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013).

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC
**URL**: http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html
*** This bug has been marked as a duplicate of bug 44483 ***
**mail** wrote:

http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html

Solved by setting $wgGroupPermissions['*']['read'] from FALSE to TRUE.
I hope there will be the possibility to have it FALSE in the future :)
Just very recently I started to work with semantic wikis intensely which use the Vector skin as a standard and where it does not make sense to switch back to MonoBook. 

Having said this, I would like to suggest that the "Refresh" tab (purge) of the action menu at the top of a page is not collapsed with miscellaneous other tabs but always displayed expanded between the "Edit" and "View history" tabs.

Especially for beginners it would be very helpful to make them aware of the possible need to refresh a page.

--------------------------
**Version**: unspecified
**Severity**: enhancement
The Semantic MediaWiki developers requested in https://phabricator.wikimedia.org/T64114 to move their task tracking to https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues and to close remaining tasks in Wikimedia Phabricator.  If you still face the problem reported in this task in a supported version of SMW, please feel free to transfer your report to https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues .  We are sorry for the inconvenience.
Removing relation to Vector skin issues. This is the default behaviour indeed, but individual menu items can indicate whether or not Vector should allow them to "come out  of the menu" and onto the horizontal menu bar when space is available.

The navigation links array in PHP (exposed via the SkinTemplateNavigation hook[1]) contains an array for each tab. Setting property 'primary' to boolean true will instruct Vector to apply class "collapsible".

Example:
 https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/1f136f9d1d/VisualEditor.hooks.php#L96-L101


[1] https://www.mediawiki.org/wiki/Manual:Hooks/SkinTemplateNavigation
The link inspector currently depends on a function which decides whether a target is an internal or external link, making it impossible to link to a new or existing page named like a URL.

This is related to bug 43063.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=43063
Made it to master for the 2013-01-16 branch.
Addressed in gerrit 43028.
**Author:** `Coiby.Xu`

**Description:**
I'm testing VE and meet such error: "Error loading data from server: Server error. Would you like to retry". And the output of Parsoid says: "non-200 response: 404 undefined". According to http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2012_12#Error_loading_data_from_server:_Server_error._Would_you_like_to_retry.3F_2, the bug should have be fixed. 
P.S. I'm using latest VE and Parsoid.

--------------------------
**Version**: unspecified
**Severity**: critical
**OS**: Linux
**Coiby.Xu** wrote:

I'm sorry, this should be a bug. It occurs due to the wrong setting in js/api/localsettings.js
env.setInterwiki( 'localhost', 'http://' );
**blue.snow013** wrote:

(In reply to comment #4)
> (In reply to comment #3)
> > I have the same problems on the latest VE and Parsoid,too.
> > could someone help me?
> Could you tell us:
> * What $wgVisualEditorParsoidURL and $wgVisualEditorParsoidPrefix are set to
> in
> your LocalSettings.php
> * the contents of Parsoid's localsettings.js file
> * where Parsoid is running

Here is my LocalSettings.php

require_once("$IP/extensions/VisualEditor/VisualEditor.php");
 
// Allow using VisualEditor in the main namespace only (default)
$wgVisualEditorNamespaces = array( NS_MAIN );
 
// Enable by default for everybody
$wgDefaultUserOptions['visualeditor-enable'] = 1;
 
// Don't allow users to disable it
$wgHiddenPrefs[] = 'visualeditor-enable';

$wgVisualEditorParsoidURL = 'http://localhost:8000/';


And my localsettings.js:

exports.setup = function( config, env ) {
        // The URL here is supposed to be your MediaWiki installation root
        env.setInterwiki( 'localhost', 'http://localhost/wiki' );

        // Use the PHP preprocessor to expand templates via the MW API
        env.usePHPPreProcessor = false;
};

// Use selective serialization
exports.useSelser = false;
                      
I run the Parsoid in the background using node on my own server.

Thanks!
(In reply to comment #3)
> I have the same problems on the latest VE and Parsoid,too.
> could someone help me?
Could you tell us:
* What $wgVisualEditorParsoidURL and $wgVisualEditorParsoidPrefix are set to in your LocalSettings.php
* the contents of Parsoid's localsettings.js file
* where Parsoid is running
**blue.snow013** wrote:

I have the same problems on the latest VE and Parsoid,too.
could someone help me?
**Coiby.Xu** wrote:

I'm running it on my own server.
Here's the address for testing: wiki.aiesec.cn/index.php?title=Test.
If you click "VisualEditor", the above error will occur.
> (In reply to comment #0)
> > P.S. I'm using latest VE and Parsoid.
> 
> Are you saying you're running it on your own server? Or are you using
> Wikipedia?
(In reply to comment #0)
> P.S. I'm using latest VE and Parsoid.

Are you saying you're running it on your own server? Or are you using Wikipedia?
Finally squashed in https://gerrit.wikimedia.org/r/#/c/43985/.
Merged; code will be deployed as part of the 2013-01-16 release cycle.
Add to deployment milestone.
This appears to have missed the deploy-train; moving.
Add to deployment milestone.
Now merged, will go out in 2013-02-04 release cycle.
Patched in https://gerrit.wikimedia.org/r/#/c/44347/
This is close-enough to done that I'm going to make this as complete. No doubt there will remain bugs, but those are within the framework of VE generally "working".
Please see Bug 41233
Related URL: https://gerrit.wikimedia.org/r/69707 (Gerrit Change I8bcdea0f7a6951216bf8368865d23ef6246880ea)
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
I'm going to remark this as closed - this breakage is bug 50652 which I believe we've just fixed.
(In reply to comment #2)
> Hope I'm not stepping on any toes by reopening, but this still seems to be an
> issue. 
> 
> See http://i.imgur.com/h8SOdGB.png and more drastically
> http://i.imgur.com/maUlOMv.png (the latter is when resizing the window to be
> moderately smaller).
Renamed bug to be applicable to these screenshots.
**KilliondudeWP** wrote:

Hope I'm not stepping on any toes by reopening, but this still seems to be an issue. 

See http://i.imgur.com/h8SOdGB.png and more drastically http://i.imgur.com/maUlOMv.png (the latter is when resizing the window to be moderately smaller).
Confirmed the fix in betalabs and test2.
(In reply to comment #5)
> Maybe, maybe not. Either way, that's a separate request.
> [...]
> If you want, file a separate ticket to turn it into a single-line text input.

bug 52133
[adding the #tracking project to tasks blocking (now deprecated) T4007 as part of T93366]
Now merged into master.
Fixed in gerrit 46863.
Assigning to current milestone, as it's been sitting around for five months untouched at this point.
The(In reply to comment #4)
> It doesn't work in RTL.

Bug 48912 is this bug for RTL; this has been closed for a year as done.
It doesn't work in RTL.
This is now how CE works; not sure when we altered behaviour to 'fix' it.
Now merged; will be deployed as part of the 2013-01-16 release cycle.
This is now not compatible with how the UX has developed; closing.
[Parsoid component reorg by merging CPP/* tickets into General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
Since incorrect date entry causes unnecessary work for other users, or new users to receive bot or user corrections, generally providing a negative experience, especially for new users. Additionally until fixed, this leads to inconsistencies in data. 

Correcting these automatically, either at input time or post edit see — http://momentjs.com/
>>! In T1186#1006024, @Krenair wrote:
> Which community's norms? Is this a Citoid thing? A VisualEditor thing?

(Or Cite?)

This still needs an answer.
>>! In T1186#1006024, @Krenair wrote:
> Which community's norms? Is this a Citoid thing? A VisualEditor thing?
Other aspects of VE are site/language specific. I don't see why this would be significantly different.
Which community's norms? Is this a Citoid thing? A VisualEditor thing?
Which Polish community norms? Is this a Citoid thing? A VisualEditor thing?
I didn't say it was easy, but I'm pretty sure its possible…
If I get this bug right, it's anything but easy...

Also adding something like momentjs and having it run over the wikitext entered by users (how?) and then correcting invalid dates could be controversial as we never did something like that before.
It's just a catch-all component, and isn't needed.
>>! In T856#14542, @Qgil wrote:
> Well, if there is a better decision we have still time to change it. What agreement are you referring to? That task got just too long with too many topics mixed.

I was going by T43#641 and related comments, and didn't see T43#653 and later comments. Happy to stand by T43#653 and then change it afterwards.
Well, if there is a better decision we have still time to change it. What agreement are you referring to? That task got just too long with too many topics mixed.
>>! In T856#14469, @Qgil wrote:
> The script applies common rules for everybody, as it was defined in {T43}.
> 
> I agree that "VisualEditor" is better. However, project owners can just apply changes like this after the migration. You will be able to fine tune the names of your projects, following the [[ https://www.mediawiki.org/wiki/Phabricator/Requesting_a_new_project#Name | naming guidelines ]], or proposing improvements to the guidelines.

Oh. After I thought that we had all agreed on what would be done in that task, the decision got reversed. :-( No wonder I was confused.
The script applies common rules for everybody, as it was defined in {T43}.

I agree that "VisualEditor" is better. However, project owners can just apply changes like this after the migration. You will be able to fine tune the names of your projects, following the [[ https://www.mediawiki.org/wiki/Phabricator/Requesting_a_new_project#Name | naming guidelines ]], or proposing improvements to the guidelines.
As a logged in user with beta access to VisualEditor using MobileFrontend, edit a new page on beta labs, e.g. http://en.m.wikipedia.beta.wmflabs.org/wiki/Apsidufapodifuasdf or some such. 

Click the pencil icon to edit the page.  I think this should bring up VE, but brings up wikitext editor instead. 

From the gear menu, click Edit to invoke VE

Again from the gear menu, click Edit source. 

VE fails to disappear. Wikitext editor does not appear. No VE controls like Bold/Italic/Link etc. function at this point. 

This is the failure at https://integration.wikimedia.org/ci/view/BrowserTests/view/-All/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox-sauce/455/testReport/(root)/VisualEditor%20Mobile/Switch_from_VisualEditor_to_source_editor/
Verified in en.wiki
Thanks. VE on mobile is apparently still broken, tracked as T85897.
Change 182943 merged by Aude:
Fix naming issue to restore ability to switch between editors

[[https://gerrit.wikimedia.org/r/182943]]
Change 182943 had a related patch set uploaded (by Kaldari):
Fix naming issue to restore ability to switch between editors

[[https://gerrit.wikimedia.org/r/182943]]

#patch-for-review
This probably needs some swift backporting to wmf13?
Verified in betalabs.  test2 still have problems with switching between Edit and Edit source.
Change 182113 merged by jenkins-bot:
Fix naming issue to restore ability to switch between editors

[[https://gerrit.wikimedia.org/r/182113]]
Change 182113 had a related patch set uploaded (by Jdlrobson):
Fix naming issue to restore ability to switch between editors

[[https://gerrit.wikimedia.org/r/182113]]

#patch-for-review
The following error is displayed: 
Uncaught TypeError: boolean is not a functionload.php?debug=false&lang=en&modules=mobile.abusefilter|mobile.editor.common%2Coverlay&skin=minerva…:8 Overlay.extend.hideload.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cmwcore|mobile.editor.ve|oojs-ui&skin=m…:624 EditorOverlayBase.extend.hideVM367:16 Class.extend._hideOverlayVM367:17 Class.extend.replaceCurrentload.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cmwcore|mobile.editor.ve|oojs-ui&skin=m…:625 (anonymous function)load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=minerva&version=20141220T…:45 fireload.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=minerva&version=20141220T…:46 self.fireWithload.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=minerva&version=20141220T…:47 deferred.(anonymous function)load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=minerva&version=20141220T…:168 mw.loader.usingload.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cmwcore|mobile.editor.ve|oojs-ui&skin=m…:625 EditorOverlayBase.extend.switchToSourceEditorload.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cmwcore|mobile.editor.ve|oojs-ui&skin=m…:624 (anonymous function)load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=minerva&version=20141220T…:65 jQuery.event.dispatchload.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=minerva&version=20141220T…:60 elemData.handle
ve.ui.Toolbar.js:224 Uncaught TypeError: Cannot read property 'triggerListener' of undefined

Example: https://m.mediawiki.org/wiki/MediaWiki_1.25/Roadmap?debug=true#/editor/0
VisualEditor is not loading in el.wikipedia since yesterday.
Checked VE for el.wikipedia in production.
Resolved by  [[https://el.wikipedia.org/w/index.php?title=MediaWiki:Common.js&diff=4979660&oldid=4917315|removing some code from Mediawiki:Common.js]] (although it was there for ages without problems).
As a logged-in user with access to VisualEditor visit any page e.g http://en.m.wikipedia.beta.wmflabs.org/w/index.php?title=Selenium_Test_Edit

Click Edit to bring up VE

From the gear menu select Edit source

No wikitext editor appears, but there is an edit icon on the page.

Click the edit icon. It does nothing.
Broken since 11 December. 

As a logged in user with access to VE, attempt to edit any page.  See a spinner. 

Javascript error shown in Chromium is "TypeError: Illegal invocation TypeError: Illegal invocation "
verified the fix in en.wiki
VE works in Mobile betalabs/test2.
Change 182993 merged by Catrope:
Update setupToolbar signature in mobile target

[[https://gerrit.wikimedia.org/r/182993]]
Change 182993 had a related patch set uploaded (by Alex Monk):
Update setupToolbar signature in mobile target

[[https://gerrit.wikimedia.org/r/182993]]

#patch-for-review
Change 181005 merged by MaxSem:
Update VE and MF for T78710

[[https://gerrit.wikimedia.org/r/181005]]
Change 181005 had a related patch set uploaded (by Jforrester):
Update VE and MF for T78710

[[https://gerrit.wikimedia.org/r/181005]]

#patch-for-review
Change 180700 merged by jenkins-bot:
Fix Ia6bf604c: Update another caller to ve.init.mw.Target

[[https://gerrit.wikimedia.org/r/180700]]
Change 180701 merged by jenkins-bot:
Followup Ia6bf604c, I431a9025: Update way VE target is constructed

[[https://gerrit.wikimedia.org/r/180701]]
Parsoid was stalled to a version from October 28th :-(  Thanks to Krenair, Roan and Kartik we get it back to the latest version :-]
(All the many different problems with Parsoid now seem to be fixed, thanks to @hashar)
(Or at least, as well as the desktop version, which just returns a Parsoid error.)
it should now work.
Change 180759 merged by jenkins-bot:
Update setupToolbar signature in mobile target

[[https://gerrit.wikimedia.org/r/180759]]
(https://gerrit.wikimedia.org/r/180690 happened while Gerrit was down.)
Change 180759 had a related patch set uploaded (by Alex Monk):
Update setupToolbar signature in mobile target

[[https://gerrit.wikimedia.org/r/180759]]

#patch-for-review
Beta labs, sorry.
Production or beta labs?
Have triage sessions. Regarding topic, stakeholders and key developers, this will focus on VisualEditor and be on a weekly basis, and volunteers are very welcome:

See Task 86867 for "VisualEditor Q3 Release Criteria".
See https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=645421507#VisualEditor_News_2015.E2.80.94.231 for announcement.

See https://www.mediawiki.org/wiki/Bug_management/Meeting_preparations for more information

First bugday with Phabricator instead of Bugzilla.

Potentially related Team-Practices tasks:
* https://phabricator.wikimedia.org/T88325 - "Whole team chat with Damon RE burndown chart expectations"
* https://phabricator.wikimedia.org/T88328 - "Feasibility study for using Phab for burndown charts"
* https://phabricator.wikimedia.org/T88365 - "Burndown chart training and support - VE release support with Editing Team"
>>! In T78684#1049659, @Qgil wrote:
> Should we consider setting the beginning of the sprint on Feb 1?

According to James' answer in T89715: No. :)
https://phabricator.wikimedia.org/project/sprint/view/1015/ With this fix and the Sprint upgrade, this page looks great now!

@Jdforrester-WMF, why there is not visible progress during the whole month of January? Should we consider setting the beginning of the sprint on Feb 1?

I'm being picky with this page because (as @damons explained at the MW Dev Summit) a burndown chart is a key communication tool, and I think we can push this page in all our VE sprint communications (also to editors etc). I guess people will wonder "what happened in January?", and this is why I'm asking.
>>! In T78684#1046995, @Christopher wrote:
> Also, I suspect that if for the  § VisualEditor Q3 Blockers project, if the "Complete" column is renamed to "Done" then all previous moves to this column will show on the burndown chart.

[[ https://phabricator.wikimedia.org/project/sprint/view/1015/ | Done ]], thanks.
Also, I suspect that if for the  § VisualEditor Q3 Blockers project, if the "Complete" column is renamed to "Done" then all previous moves to this column will show on the burndown chart.
This is expected since the switch from Maniphest Status to Column Position.  To show progress in a Sprint, the normal workflow is to move the task to the "Done" column on the board.  This then deducts the points from "Points Remaining".  

As mentioned in T88328, there are currently 4 static column "type" constants, "Backlog", "Doing", "Review" and "Done" that are recommended for the Sprint extension.   Teams are encouraged, but not required, to use these column names.  Future implementation may allow the possibility of user-defined names that map to these types, and perhaps additional column types.
Just a side question: is it normal that the "remaining points" line is not burning down at https://phabricator.wikimedia.org/project/sprint/view/1015/ ?

CCing @christopher just in case.
I'm not sure whether {T88198} is a pure blocker of this task, but there is a relationship.
Ok, I'm now convinced that we don't need to use an additional task for this process. Just keep in mind that not everybody will be able to follow at the same path, and some users might want to voice their opinions constructively in channels other than the phone call meeting. Let's be understanding and let's bring their relevant opinions to the triage meetings, as opposed to i.e. limiting ourselves to remind people about the official process.

I'm pretty sure you were already planning to do this, but since we are running this type of process for the first time, I prefer to write this down somewhere.  :)
I don't know. 
In theory folks that unfortunately skipped communicating with product/project maintainers could already add the "real" Q3 project anyway without making sure that their addition is helpful from a "let's get the stuff out" maintainer prospective. 

Folks could try to convince maintainers on IRC why some task is important enough before adding the task. 
Or in the task itself. I'm not sure if that tag in addition to the comment itself would really help us (well, it might if noone reads all the incoming comments on all the VE tasks, to be honest). It might be yet another list that's as diverse as the list of all open tasks when it comes to importance; it might also be a way to get helpful feedback from folks that have good judgement what's important now - really hard for me to judge VE's community.
@Jdforrester-WMF, when chatting with @aklapper about the VE weekly calls, I suggested the possibility of offering a temporary #VE-Q3-candidate tag of sorts to users willing to propose a specific task for the mega-sprint. The reason being that defending a proposal in English and in front of an unseen/unknown crowd during a synchronous phone call might deter some users. Even if a user plans to do so, being able to mark a task as candidate, explaining in the comments why, sounds like a good way to have a more productive meeting.

What do you think?
Next triage should be targetting VisualEditor I guess.

Notes to myself: https://phabricator.wikimedia.org/tag/%C2%A7_visualeditor_q3/ seems to be the current quarter (Using 'Q3' and no year and no description was not totally obvious though). [[ https://phabricator.wikimedia.org/sprint/board/1015/ | Workboard ]]; [[ https://phabricator.wikimedia.org/sprint/view/1015/ | Burndown chart ]] (not too readable).

Generally speaking, there are currently 1152 open tickets in the umbrella VE project (which is automatically added for any subproject tasks). Also see the [[ https://phabricator.wikimedia.org/maniphest/report/project/ | Distribution of priorities of open tickets ]] (search for "VisualEditor").
When I load VE on [[en:Gosford]], the following API requests are made:

- 3x action=query&prop=imageinfo
- 1x action=query&prop=info
- 1x action=visualeditor&paction=parse (also see {T87553})

For a total of five API requests. Couldn't the VisualEditor API module expose an endpoint that combines this metadata into a single response?
Change 193026 had a related patch set uploaded (by Jforrester):
[WIP] Factor out loading code into TargetLoader

[[https://gerrit.wikimedia.org/r/193026]]
Also it's worth mentioning that only the action=visualeditor request blocks loading VE (which is reasonable because it delivers the Parsoid HTML). The prop=info and imageinfo requests do not block loading.
This is a duplicate of several tickets, and should probably become a tracking ticket. I'll find them and make them all subtasks of this one.
Indeed, the click event was getting unbound, because local site JS was rewriting some `.innerHTML` properties (which has the side-effect of killing everything that's not in initial HTML, like event handlers and inputted form field values). I removed one line: https://zh.wiktionary.org/w/index.php?title=MediaWiki:Common.js&diff=prev&oldid=4074338 and it seems to be working. If any other sites have the same problem, doing this will probably help them too.
I believe its 100% js but I dunno - I just know I'm like a bull in a china shop with browser debugging.
Hmm, wondering who could investigate the JS part then... any idea?
Unassigning to myself as I can't figure it out and Javascript isn't my forte.  It looks like the click event is getting unbound from the button after its creation.  This returns undefined:
$._data($('#mw-search-toggleall')[0], 'events')
on the wikis that don't work.
The all/none buttons still work on zhwikipedia but do not on zhwikibooks or zhwiktionary.....
Also - its clicking the buttons that is broken.  Clicking on the check boxes still seems to work.
Reopened - it is indeed broken on zhwiktionary but not enwiktionary.  No idea why yet.
>>! In T78553#981797, @Aklapper wrote:
> @Liuxinyu970226: Can you provide a link / steps to reproduce please?

Try "全选 (all)" & "全不选 (none)" at:
* https://zh.wiktionary.org/w/index.php?title=Special:搜索&search=asdfg&fulltext=搜索&profile=advanced
* https://zh.wikibooks.org/w/index.php?title=Special:搜索&search=asdfg&fulltext=搜索&profile=advanced
@Liuxinyu970226: Can you provide a link / steps to reproduce please?
Can't work again on zhwiktionary and zhwikibooks, who can help them.
Can't work again on zhwiktionary and zhwikibooks
>>! In T78553#931954, @Liuxinyu970226 wrote:
> @Nikerabbit: Keeps on translatewiki, u know.

OK now tsw fixed too.
@Nikerabbit: Keeps on translatewiki, u know.
Verified on mw.org
Change 180319 merged by jenkins-bot:
Move advanced search inputs back into the form

[[https://gerrit.wikimedia.org/r/180319]]
>>! In T78553#852344, @Krinkle wrote:
> This isn't just causing a user scripts or extensions to throw an exception due to elements not existing in javascript land. The core feature itself is also plain broken.
> 
> 1. https://meta.wikimedia.org/w/index.php?title=Special%3ASearch&profile=advanced&search=formsGadgetConfig&fulltext=Search
> 2. Tick/untick any namespace checkboxes.
> 3. Press "Search"
> 
> Expected: Search results now include different results and namespace selection is there as the user submitted it
> 
> Actual: The checkboxes not being part of the `<form>` means they're not submitted and completely ignored by the server. The advanced search is completely non-functional.

Thanks for making that clear.  I didn't do a good job of documenting how broken it was.  I took a stab at it in https://phabricator.wikimedia.org/T78553#849773 but wasn't super clear.  The change to fix it is scheduled to by SWATed tonight.
This isn't just causing a user scripts or extensions to throw an exception due to elements not existing in javascript land. The core feature itself is also plain broken.

1. https://meta.wikimedia.org/w/index.php?title=Special%3ASearch&profile=advanced&search=formsGadgetConfig&fulltext=Search
2. Tick/untick any namespace checkboxes.
3. Press "Search"

Expected: Search results now include different results and namespace selection is there as the user submitted it

Actual: The checkboxes not being part of the `<form>` means they're not submitted and completely ignored by the server. The advanced search is completely non-functional.
This isn't just causing a user script exception due to elements not existing. The core feature is also plain broken.

1. https://meta.wikimedia.org/w/index.php?title=Special%3ASearch&profile=advanced&search=formsGadgetConfig&fulltext=Search
2. Tick/untick any namespace checkboxes.
3. Press "Search"

Expected: Search results now include different results and namespace selection is there as the user submitted it

Actual: The checkboxes not being part of the `<form>` means they're not submitted and completely ignored by the server. The advanced search is completely non-functional.
Evening swat deployment scheduled: https://wikitech.wikimedia.org/w/index.php?title=Deployments&oldid=138343
Change 180319 had a related patch set uploaded (by Robmoen):
Move advanced search inputs back into the form

[[https://gerrit.wikimedia.org/r/180319]]

#patch-for-review
Change 180237 merged by jenkins-bot:
Move advanced search inputs back into the form

[[https://gerrit.wikimedia.org/r/180237]]
Change 180237 had a related patch set uploaded (by Robmoen):
Move advanced search inputs back into the form

[[https://gerrit.wikimedia.org/r/180237]]

#patch-for-review
Awesome!  Can you link it here?  We can certainly SWAT it tomorrow morning or this afternoon if we can get it reviewed ASAP.
>>! In T78553#851447, @Manybubbles wrote:
> Do they have to be logged in?  Not that it really matters.  Is it something you can fix in an hour or two?  If so we should just fix it I think

Agreed.  I have identified a fix.
Do they have to be logged in?  Not that it really matters.  Is it something you can fix in an hour or two?  If so we should just fix it I think
>>! In T78553#850699, @Manybubbles wrote:
> Reassigning to rmoen as its very likely related to Ic6ec29817ab7deadc6bc7125f8b4cd16686baa04.  I don't want to just revert his work because it looks like it has some value.  If he isn't able to pick this up in a few hours I will just revert it so we can have advanced search back.

The breaking change should be reverted as turns out it breaks the entire advanced search form for logged in users.  However, I have an easy fix for all of this.
>>! In T78553#850699, @Manybubbles wrote:
> Reassigning to rmoen as its very likely related to Ic6ec29817ab7deadc6bc7125f8b4cd16686baa04.  I don't want to just revert his work because it looks like it has some value.  If he isn't able to pick this up in a few hours I will just revert it so we can have advanced search back.

The breaking change should be reverted as turns out it breaks the entire advanced search form for logged in users.
Reassigning to rmoen as its very likely related to Ic6ec29817ab7deadc6bc7125f8b4cd16686baa04.  I don't want to just revert his work because it looks like it has some value.  If he isn't able to pick this up in a few hours I will just revert it so we can have advanced search back.
I'm going to grab this.  I'm not particularly well qualified for it so if a Javascript expert wants it feel free to trump me.  I just think it needs looking at sooner rather than later.
NOTE: In case it matters; excerpt from the recently merged duplicate T78636

**Confirmed** ... reproduced behavior on both __www.MediaWiki.org__ and __test2.wikipedia.org__ `[1.25wmf12 (1d22bb3)]` at the moment.

I could not reproduce this behavior (selecting //none// or //all// executes as expected) on __en.wikipedia.org__ or __en.wikisource.org__ `[1.25wmf11 (038c7a8)]` however.
> The check all/none buttons do nothing. If I check or uncheck any of the namespace check boxes and then hit search to refine my search, the checkboxes revert to default and my results do not change.

I see that too.
I simply cannot get see any stacktrace rendered in my browser - I get 1076 results for your link and nothing that makes it look like something really important is broken here. Could you elaborate?

I can confirm that there's error output in the browser console, triggered by this line:
  this.form.method = this.checked ? 'post' : 'get';
from https://git.wikimedia.org/history/mediawiki%2Fcore.git/HEAD/resources%2Fsrc%2Fmediawiki.special%2Fmediawiki.special.search.js which hasn't seen recent changes.
> Clicking on "Advanced" search and changing the default namespaces to search and clicking search returns:

Please provide //exact// steps to reproduce. I cannot reproduce the problem using https://www.mediawiki.org/w/index.php?title=Special:Search&search=&fulltext=Search&profile=advanced but the steps are simply too vague. Using &debug=true is also very welcome.
Recently, there has been a rapid increase in errors like:

```
Sorry! This site is experiencing technical difficulties.

Try waiting a few minutes and reloading.

(Cannot contact the database server: Too many connections (208.80.154.18))
```

This happens not only when I open dozens of wikitech pages, but also when I reload single pages afterwards.
This has stopped happening now that wikitech is on silver, safely away from puppet's vandalism.
… and they come from the Puppet extension, so that's fine.  I think the problem lies in the interface MediaWiki/MySQL.  7 hits/11 s shouldn't bring a wiki down; perhaps some connection pool not set up or something like that?

(@yuvipanda: BTW, totally forgot: Congrats! :-))
All the Hiera hits are from the puppetmaster
Most likely the issue here is that the main cluster robots.txt is more tolerant of crawlers than wikitech can afford to be.  I'll investigate how to make a site-local robots.txt (or bug bryan to do so).
Looks like we're getting crawled.

208.80.154.18 - - [15/Dec/2014:01:40:57 +0000] "GET /w/api.php?action=query&prop=revisions&format=json&rvprop=ids&titles=Hiera:Video HTTP/1.1" 200 5064 "-" "HieraMwCache/0.1 (/, ruby 1.8.7 (2011-06-30) [x86_64-linux])"
208.80.154.18 - - [15/Dec/2014:01:40:57 +0000] "GET /w/api.php?action=query&prop=revisions&format=json&rvprop=content&titles=Hiera:Video HTTP/1.1" 200 666 "-" "HieraMwCache/0.1 (/, ruby 1.8.7 (2011-06-30) [x86_64-linux])"
208.80.154.18 - - [15/Dec/2014:01:41:00 +0000] "GET /w/api.php?action=query&prop=revisions&format=json&rvprop=ids&titles=Hiera:Oxygenguide HTTP/1.1" 200 5064 "-" "HieraMwCache/0.1 (/, ruby 1.8.7 (2011-06-30) [x86_64-linux])"
208.80.154.18 - - [15/Dec/2014:01:41:00 +0000] "GET /w/api.php?action=query&prop=revisions&format=json&rvprop=content&titles=Hiera:Oxygenguide HTTP/1.1" 200 666 "-" "HieraMwCache/0.1 (/, ruby 1.8.7 (2011-06-30) [x86_64-linux])"
68.180.228.125 - - [15/Dec/2014:01:41:01 +0000] "GET /wiki/Special:PrefixIndex/User:OccultZone/ HTTP/1.1" 500 5485 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"
208.80.154.14 - - [15/Dec/2014:01:41:10 +0000] "GET / HTTP/1.1" 302 457 "-" "check_http/v1.4.15 (nagios-plugins 1.4.15)"
208.80.154.18 - - [15/Dec/2014:01:41:10 +0000] "GET /w/api.php?action=query&prop=revisions&format=json&rvprop=ids&titles=Hiera:Visualeditor HTTP/1.1" 200 5064 "-" "HieraMwCache/0.1 (/, ruby 1.8.7 (2011-06-30) [x86_64-linux])"
2
Turns out Flow is a great tool for newbies compared to free-form wikitext. Well, at least until the point where they need to create a link or they want to add some basic formatting. Especially if the newbies are defaulting to VisualEditor, they might have difficulties posting anything other than plaintext and full URLs.

{F21334 size=full}

Trimming the selection was discussed, and discovered to be both subjectively-desirable and technically-complicated. Newcomers will eventually have an alternative VE interface, to satisfy the requests for a less complicated set of buttons. So, please implement the full/default WikiEditor toolbar.

Further notes at {T90052}

See also: {T93243}
I'm retitling this task, due to the recent work on the VE toolbar in {T93243}
Some thoughts raised during Collaboration team's offsite concerning VE toolbar for Flow have been added to {T93243}.
[[https://fr.wikipedia.org/wiki/Sujet:T32v2yjule0ssfq7 | New feedback concerning the lack of toolbars]]. I hope we will be able to address that problem soon.
>>! In T78346#1747890, @Pginer-WMF wrote:
>> Create a minima a way to personalize VE and wikitext toolbars with a gadget would be a good idea.
> 
> Adding media is a reasonable usecase for conversations. We consider providing support for it from the beginning but the decision was postponed until VE would be able to support an uploading process (and not just reusing existing images from commons).

That will be done very soon, next week iirc. ({T40030})
 
> As the image upload workflow gets supported inside VE,  Flow would adopt those powers too (at least for the rich text view where VE is used). If I recall correctly, exposing the "insert media" icon is just a simple configuration change.

There is two different requests from communities : 
- add images on a conversation
- add smileys/kittens/whatever on a conversation ([[https://www.mediawiki.org/w/index.php?title=Topic:Smsn1ofyp04kqxle&topic_showPostId=snovfwyo3tasvyou#flow-post-snovfwyo3tasvyou | usual tools  ]] on a chat)

And there is still the following needs:
- add a toolbar to wikitext
- personalize the toolbars (I would love to have my personal pre-written messages when I answer on the fr help desk)
>>! In T78346#1747890, @Pginer-WMF wrote:
>> Create a minima a way to personalize VE and wikitext toolbars with a gadget would be a good idea.
> 
> Adding media is a reasonable usecase for conversations. We consider providing support for it from the beginning but the decision was postponed until VE would be able to support an uploading process (and not just reusing existing images from commons).

That will be done very soon, next week iirc. ({T40030})
 
> As the image upload workflow gets supported inside VE,  Flow would adopt those powers too (at least for the rich text view where VE is used). If I recall correctly, exposing the "insert media" icon is just a simple configuration change.

There is two different requests from communities : 
- add images on a conversation
- add smileys/kittens/whatever on a conversation ([[ https://www.mediawiki.org/w/index.php?title=Topic:Smsn1ofyp04kqxle&topic_showPostId=snovfwyo3tasvyou#flow-post-snovfwyo3tasvyou | usual tools  ]]on a chat)

And there is still the following needs:
- add a toolbar to wikitext
- personalize the toolbars (I would love to have my personal pre-written messages when I answer on the fr help desk)
> Create a minima a way to personalize VE and wikitext toolbars with a gadget would be a good idea.

Adding media is a reasonable usecase for conversations. We consider providing support for it from the beginning but the decision was postponed until VE would be able to support an uploading process (and not just reusing existing images from commons).

As the image upload workflow gets supported inside VE,  Flow would adopt those powers too (at least for the rich text view where VE is used). If I recall correctly, exposing the "insert media" icon is just a simple configuration change.
A user [[ https://fr.wikipedia.org/w/index.php?title=Sujet:Sqsccaf41ercbdaq&topic_showPostId=sqtsyrdrdzk309os#flow-post-sqtsyrdrdzk309os | complains ]] about she can't post pictures of kittens on a conversation. We definitely need to do something. For kittens.

Create //a minima// a way to personalize VE and wikitext toolbars with a gadget would be a good idea. I know, there is always risks of abuses (thousand of buttons) but this did not happen with wikitext editing toolbar afak.
On [[ https://fr.wikipedia.org/w/index.php?title=Sujet:Sox3xbkro37l4fta&topic_showPostId=sox3xblgm25yjf9q#flow-post-sox3xblgm25yjf9q | this feedback ]], a user asks to have personalized buttons on the toolbar (#3), and a way to add templates (#8).
See also https://www.mediawiki.org/wiki/Topic:Smsn1ofyp04kqxle.
Shouldn't this be resolved?
In ru.wiki we definitely ourselves will add some buttons for wikitext. (https://ru.wikipedia.org/wiki/Википедия:Викификатор , https://ru.wikipedia.org/wiki/Википедия:Гаджеты/Упрощение_ссылок ) Something for these buttons "it was necessary already yesterday".
>>! In T78346#1115277, @DannyH wrote:
> I added new screenshots from the prototype to T90764.
> 
> I have a question about the Mentions modal: If there are a lot of users who have posted on the thread, does it get a scroll bar? 

Yes.  Try typing Assoc into the link inspector to get an idea.  Ours probably won't be a truncated list, though.

I've created {T92588} to track this specifically.
I added new screenshots from the prototype to T90764.

I have a question about the Mentions modal: If there are a lot of users who have posted on the thread, does it get a scroll bar?
> - Inspector (the one you see when you click the link icon)
We can start using this. I can create a mockup to illustrate the dialog in that format.
>>! In T78346#1099845, @Pginer-WMF wrote:
> For the mention dialog (check mockups below), I would recommend the following:
> - Show the dialog in-line with the text. When the user clicks on the mention icon, the dialog is shown where the text cursor is. This makes the user feel that she is manipulating the content directly since the information is in a single place.

We decided it will use an inspector, at least initially.

> - Initially, provide as the auto-suggestion values the users that participate in the current conversation or sub-conversation, or the frequently mentioned by the user (or any other criteria that can anticipate the user action and it is easy to implement).

Auto-complete will use all authors in the current topic.
VE basically has two types of dialogs:

* Inspector (the one you see when you click the link icon)
* Dialog (e.g. Insert->Template)

For now, I think we should stick to one of these two, for both maintainability and visual consistency.  The closer one (but not that close) is inspector.
I also put together some of the mockups we mentioned for the first version [[ http://pauginer.github.io/prototypes/flow/editor/index.html | in this prototype ]]. Only basic transition between modes are supported, don't expect to actually turn text into bold.
For the mention dialog (check mockups below), I would recommend the following:
- Show the dialog in-line with the text. When the user clicks on the mention icon, the dialog is shown where the text cursor is. This makes the user feel that she is manipulating the content directly since the information is in a single place.
- Initially, provide as the auto-suggestion values the users that participate in the current conversation or sub-conversation, or the frequently mentioned by the user (or any other criteria that can anticipate the user action and it is easy to implement).
- As the user types, auto-suggestions will show users with the given username (if possible, it would be great to be flexible in the search to typos and preferred names if those are available). The first selection will be highlighted (following the standard style for list selection).
- If the user is not found, some text will indicate so.
- An option to close the dialog is provided.
- The dialog can be controlled with the keyboard. The user can type @ and the dialog will open for the user to just type the user name and hit enter to insert the first selection from the list. We may want to not interfere with the use of "@" as a valid character. For that we may want to (a) make sure that the "@" happens in a valid context (after a space, text beginning, or non-word character) to avoid it appearing when users type an email for example; and (b) close the panel if the user types a space after having pressed "@", which would just result in adding the "@" character. the "esc"key will close the dialog.
- Most of the time the mention action will be triggered without a selected text,but if there is a text selection, we may want to use that text for the user search when the panel is opened. In this scenario, if the operation is cancelled, the user text should not be destroyed.



{F65305}

{F65534}

{F65307}
Pau, I think the only mockup that we still need is the mentions modal... Am I forgetting anything?
We talked about this in the design meeting this morning, and decided on a plan for v1. 

We need to get a simple v1 of the VE toolbar out soon, in order to roll out on a couple of languages that are excited about trying out Flow. 

So v1 will have:

* Bold/Italics (with a menu offering the two choices)
* Link (with the same VE modal)
* Mention (with a new modal)
* Toggle to wikitext / VE

There are several pieces that we definitely want to include, but not in the v1: Lists, something that helps with Code/Pre/Nowiki/Blockquote (tbd), and Insert media. (Insert media would be especially helpful if it includes an upload picture function, so that people could upload screenshots when they're asking for help.)
The idea is for the different controls to behave like they do on the VE toolbar (preferably using the same components, just adjusting how prominent they are shown according to our context). For the case of the text format action, a drop-down like the one used by VE will be shown:

{F53362}


Regarding which controls to use, some thoughts:
- Regarding the "code" and "nowiki", I wonder if we can have a unified "quote" action to cover most of the usecases (refer to portions of wikicode, source code, or specific parts of a comment someone previously said).
- We may consider lists and inserting media to be under the "more" section. For example, in the current conversation in Phabricator they are used frequently and, although it cannot be generalised, I wonder if they may be used more in the wiki context if they were easily accessible.
- I think it is ok to start with fewer controls and iterate on adding new ones.

With the controls mentioned above, the expanded "more" menu can either expand in-place the advanced controls or be a regular dropdown menu (the later may be easier to support initially, but if menu items grow, or we want to better support repetitive use the former is preferred):

{F53387}

{F53373}
if anyone is going to write 'yet another toolbar', can someone please make sure to really think stuff through ? I'm counting:

1: Old toolbar (that community doesn't want to get rid off, yet we do)
2: WikiEditor toolbar (that we prefer over old, but is also a bit over designed and old style JS)
3: VE toolbar (OOjs UI, but not yet finished)
4: Mobile Editing versions of VE toolbar.
5: and now Flow

Will the Math extension soon require 4 modules to provide a math insertion button to all editors types ?
We have things like textSelection, confirmCloseWindow, live preview and stash. All that stuff comes into play, and any new wikitext editor work we do should recognize that and along the way should try to improve and consolidate.

Similarly:
```
Enhancing WikiEditor for normal pages is completely outside the scope of this bug.
```
But please do account for the many ways in which it is FAILING users.
if anyone is going to write 'yet another toolbar', can someone please make sure to really think stuff true ? I'm counting:

1: Old toolbar (that community doesn't want to get rid off, yet we do)
2: WikiEditor toolbar (that we prefer over old, but is also a bit over designed and old style JS)
3: VE toolbar (OOjs UI, but not yet finished)
4: Mobile Editing versions of VE toolbar.
5: and now Flow

Will the Math extension soon require 4 modules to provide a math insertion button to all editors types ?
We have things like textSelection, confirmCloseWindow, live preview and stash. All that stuff comes into play, and any new wikitext editor work we do should recognize that and along the way should try to improve and consolidate.

Similarly:
```
Enhancing WikiEditor for normal pages is completely outside the scope of this bug.
```
But please do account for the many ways in which it is FAILING users.
+1 to the idea of starting with a subset of the current VE toolbar for articles.

+1 to the idea of enabling in the Flow VE buttons the same UX as the full ED version.
Based on these example threads, and our goal to rollout further at mediawikiwiki, and He7d3r's comment above, and my own experience, I still strongly advocate for having `<code>` and `<nowiki>` tags available and planned from the start (in a dropdown menu).

* https://ca.wikipedia.org/wiki/Topic:Sbk26yv6cpcxxm87
* https://ca.wikipedia.org/wiki/Topic:Sbi6jrldf94ea8nt
* https://ca.wikipedia.org/wiki/Topic:Sa23rwtl0w12e4sk
* https://ca.wikipedia.org/wiki/Topic:S8h1yv4n7yfm4fmi
* https://ca.wikipedia.org/wiki/Topic:S8adbxrruu971vyd
* https://fr.wikipedia.org/wiki/Sujet:Sb3nxhhm4wdodaez
* https://fr.wikipedia.org/wiki/Sujet:Sabk082dkr6rat37
* https://fr.wikipedia.org/wiki/Sujet:Sb3m5set5zkob0rj
* https://fr.wikipedia.org/wiki/Sujet:Sbceer9529lnk66g
Being able to //discuss// wikimarkup, is crucial to so many of the places we want to deploy to.
Link should be exactly the same as VE once you click it, both for a consistent user experience and so we don't have to implement a new link widget (with autocomplete, etc.)
I talked to James about toolbar use in VE -- they don't currently have tracking on which buttons get used the most. But he gave me his gut instinct on it, which I think is good enough for a first pass. 

He said that for discussions, the most used tools are: Links, Mentions, and Bold/Italics. 

(For article content, he'd also include Citations, Templates & Media, but these aren't as important for discussions.)

I think we can go with Pau's mockups for a first version of a VE/Flow toolbar. We can even take out the ellipsis/more menu, and just have these controls:

* Bold/Italics
* Link
* Mention
* switch to wikitext

This will be better than not having one, and we can find out what else people need from there. 

Pau, we'll need mockups that show what happens when you click on those buttons. I'm assuming Bold/Italics has a dropdown menu. Would Link and Mention have little modal boxes? 

{F34174}
{F34176}
{F52902}
>>! In T78346#1061982, @Pginer-WMF wrote:
> 
> @GOIII, so for the specific case of discussions in Wikisource, is there any specific kind of content that would be useful to get help from a rich text editor to deal with in converstions?
> 
> I tried to look for some complex scenarios based on current use but [[ https://en.wikisource.org/wiki/Talk:The_Metamorphosis | in the example I found ]] formatting needs seemed basic (user mentions, lists, and links). Do you know of some examples of current (or potential) uses of more advanced formatting?

@Pginer-WMF - Boy, finding something in NS-1 (the talkspace for the main namespace) that would benefit from //Flow// is not likely to exist. Again, Wikisource's mainspace output follows the premise of ''reproducing an original publication as faithfully as possible" so there is little left to question where long or ongoing talk page discussions are likely needed to take place.

Still, we do have continuous "action" in the Village Pump equivalent, [[https://en.wikisource.org/wiki/Wikisource:Scriptorium| Scriptorium]], that might benefit from using //Flow//. Debate traffic also exists for certain Help: and Template: namespace pages every so often, but nowhere near approaching the typical Wikipedia article's talkpage traffic or timeframe.

I'll keep looking for other possible examples in mind but I wouldn't bet on anything more substantial coming to light beyond those already mentioned.
> Flow is pretty and (I guess) helpful for ongoing or complex discussions; we just don't have as many instances of this as Wikipedia seems to have. Sure, making it standard provides easier maintenance across all wikis but it won't add much "value" to our project if any at all.

 @GOIII, so for the specific case of discussions in Wikisource, is there any specific kind of content that would be useful to get help from a rich text editor to deal with in converstions?

I tried to look for some complex scenarios based on current use but [[ https://en.wikisource.org/wiki/Talk:The_Metamorphosis | in the example I found ]] formatting needs seemed basic (user mentions, lists, and links). Do you know of some examples of current (or potential) uses of more advanced formatting?
>>! In T78346#1038829, @GOIII wrote:
> So until we either actively poll for as much or implement & advertise those "enhancements" to accurately gauge User: preference, etc., we're just making decisions based in conjecture & assumptions more so than in reality and facts.

The Design Research team did some investigation into editing tools. I believe they're still compiling the results, but here are the links for watchlisting: https://www.mediawiki.org/wiki/Design/Research#Editing
>>! In T78346#1038747, @Mattflaschen wrote:
> Note: Enhancing WikiEditor for normal pages is completely outside the scope of this bug.

Then don't select the next course of action based solely on that mwgrep's results.

Folks aren't using WikiEditor in some meaningful number just because of the lack in the ease of customization compared to the //Classic// toolbar followed by some other meaningful number for the inability to prevent the generation of WikiEditor's current defaults.

So until we either actively poll for as much or implement & advertise those "enhancements" to accurately gauge User: preference, etc., we're just making decisions based in conjecture & assumptions more so than in reality and facts.
>>! In T78346#1026966, @Quiddity wrote:
> Separately, I know there is some amount of local customization of the WikiEditor Toolbar buttons (both individually, and at the wiki-level), but I'm not sure how widespread the individual customizations are, nor how to find out, beyond searching for "addToToolbar" at each wiki in user-space and mediawiki-space. Any suggestions?

mwgrep can answer this question for WMF production.  It allows searching for CSS and JS in the User, MediaWiki, or Module namespaces (one at a time).

>>! In T78346#1033515, @GOIII wrote:
> Make the current //WikiEditor// defaults an option or User pref with a far more simply way to customize it for individuals and I guarantee you the "opting-in" of the //Classic// toolbar would drop off drastically.

Note: Enhancing WikiEditor for normal pages is completely outside the scope of this bug.
On talk pages, I believe these are the custom buttons I use the most:
> <code>test</code>
> <nowiki>test</nowiki>
> <syntaxhighlight lang="javascript" enclose="none">test</syntaxhighlight>
> <span style="color: #000; background: #E99;"></span>
> <pre>test</pre>
(mainly because I usually help with technical problems in the wikis I use) and for content pages,
> <math>test</math>
which was removed in 2009 by the usability initiative
https://usability.wikimedia.org/wiki/Talk:Releases/Acai#Math
>>! In T78346#1017880, @He7d3r wrote:
> I miss my custom buttons in the edit toolbar.
> See also:
> * {T23692}

I installed 3 of your scripts to test: https://meta.wikimedia.org/w/index.php?title=User:Quiddity_%28WMF%29/global.js&diff=11213986&oldid=10917385
And took these screenshots: http://imgur.com/a/na16D#0

Are there any use-cases here that might be widely applicable to an entire wiki, or even to all wikis as a default Flow feature? Or perhaps a global-template (if/when those arrive) ?

Separately, I know there is some amount of local customization of the WikiEditor Toolbar buttons (both individually, and at the wiki-level), but I'm not sure how widespread the individual customizations are, nor how to find out, beyond searching for "addToToolbar" at each wiki in user-space and mediawiki-space. Any suggestions?
I miss my custom buttons in the edit toolbar.
See also:
* {T23692}
We're going to work on this as part of turning on VE for Flow. 

The current spike card is T88182 : Define and estimate work for Minimum Viable Product of VisualEditor in Flow (spike)
We're going to work on this as part of turning on VE for Flow. 

The current spike card is T88182
Since people are already talking about VE, I expanded the scope of the task somewhat ("WikiEditor" is the wikitext toolbar shown in production).  This is in the idea/design stage, so it's okay to cover both technologies in the same task for now.
Since people are already talking about VE, I expanded the scope of the task somewhat ("WikiEditor" is the wikitext toolbar shown in production).  This is in the idea/design stage, so it's okay to cover both technologies in the same card for now.
>>! In T78346#1010433, @Pginer-WMF wrote:
> Regarding the second comment, I think you are right and we could avoid the whole mode switching if VE supported wikitext input.

Currently, VE mostly just warns you about this ("Wikitext markup detected")

Even if VE supported certain obvious wikitext examples (actually, it does for certain very limited cases like the * list keyboard shortcut), it's never going to support the full power of wikitext.  That would require a *third* full-featured wikitext parser, in addition to the PHP MW parser and Parsoid, with the added complication that the source text is part rich text, part wikitext.

I think mode switching is a better choice.  We can make the mode switch control normally subtle, then become obvious if you start typing wikitext (VE already has logic to detect this, as noted above).
@Jaredzimmerman-WMF regarding the first comment, I think we need a general framework to deal with actions attached to input fields. I was thinking on distributing actions on the left and configuration on the right where the input method menu could fit.

Regarding the second comment, I think you are right and we could avoid the whole mode switching if VE supported wikitext input.
Two things…

I think its smart to have WYSIWYG as the default, but we'd talked in the past about having the bottom right corner reserved for IME tools, we should decide on the merit of having that be the WTE/VE switch vs access to IME, especially if we want IME to be a standard component on input fields. 

One thing that I've been asking for forever was the ability for VE to detect wikitext input and parse it on the fly to convert to rich text, not to increase scope but this might be an ideal use case for this, rather than manually switching between modes.
Discussing this with Pau -- we'll have to define the set of controls that we'll expose. We'll look at current use on talk pages, and also talk with some of the people who are currently using Flow (or will be using it soon). 

Today's hypothesis for what we think are important:
* Links 
* Mentions
* Lists?
* Add image?

Not sure about Bold/Italics/Underline. 

Whatever we decide on, we'll have to use event logging to see if people are using the "More" section to access other controls. 

All of this WIP.
For the contest of Flow, I think styling controls should be less prominent than the user message, and consider the specific needs in the context of Flow. That may imply to hide some controls and show new ones (e.g., user mentioning).

I created a mockup showing these ideas, but more research is needed to determine the specific actions to show:
{F34174}

The above was done assuming rich text editing as the default mode and making it possible to switch to wikitext for advanced users. I didn't include a specific toolbar for wikitext in the mockups but it would be possible to keep the same tools if we really think that they are needed in that mode. This is illustrated below:
{F34176}
>>! In T78346#844010, @Qgil wrote:
> But, but, but... 

On a second thought, I'm happy with the solution that can land faster. At the end, this is an interim situation while VisualEditor integration in Flow comes. On that day, we will have most likely two main types of Flow users: those defaulting consistently to VE and those defaulting consistently to wikitext. If both have the tools they want, both will be happy.
>>! In T78346#843120, @Quiddity wrote:
> Personally, I'd like to have the entire existing WikiEditor toolbar in Flow, with 1 exception.[1]
> I often need special characters, or `<nowiki>` tags, or to insert an image, or create a table, or add a citation for discussion.{F20913}
> 
> [1] The //only// element I think we'd want to remove, is the signature button. And that should be removed when the toolbar is shown on articles anyway, so double benefit if we solve it!
> 
> Can we add that to WikiEditor, somehow?

//My repeated solution -->// ... all we need to do is add...

		'filters': [ 'body.ns-talk' ],

... to the 'signature' button's entry in...

		jquery.wikiEditor.toolbar.config.js

... and you're done. The same approach is used for the 'reference' button btw (see [[https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FWikiEditor/HEAD/modules%2Fjquery.wikiEditor.toolbar.config.js#L170 | that same .js file]] if you don't believe me).

This way, all talk pages will automatically generate the 'signature' button while solving the immediate issue of how to stop its generation in the ns-0 and other Subject-space namespaces.
If it was up to me, I'd at least thrown in the Project: namespace (like for Village Pump) along with all the talkspaces...

		'filters': [ 'body.ns-talk, body.ns-4' ],

... The above should be the common sense "default" setting. And I suspect all the  other "hide WikiEditor type of fixes" floating about would not be affected no matter what this 'filters' setting might be set to - no?
>>! In T78346#843064, @Mattflaschen wrote:
> If OOJS-UI (the UI library used by VE) rolled out everywhere (to e.g. WikiEditor) this consideration would no longer apply

We're on it. Not in the next few weeks, though.
But, but, but... Flow is about simplicity for everybody, and for increasing the participation of newcomers in discussions. <ref> in comments? Tables? Really? I'd rather bet on a very simple setup that solves 90% of the formatting used 90% of the times by 90% of the users. Then the "Help" link explains how to type all the rest.
>>! In T78346#843120, @Quiddity wrote:
> [1] The //only// element I think we'd want to remove, is the signature button. And that should be removed when the toolbar is shown on articles anyway, so double benefit if we solve it!

See T42972. Seems like it ought an easy bug to resolve, but not so.
Personally, I'd like to have the entire existing WikiEditor toolbar in Flow, with 1 exception.[1]
I often need special characters, or `<nowiki>` tags, or to insert an image, or create a table, or add a citation for discussion.{F20913}

[1] The //only// element I think we'd want to remove, is the signature button. And that should be removed when the toolbar is shown on articles anyway, so double benefit if we solve it!

(Note, the CharInsert (special character section //under// the editing window) uses this code, to remove the signature button, when we're editing mainspace. 
`{{#ifeq:{{NAMESPACE}}|{{ns:0}}||'''Sign your posts on talk pages:''' <nowiki>~~~~</nowiki> &nbsp;}}` at https://en.wikipedia.org/w/index.php?title=MediaWiki:Edittools&diff=559635127&oldid=558019716
Can we add that to WikiEditor, somehow?
>>! In T78346#843064, @Mattflaschen wrote:
> It would make more sense to use the WikiEditor icons.

I disagree, because Flow design and VE design fit, while the old toolbar icons will look really old there, and what matters is the impression we cause to new users, but.... this is not a battle I will pick.  :)

In any case the icons are available. It is a matter of deciding which options would survive the pruning (I just added a proposal to the description) and reuse them. There is basically no need for asset creation.
>>! In T78346#843053, @Qgil wrote:
> There is no lack of existing design assets. Why not just removing the VE toolbar icons that are superfluous in the context of discussions? See M26

As of now, using the VE toolbar (or a subset of it) for wikitext would be very confusing.  Looking at your mockup, it strongly makes me think I'm using VisualEditor (the only odd man out is the Preview button).

It would make more sense to use the WikiEditor icons.  If OOJS-UI (the UI library used by VE) rolled out everywhere (to e.g. WikiEditor) this consideration would no longer apply (but at that point we'd want another way to visually hint to people whether they're using wikitext or VE).
There is no lack of existing design assets. Why not just removing the VE toolbar icons that are superfluous in the context of discussions? See M26
There is no lack of existing design assets. Why not just removing the VE options that are superfluous in the context of discussions? See M26
adding design, as we had previously talked about adding the default toolbar and it was considered too cluttered and confusing.  Something less confusing would need to be designed.
Steps to reproduce:

1.Open a page with VE
2.Place a cursor after a text like "sub-heading 1"
3.Open the link inspector

Observe that the character 1 is not getting selected and the link inspector is opening at the end of the line

{F20734}
Verified the fix in Betalabs and test2
Change 197661 merged by jenkins-bot:
[BREAKING CHANGE] Use Unicode character class to calculate word expansions

[[https://gerrit.wikimedia.org/r/197661]]
Change 197661 had a related patch set uploaded (by Divec):
WIP: BREAKING CHANGE: Use unicode character class to calculate word expansions

[[https://gerrit.wikimedia.org/r/197661]]
UnicodeJS change was released in v0.1.3, which is now in VisualEditor core master following https://gerrit.wikimedia.org/r/188729 – what's next?
The word break calculation is correct:

|Sub| |heading| |1|

But our word expansion logic avoids wrapping single length ranges due to the following cases:

|Double| | |Space|

|中|國|人|
I spoke to David about this issue, there is definitely something off about how we account for word boundary and wordbreaks.
Message 'visualeditor-find-and-replace-regular-expression' missing.
We should really be consuming modules.json from core to avoid problems like this
Change 178883 merged by jenkins-bot:
Follow-up I4e38607d8: Register <visualeditor-find-and-replace-regular-expression>

[[https://gerrit.wikimedia.org/r/178883]]
Change 178881 merged by jenkins-bot:
Follow-up I4e38607d8: Register <visualeditor-find-and-replace-regular-expression>

[[https://gerrit.wikimedia.org/r/178881]]
Change 178883 had a related patch set uploaded (by Jforrester):
Follow-up I4e38607d8: Register <visualeditor-find-and-replace-regular-expression>

[[https://gerrit.wikimedia.org/r/178883]]

#patch-for-review
Change 178881 had a related patch set uploaded (by Jforrester):
Follow-up I4e38607d8: Register <visualeditor-find-and-replace-regular-expression>

[[https://gerrit.wikimedia.org/r/178881]]

#patch-for-review
Bah, probably my screw-up.
[[ https://www.mediawiki.org/w/index.php?title=VisualEditor/Feedback&offset=20141127161632#Input_Chinese_to_table_will_disappear_when_saving_unless_start_with_an_English_alphabet.__51109 | Original report ]] by Cwlin0416 on 27 November 2014:

Input Chinese to table will disappear when saving unless start with an English alphabet.

If i just type Chinese into table, it can't be saved, if i start with an English alphabet, the problem is solved.
The problem was originally spotted in Google Chrome while using Traditional Chinese.

The user says (at 16:48 UTC on 11 December) that it was fixed with the recent update.  From Elena's testing, it sounds like we should re-confirm this.
Confirmed on https://zh.wikipedia.org/ - typed Cangjie(on Mac) in tables is not saved.

Tried  in betalabs and test2(wmf12)  the typed text in tables is saved as well as  everywhere else.
See screenshot:

{F20272}
Change 179339 merged by jenkins-bot:
TextInputWidget: Set vertical-align: middle, like buttons

[[https://gerrit.wikimedia.org/r/179339]]
Above patch fixes this:

{F20933}
Change 179339 had a related patch set uploaded (by Bartosz Dziewoński):
TextInputWidget: Set vertical-align: middle, like buttons

[[https://gerrit.wikimedia.org/r/179339]]

#patch-for-review
See screenshot:

{F20262}
Change 179193 merged by jenkins-bot:
MediaWiki theme: Use gray instead of blue for select and highlight

[[https://gerrit.wikimedia.org/r/179193]]
Change 179193 had a related patch set uploaded (by Trevor Parscal):
Use gray instead of blue for select and highlight

[[https://gerrit.wikimedia.org/r/179193]]

#patch-for-review
Eww. Oh well.
See T78032, I think the MediaWiki theme calls for light gray for highlighted and a medium gray for selected.
See screenshot:

{F20257}
Change 179518 merged by jenkins-bot:
MediaWiki theme: Make button sizes match Apex

[[https://gerrit.wikimedia.org/r/179518]]
Change 179518 had a related patch set uploaded (by Jforrester):
MediaWiki theme: Make button sizes match Apex

[[https://gerrit.wikimedia.org/r/179518]]

#patch-for-review
The clipping depends on zoom level, so probably Chromium rendering bug.
I'm pretty sure that's by design. The task for figuring out what to do with the massive buttons is T78169.
No clipping for me in Chrome of FF, but the thing that really stands out is the massive difference in height between buttons and textboxes. That needs to get fixed.
See screenshot:

{F20257}
Change 179545 merged by jenkins-bot:
ButtonGroupWidget: Remove weird margin-bottom: -1px; from theme styles

[[https://gerrit.wikimedia.org/r/179545]]
https://gerrit.wikimedia.org/r/#/c/179545/
This also affects the Apex theme.
Change 179339 merged by jenkins-bot:
TextInputWidget: Set vertical-align: middle, like buttons

[[https://gerrit.wikimedia.org/r/179339]]
Not fixed. I'm going to declare this not a blocker to switching.
Above patch doesn't seem to fix the issue at hand:

{F20931}
I am not sure if the patch fixes the issue here, because I've somehow broken all the styles for the search-and-replace "pulldown" locally. Let's retest this after pulling all recent fixes through.
Change 179339 had a related patch set uploaded (by Bartosz Dziewoński):
TextInputWidget: Set vertical-align: middle, like buttons

[[https://gerrit.wikimedia.org/r/179339]]

#patch-for-review
We'd need to upstream this functionality into OOUI, as the input widget padding varies from skin to skin.
See screenshot:

{F20244}
Change 179343 abandoned by Trevor Parscal:
[WIP] Apex theme: Fix box-sizing for inputs

Reason:
Didn't live up to my expectations. In that... It didn't work at all.

[[https://gerrit.wikimedia.org/r/179343]]
Change 179355 merged by jenkins-bot:
MediaWiki theme: Improve search widget styling

[[https://gerrit.wikimedia.org/r/179355]]
Change 179355 had a related patch set uploaded (by Jforrester):
Improve search widget styling in MediaWiki theme

[[https://gerrit.wikimedia.org/r/179355]]

#patch-for-review
Change 179343 had a related patch set uploaded (by Trevor Parscal):
[WIP] Fix box-sizing for inputs

[[https://gerrit.wikimedia.org/r/179343]]

#patch-for-review
See screenshot:

{F20244}
Change 179343 abandoned by Trevor Parscal:
[WIP] Apex theme: Fix box-sizing for inputs

Reason:
Didn't live up to my expectations. In that... It didn't work at all.

[[https://gerrit.wikimedia.org/r/179343]]
Change 179355 merged by jenkins-bot:
MediaWiki theme: Improve search widget styling

[[https://gerrit.wikimedia.org/r/179355]]
With the "Improve search widget styling" patch, this looks better but not ideal: {F20921}

Adding the "Fix box-sizing for inputs" patch doesn't change the display: {F20923}

For context, the current Apex display in master/OOUI 0.4.0: {F20925}
Change 179355 had a related patch set uploaded (by Jforrester):
Improve search widget styling in MediaWiki theme

[[https://gerrit.wikimedia.org/r/179355]]

#patch-for-review
Change 179343 had a related patch set uploaded (by Trevor Parscal):
[WIP] Fix box-sizing for inputs

[[https://gerrit.wikimedia.org/r/179343]]

#patch-for-review
See screenshot:

{F20244}
Change 178717 merged by jenkins-bot:
ve.ui.MWParameter*: Use the destructive flag for all four remove buttons

[[https://gerrit.wikimedia.org/r/178717]]
>>! In T78033#835291, @TrevorParscal wrote:
> Gosh that looks terrible. I don't know that the style guide actually demands this, because these are secondary actions and should thus be quieter.

Yeah, but consistency…
Change 178717 had a related patch set uploaded (by Jforrester):
ve.ui.MWParameter*: Use the destructive flag for all four remove buttons

[[https://gerrit.wikimedia.org/r/178717]]

#patch-for-review
Gosh that looks terrible. I don't know that the style guide actually demands this, because these are secondary actions and should thus be quieter.
//Migrated from: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/231 //

== Narrative ==

As a development team, we can enable Media Viewer by default on a few pilot sites, so that we can try it out in a limited release before deploying it everywhere.

== Acceptance Criteria ==

Add a site configuration option with which Media Viewer can be enabled for every user (including non-logged-in) on a few pilot wikis(e.g. Commons, French, Hungarian, Korean)
 * Configure Beta Features so that when Media Viewer is enabled, it does not show up as a beta option anymore
 * We can adapt the code used by VisualEditor for the same purpose
 * After we've tested the feature on a few wikis, we may want to gradually increase the number of sites -- or enable it everywhere, based on community feedback.


== Related Bugs ==

== Related Stories ==

== Related Changesets ==



 [[https://gerrit.wikimedia.org/r/117374 | https://gerrit.wikimedia.org/r/117374]]
>>! In [[https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/231 | mingle]] on 2014-03-27 at 21:15:30, @Tgr wrote:

https://gerrit.wikimedia.org/r/#/c/121526/
>>! In [[https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/231 | mingle]] on 2014-03-07 at 02:08:31, @MarkTraceur wrote:

https://gerrit.wikimedia.org/r/117374
>>! In [[https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/231 | mingle]] on 2014-02-27 at 19:42:03, @Tgr wrote:

I'll make this one into the server-side ticket and the other one into the client-side one.
>>! In [[https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/231 | mingle]] on 2014-02-27 at 18:09:16, @MarkTraceur wrote:

Should be merged with  [[https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/263 | #263]]
//Migrated from: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/43 //

== Narrative ==

As a user, I want the option to enable Visual Editor, if it is not available by default on this site.

== Acceptance Criteria ==

Some sites require user opt-in for the VisualEditor (the English and German Wikipedias in particular aren't ready yet to make this feature available by default). So we would like to make the basic version of VisualEditor available as a prominent BetaFeature -- but for those sites only. For example, we could handle this issue by having a site whitelist/blacklist for each beta feature -- or there may also be other technical solutions that work just as effectively to achieve the same results.

See more feature requirements here:

 [[https://www.mediawiki.org/wiki/Beta_Features#Tasks | https://www.mediawiki.org/wiki/Beta_Features#Tasks]] 





== Related Bugs ==

== Related Stories ==
>>! In [[https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/43 | mingle]] on 2013-10-11 at 18:00:20, @MarkTraceur wrote:

https://gerrit.wikimedia.org/r/78795
AFAICT this hasn't been done yet?
My guess it the problem was T133830 or similar.
Er, I added the above commit 1,5 years ago.. not sure what just happened here...
Thank you everyone. :-)
Change 184904 merged by Alexandros Kosiaris:
Re-use Parsoid Varnishes for citoid too

[[https://gerrit.wikimedia.org/r/184904]]
Change 184904 had a related patch set uploaded (by Jforrester):
Re-use Parsoid Varnishes for citoid too

[[https://gerrit.wikimedia.org/r/184904]]

#patch-for-review
Change 178419 abandoned by Catrope:
Expose citoid through misc-web

Reason:
Forgot to abandon this. Gabriel said he'd work on caching infra for the entire services cluster, which they need for RESTbase, but which Citoid would then also use once it's done.

[[https://gerrit.wikimedia.org/r/178419]]
Citoid !== Cite, they're totally different.

However, Gabriel said he would work on setting up a services Varnish thing as part of setting up RESTbase, and Citoid could hitch a ride on that. So this ticket should have been marked as blocked on services, instead it was marked as blocked on ops by mistake.

Under normal circumstances I would have attended SoS yesterday and would have known to file this correctly, but I wasn't able to make it.
Hello,

So I am a bit unclear on this and the two tasks listed as blocked (T62768 and T67540) did not make it any more clear for me. So here's the question:

We want citoid to be publicly available as an endpoint so that Cite and VisualEditor to directly query it, right ?

I assume, Cite is this: http://www.mediawiki.org/wiki/Extension:Cite in which case I am wondering why a Mediawiki Extension can not query an internal endpoint (namely citoid.svc.eqiad.wmnet). I am not at all familiar with Cite so it might be javascript, served by Cite, that runs on the user's browser that does the querying at which point what this ticket asks make sense.

Same thing goes for VisualEditor, I just want to clarify what/who will be doing the endpoint query. Is the situation different than Cite ? And if yes, how ? 

As as side note and since I mentioned javascript, what about same origin policy ? Will that end up being a problem ?
Change 178419 had a related patch set uploaded (by Catrope):
Expose citoid through misc-web

[[https://gerrit.wikimedia.org/r/178419]]

#patch-for-review
Change 192072 merged by jenkins-bot:
Show the toolbar as soon as the target has been activated

[[https://gerrit.wikimedia.org/r/192072]]
Change 192072 had a related patch set uploaded (by Esanders):
Show the toolbar as soon as the target has been activated

[[https://gerrit.wikimedia.org/r/192072]]

#patch-for-review
The Page options menu, which appears when the "hamburger" button is clicked, goes off-screen in RTL wikis.

Screenshot with wrong display in Hebrew:
https://commons.wikimedia.org/wiki/File:VisualEditorBug2a.png
{F168546}

Screenshot with correct display in English:
https://commons.wikimedia.org/wiki/File:VisualEditorBug2b.png
{F168548}

(I have a vague recollection that I reported it once, but I cannot find it now. If somebody does find it, please mark this one as a dupe.)
My fix for this caused part of T98506.
Change 179581 merged by jenkins-bot:
ClippableElement: Handle clipping with left edge

[[https://gerrit.wikimedia.org/r/179581]]
Change 179565 abandoned by Amire80:
Add noflip to oo-ui-popupToolGroup-left and -right

Reason:
Done better in I0c2d9800a1c0bdbe523c978307546ec205202681 .

[[https://gerrit.wikimedia.org/r/179565]]
Change 179581 had a related patch set uploaded (by Bartosz Dziewoński):
[WIP] ClippableElement: Handle clipping with left edge

[[https://gerrit.wikimedia.org/r/179581]]

#patch-for-review
The real issue is that ClippableElement doesn't handle clipping with the left edge of browser window, only with the right edge.
Setting appropriate left and right values for oo-ui-popupToolGroup-left and oo-ui-popupToolGroup-right by adding noflip seems to fix the issue, but because I'm not an experienced oojs-ui dev, this needs review.

For now I fixed this locally in he.wikipedia by adding:

```
.oo-ui-popupToolGroup-left > .oo-ui-toolGroup-tools {
	left: 0;
	right: auto;
}
```
Change 179565 had a related patch set uploaded (by Amire80):
Add noflip to oo-ui-popupToolGroup-left and -right

[[https://gerrit.wikimedia.org/r/179565]]

#patch-for-review
Change 181863 merged by jenkins-bot:
Change the cookie name for valid translation workflow

[[https://gerrit.wikimedia.org/r/181863]]
Change 181863 had a related patch set uploaded (by Santhosh):
Change the cookie name for valid translation workflow

[[https://gerrit.wikimedia.org/r/181863]]

#patch-for-review
Change 179105 merged by jenkins-bot:
Make sure translator see license text even if use manually created URL

[[https://gerrit.wikimedia.org/r/179105]]
I adjusted the styling for the red interlanguage links dialog ([[ https://gerrit.wikimedia.org/r/#/c/179489/ | patchset]]) and the new translation dialog on the dashboard ([[https://gerrit.wikimedia.org/r/#/c/179498/ | patchset]]). 

Screenshots:
{F21011}
{F21017}
I adjusted the styling for the red interlanguage links dialog [[ https://gerrit.wikimedia.org/r/#/c/179489/ | patchset]]) and the new translation dialog on the dashboard ([[https://gerrit.wikimedia.org/r/#/c/179498/ | patchset]]). 

Screenshots:
{F21011}
{F21017}
I adjusted the styling for the red interlanguage links dialog ([[ URL | at ]] [[ https://gerrit.wikimedia.org/r/#/c/179489/ | patchset]]) and the new translation dialog on the dashboard ([[https://gerrit.wikimedia.org/r/#/c/179498/ | patchset]]). 

Screenshots:
{F21011}
{F21017}
I adjusted the styling for the red interlanguage links dialog at https://gerrit.wikimedia.org/r/#/c/179489/

Screenshot:
{F21011}
Screenshot of CX dashboard with source selector automatically opened and prefilled with URL parameters {F20775}
Change 179105 had a related patch set uploaded (by Santhosh):
Make sure translator see license text even if use manually created URL

[[https://gerrit.wikimedia.org/r/179105]]

#patch-for-review
> publishing only happens in the regular editor (the Translation View in this case).

"Translation view" doesn't sound like the regular editor.

P.s.: Confirmed, it's not. Commented on that at https://www.mediawiki.org/wiki/Talk:Content_translation/Translation_view
> publishing only happens in the regular editor (the Translation View in this case).

"Translation view" doesn't sound like the regular editor.
Change 176327 merged by jenkins-bot:
Add the license agreement text to new translation entry points

[[https://gerrit.wikimedia.org/r/176327]]
@Nemo_bis: publishing only happens in the regular editor (the Translation View in this case). The purpose of this is to show the legal terms at the beginning of the process so that users can focus on translating on the Translation View without additional legal text or confirmation steps when publishing.
This would be easier if "publishing" only happened in the regular editor: see for instance how VisualEditor sends you to action=edit (actually action=submit) when commuting an edit.
New translation dialog with legal agreement: {F17064}
Change 176327 had a related patch set uploaded (by Santhosh):
Add the license agreement text to new translation dialog

[[https://gerrit.wikimedia.org/r/176327]]

#patch-for-review
As of this writing, http://en.wikipedia.beta.wmflabs.org/wiki/Special:Version says beta labs is running a 20-hour old version of VE, and that seems to be accurate given that there are a few bugs that are fixed in master but not in beta.
Seems there was some transient error that prevented Gerrit to merge the bot change automatically. Apparently due to some merge conflict.  I am not sure what went wrong but that is definitely fixed.

The last bot change is https://gerrit.wikimedia.org/r/#/c/176867/ which updates the VisualEditor submodule in mediawiki/extensions.git to 6c4c340

I have pulled the repo and did `git submodule update --init VisualEditor`, that points to the same commit 6c4c340.
Seems the script python I wrote to update the VisualEditor repo is no more working / choking on something.  I haven't noticed this task until it has be pointed to me during the Releng weekly checkin.

The related Jenkins job is `mwext-VisualEditor-sync-gerrit`  one might want to look at it to see what is happening and hopefully fix it.


If it is quite tonight at home, I *might* be able to look at this issue.
The commit on Beta Labs has now moved to d20cc324…; however, for ~ 24 hours 9dad03819… has been the latest merged commit. The Jenkins views on code updates to Beta Labs looks fine (notwithstanding https://integration.wikimedia.org/ci/view/Beta/job/beta-scap-eqiad/31718/console which happened much later). Odd.
info-extensions-VisualEditor.json says:

```
{
  "head": "a14f88d80eec331a94cfdfc50da800c8fbc68ef3",
  "remoteURL": "https://gerrit.wikimedia.org/r/p/mediawiki/extensions/VisualEditor.git", 
  "branch": "a14f88d80eec331a94cfdfc50da800c8fbc68ef3", 
  "headCommitDate": "1417037864", 
  "headSHA1": "a14f88d80eec331a94cfdfc50da800c8fbc68ef3", 
  "@directory": "/srv/mediawiki-staging/php-master/extensions/VisualEditor"
}
```
deployment-bastion:/srv/mediawiki-staging/php-master/extensions/VisualEditor is at git hash a14f88d which seems to match https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FVisualEditor and https://github.com/wikimedia/mediawiki-extensions-VisualEditor/commits/master
We are getting ready to integrate Parsoid with RESTBase. This task tracks our progress and what's left to do.

Generally, we need a way to communicate multiple mime entities both in POST requests to Parsoid, and in responses from Parsoid back to RESTBase. We could use [RFC 2387](https://tools.ietf.org/html/rfc2387) or [RFC 2388](https://www.ietf.org/rfc/rfc2388.txt), but this seems to be a bit cumbersome especially for the response part. Instead, we can just use a simple JSON encoding with a structure that's otherwise basically identical to MIME.

The downside of using JSON is possibly efficiency (quite a bit more escaping going on, especially for HTML-in-JSON). However, we could address that later by optionally using a binary encoding like [msgpack](http://msgpack.org/) without changing the message structure itself.

Another option to consider would be to flatten the structure by using names like `original.html`. This would make it easy to encode the same message as `multipart/related`.

== Implementation notes ==

- Parsoid: Slightly simpler format done & deployed. Needs to be updated to indicate the mime types as documented above.
- RESTBase: Prototype implementation.
  - should pass to Parsoid:
    - previous revision's HTML + data-parsoid OnEdit
    - current revision's HTML + data-parsoid OnDependencyChange
- Parsoid WIP implementation: https://gerrit.wikimedia.org/r/#/c/165685/
- RESTBase to be done
Resolved by Parsoid deploy yesterday.
Latest iteration of the RESTBase transform API: https://github.com/wikimedia/restbase/pull/173

Testing revealed an issue with selser, possibly on the Parsoid side: T89411
See https://github.com/wikimedia/restbase/blob/master/specs/mediawiki/v1/content.yaml for the content API v1 spec in development.
This task is getting rather unwieldy.  I'm going to split it up into better-digestible subtasks.
Notes from conversation with @gwicke:

* We don't want the client to pass in `original` -- RESTBase will always find that on its own (e.g. from storage)
* We don't need to allow the client to specify the content type //yet//
* Assume client is always using the latest spec for whichever Content-Type they're using
* Client //might// know the specific Content-Type, but we shouldn't break if we can fallback to a functioning default
@jdouglas, your example is from the Parsoid v2 API, while the RESTBase transform API can just use flat posts. We make the assumption that the transform API does not need to deal with mis-matches in the posted content, as the use cases this is intended for (VE, edit widgets etc) aren't long-running & don't involve storage.

`multipart/form-data` does support per-field content-type headers, but by default those are not set afaik.
It's from the discussion above:

{F34542}
@jdouglas, is there a use case for this? The discussion about multipart/form-data is about the RESTBase API, not the Parsoid v2 API.
This is what Parsoid uses: https://github.com/wikimedia/parsoid/blob/master/lib/mediawiki.ApiRequest.js#L224
Great, thanks!
>>! In T75955#1005304, @Jdouglas wrote:
> Can you point me to the docs on how to get Wikitext from the MW API?

[action=raw](https://www.mediawiki.org/wiki/Manual:Parameters_to_index.php#Raw) ought to help
> The other missing bit is that we currently don't actually fetch wikitext from the MW API. We need to do so (and perhaps store it) for proper html2wt support.

Can you point me to the docs on how to get Wikitext from the MW API?
>>! In T75955#980780, @Jdouglas wrote:
> * accept a `multipart/form-data` body rather than JSON

We could also accept both.

The other missing bit is that we currently don't actually fetch wikitext from the MW API. We need to do so (and perhaps store it) for proper html2wt support.
Ok, so it sounds like we need only augment the `POST /{domain}/v1/transform/<html|wt>/to/html` endpoint to:

* allow an optional `bodyOnly` field
* accept a `multipart/form-data` body rather than JSON

Sound right?
@jdouglas, I think we need to always request the full HTML from Parsoid, so that our storage has the full version. If bodyOnly was requested in the POST, then we should probably pluck out the body with a regexp in restbase.

Regarding `multipart/form-data` vs. `application/json`: Should we promote the former for the transform API?
@jdouglas, I think we need to always request the full HTML from Parsoid, so that our storage has the full version. If bodyOnly was requested in the POST, then we should probably pluck out the body with a regexp in restbase.

Regarding `multipart/form-data` vs. `application/json`: Should we promote the former for now?
>>! In T75955#976719, @Jdouglas wrote:
>> test whether the original content was indeed passed to parsoid
> 
> @gwicke For specification purposes, can you define "original" in this context?
> 
> Does it always mean "penultimate" with respect to the state of the wiki behind `{domain}`?

On second thought, does it mean "the revision for which new changes are being submitted"?
Does the following look correct?

**User -> RESTBase:**

```
{
  method: 'post',
  uri: '/{domain}/v1/transform/<html|wt>/to/html',
  headers: {
    'content-type': 'application/json',
  },
  body: {
    content: 'Hello, world!',
    bodyOnly: true,
  },
}
```

**RESTBase -> Parsoid:**

```
{
  method: 'post',
  uri: 'http://parsoid-lb.eqiad.wikimedia.org/{domain}/FAKE_PAGE_NAME',
  headers: {
    'content-type': 'application/x-www-form-urlencoded',
  },
  body: '$BODY',
}
```


Where `$BODY` is the form-urlencoded representation of:

```
{
  oldid: 123, // optional
  html: 'Hello, world!',
  body: true, // optional
}
```
Does the following look correct?

**User -> RESTBase:**

```
{
  method: 'post',
  uri: '/{domain}/v1/transform/<html|wt>/to/html',
  headers: {
    'content-type': 'application/json',
  },
  body: {
    content: 'Hello, world!',
    bodyOnly: true,
  },
}
```

**RESTBase -> Parsoid:**

```
{
  method: 'post',
  uri: 'http://parsoid-lb.eqiad.wikimedia.org/{domain}/{page}',
  headers: {
    'content-type': 'application/x-www-form-urlencoded',
  },
  body: '$BODY',
}
```


Where `$BODY` is the form-urlencoded representation of:

```
{
  oldid: 123, // optional
  html: 'Hello, world!',
  body: true, // optional
}
```
>>! In T75955#977393, @Jdouglas wrote:
>> Anyone want to do a final check of the tests to verify they cover the scope of this task?
> 
> We're not quite there yet.  The [[ https://www.mediawiki.org/wiki/Parsoid/API | Parsoid API ]] accepts a `body` flag that reduces the scope of the response.
> 
> @GWicke do you know who is using this feature?  

AFAIK this is currently used by Flow, likely also VE.

> Is it something RESTBase should provide via its own API?

Yes. We talked about supporting a plain POST body with the html/wt in 'content' and optional other fields like a 'bodyOnly' boolean. I would vote for using this option in the transform API, as it is easy enough and more efficient for binary content when using `multipart/form-data` encoding. We can always add JSON as an option later.
> Anyone want to do a final check of the tests to verify they cover the scope of this task?

We're not quite there yet.  The [[ https://www.mediawiki.org/wiki/Parsoid/API | Parsoid API ]] accepts a `body` flag that reduces the scope of the response.

@GWicke do you know who is using this feature?  Is it something RESTBase should provide via its own API?  If so, how will it effect storage?  We might not want to store the `body.innerHTML`, but instead store the entire content.  The drawback to this is that we'll have to replicate some of the same DOM parsing that Parsoid currently handles to be able to subset the content on demand.
> test whether the original content was indeed passed to parsoid

@gwicke For specification purposes, can you define "original" in this context?

Does it always mean "penultimate" with respect to the state of the wiki behind `{domain}`?
Strictly speaking https://github.com/wikimedia/restbase/blob/3412329b102e69bb25482d9f21a74151bd00abdd/test/features/parsoid/ondemand.js#L87 does not really test whether the original content was indeed passed to parsoid. Maybe we could let parsoid emit a header if it received the original properly. We could then assert that header in the response.
I think we're pretty close to marking this one as done.  Anyone want to do a final check of the tests to verify they cover the scope of this task?

//On-demand generation of HTML and data-parsoid://

https://github.com/wikimedia/restbase/blob/3412329b102e69bb25482d9f21a74151bd00abdd/test/features/parsoid/ondemand.js

//html2wt conversion support://

https://github.com/wikimedia/restbase/blob/3412329b102e69bb25482d9f21a74151bd00abdd/test/features/parsoid/transform.js
I think we're pretty close to ready to close this task.  Anyone want to do a final check of the tests to verify they cover the scope of this task?

//On-demand generation of HTML and data-parsoid://

https://github.com/wikimedia/restbase/blob/3412329b102e69bb25482d9f21a74151bd00abdd/test/features/parsoid/ondemand.js

//html2wt conversion support://

https://github.com/wikimedia/restbase/blob/3412329b102e69bb25482d9f21a74151bd00abdd/test/features/parsoid/transform.js
The transform endpoint is now functioning: https://github.com/wikimedia/restbase/pull/98

After #98, is there anything else needed for T75955?

Answer: yes: https://coveralls.io/files/412841510#L93
The transform endpoint is now functioning: https://github.com/wikimedia/restbase/pull/98

After #98, is there anything else needed for T75955?
The transform endpoint is now functioning: https://github.com/wikimedia/restbase/pull/98
Oh, my mistake.  The new patch already supports `POST parsoid/v2/{domain}/wt`.
@jdouglas, basically title and oldid are optional, so both `POST parsoid/v2/{domain}/wt/{title}` and `POST parsoid/v2/{domain}/wt` should work. If the request without title doesn't work in parsoid right now, then we could work around it by inventing one like 'Main_Page' for now. IIRC that's what Parsoid used to do as well if the title is missing.

Edit: Parsoid [uses the configured mainpage for the wiki](https://github.com/wikimedia/parsoid/blob/1f43a268b70cf4a91b4e982e328e9dbfd0889f96/lib/mediawiki.parser.environment.js#L248), which happens to be 'Main Page' for enwiki, but differs for other languages.
@jdouglas, basically title and oldid are optional, so both `POST parsoid/v2/{domain}/wt/{title}` and `POST parsoid/v2/{domain}/wt` should work. If the request without title doesn't work in parsoid right now, then we could work around it by inventing one like 'Main_Page' for now. IIRC that's what Parsoid used to do as well if the title is missing.
When there's no title or revision, i.e. `POST /{domain}/v1/transform/html/to/wt`, what should be the Parsoid request URL?

`POST parsoid/v2/{domain}/wt/{title}/{oldid}`

Parsoid appears to allow gibberish:

`POST parsoid/v2/{domain}/wt/___NOT_A_REAL_TITLE_1231___/`

Should we designate a special placeholder title?  Or should we update Parsoid to respond to `POST parsoid/v2/{domain}/wt`?
When there's no title or revision, i.e. `POST /{domain}/v1/transform/html/to/wt`, what should be the Parsoid request URL?

`POST parsoid/v2/{domain}/wt/{title}/{oldid}`
{icon thumbs-up}
@jdouglas: I think we can always wrap things into a full request on the restbase end, and just add the latest configured parsoid mime type if we didn't receive any from the client. So we can perhaps just strike this as a parsoid requirement.
@jdouglas: I think we can always wrap things into the a full request on the restbase end, and just add the latest configured parsoid mime type if we didn't receive any from the client. So we can perhaps just strike this as a parsoid requirement.
@jdouglas: I think we can always wrap things into the a full request on the restbase end, and just add the latest configured parsoid mime type if we didn't receive any from the client.
@gwicke:

> If the modified html is just a string, then Parsoid is expected to assume that it's in the latest html version.

Does this refer to a POST to //parsoid/v2/{domain}/wt/{title}/{oldid}// with a request body containing raw HTML?
@gwicke:

> If the modified html is just a string, then Parsoid is expected to assume that it's in the latest html version.If the modified html is just a string, then Parsoid is expected to assume that it's in the latest html version.

Does this refer to a POST to //parsoid/v2/{domain}/wt/{title}/{oldid}// with a request body containing raw HTML?
See proposed tests here: https://github.com/wikimedia/restbase/pull/98
Change 165685 merged by Jdouglas:
API v2 parsing and serialization routes

[[https://gerrit.wikimedia.org/r/165685]]
@jdouglas: To be fair, JSON schema validation is not usually happening for free just by having stronger typing.
Understandable, considering we're operating without a type system. :]
@jdouglas I think validation is fairly embryonic at this point. Definitely agreed on 400 being better than 500.
Gotcha. Does Parsoid have any infrastructure for validation? A 400 with a reason might be more informative to an erroneous client than a 500 with an obscure es6-shim stack trace.
@jdouglas: Passing in data-parsoid without ids in the body could be considered a bug in the client worth highlighting. If that passed unnoticed, the result would likely be wikitext corruption in edits, which would make many people unhappy. If we send the 'original' object, then it should contain both html *and* a valid data-parsoid attribute, both from storage. 

Parsoid also needs to support html2wt conversion without the 'original' object (for new page creation for example). That might be a simpler mode to test for the first iteration.
Here's the source of the problem: https://github.com/wikimedia/parsoid/blob/04721c235f9cc6d4ffdca8418e73d602aecfebba/lib/mediawiki.DOMUtils.js#L1963

Would it be better to allow for an id-less body?

e.g.

```
Object.keys( dp.ids || {} ).forEach(function ( key ) {
```
This works for `wt` when I replace `"body": {}" with the following:

```
        "body": {
            "counter": 1,
            "ids": {
                "mwAA": {
                    "dsr": [
                        0,
                        949,
                        0,
                        0
                    ]
                },
                "mwAQ": {
                    "dsr": [
                        928,
                        949,
                        0,
                        0
                    ]
                }
            }
        }
```

EDIT: The key is having `body.ids` -- at least `"body": { "ids": {} }`
This works for `wt` when I replace `"body": {}" with the following:

```
        "body": {
            "counter": 1,
            "ids": {
                "mwAA": {
                    "dsr": [
                        0,
                        949,
                        0,
                        0
                    ]
                },
                "mwAQ": {
                    "dsr": [
                        928,
                        949,
                        0,
                        0
                    ]
                }
            }
        }
```

The key is having `body.ids` -- at least `"body": { "ids": {} }`
This works for `wt` when I replace `"body": {}" with the following:

```
        "body": {
            "counter": 1,
            "ids": {
                "mwAA": {
                    "dsr": [
                        0,
                        949,
                        0,
                        0
                    ]
                },
                "mwAQ": {
                    "dsr": [
                        928,
                        949,
                        0,
                        0
                    ]
                }
            }
        }
```
I converted the `POST parsoid/v2/{domain}/wt/{title}/{oldid}` example above to a JSON file, and attempted to run it locally, but something went wrong:


```
$ curl -H "Content-Type: application/json" -X POST -d @T75955.json localhost:8000/v2/en.wikipedia.org/wt/Main_Page/1
Cannot call method on undefined
TypeError: Cannot call method on undefined
    at Object.ES.CheckObjectCoercible (/home/jdouglas/code/parsoid/node_modules/es6-shim/es6-shim.js:152:17)
    at Object.ES.ToObject (/home/jdouglas/code/parsoid/node_modules/es6-shim/es6-shim.js:164:26)
    at Function.Object.keys (/home/jdouglas/code/parsoid/node_modules/es6-shim/es6-shim.js:905:38)
    at Object.DU.applyDataParsoid (/home/jdouglas/code/parsoid/lib/mediawiki.DOMUtils.js:1958:10)
    at Promise.then.timeout.then.apiUtils.jsonResponse.wikitext.headers.content-type (/home/jdouglas/code/parsoid/api/routes.js:275:7)
    at /home/jdouglas/code/parsoid/node_modules/es6-shim/es6-shim.js:1220:20
    at Object._onImmediate (/home/jdouglas/code/parsoid/node_modules/es6-shim/es6-shim.js:1177:28)
    at processImmediate [as _immediateCallback] (timers.js:345:15)
```

Any debugging pointers?

{F25608}

EDIT: It works if I s/wt/html/g in the URL.
I converted the `POST parsoid/v2/{domain}/wt/{title}/{oldid}` example above to a JSON file, and attempted to run it locally, but something went wrong:


```
$ curl -H "Content-Type: application/json" -X POST -d @T75955.json localhost:8000/v2/en.wikipedia.org/wt/Main_Page/1
Cannot call method on undefined
TypeError: Cannot call method on undefined
    at Object.ES.CheckObjectCoercible (/home/jdouglas/code/parsoid/node_modules/es6-shim/es6-shim.js:152:17)
    at Object.ES.ToObject (/home/jdouglas/code/parsoid/node_modules/es6-shim/es6-shim.js:164:26)
    at Function.Object.keys (/home/jdouglas/code/parsoid/node_modules/es6-shim/es6-shim.js:905:38)
    at Object.DU.applyDataParsoid (/home/jdouglas/code/parsoid/lib/mediawiki.DOMUtils.js:1958:10)
    at Promise.then.timeout.then.apiUtils.jsonResponse.wikitext.headers.content-type (/home/jdouglas/code/parsoid/api/routes.js:275:7)
    at /home/jdouglas/code/parsoid/node_modules/es6-shim/es6-shim.js:1220:20
    at Object._onImmediate (/home/jdouglas/code/parsoid/node_modules/es6-shim/es6-shim.js:1177:28)
    at processImmediate [as _immediateCallback] (timers.js:345:15)
```

Any debugging pointers?

{F25608}
I converted the `POST parsoid/v2/{domain}/wt/{title}/{oldid}` example above to a JSON file, and attempted to run it locally, but something went wrong:


```
$ curl -H "Content-Type: application/json" -X POST -d @T75955.json localhost:8000/v2/en.wikipedia.org/wt/Main_Page/1
Cannot call method on undefined
TypeError: Cannot call method on undefined
    at Object.ES.CheckObjectCoercible (/home/jdouglas/code/parsoid/node_modules/es6-shim/es6-shim.js:152:17)
    at Object.ES.ToObject (/home/jdouglas/code/parsoid/node_modules/es6-shim/es6-shim.js:164:26)
    at Function.Object.keys (/home/jdouglas/code/parsoid/node_modules/es6-shim/es6-shim.js:905:38)
    at Object.DU.applyDataParsoid (/home/jdouglas/code/parsoid/lib/mediawiki.DOMUtils.js:1958:10)
    at Promise.then.timeout.then.apiUtils.jsonResponse.wikitext.headers.content-type (/home/jdouglas/code/parsoid/api/routes.js:275:7)
    at /home/jdouglas/code/parsoid/node_modules/es6-shim/es6-shim.js:1220:20
    at Object._onImmediate (/home/jdouglas/code/parsoid/node_modules/es6-shim/es6-shim.js:1177:28)
    at processImmediate [as _immediateCallback] (timers.js:345:15)
```

Any debugging pointers?
@jdouglas: Yes, that should work. See https://www.mediawiki.org/wiki/Parsoid/Setup#Manual_installation_on_Linux_or_Mac_OS_X

Basic summary:

```
# clone parsoid
git clone ssh://<user>@gerrit.wikimedia.org:29418/mediawiki/services/parsoid

cd parsoid

# check out the patch with the git commandline shown in gerrit:
git fetch ssh://<user>@gerrit.wikimedia.org:29418/mediawiki/services/parsoid refs/changes/85/165685/13 && git checkout FETCH_HEAD
npm install

node api/server
```

This should bring up parsoid locally. The wikipedia domains are all configured by default.
@jdouglas: Yes, that should work. See https://www.mediawiki.org/wiki/Parsoid/Setup#Manual_installation_on_Linux_or_Mac_OS_X

Basic summary:

```
# clone parsoid
git clone ssh://<user>@gerrit.wikimedia.org:29418/mediawiki/services/parsoid

cd parsoid

# check out with the git commandline shown in gerrit:
git fetch ssh://<user>@gerrit.wikimedia.org:29418/mediawiki/services/parsoid refs/changes/85/165685/13 && git checkout FETCH_HEAD
npm install

node api/server
```

This should bring up parsoid locally. The wikipedia domains are all configured by default.
@jdouglas: Yes, that should work. See https://www.mediawiki.org/wiki/Parsoid/Setup#Manual_installation_on_Linux_or_Mac_OS_X

Basic summary:

```bash
# clone parsoid
git clone ssh://<user>@gerrit.wikimedia.org:29418/mediawiki/services/parsoid

cd parsoid

# check out with the git commandline shown in gerrit:
git fetch ssh://<user>@gerrit.wikimedia.org:29418/mediawiki/services/parsoid refs/changes/85/165685/13 && git checkout FETCH_HEAD
npm install

node api/server
```

This should bring up parsoid locally. The wikipedia domains are all configured by default.
Is it feasible to run this Parsoid patch in my local dev environment so that I can develop against it?

EDIT: I found instructions [[ https://github.com/wikimedia/cassandra-codec/pull/9#issuecomment-68279450 | here ]].
Is it feasible to run this Parsoid patch in my local dev environment so that I can develop against it?

EDIT: I found instructions [[ https://github.com/wikimedia/cassandra-codec/pull/9#issuecomment-68279450 | here ]].
```
Is it feasible to run this Parsoid patch in my local dev environment so that I can develop against it?
Is it feasible to run this patch in my local dev environment so that I can develop against it?
I updated the patch with that.
@arlolra: See my review there.

As you noted in your response, we also need a way to request more targeted updates. This includes the current wt2html updates (re-render templates or re-render images), but we should use a mechanism that can also cover more refined requests in the future: 

- re-sanitization of HTML / upgrade of HTML spec
- update of transclusions affected by certain templates only
- update of specific images only

A key in the request seems to make most sense. Perhaps something like this?

```
{
   update: {
      templates: true,
      images: false,
      spec: true
   },
   original: { ... }
}
```

Not all of these need to be set all the time, only the actually requested updates could be set to a truish value. In the future, we could add an object value with finer-grained options instead to support targeted template / image updates.
> Do you mean html2wt or wt2html in the issue summary?

wt2html

> It reuses template expansions or images, depending which of the two triggered the update. The reason for the update is relayed in an x-parsoid header currently.

I was thinking it only did that with the `previous` revision data but I guess it's both then
https://gerrit.wikimedia.org/r/#/c/165685/12/api/routes.js

can you review https://gerrit.wikimedia.org/r/#/c/165685/ when you get a chance?
>>! In T75955#937200, @Arlolra wrote:
> @Gwicke: In the example responses from Parsoid, you'll showing the pagebundle but the route examples say `/html/`.

Do you mean html2wt or wt2html in the issue summary?

>> For a no-cache request, RESTBase instead first checks whether the *current* revision is found in storage. If it is, it sends the data for that in the original key:
> 
> what, if anything, does Parsoid do with the `original` data.

It reuses template expansions or images, depending which of the two triggered the update. The reason for the update is relayed in an x-parsoid header currently.
>>! In T75955#937200, @Arlolra wrote:
> @Gwicke: In the example responses from Parsoid, you'll showing the pagebundle but the route examples say `/html/`.

Do you mean html2wt or wt2html in the issue summary?

>> For a no-cache request, RESTBase instead first checks whether the *current* revision is found in storage. If it is, it sends the data for that in the original key:
> 
> what, if anything, does Parsoid do with the `original` data.

It reuses template expansions or images, depending which of the two triggered the update. The reasion for the update is relayed in an x-parsoid header currently.
> what, if anything, does Parsoid do with the original data.

if the original data contains the wikitext source, then parsoid won't have to fetch it. I'll assume you meant that
@Gwicke: In the example responses from Parsoid, you'll showing the pagebundle but the route examples say `/html/`.

Also, in the cache scenario (wt2html), we try to reuse the expansions from the previous revision, as in,
https://gerrit.wikimedia.org/r/#/c/165685/10/api/routes.js

but, for no-cache,

> For a no-cache request, RESTBase instead first checks whether the *current* revision is found in storage. If it is, it sends the data for that in the original key:

what, if anything, does Parsoid do with the `original` data.
Makes sense, thanks!
>>! In T75955#934492, @Jdouglas wrote: 
> 1. What does `original` mean -- is it the penultimate revision of the content in question?  Is it the first revision of the content?  What's the context of originality?

'original' means the data for the edit revision the edit was based on (if title and oldid is specified, and if we had that in restbase).

> 1. Why is so much data being sent to Parsoid?  Does Parsoid need two HTML representations, plus a wikitext representation, plus a data-parsoid representation?  Or does this example show the different options for the types of source data?

Parsoid does a lot of clever tricks to keep the conversion clean and make it fast. One is to diff the modified HTML against the original & using the original wikitext for portions of the DOM that weren't modified (based on offset information similar to a source map from data-parsoid). The predecessor revision is used to speed up parsing of new versions by plucking out some bits of content (template expansions, image thumbs) & reusing them without going off and generating them from scratch using the PHP API.

> 1. What is the minimum request that could be sent to Parsoid through this endpoint?
> 
> My goal is to be able to document this API , part of which means defining the schemas for the requests and responses, so it will help me to understand exactly what's going on.

We could only send the modified content, but then diffs will be dirty and the performance will suffer.
@gwicke Can you break down the request described above?

```
POST parsoid/v2/{domain}/{title}/wt

{
    html: {
        headers: {
            'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
        },
        body: '<html>The modified HTML</html>'
    },
    original: {
        revid: 12345, // The original revision ID
        wikitext: {
            headers: {
                'content-type': 'text/plain;profile=mediawiki.org/specs/wikitext/1.0.0'
            },
            body: "the original wikitext"
        },
        html: {
            headers: {
                'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
            },
            body: "the original HTML"
        }
        'data-parsoid': {
            headers: {
                'content-type': 'application/json;profile=mediawiki.org/specs/data-parsoid/0.0.1'
            },
            body: {}
        }
    }
}
```

I have several questions, most of which are probably due to my lack of knowledge about how Parsoid works.

1. What does `original` mean -- is it the penultimate revision of the content in question?  Is it the first revision of the content?  What's the context of originality?
1. Why is so much data being sent to Parsoid?  Does Parsoid need two HTML representations, plus a wikitext representation, plus a data-parsoid representation?  Or does this example show the different options for the types of source data?
1. What is the minimum request that could be sent to Parsoid through this endpoint?

My goal is to be able to document this API , part of which means defining the schemas for the requests and responses, so it will help me to understand exactly what's going on.
Right now these POST requests are completely ephemeral.

We *could* eventually consider caching some responses based a request hash for a limited time (and return that hash in some header), so that the result could be dereferenced shortly later using just the hash. That could be handy for features like VisualEditor's speculative html2wt conversion, which is currently implemented using custom memcached logic. But that's really not needed in the first iteration IMHO.
@Jdouglas I think it would have to be ephemeral. You could hash the content to create an identifier but if it contained a template or whatnot, it wouldn't be clear when that needs expunging.
If the optional title is omitted, does that mean the converted data is ephemeral, or would we want to generate some kind of identifier so that the content can be stored for future access?
Re POST requests, I think we could perhaps use the following:

- html2wt without selser: `POST /v2/{domain}/wt/{title}` (title optional)
- html2wt with selser: `POST /v2/{domain}/wt/{title}/{oldid}`
- html2html or wt2html: `POST /v2/{domain}/html/{title}/{oldid}` (title and oldid optional)
>>! In T75955#853672, @Jdouglas wrote:
>> html2wt conversion support
>> 
>> Request to RESTBase: POST /v1/{domain}/transform/html/to/wt
>>
>> RESTBase retrieves the original html, wikitext & data-parsoid from storage & POSTs it to Parsoid:
>>
>> POST parsoid/v2/{domain}/{title}/wt
> 
> How does RESTBase determine the title of the content?

@jdouglas, @arlolra: good question. Maybe flipping the order would actually make more sense for Parsoid? It would still provide a list of formats, and it does not require knowledge of the oldid.

Example: `POST parsoid/v2/{domain}/wt/{title}`

Alternatively, we could figure everything but the domain out by POSTing to `/v2/{domain}/`.
>>! In T75955#853672, @Jdouglas wrote:
>> html2wt conversion support
>> 
>> Request to RESTBase: POST /v1/{domain}/transform/html/to/wt
>>
>> RESTBase retrieves the original html, wikitext & data-parsoid from storage & POSTs it to Parsoid:
>>
>> POST parsoid/v2/{domain}/{title}/wt
> 
> How does RESTBase determine the title of the content?

@jdouglas, @arlolra: good question. Maybe flipping the order would actually make more sense for Parsoid? It would still provide a list of formats, and it does not require knowledge of the oldid.
> html2wt conversion support
> 
> Request to RESTBase: POST /v1/{domain}/transform/html/to/wt
>
> RESTBase retrieves the original html, wikitext & data-parsoid from storage & POSTs it to Parsoid:
>
> POST parsoid/v2/{domain}/{title}/wt

How does RESTBase determine the title of the content?
If the title isn't provided, what do we supply in the POST to Parsoid?

> POST parsoid/v2/{domain}/{title}/wt

Or would there be a different URL for arbitrary html conversion in Parsoid?
>>! In T75955#842132, @Jdouglas wrote:
> In the //html2wt conversion support// section, how do we identify the article that the user wants to convert?  Should we add a //{title}// to the url?

Since it's a POST anyway, we could also just ask for an optional `title` and `revision` in the post data. That way the same URL will work for random HTML (which is not associated with any particular page / revision), and for edits to existing content.
In the //html2wt conversion support// section, how do we identify the article that the user wants to convert?  Should we add a //{title}// to the url?

> Request to RESTBase: POST /v1/{domain}/transform/html/to/wt
@ssastry: We could add a 'version' property which has the link to the spec version, which we can then prefix with text/html and application/json to get a complete mime type for each respective bit. On the way back we'll then need to undo that. When we re-sanitize HTML, we'll also need to update the version numbers on data-mw and data-parsoid, even if those weren't actually changed in any way. Or, alternatively, we could use the maximum version for a combined version as you propose when sending the different bits of content back to Parsoid.

This is all more complexity than I'd like to have. It would really be simpler if you could just give us a complete mime type for each bit of content, the same way you would set it when asked for one of those formats only (for non-pagebundle formats). We can then set that mime type in responses to clients asking for HTML, and send it back to you later, without having to track special details about the parsoid version scheme.
@ssastry: We could add a 'version' property which has the link to the spec version, which we can then prefix with text/html and application/json to get a complete mime type for each respective bit. On the way back we'll then need to undo that. When we re-sanitize HTML, we'll also need to update the version numbers on data-mw and data-parsoid, even if those weren't actually changed in any way. Or, alternatively, we could use the maximum version for a combined version as you propose when sending the different bits of content back to Parsoid.

This is all more complexity than I'd like to have. It would really be simpler if you could just give me a complete mime type for each bit of content. I can then set that mime type in responses to clients asking for HTML, and send it back to you later, without having to track special details about the parsoid version scheme.
@ssastry: We could add a 'version' property which has the link to the spec version, which we can then prefix with text/html and application/json for the respective bits. We'll also need to indicate the mime type in mixed content we send to parsoid, for each part. To me as a user it's actually simpler if you just give me a complete mime type for each bit of content. I can then just send that back to you later, without knowing much about custom mime type massaging etc.
@ssastry: We could add a 'version' property which has the link to the spec version, which we can then prefix with text/html and application/json for the respective bits. We'll also need to send that in stuff we send to parsoid, for each part. To me as a user it's actually simpler if you just give me a complete mime type for each bit of content. I can then just send that back to you later, without knowing much about custom mime type massaging etc.
Right, we need to know the version number, but, I was just wondering if it needs to be part of every resource in the v2 page bundle, i.e. you can add a html-version property to the v2 page bundle, for example.
@ssastry: When we load some old HTML from storage, we need to know

1) whether this HTML needs to be re-sanitized after discovering that sanitization issue in the Parsoid version that emitted DOM spec 1.0.0, and
2) whether we need to update the HTML to actually work in current clients like VE. This is both purely in RESTBase.

If Parsoid is going to use (and likely update / re-sanitize) old HTML, it also needs to know which assumptions it can make based on the version. It might well elect to throw away any old HTML before version X, but without knowing the version you can't make that decision easily.

So far we ducked these issues by not storing any HTML, and clearing the entire cache when we made major changes. We won't be able to do this with storage in the longer term.
Sorry I couldn't look at this earlier. 

But, one obvious comment right away is that wikitext doesn't have a "spec" really and there is no real versioning as far as I know. Secondly, I don't see a real use case where Parsoid would be able to take different HTML versions (for old and modified) and then use that for serialization. Parsoid may regenerate the old HTML for the new HTML spec and/or fall back to full serialization in that scenario.

I also don't see a scenario where a client (like VE, Flow, etc) is going to take an old version of HTML, edit it and generate a new version of the HTML. So, I think from the scenario of editing clients, the HTML version is going to be preserved. All version bumps in HTML are likely going to happen entirely in Parsoid land on the wt2html pipeline.

So, is this more richer representation really useful? I personally prefer a simpler representation. But, I haven't thought through this fully. Perhaps something worth a discussion on IRC so I understand this better.
>>! In T75955#833765, @Jdouglas wrote:
> Makes sense to me.  I like the idea of including spec versions in the content types.  Is there a central repository of specs I can peruse?

Not yet, but we should start building it up, even if it isn't exposed in the advertised location yet.

> Would this framing structure extend to other types of content, such as binary data?

Yes. We can use `'transfer-encoding': 'base64'` in the headers.
>>! In T75955#833765, @Jdouglas wrote:
> Makes sense to me.  I like the idea of including spec versions in the content types.  Is there a central repository of specs I can peruse?

Not yet, but we should start building it up, even if it isn't exposed in the advertised location yet.

> Would this framing structure extend to other types of content, such as binary data?

Yes. We can use 'transfer-encoding': 'base64' in the headers.
Makes sense to me.  I like the idea of including spec versions in the content types.  Is there a central repository of specs I can peruse?

Would this framing structure extend to other types of content, such as binary data?
One issue with the format above (especially for GETs) is that we don't have a content type for the HTML & data-parsoid. This is important, as the content-type also indicates the spec version that parsoid currently emits, which we really need to track in the database. On the way back, we should indicate to Parsoid which version of HTML, wikitext or data-parsoid we are passing it, so that Parsoid can interpret it correctly. This is especially important when editing old revisions.

To fix this, I have been thinking about a more generic framing structure for multi-part responses more along the lines of `multipart/form-data`:

```
{
    headers: {
        'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
    },
    body: '<html>....</html>'
}
```

In the v2 serialization API, we could basically replace each individual key with a full mime object:

```
{
    html: {
        headers: {
            'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
        },
        body: "the modified html"
    },
    original: {
        revid: 12345, // The original revision ID
        wikitext: {
            headers: {
                'content-type': 'text/plain;profile=mediawiki.org/specs/wikitext/1.0.0'
            },
            body: "the original wikitext"
        },
        html: {
            headers: {
                'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
            },
            body: "the original HTML"
        }
        'data-parsoid': {
            headers: {
                'content-type': 'application/json;profile=mediawiki.org/specs/data-parsoid/0.0.1'
            },
            body: {}
        }
    }
}
```
Similarly, the v2 wt2html API would indicate the content type of each component in its response, which restbase will then store & return to the client.

@arlolra, @parsoid, @jdouglas: Does this makes sense to you?
One issue with the format above (especially for GETs) is that we don't have a content type for the HTML & data-parsoid. This is important, as the content-type also indicates the spec version that parsoid currently emits, which we really need to track in the database. On the way back, we should indicate to Parsoid which version of HTML, wikitext or data-parsoid we are passing it, so that Parsoid can interpret it correctly. This is especially important when editing old revisions.

To fix this, I have been thinking about a more generic framing structure for multi-part responses more along the lines of `multipart/form-data`:

```
{
    headers: {
        'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
    },
    body: '<html>....</html>'
}
```

In the v2 serialization API, we could basically replace each individual key with a full mime object:

```
{
    html: {
        headers: {
            'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
        },
        body: "the modified html"
    },
    original: {
        revid: 12345, // The original revision ID
        wikitext: {
            headers: {
                'content-type': 'text/plain;profile=mediawiki.org/specs/wikitext/1.0.0'
            },
            body: "the original wikitext"
        },
        html: {
            headers: {
                'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
            },
            body: "the original HTML"
        }
        'data-parsoid': {
            headers: {
                'content-type': 'application/json;profile=mediawiki.org/specs/data-parsoid/0.0.1'
            },
            body: {}
        }
    }
}
```
Similarly, the v2 wt2html API would indicate the content type of each component in its response, which restbase will then store & return to the client.

Does this makes sense to you?
One issue with the format above (especially for GETs) is that we don't have a content type for the HTML & data-parsoid. This is important, as the content-type also indicates the spec version that parsoid currently emits, which we really need to track in the database. On the way back, we should indicate to Parsoid which version of HTML, wikitext or data-parsoid we are passing it, so that Parsoid can interpret it correctly. This is especially important when editing old revisions.

To fix this, I have been thinking about a more generic framing structure for multi-part responses more along the lines of `multipart/form-data`:

```
{
    headers: {
        'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
    },
    body: '<html>....</html>'
}
```

In the v2 serialization API, we could basically replace each individual key with a full mime object:

```
{
    html: {
        headers: {
            'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
        },
        body: "the modified html"
    },
    original: {
        revid: 12345, // The original revision ID
        wikitext: {
            headers: {
                'content-type': 'text/plain;profile=mediawiki.org/specs/wikitext/1.0.0'
            },
            body: "the original wikitext"
        },
        html: {
            headers: {
                'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
            },
            body: "the original HTML"
        }
        'data-parsoid': {
            headers: {
                'content-type': 'application/json;profile=mediawiki.org/specs/data-parsoid/0.0.1'
            },
            body: {}
        }
    }
}
```

Does this makes sense to you?
One issue with the format above (especially for GETs) is that we don't have a content type for the HTML & data-parsoid. This is important, as the content-type also indicates the spec version that parsoid currently emits, which we really need to track in the database. On the way back, we should indicate to Parsoid which version of HTML, wikitext or data-parsoid we are passing it, so that Parsoid can interpret it correctly. This is especially important when editing old revisions.

To fix this, I have been thinking about a more generic framing structure for multi-part responses more along the lines of `multi-part/form-data`:

```
{
    headers: {
        'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
    },
    body: '<html>....</html>'
}
```

In the v2 serialization API, we could basically replace each individual key with a full mime object:

```
{
    html: {
        headers: {
            'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
        },
        body: "the modified html"
    },
    original: {
        revid: 12345, // The original revision ID
        wikitext: {
            headers: {
                'content-type': 'text/plain;profile=mediawiki.org/specs/wikitext/1.0.0'
            },
            body: "the original wikitext"
        },
        html: {
            headers: {
                'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
            },
            body: "the original HTML"
        }
        'data-parsoid': {
            headers: {
                'content-type': 'application/json;profile=mediawiki.org/specs/data-parsoid/0.0.1'
            },
            body: {}
        }
    }
}
```

Does this makes sense to you?
One issue with the format above (especially for GETs) is that we don't have a content type for the HTML & data-parsoid. This is important, as the content-type also indicates the spec version that parsoid currently emits, which we really need to track in the database. 

To fix this, I have been thinking about a more generic framing structure for multi-part responses more along the lines of `multi-part/form-data`:

```
{
    headers: {
        'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
    },
    body: '<html>....</html>'
}
```

In the v2 serialization API, we could basically replace each individual key with a full mime object:

```
{
    html: {
        headers: {
            'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
        },
        body: "the modified html"
    },
    original: {
        revid: 12345, // The original revision ID
        wikitext: {
            headers: {
                'content-type': 'text/plain;profile=mediawiki.org/specs/wikitext/1.0.0'
            },
            body: "the original wikitext"
        },
        html: {
            headers: {
                'content-type': 'text/html;profile=mediawiki.org/specs/html/1.0.0'
            },
            body: "the original HTML"
        }
        'data-parsoid': {
            headers: {
                'content-type': 'application/json;profile=mediawiki.org/specs/data-parsoid/0.0.1'
            },
            body: {}
        }
    }
}
```

Does this makes sense to you?
Change 165685 had a related patch set uploaded (by Arlolra):
Add v2 serialization route

[[https://gerrit.wikimedia.org/r/165685]]

#patch-for-review
In BugZilla, the MediaWiki product had milestones like "1.1 release", "1.20.x release" and "1.25.0 release" etc.

Individual MediaWiki extensions didn't have such a milestone, but we did have shared ones for extensions like "MW 1.18 version", "MW 1.14 version".

To avoid clashing with other project's release tags (see also T75899), we should rename the MediaWiki core ones to include "MediaWiki" or "MW".

While at it I'd like to propose merging the ones formerly for extensions to be the same (e.g. merge "1.24.0 release" and "MW 1.24 version" into "MediaWiki-1.24" or something like that.
Thanks for raising these very valid and convincing points and for your patience.

I have added "MW-"prefixes. They are slightly less discoverable as I didn't want more stuff cluttering the projects dropdown when you enter "MediaWiki" plus as the dropdown does not support colors yet (there is some upstream ticket about this), people might think that they describe the version they are running instead of the version the bug should get fixed for.

See https://phabricator.wikimedia.org/project/query/all/?after=MW for a list.

Ironically that prefix we had also used for extension target milestones in Bugzilla too, so there were also disabled "MW-1.18-version" style projects. I have renamed those to "MW-extension-1.18-version" style to have less confusion in project dropdowns.

All in all, it's a bit more confusing than I had naively anticipated. I am sorry for that.

Closing as resolved.
This issue doesn't seem resolved.
>>! In T75916#960085, @Legoktm wrote:
> I agree with Krinkle and fbstj that the projects should be MediaWiki specific. Basically, there should be one project for a MediaWiki 2.0 Release and another for a Pywikibot 2.0 Release.

+1
I agree with Krinkle and fbstj that the projects should be MediaWiki specific. Basically, there should be one project for a MediaWiki 2.0 Release and another for a Pywikibot 2.0 Release.
So if I understand correctly you're recommending we consider version milestones as "accidentally" indexed and browsable through Phabricator as projects.

Thus we'd have to disregard all features related to it (members, watchers, workboards, archiving, edit permissions, change feeds, ..).

Because if you'd archive v2.0 when Project A's v2.0 is finished, that says nothing about a Project B still at v1.9 that will have a v2.0 next year. (e.g. like Firefox 30 and Chrome 30, you'd have to abandon all features related to individual projects and treat them as individual-meaningless correlation keywords instead).

That seems like a big waste and compromise in overall usability of Phabricator (the link on task pages to e.g. [1.24 release](https://phabricator.wikimedia.org/tag/1.24-release/) would only be confusing for users as it'd provide a meaningless feed of unrelated projects). All only to try and gain what? Smaller number of projects overall?

I'm not saying we should have separate version milestones for MediaWiki Core and MediaWiki extensions that follow the same release versioning. It makes perfect sense to share one "MW 1.25 release" between those (as I originally recommended which is what prompted this whole thread). Those would use additional filters in searches for e.g. "MediaWiki" when interested in that one project. (E.g. the Cite extension doesn't have its own release process, it just follows MediaWiki). But I'm talking about projects not directly following MediaWiki's release process. E.g. OOjs, VisualEditor, CDB, and all other projects we have.
So if I understand correctly you're recommending we consider version milestones as "accidentally" indexed and browsable through Phabricator as projects.

Thus we'd have to disregard all features related to it (members, watchers, workboards, archiving, edit permissions, change feeds, ..).

Because if you'd archive v2.0 when Project A's v2.0 is finished, that says nothing about a Project B still at v1.9 that will have a v2.0 next year. (e.g. like Firefox 30 and Chrome 30, you'd have to abandon all features related to individual projects and treat them as individual-meaningless correlation keywords instead).

That seems like a big waste and compromise in overall usability of Phabricator (the link on task pages to e.g. [1.24 release](https://phabricator.wikimedia.org/tag/1.24-release/) would only be confusing for users as it'd provide a meaningless feed of unrelated projects). All only to try and gain what? Smaller number of projects overall?

I'm not saying we should have separate version milestones for MediaWiki Core and MediaWiki extensions that follow the same release versioning. It makes perfect same to share one "MW 1.25 release" between those and use "MediaWiki" as additional filter in searches when only interested in one project. (E.g. the Cite extension doesn't have its own release process, it just follows MediaWiki). But I'm talking about projects not directly following MediaWiki's release process. E.g. OOjs, VisualEditor, CDB, and all other projects we have.
I disagree as I do not see the problem of "clashing" once you can explicitly search for //MediaWiki core tasks only// with that generic milestone. So with the given arguments I currently don't (yet?) see a need to identify that the generic 1.25 milestone tag should specifically refer to MediaWiki releases only.
If there are other projects forced to adopt some pattern, I'm happy to get aware of these projects and discuss why `v1.2.3-release` is better for them instead of `1.2.3-release`.
>>! In T75916#959250, @Aklapper wrote:
> I'm afraid that I don't understand the last two comments and I need a more concrete example of an existing problem. (In short: if you don't want non-MediaWiki results in your search results, don't put non-MediaWiki projects into your search criteria. [..]

I'm sorry but this is rather frustrating. What don't you understand? This has got nothing to do with search results. I'll try and repeat myself one more time in verbose bullet points.

* All Phabricator projects share a common global namespace. They're not like nested directories. Associating umbrellla or parent projects does not change this (it'll always be `project/1.25-release`, it doesn't nest like `project/mediawiki/1.25-release`, the umbrella is just meta-data, not part of the identifier).
* A `1.2.3-release` pattern is too generic as it doesn't specify what project it is about and can't be adopted as Phabricator convention in general as it would clash with other projects. It assumes MediaWiki core it the only project we have. We have in fact about 100 others.
* Other projects are already forced to adopt a different pattern. Maybe they'll use a different generic pattern (arms racing for every variation you can think of). E.g. Project A might use `v1.2.3-release` (prefix "v"), Project B might use `Release 1.2.3` (the word "Release"), project C might use `ProjectC-v1.2.3`. All variations that either try to fight MediaWiki's version numbers or come up with their own non-generic pattern.
* Therefore, let's agree on a non-generic pattern to use for all projects (e.g. `ProductName-v1.2.3` seems sensible).
* Now use that for MediaWiki as well (keeping the old names as additional-hashtag aliases for back-compat).
>>! In T75916#959250, @Aklapper wrote:
> I'm afraid that I don't understand the last two comments and I need a more concrete example of an existing problem. (In short: if you don't want non-MediaWiki results in your search results, don't put non-MediaWiki projects into your search criteria. [..]

I'm sorry but this is rather frustrating. What don't you understand? This has got nothing to do with search results.I'll try and repeat myself one more time in verbose bullet points.

* All Phabricator projects share a common global namespace. They're not like nested directories. Associating umbrellla or parent projects does not change this (it'll always be `project/1.25-release`, it doesn't nest like `project/mediawiki/1.25-release`, the umbrella is just meta-data, not part of the identifier).
* A `1.2.3-release` pattern is too generic as it doesn't specify what project it is about and can't be adopted as Phabricator convention in general as it would clash with other projects. It assumes MediaWiki core it the only project we have. We have in fact about 100 others.
* Other projects are already forced to adopt a different pattern. Maybe they'll use a different generic pattern (arms racing for every variation you can think of). E.g. Project A might use `v1.2.3-release` (prefix "v"), Project B might use `Release 1.2.3` (the word "Release"), project C might use `ProjectC-v1.2.3`. All variations that either try to fight MediaWiki's version numbers or come up with their own non-generic pattern.
* Therefore, let's agree on a non-generic pattern to use for all projects (e.g. `ProductName-v1.2.3` seems sensible).
* Now use that for MediaWiki as well (keeping the old names as additional-hashtag aliases for back-compat).
>>! In T75916#959250, @Aklapper wrote:
> I'm afraid that I don't understand the last two comments and I need a more concrete example of an existing problem. (In short: if you don't want non-MediaWiki results in your search results, don't put non-MediaWiki projects into your search criteria. There's no forcing to needless variation as any project can request creating new projects, and there's no forcing to adopt prefixes as there are no prefixes currently.)
> 
> I'm closing this ticket as resolved. Which still allows adding followup comments.

I'm sorry but this is rather frustrating. What don't you understand? I'll try and repeat myself one more time in verbose bullet points.

* All Phabricator projects share a common global namespace. They're not like nested directories. Associating umbrellla or parent projects does not change this (it'll always be `project/1.25-release`, it doesn't nest like `project/mediawiki/1.25-release`, the umbrella is just meta-data, not part of the identifier).
* A `1.2.3-release` pattern is too generic as it doesn't specify what project it is about and can't be adopted as Phabricator convention in general as it would clash with other projects. It assumes MediaWiki core it the only project we have. We have in fact about 100 others.
* Other projects are already forced to adopt a different pattern. Maybe they'll use a different generic pattern (arms racing for every variation you can think of). E.g. Project A might use `v1.2.3-release` (prefix "v"), Project B might use `Release 1.2.3` (the word "Release"), project C might use `ProjectC-v1.2.3`. All variations that either try to fight MediaWiki's version numbers or come up with their own non-generic pattern.
* Therefore, let's agree on a non-generic pattern to use for all projects (e.g. `ProductName-v1.2.3` seems sensible).
* Now use that for MediaWiki as well (keeping the old names as additional-hashtag aliases for back-compat).
Ahh yeah, my problem can be solved by either doing `MediaWiki + version number` tags or doing `version number + not MediaWiki` tags (querying 'not in 'MediaWiki tag')

EDIT: after further comments, I would still support prefixing rather than multi-tagging
Ahh yeah, my problem can be solved by either doing `MediaWiki + version number` tags or doing `version number + not MediaWiki` tags (querying 'not in 'MediaWiki tag')
I'm afraid that I don't understand the last two comments and I need a more concrete example of an existing problem. (In short: if you don't want non-MediaWiki results in your search results, don't put non-MediaWiki projects into your search criteria. There's no forcing to needless variation as any project can request creating new projects, and there's no forcing to adopt prefixes as there are no prefixes currently.)

I'm closing this ticket as resolved. Which still allows adding followup comments.
But what about when there is a task/bug which involves one of these tags (targeting it for a particular release) and another piece of software/library/etc which is targeted too?
>>! In T75916#955248, @Aklapper wrote:
> It is not too generic once we've fixed T76942.

Association or hierarchy does not equal containment. Even when Phabricator supports parent project associations (umbrellas), they're still in a shared global namespace and are bound to clash with other software projects. Forcing projects other than MediaWiki them to either adopt needless variation (e.g. v123 instead of 123-release), or adopt the same kind of prefixes I'm proposing for MediaWiki release tags.
It is not too generic once we've fixed T76942.
>>! In T75916#952762, @Aklapper wrote:
> Urgh. So I wasn't aware that Phabricator doesn't support mentioning hash tags starting with a number. :(

Phabricator support aside, "1.24 release" is too generic. Let's rename them to include "MW" (or "MediaWiki")?
Urgh. So I wasn't aware that Phabricator doesn't support mentioning hash tags starting with a number. :(
However, when is that important? I'd expect people to edit the Projects when setting a milestone, not mention those exact milestone names in a comment instead.

Regarding an umbrella MediaWiki project, that's covered in T76942.

I've dropped the .x and .0 suffixes from those milestone projects still active. Active projects left are:
* 1.19-release
* 1.23-release
* 1.24-release
* 1.25-release
* In the list view: https://phabricator.wikimedia.org/project/query/all/?after=1

So from my point of view we are done here.
+1 to dropping the point release suffixes.
I also support dropping and also prefixing with MW as there's more than just mediawiki that might require versions at some point
I'd drop the suffixes indeed. And also rename to mention "MW" or "MediaWiki" (with old name as additional hash-tag for back-compat and redirect). This to be less generic, and also because Phabricator doesn't support mentioning hash tags starting with a number.
Left here: Drop the .x or .0 prefixes?
<tl;dr>: We now have [[ https://phabricator.wikimedia.org/project/query/active/?after=1 | four active "Target Milestone" release projects ]] in Phabricator left, regarding the MW core (and to some extend MW extensions) world:
* 1.19.x release
* 1.23.x release
* 1.24.0 release
* 1.25.0 release

------

Way too long version for transparency (had to write this down anyway as this stuff can get confusing if I don't concentrate):

I've archived the past projects #1.23.0_release , #1.22.x_release, #1.22.0_release, #1.21.x_release, #1.21.0_release, #1.20.x_release, #1.20.0_release, #1.19.0_release, #1.18.x_release, #1.18.0_release (which somehow don't get autolinked here, sigh).

In the meantime, @Legoktm had archived the  #MW_1.24_version and #MW_1.23_version projects (use for extensions before) and changed their (open and closed) tasks' TM projects to the generic TM projects #1.24.0_release ( we don't have a 1.24.x_release project) and #1.23.0_release (.0, which is archived now, but there were no open tasks anyway).

I archived #MW_1.22_version which was empty. In general the use of these target milestones in Bugzilla seems to have declined over the versions

I batch-edited those tasks having MW_1.99_version tags set to have 1.99.x_release tags now.

Then I archived #MW_1.19_version to #MW_1.21_version.
Happy for us to go ahead with this.
If we have a decision, I volunteer with the renaming itself. For some reason blocked tasks T75994 and T78140 bother me more than they should whenever I see them in backlogs.  :)
I also think that one MediaWiki 1.47 target milestone is better than two. While a minority knows which one should be used where, the majority get puzzled whenever find the double 1.47.

I'm for applying the single tag for a single version, and then deal with the problems retrieving the right information, i.e. by sharing a saved search somewhere public for "All MediaWiki core tasks tagged for 1.47".
>>! In T75916#808898, @Aklapper wrote:
>So "MediaWiki-1.47.0-release" and "MediaWiki-1.47.x-release" (literally, replace "47" by your favorite number though)?

Whether we should have only "MediaWiki-1.47", or "MediaWiki-1.47.0" and "MediaWiki-1.47.x", is a separate from this task. But, personally, I think we should only have "MediaWiki-1.47". These tags are milestones, release targets. Not the version a bug report relates to, or whether a fix should be backported. I always found the `.x` ones strange in the milestones for MediaWiki core when we used BugZilla.
>>! In T75916#793597, @Jdforrester-WMF wrote:
>>>! In T75916#792822, @Qgil wrote:
>>>>! In T75916#789084, @Jdforrester-WMF wrote: 
>>> Well, the union search of "MediaWiki" project &&
>> 
>> A problem being that "MediaWiki" (core) is not one project but a bunch of them. Not a problem for a saved search but not ideal for casual queries... Is this relevant?
> 
> Oh, I assumed that the MW team were going to fix this the way we have for VisualEditor, Parsoid, Multimedia… are they not?
> 

I'd really like us to tag every single MediaWiki core bug with a [MediaWiki] project. The various subprojects (-Database, -UnitTests, etc) would be generalized to not be MW-core specific.

So for a MediaWiki database bug you'd tag it with [MediaWiki] and [Database].

This would also allow us to do things like [CirrusSearch] [UnitTests].

But really this should be its own task.
I'm happy with this, for one. Let's do it.
> A problem being that "MediaWiki" (core) is not one project but a bunch of them. Not a problem for a saved search but not ideal for casual queries... Is this relevant?

Thanks for the better wording; that is the one single reason why I wrote "cross-pollution" here, as long as subprojects in https://secure.phabricator.com/T3670 aren't available...

If adding (currently) 30 projects (all those previous components of MediaWiki core in Bugzilla) to a search query to get only get MediaWiki core tasks with that milestone isn't considered a huge hassle (do it once for that target milestone, save the custom query for yourself or share the search query URL on some wikipage) I'm definitely in for making the naming scheme between extensions and core for target milestones consistent.

I assume we still want to distinguish "1.47.0" (which would cover potentially everything that was fixed in all those 1.46wmfXY versions and hence included in the 1.47.0 tarball) from "1.47.x" (to mark stuff that should be fixed or has been fixed in 1.27.x tarball releases //after// the initial 1.47.0 release and has required backporting from 1.48wmfXY branches or git master)?

So "MediaWiki-1.47.0-release" and "MediaWiki-1.47.x-release" (literally, replace "47" by your favorite number though)?
A venturous summary of this discussion could be:

* Valid Tags for past, present, and future MediaWiki releases: #MW-1.24.x, #MW-1.24.0, #MW-1.24.1...
* Valid Tags for past, present, and future MediaWiki weekly snapshots: WMF-deploy-2014-11-26-(1.25wmf10)...

These tags are equally applicable to core, extensions, and anything else.
>>! In T75916#787907, @Aklapper wrote:
> I'm not convinced to give those MediaWiki extensions Target Milestones the same name though as that would cross-pollute when searching in all those MediaWiki-* projects we have now so I' rather go with some "MW-1.24.x-series" or such. 

I think this is biased towards MediaWiki core. You'd need to create milestones for every extension, skin and other MediaWiki-related project that doesn't have its own release/versioning scheme. That seems like a waste. Using #MW_1.24_version (as we're already doing for extensions, one has to intersect with the relevant project) seems simple enough.

For projects with lots of sub projects (e.g. things formerly having their own BugZilla product, like MediaWiki core and VisualEditor) would use an umbrella project.

At the moment that involves manual double-tagging (though a triager would have queries to find untagged issues to clean up). But there's to be intent in upstream Phabricator to embrace umbrella projects as a native concept (e.g. projects being in a hierarchy where they're visible and queryable via their parents). – https://secure.phabricator.com/T3670
>>! In T75916#792822, @Qgil wrote:
>>>! In T75916#789084, @Jdforrester-WMF wrote: 
>> Well, the union search of "MediaWiki" project &&
> 
> A problem being that "MediaWiki" (core) is not one project but a bunch of them. Not a problem for a saved search but not ideal for casual queries... Is this relevant?

Oh, I assumed that the MW team were going to fix this the way we have for VisualEditor, Parsoid, Multimedia… are they not?

> What is clear is that the current cohabitation of #1.24.0-release and #mw_1.24_version is confusing. As a bug reporter or even as a casual extension developer, how am I supposed to know which one to use?

I agree we should fix this by only having one.

> PS: also, I wonder why #1.24.0_release or #1.24.0-release won't render a proper label.

Maybe projects' hashtags can't start with a number to get auto-linked?
>>! In T75916#789084, @Jdforrester-WMF wrote: 
> Well, the union search of "MediaWiki" project &&

A problem being that "MediaWiki" (core) is not one project but a bunch of them. Not a problem for a saved search but not ideal for casual queries... Is this relevant?

What is clear is that the current cohabitation of #1.24.0-release and #mw_1.24_version is confusing. As a bug reporter or even as a casual extension developer, how am I supposed to know which one to use?

PS: also, I wonder why #1.24.0_release or #1.24.0-release won't render a proper label.
>>! In T75916#789084, @Jdforrester-WMF wrote: 
> Well, the union search of "MediaWiki" project &&

A problem being that "MediaWiki" (core) is not one project but a bunch of them. Not a problem for a saved search but not ideal for casual queries... Is this relevant?

What is clear is that the current cohabitation of #1.24.0-release and #mw_1.24_version is confusing. As a bug reporter or even as a casual extension developer, how am I supposed to know which one to use?

PS: also, I wonder why #1.24.0_release or #1.24.0_release won't render a proper label.
>>! In T75916#787907, @Aklapper wrote:
> I strongly support renaming the generic MediaWiki Target Milestones.
> I'm not convinced to give those MediaWiki extensions Target Milestones the same name though as that would cross-pollute when searching in all those MediaWiki-* projects we have now so I' rather go with some "MW-1.24.x-series" or such. 
> There is also a small (maybe neglectable?) differentiation between "must fix in MW core for the 1.25.0 tarball release" vs. "should fix in this MW extension at some point in the branch corresponding to MW core 1.25.x releases".

Well, the union search of "MediaWiki" project && "MediaWiki-release-1.18" release tag won't contain any extension items (and v.v.) – is that not suitable? This is what we're doing with "WMF-deploy-2014-11-26_(MW1.25wmf10)".
> Individual MediaWiki extensions didn't have such a milestone, but we did have shared ones for extensions like "MW 1.18 version", "MW 1.14 version".
What was the purpose of those milestones? Where they for things that should be backported or for planning ("hope to get this done by then")?

@Aklapper: can you update the description of {T100} with the summary of what we did/planned (or point to a wiki page that describes it). That should probably be the place we work from to solve this issue.
I strongly support renaming the generic MediaWiki Target Milestones.
I'm not convinced to give those MediaWiki extensions Target Milestones the same name though as that would cross-pollute when searching in all those MediaWiki-* projects we have now so I' rather go with some "MW-1.24.x-series" or such. 
There is also a small (maybe neglectable?) differentiation between "must fix in MW core for the 1.25.0 tarball release" vs. "should fix in this MW extension at some point in the branch corresponding to MW core 1.25.x releases".
You say "release tags", I CC @greg and @Jdforrester-WMF.
(Starting today, I'm moving all the tasks related to new/renamed projects to #Project-Creators because the Phabricator backlog is getting really big)
We're scrapping tracking bugs

* All VE projects' descriptions should have "Reminder: All VisualEditor-related tasks should be tagged with #VisualEditor as well, for tracking, triage and management purposes." appended.
* All projects are regular (briefcase) type.

| Project | Description | Task it replaces
| #VisualEditor-Performance | Performance issues with #VisualEditor. | T51685 |
| #VisualEditor-CopyPaste | Copy paste issues with #VisualEditor. | T35105 |
| #VisualEditor-InterfaceLanguage | Multi-lingual interface (i18n, l10n, RTL) issues with #VisualEditor. | N/A |
| #VisualEditor-Links | Link editing in #VisualEditor (not #VisualEditor-MediaWiki specific). | N/A |
| #VisualEditor-Media | Media editing in #VisualEditor (not #VisualEditor-MediaWiki specific). | N/A |
| #VisualEditor-MediaWiki-Plugins | Performance issues with #VisualEditor. | T48803 |


Merge into existing projects:

| Tracker | Projects |
| T68083 | #VisualEditor, #VisualEditor-ContentEditable |
| T69690 | #VisualEditor, #VisualEditor-MediaWiki-Media |
| T67955 | #VisualEditor, #VisualEditor-EditingTools |
| T72372 | #VisualEditor, #VisualEditor-MediaWiki-Mobile, #Browser_Support_Google_Android |
| T49780 | #VisualEditor, #VisualEditor-EditingTools |
| T52781 | #VisualEditor, #VisualEditor-Initialisation |
| T54327 | #VisualEditor, #VisualEditor-Initialisation |
| T50789 | #VisualEditor, #VisualEditor-MediaWiki-Links |
| T55604 | #VisualEditor, #VisualEditor-MediaWiki-Templates |
| T53792 | #VisualEditor, #VisualEditor-ContentLanguage |
| T35126 | #VisualEditor, #VisualEditor-ContentLanguage |
| T35077 | #VisualEditor, #VisualEditor-ContentLanguage |
| T41596 | #VisualEditor, #VisualEditor-Tables |
| T39870 | #VisualEditor, #VisualEditor-MediaWiki-Media |
Now complete.
Errors: 

"Exception thrown by papaparse" load.php:161
"TypeError: document.getElementById(...) is null"

"Exception thrown by user callback" load.php:161
"TypeError: mw.log.warning is not a function"
Verified in Betalabs
Change 175862 merged by jenkins-bot:
Disable papaparse because it breaks everything

[[https://gerrit.wikimedia.org/r/175862]]
Change 175862 had a related patch set uploaded (by Catrope):
Disable papaparse because it breaks everything

[[https://gerrit.wikimedia.org/r/175862]]

#patch-for-review
my bot found maiwiki at meta_p and tried to start running queries, but this fails.

name value must be 'Wikipedia' but name is currently a char sequenze repeating hex E0A4B5
```
MariaDB [(none)]> select *, hex(name) from meta_p.wiki where dbname like 'mai%';
+---------+------+------------+-----------+--------------------------+------+-----------+-----------+----------+-----------------+------------------+--------------+--------------------------------------------------------------+
| dbname  | lang | name       | family    | url                      | size | slice     | is_closed | has_echo | has_flaggedrevs | has_visualeditor | has_wikidata |                                                    hex(name) | 
+---------+------+------------+-----------+--------------------------+------+-----------+-----------+----------+-----------------+------------------+--------------+--------------------------------------------------------------+
| maiwiki | mai  | ?????????? | wikipedia | http://mai.wikipedia.org |    1 | s3.labsdb |         0 |        1 |               0 |                1 |            1 | E0A4B5E0A4BFE0A495E0A4BFE0A4AAE0A4BFE0A4A1E0A4BFE0A4AFE0A4BE |
+---------+------+------------+-----------+--------------------------+------+-----------+-----------+----------+-----------------+------------------+--------------+--------------------------------------------------------------+
1 row in set (0.00 sec)
```
maiwiki.labsdb missing in /etc/hosts
```
$ mysql -hmaiwiki.labsdb
ERROR 2005 (HY000): Unknown MySQL server host 'maiwiki.labsdb' (0)
```
The hosts files have been updated accross tools.
Ok, but the dns problem still exists:

```
tools.merlbot@tools-dev:~/lists/qs$ mysql -hmaiwiki.labsdb
ERROR 2005 (HY000): Unknown MySQL server host 'maiwiki.labsdb' (0)

```
The data of the meta table is mostly filled by the maintain-replicas script from API queries to the actual wiki proper; what I see when I query the table manually is 'विकिपिडिया' which is, as far as I can tell, the correct name for the project in that language.  The value in hexadecimal is also correct; it /appears/ to repeat itself because those are Unicode codepoints are on a high codepoint plane and the utf8 encoding has a long prefix for every character.  Notice:

E0A4**B5**E0A4**BF**E0A4**95**...

In other words, this works as designed.  You may want to use 'family' if you want to test for Wikipedia-ness rather than 'name' which is meant for display to endusers.  This is true even in European languages since, for example, frwiki would have 'Wikipédia' (note the accent) in the name column.
The data of the meta table is mostly filled by the maintain-replicas script from API queries to the actual wiki proper; what I see when I query the table manually is 'विकिपिडिया' which is, as far as I can tell, the correct name for the project in that language.  The value in hexadecimal is also correct; it /appears/ to repeat itself because those are Unicode codepoints are on a high codepoint plane and the utf8 encoding has a long prefix for every character.  Notice:

E0A4**B5**E0A4**BF**E0A4**95**...

In other words, this works as designed.  You may want to use 'family' if you want to test for Wikipedia-ness rather than 'name' which is meant for display to endusers.  This is true even in European languages since, for example, frwiki would have 'Wikipédia' (not the accent) in the name column.
1. Go to http://en.wikipedia.org/wiki/Barack_Obama as a logged-in user in Chrome
2. Open the inspector, go to the network panel, click the filter icon and select "XHR"
3. Click Edit beta
4. Observe lots of POST /w/api.php requests, one for each image

We should combine these requests rather than doing a separate one for each image.
Change 180228 merged by jenkins-bot:
Combine imageinfo requests

[[https://gerrit.wikimedia.org/r/180228]]
There are two Parsoid bug/feature requests that prevent us from eliminating the API calls:

1. We need the original dimensions and image type of the image. If Parsoid can give it to us in the data that will solve the issue.
2. Right now, Parsoid hard-codes the image default size to 220, which is the enwiki size default. That, however, is not the default of all wikis (and definitely not standalone) so we have to resize the image. This requires us to get the original dimensions and file type (since many resize rules depend on whether the image is bitmap or drawing) which leads to API requests.

If #1 is solved, we shouldn't need an API request on load for existing images.
I don't think that batching imageinfo requests goes quite far enough. I'd like to eliminate this API request from the critical path.

Let's assume that every image whose file name matches /\.svg/ is type=DRAWING type and that all other images are bitmaps. Although not guaranteed to be reliable, in practice this heuristic will almost always be correct. We should only attempt to validate our guess with an API request when the user attempts to resize the image. (This may mean that we have to scale the image back down after allowing the user to scale it up. Such cases should be exceedingly rare, however.)

The original dimensions of bitmap images should ideally be part of the paction=parse response from the API. We could also include them in the MediaWiki read HTML as data-* attributes. (This approach would take 30 days to propagate fully, but I think that's OK.)
Change 180228 had a related patch set uploaded (by Alex Monk):
[WIP] Combine imageinfo requests by setting up a new class like LinkCache to request them all centrally

[[https://gerrit.wikimedia.org/r/180228]]

#patch-for-review
Open up the wikitext editor and attempt to switch to VE. It no longer works. Clicking has no effect and you remain on the wikitext editor.

On Chrome and Firefox.

--------------------------
**Version**: unspecified
**Severity**: critical
Change 176052 merged by Catrope:
Followup 142a44e: fix path names to MobileContextItemWidget.{js,css}

[[https://gerrit.wikimedia.org/r/176052]]
Verified the fix in Betalabs and test2
Change 176052 had a related patch set uploaded (by Catrope):
Followup 142a44e: fix path names to MobileContextItemWidget.{js,css}

[[https://gerrit.wikimedia.org/r/176052]]

#patch-for-review
Still failing in wmf9, now because our fix used MobileContextOptionWidget instead of MobileContextItemWidget
Checked the fix in betalabs - switching between Editor and Edit source works.
Fixed in master; backport scheduled for this evening's SWAT.
**gerritadmin** wrote:

Change 174779 merged by jenkins-bot:
Follow-up I7eb0d0e: ve.ui.MobileContext.css doesn't exist any more, Toto

https://gerrit.wikimedia.org/r/174779
**gerritadmin** wrote:

Change 174779 had a related patch set uploaded by Jforrester:
Follow-up I7eb0d0e: ve.ui.MobileContext.css doesn't exist any more, Toto

https://gerrit.wikimedia.org/r/174779
Issue seems to be in VisualEditor
exception 'MWException' with message 'ResourceLoaderFileModule::readStyleFile: style file not found: "/srv/mediawiki/php-master/extensions/VisualEditor/lib/ve/src/ui/styles/ve.ui.MobileContext.css"' in /srv/mediawiki/php-master/includes/resourceloader/ResourceLoaderFileModule.php:902
Stack trace:

See http://bits.beta.wmflabs.org/en.wikipedia.beta.wmflabs.org/load.php?debug=false&lang=en&modules=ext.visualEditor.core.mobile%7Cext.visualEditor.mediawiki.mobile%7Cext.visualEditor.mobileViewTarget%7Cmobile.editor.ve&skin=minerva&version=20141120T011929Z&*
I'm investigating this. I know what's happening but not why.
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/AbulO05q
See e.g. https://fr.wikipedia.org/?diff=109114947

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix in test2.
Verified the fix in beta.
To go out in Monday's SWAT.
Change 173363 merged by jenkins-bot:
Restore original rowspan/colspan rather than normalizing or overwriting with NaN

https://gerrit.wikimedia.org/r/173363
It turned out there were two corruption problems: colspan="02" was normalized to colspan="2", and colspan="2 garbage" was normalized to colspan="NaN". The patch fixes both.
Change 173363 had a related patch set uploaded by Catrope:
Restore original rowspan/colspan rather than normalizing or overwriting with NaN

https://gerrit.wikimedia.org/r/173363
Betalabs and test2

In VE on Mac click Ctrl+1 which should insert Page Title - nothing happens. 

All other shortcuts - Ctrl+0,2-7 - work.


Ctrl+1 works in IE 11.

--------------------------
**Version**: unspecified
**Severity**: normal
**Platform**: Macintosh
So, it was actually set as one of your shortcuts as we have seen yesterday.Changing Status back to Resolved Invalid.
Ctrl+1 does not work in any of browsers on my Mac - Safari7, Chrome, and FF 38. 

And I did not see any shortcuts assigned to Ctrl+1 in my System preferences.
Works for me in Safari 8, Chrome 38 and Firefox 33. What browser were you using?
screenshot

Environment- beta

1> Select Insert -> Template 
2> In the resulting add a template dialog the button is labeled "Hide Options".See screenshot.

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F14839}
Checked in production.
Verified the fix in test2
Was a regression in wmf7, fix has been cherry-picked and deployed.
**gerritadmin** wrote:

Change 172329 merged by jenkins-bot:
Followup a86d824: fix reference to this in foreach callback

https://gerrit.wikimedia.org/r/172329
Verified the fix in betalabs.
**gerritadmin** wrote:

Change 172329 had a related patch set uploaded by Catrope:
Followup a86d824: fix reference to this in foreach callback

https://gerrit.wikimedia.org/r/172329
**gerritadmin** wrote:

Change 172320 merged by jenkins-bot:
Followup a86d824: fix reference to this in foreach callback

https://gerrit.wikimedia.org/r/172320
**gerritadmin** wrote:

Change 172320 had a related patch set uploaded by Catrope:
Followup a86d824: fix stupid stupid logic inversion

https://gerrit.wikimedia.org/r/172320
Good finding! 

It's in betalabs only. test2 and production display 'Show options' button.
If I open https://en.wikipedia.org/wiki/James_Braid_(surgeon)?veaction=edit in Chrome 38, the viewport initially jumps to the bottom of the page (the references list). If I press a cursor key, I'm back at the top. If I reload the page, the problem is not reproducible. Cannot reproduce in Firefox either.

--------------------------
**Version**: unspecified
**Severity**: normal
Verified in Chrome 38.
Scheduled for SWAT later today.
**gerritadmin** wrote:

Change 172983 merged by jenkins-bot:
Initialize context's $element as hidden

https://gerrit.wikimedia.org/r/172983
**gerritadmin** wrote:

Change 172983 had a related patch set uploaded by Esanders:
Initialize context's $element as hidden

https://gerrit.wikimedia.org/r/172983
Note that I am able to reproduce the incorrect scroll position in Chrome in a private browser window.
Chrome remembers a scroll position on the page - if a a content at the bottom of the page was viewed/edited, and Back/Forward buttons then were used, loading the same page again will display the last scroll position. 

So far, I could not see that anything was stored in cookies.
This is due to the fix applied in https://gerrit.wikimedia.org/r/#/c/170280/

--------------------------
**Version**: unspecified
**Severity**: normal
Verified in test2 and production.
Also fixed in test2 now.
Verified the fix in betalabs.
Change 172298 merged by jenkins-bot:
Fix craziness in template dialog focusing

https://gerrit.wikimedia.org/r/172298
Change 172298 had a related patch set uploaded by Jforrester:
Fix craziness in template dialog focusing

https://gerrit.wikimedia.org/r/172298
Change 171997 merged by jenkins-bot:
Fix craziness in template dialog focusing

https://gerrit.wikimedia.org/r/171997
Change 171997 had a related patch set uploaded by Catrope:
Fix craziness in template dialog focusing

https://gerrit.wikimedia.org/r/171997
When I click on the "Bin" icon to delete an empty parameter from a template, the system doesn't delete it.

--------------------------
**Version**: unspecified
**Severity**: major
Verified in production.
Confirmed, it works on itwiki (Chrome; VEctor; Win 8.1)
Verified in Betalabs and test2.
Fix was backported to wmf7 and deployed.
**gerritadmin** wrote:

Change 172446 merged by jenkins-bot:
Followup a054a75: don't reintroduce removed template parameters

https://gerrit.wikimedia.org/r/172446
**gerritadmin** wrote:

Change 172446 had a related patch set uploaded by Catrope:
Followup a054a75: don't reintroduce removed template parameters

https://gerrit.wikimedia.org/r/172446
**gerritadmin** wrote:

Change 172317 merged by jenkins-bot:
Followup a054a75: don't reintroduce removed template parameters

https://gerrit.wikimedia.org/r/172317
**gerritadmin** wrote:

Change 172317 had a related patch set uploaded by Catrope:
Followup a054a75: don't reintroduce removed template parameters

https://gerrit.wikimedia.org/r/172317
Did we break something when we re-wrote the template parameter fixing code last week?
Can confirm in Chrome and FF. What happens is that clicking on the bin makes the field disappear in the dialog, but when you save it's still in the template, as if you hadn't changed anything.
Could not confirm - tried both mentioned links - [https://it.wikipedia.org/wiki/Atletica_leggera_ai_Giochi_della_XXV_Olimpiade_-_100_metri_ostacoli] and[https://it.wikipedia.org/w/index.php?title=Utente%3ANnvu%2FSandbox1&diff=69043230&oldid=69043213] 
 any field(empty or not) can be deleted.
I got no error.
Ok, on both of those templates I was able to delete the missing fields while using Chrome on Ubuntu. 

You could try opening up the javascript console in Chrome (Ctrl+Shift+J) and seeing if any errors appear when you try to use the bin button.
I tried to delete the field on [https://it.wikipedia.org/wiki/Atletica_leggera_ai_Giochi_della_XXV_Olimpiade_-_100_metri_ostacoli this page] with Chrome and Firefox, but I couldn't delete any field. 

In [https://it.wikipedia.org/w/index.php?title=Utente%3ANnvu%2FSandbox1&diff=69043230&oldid=69043213 this edit] I tried to delete the field "successivo" (which is not a required field) and I couldn't delete it.
I'm unable to duplicate this on master. I tried emptying the field and then deleting it, which worked. I also tried adding an empty field in wikitext, saving, and then opening it up in VE. I was able to delete the parameter then too. 

Do you have any more details that might help us duplicate? Do you have a particular diff where this was happening?
Steps to reproduce:

1.Open any of the following dialog:
Basic Reference/Citation/Reference list/Page Settings

2.Start typing

Observe that , the text that you are typing is appearing on CE, as the cursor is active there instead of inside the dialog

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix in production
Verified the fix in test2
Verified the fix in test2
Fix was cherry-picked to wmf7 and deployed.
Verified the fix in Betalabs
**gerritadmin** wrote:

Change 171882 merged by jenkins-bot:
Remove and restore selection for non-isolated dialogs

https://gerrit.wikimedia.org/r/171882
**gerritadmin** wrote:

Change 171882 had a related patch set uploaded by Catrope:
Remove and restore selection for non-isolated dialogs

https://gerrit.wikimedia.org/r/171882
**gerritadmin** wrote:

Change 171852 merged by jenkins-bot:
Remove and restore selection for non-isolated dialogs

https://gerrit.wikimedia.org/r/171852
**gerritadmin** wrote:

Change 171852 had a related patch set uploaded by Esanders:
Remove and restore selection for non-isolated dialogs

https://gerrit.wikimedia.org/r/171852
This is still happening for all other dialogs(Page Settings,References List,Citation) except Basic Reference dialog in test2
Going out in 16:00 SWAT.
**gerritadmin** wrote:

Change 171757 merged by jenkins-bot:
Fix non-linear selection handling in ce.Surface#focus

https://gerrit.wikimedia.org/r/171757
**gerritadmin** wrote:

Change 171757 had a related patch set uploaded by Catrope:
Fix non-linear selection handling in ce.Surface#focus

https://gerrit.wikimedia.org/r/171757
**gerritadmin** wrote:

Change 171734 merged by jenkins-bot:
Fix non-linear selection handling in ce.Surface#focus

https://gerrit.wikimedia.org/r/171734
**gerritadmin** wrote:

Change 171734 had a related patch set uploaded by Catrope:
Fix non-linear selection handling in ce.Surface#focus

https://gerrit.wikimedia.org/r/171734
Dragging images to table

1. In VE insert a table(do not enter anything in the table).
2. Inser->Media-> select and insert any image outside the table.
3. Select the inserted image and drag it to the table - make sure that the insertion indication(an underscore) is displayed outside of the table,  on the right side. 

Drop the table  - the table becomes separated in two parts. The attached screenshot shows the result of several attempts of the described scenario

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

**Attached**: {F14885}
Verified the fix in production.
Confirmed in Betalabs and test2.
Bug 73318 was created about drag-and-drop block images issue.
(In reply to etonkovidova from comment #3)
> Created attachment 17066 [details]
> Dragging images to table
> 
> I added a screen recording  - kind of tricky to reproduce, however,
> something can be(or should be) done about the issue?

Ah, that's of block images; inline images now work fine.

I'm minded to say that we won't try to fix block images here; at least, let's put that into a different bug?

**Attached**: {F14887}
Created attachment 17066
Dragging images to table

I added a screen recording  - kind of tricky to reproduce, however, something can be(or should be) done about the issue?

**Attached**: {F14887}
Change 171271 merged by jenkins-bot:
Replace block drop logic with isAllowedChildNodeType check

https://gerrit.wikimedia.org/r/171271
Change 171271 had a related patch set uploaded by Esanders:
Replace block drop logic with isAllowedChildNodeType check

https://gerrit.wikimedia.org/r/171271
Steps to reproduce:

1.Select a text
2.Press command+k
3.When the link inspector opens , place the cursor inside the textbox which already has the selected text as link target name

Observed Result:
Link suggestions are not appearing after placing the cursor inside it.

Environment:Betalabs

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 171006 merged by jenkins-bot:
Populate LookupInputWidget on mousedown too

https://gerrit.wikimedia.org/r/171006
Change 171006 had a related patch set uploaded by Catrope:
Populate LookupInputWidget on mousedown too

https://gerrit.wikimedia.org/r/171006
Steps:
1. In Firefox, enable "Preferences > Advanced > General > Browsing > Check my spelling as I type"
2. On an empty line (slug), write "occurence"
3. Observe wiggly red line; right click and change it to "occurrence"
4. Observe explosion

Possibly a unicorning issue?


Working steps:

1. On an empty line (slug), write "Foo occurence" or "occurence bar"
2. Observe wiggly red line; right click and change it to "occurrence"
3. Observe non-explosion

(i.e., it works fine if there's any other content in the content node)

--------------------------
**Version**: unspecified
**Severity**: normal
Re-checcked (Mac FF 34.0.5)

- production
- test2
- betalbs

The issue is not presented anymore.  Closing the bug as Resolved.
Cannot reproduce on https://cs.wikipedia.org/wiki/Wikipedista:AKlapper_%28WMF%29/Sandbox?veaction=edit with Firefox 35 on Fedora 21, given the steps above. 
Only one insertion/string replacement (as expected); no output in browser console.

Is this still an issue? If so, which FF version on which platform?
This sounds similar to T65462 in Chrome, which has insertions, deletions, and corruptions.
See https://fr.wikipedia.org/w/index.php?title=Univers_cin%C3%A9matographique_Marvel&curid=5796605&diff=108676945&oldid=108668984 for a particularly bad sequence of nowikis.

We should examine this and NicoV's suggestions below and see what is realistic / feasible. But, at least a couple of back-to-back nowikis should be avoidable.

NicoV says (on https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=631914857#Unnecessary_succession_of_nowiki)

-----
    There are 4 sets of nowiki tags:

        The first one is a combination of an opening tag and a closing tag <nowiki>...</nowiki>.
        The second one is a self-closing nowiki tag <nowiki/> (just after the previous set) : it's totally useless, and brings nothing except more complexity to the wikitext
        The third one is a self-closing nowiki tag <nowiki/> (just before the next set) : same remark as above
        The fourth one is a combination of an opening tag and a closing tag <nowiki>...</nowiki>.

    My report is that 2 sets are completely useless (first and second are redundant; third and fourth are redundant).
    Of course, there's also the problem reported many times, a long time ago, that if nowiki are added they should be added only around the part that needs them not around a whole part of a sentence, but it was not the main issue I was reporting. For this, as it already been said so many times, my preferred methods (in order):

        Use {{'}} (it should be possible to configure VE on each wiki to know if there's such a template, that's what I'm doing for example in WPCleaner's configuration)
        Use '<nowiki/>'' (nowiki between the single quote and the italic formatting)
        Use <nowiki>'</nowiki>'' (nowiki around the single quote)
-----

--------------------------
**Version**: unspecified
**Severity**: normal
A whole bunch of fixes landed in production yesterday which should improve this situation.
I may not be able to get this done quickly enough -- I have an updated version up now, which eliminates the excess nowikis in this example by consolidating all heuristics in once place, but it might require more smarts. In this new version, it will insert a <nowiki/> whenever it sees a quote-char as the preceding/next sibling or first/last child of a I/B element in the DOM. That said, because of selective serializer, this might only kick in when new quotes are needed in those positions.

Still have to figure out some improvements to the heuristics .. but given the context-sensitive nature of quote-parsing where stuff at the end of line can change parse behavior earlier in the line, these might be elusive. 

I am going to be travelling and so cannot get to this again before next week.
**gerritadmin** wrote:

Change 171154 had a related patch set uploaded by Subramanya Sastry:
WIP: (Bug 72844): Fixes to quote nowiki protection in selser mode.

https://gerrit.wikimedia.org/r/171154
This seems to be selser-specific.

This below is what selser generates:
[subbu@earth lib] node parse --selser --html2wt --oldtextfile /tmp/quote.wt --oldhtmlfile /tmp/old.html < /tmp/new.html
*<nowiki> MARVEL Studios et ABC prépare cinq séries '</nowiki><nowiki/>''Netflix Original''<nowiki/><nowiki>'de </nowiki>[[Film de super-héros|super-héros]] pour [[Netflix]]. La diffusion de ces séries s'étalera sur plusieurs années : ''[[Daredevil (série télévisée)|Daredevil]]'' sera la première, puis ''Jessica Jones'', ''Iron Fist'' et enfin ''Luke Cage''.

This below is what the full serializer generates:
[subbu@earth lib] node parse --html2wt < /tmp/new.html
* MARVEL Studios et ABC prépare cinq séries '<nowiki/>''Netflix Original''<nowiki/>'de [[Film de super-héros|super-héros]] pour [[Netflix]]. La diffusion de ces séries s'étalera sur plusieurs années : ''[[Daredevil (série télévisée)|Daredevil]]'' sera la première, puis ''Jessica Jones'', ''Iron Fist'' et enfin ''Luke Cage''.
Page settings box opacity issue

found in test2 and betalabs

Steps to reproduce: 

1. In VE - click on Page options icon. 
2. Select Page settings->click in the check box 'Redirect this page to'
3. Start typing 'Something' (no quotes)
4. At some point of typing(or after you type 'Something' and then start to delete it a letter by letter) - a drop-down list of suggestions appears partially displaying underlying options for 'Show the Table of Contents' options. Look at the attached screenshot.

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

**Attached**: {F15193}
Verified in production.
Verified the fix in betalabs and test2.
**gerritadmin** wrote:

Change 170508 merged by jenkins-bot:
Pass $overlay to redirectTargetInput in MWSettingsPage

https://gerrit.wikimedia.org/r/170508
**gerritadmin** wrote:

Change 170508 had a related patch set uploaded by Alex Monk:
Pass $overlay to redirectTargetInput in MWSettingsPage

https://gerrit.wikimedia.org/r/170508
screenshot

(On beta.wmflabs) I had a very hard time finding the table editing menus for Merge cell. I knew they were available, but assumed they would be part of the normal attached-to-the-table menu system.

I also didn't notice the "Content cell" menu appear until it was pointed out to me.

I think it would be more intuitive, to put those controls next to the elements I'm changing, as shown in the mockups at https://www.mediawiki.org/wiki/VisualEditor/Design/Table_editor#Version_2

--------------------------
**Version**: unspecified
**Severity**: enhancement

**Attached**: {F14988}
{F17789}

{F17790}

Designs for including a menu in context.
Yeah, I agree. Over-riding the formatting menu is clever but entirely non-obvious, and completely breaks the VE design rule about only disabling, not changing, controls between contexts.
See e.g. the table in section 0 of the link.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://en.wikipedia.beta.wmflabs.org/wiki/User:Jdforrester_(WMF)/Sandbox?veaction=edit
Verified in production.
Verified the fix in betalabs and test2(FF, Safari, Chrome).
Thanks!
1. Open VE on a page that contains a focusable node
2. Click out of the surface so it's blurred and the toolbar tools are greyed out (selection is a ve.dm.NullSelection)
3. Try to select a focusable node by clicking on it
4. Nothing happens
5. Click to drop the cursor in some normal text
6. Repeat #3, observe that it works now

This also causes bug 72719: double-clicking focusable nodes fires their double-click handler and opens the associated dialog, but the selection is still null, so the dialogs don't open with the right context.

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix in test2 and production (en.wiki)
Change 170370 merged by jenkins-bot:
Fix selection transitions between FocusableNodes and non-linear selections

https://gerrit.wikimedia.org/r/170370
Change 170371 merged by jenkins-bot:
Fix selection transitions between FocusableNodes and non-linear selections

https://gerrit.wikimedia.org/r/170371
Change 170371 had a related patch set uploaded by Catrope:
Fix selection transitions between FocusableNodes and non-linear selections

https://gerrit.wikimedia.org/r/170371
Change 170370 had a related patch set uploaded by Catrope:
Fix selection transitions between FocusableNodes and non-linear selections

https://gerrit.wikimedia.org/r/170370
Verified the fix in Betalabs
Change 169966 merged by jenkins-bot:
Fix selection transitions between FocusableNodes and non-linear selections

https://gerrit.wikimedia.org/r/169966
Change 169966 had a related patch set uploaded by Catrope:
Fix selection transitions between FocusableNodes and non-linear selections

https://gerrit.wikimedia.org/r/169966
Screenshot

There is an extra space appearing at the top of the toolbar inside VE

See the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F14781}
Verified the fix in production
Verified the fix in Betalabs and test2
**gerritadmin** wrote:

Change 169861 merged by jenkins-bot:
Hide page status indicators even if they aren't :visible

https://gerrit.wikimedia.org/r/169861
**gerritadmin** wrote:

Change 169860 merged by jenkins-bot:
Hide page status indicators even if they aren't :visible

https://gerrit.wikimedia.org/r/169860
**gerritadmin** wrote:

Change 169861 had a related patch set uploaded by Jforrester:
Hide page status indicators even if they aren't :visible

https://gerrit.wikimedia.org/r/169861
**gerritadmin** wrote:

Change 169860 had a related patch set uploaded by Bartosz Dziewoński:
Hide page status indicators even if they aren't :visible

https://gerrit.wikimedia.org/r/169860
(In reply to Bartosz Dziewoński from comment #2)
> Butbutbut wasn't that supposed to be fixed with c81ed82f?

Apparently it didn't work.
Butbutbut wasn't that supposed to be fixed with c81ed82f?
This is because of the mw-indicators div. It's empty if there are no indicators, but the fact that it floats right and the VE toolbar then has clear: both; seems to make it take up space somehow.

Even if an empty indicators div doesn't take up space: if there are indicators, where do we put them in VE mode?
Reproduce:

1. go to https://fi.wikipedia.org/wiki/User:Stryn/VE?veaction=edit
2. highlight all texts from the end of "This is just a test.[1]" to end of "Visuaalinen muokkain.[2]" and press backspace button or delete or whatever and nothing happens - VE just gets stuck.
3. you can't save the page nor switch to wikitext editor even if you have made changes to the page.

If you highlight text from "This is just a test.[1]" to "This is not." it's working as it should. So probably the problem is with the references.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=72640
Confirmed in test2 and on https://fi.wikipedia.org/wiki/User:Stryn/VE?veaction=edit.

On the page https://fi.wikipedia.org...  - there are many Uncaught Error: ve.dm.Document.getBranchNodeFromOffset(): offset 39 is out of bounds etc.


In test2: type four lines of text on four separate lines.

- Add reference to the end of the first line
- add another reference to the end of the second line
- leave the third line as it is
- re-use the first reference and add it to the end of the fourth line


Start highlighting the text and try to delete it with 'Delete' button. 
FF displays: 
Error: Unbalanced set of replace operations found load.php:316
TypeError: currentNode.children[(nao.offset - 1)] is undefined load.php:479
Error: Unbalanced input passed to document.

After several attempts of highlighting and deleting - the page becomes unresponsive - I can place cursor but cannot move it with arrow or Enter buttons; cannot Save, cannot switch to Read mode(TypeError: data[i] is undefined).
screenshot of the console error

Environment- test2,production,beta

1>In a blank page, open the link inspector,type in some text in the link input box and keep the inspector open.
2> While the inspector is open ,click on to add a bullet/numbered list.
3> JS  console error “Uncaught Error: offset -1 out of bounds” and the inspector remains open.See screenshot.

Clicking on Done or Remove does not close the inspector.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=72494

**Attached**: {F15103}
Verified in production.
Verified the fix in betalbs and test2.
Change 170855 merged by jenkins-bot:
Protect against offset=-1 in insertContent()

https://gerrit.wikimedia.org/r/170855
Change 170855 had a related patch set uploaded by Catrope:
Protect against offset=-1 in insertContent()

https://gerrit.wikimedia.org/r/170855
I don't seem to be able to trigger the warning with anything on any production wiki today.

--------------------------
**Version**: unspecified
**Severity**: normal
Verified in production, betalabs, and test2.
Change 168620 merged by jenkins-bot:
Fix wikitext warning: Get range from selection before trying to find start

https://gerrit.wikimedia.org/r/168620
Change 168619 merged by jenkins-bot:
Fix wikitext warning: Get range from selection before trying to find start

https://gerrit.wikimedia.org/r/168619
Change 168620 had a related patch set uploaded by Catrope:
Fix wikitext warning: Get range from selection before trying to find start

https://gerrit.wikimedia.org/r/168620
Change 168608 merged by jenkins-bot:
Fix wikitext warning: Get range from selection before trying to find start

https://gerrit.wikimedia.org/r/168608
Change 168619 had a related patch set uploaded by Catrope:
Fix wikitext warning: Get range from selection before trying to find start

https://gerrit.wikimedia.org/r/168619
Change 168608 had a related patch set uploaded by Alex Monk:
Fix wikitext warning: Get range from selection before trying to find start

https://gerrit.wikimedia.org/r/168608
Firefox with the wrong box

Steps to reproduce:

1.  Open [[William Shakespeare]] in VisualEditor. 

2.  Scroll to the ==References== section and select the contents (a complex transclusion).

3.  Try to open it so you can edit it.


This hangs in Firefox 32 with this error message:

Warning:  Unresponsive script

A script on this page may be busy, or it may have stopped responding. You can stop the script now, open the script in the debugger, or let the script continue.

Script: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141016T200718Z:89


It opens correctly (but slowly) in Chrome and Safari, and sometimes in Firefox, too.  When it fails to open correctly, then it displays the contents in the wrong dialog box (see attachment).

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

**Attached**: {F15370}
Is this the same problem as {T71799}?
Right now we have a hack in ve.test.utils.js that reregisters the core versions of HeadingNode and PreformattedNode to ensure MWHeadingNode and MWPreformattedNode aren't used, because using them would break the VE core tests when run in VE-MW.

This is horrible, because it makes us unable to test specific behavior in the MW nodes. For instance, https://gerrit.wikimedia.org/r/#/c/162310/3 fails its own tests because those tests use HeadingNode rather than MWHeadingNode, even though the tests in question were clearly designed to use MWHeadingNode.

We should come up with a way that MW nodes can be not registered for code tests, but be registered for MW tests.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 191036 merged by jenkins-bot:
Add tests for MW node variants (heading/table/pre)

[[https://gerrit.wikimedia.org/r/191036]]
Change 191036 had a related patch set uploaded (by Esanders):
Add tests for MW node variants (heading/table/pre)

[[https://gerrit.wikimedia.org/r/191036]]

#patch-for-review
IE11 test2 and betalabs

Steps to reproduce: 

1. Open VE-> try to insert a link(via a shortcut or by clicking on the option) - the box(class="oo-ui-window-isolated oo-ui-ltr" ) shows up and disappears momentarily.

2. Editing links - presents the same problem 

Debugger complains about load.php "Unable to get property 'from' of undefined or null reference' rangeSelection is undefined.

--------------------------
**Version**: unspecified
**Severity**: major
The previous comment was filed as a separate bug: 73154

Besides bug 73154 - the fix re-verified in betalbs/test2/en wiki.
IE11: Using a shortcut Ctrl+K to insert a link consistently gives the following message twice :

DOM7009: Unable to decode image at URL: 'data:image/gif;base64,R0lGODdhAQABAADcACwAAAAAAQABAAA'.  File: gif;base64,R0lGODdhAQABAADcACwAAAAAAQABAAA
Verified in test2 and production(en.wikipedia.org)

- inserting a link with a menu option - OK
- editing an existing link wiht a menu option - OK
- insert a link with the shortcut - Ctrl+K - the link inspector opens and closes momentarily
**gerritadmin** wrote:

Change 169228 merged by jenkins-bot:
Make link inspector not close itself in IE... again

https://gerrit.wikimedia.org/r/169228
**gerritadmin** wrote:

Change 169228 had a related patch set uploaded by Catrope:
Make link inspector not close itself in IE... again

https://gerrit.wikimedia.org/r/169228
**gerritadmin** wrote:

Change 169224 merged by jenkins-bot:
Make link inspector not close itself in IE... again

https://gerrit.wikimedia.org/r/169224
**gerritadmin** wrote:

Change 169221 merged by jenkins-bot:
Make link inspector not close itself in IE... again

https://gerrit.wikimedia.org/r/169221
**gerritadmin** wrote:

Change 169224 had a related patch set uploaded by Jforrester:
Make link inspector not close itself in IE... again

https://gerrit.wikimedia.org/r/169224
**gerritadmin** wrote:

Change 169221 had a related patch set uploaded by Catrope:
Make link inspector not close itself in IE. Again.

https://gerrit.wikimedia.org/r/169221
Affecting IE10 as well, as per fi.wp report.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Template
3.Select any template
4.Click on "Show Options"


Observed Result:
There is no advanced option showing up on the left panel.

See the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F15057}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
**gerritadmin** wrote:

Change 167973 merged by jenkins-bot:
GridLayout: Set dimensions.visibility = '' again if we have a height and a width

https://gerrit.wikimedia.org/r/167973
**gerritadmin** wrote:

Change 167973 had a related patch set uploaded by Alex Monk:
GridLayout: Set dimensions.visibility = '' again if we have a height and a width

https://gerrit.wikimedia.org/r/167973
Caused by Gerrit change 166191
Steps to reproduce:

1.  Open a page and go to Page options > Categories.

2.  (Add a category if none exist.)  Edit a category to add a sort key.

3.  Save page.

4.  Check diff:  no sort key was added.  :-(  


Confirmed in Firefox 32 and Safari 6.2 on Macs and Windows, so it's probably happening everywhere.

This doesn't seem to be bug 48555.

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified in betalabs, test2, and wikimedia - e.g. a Category gets added as [[Category:Cat2|Sort_added]]
Change 167876 merged by jenkins-bot:
CategoryPopupWidget: Track popup hiding again so sortkey changes are applied

https://gerrit.wikimedia.org/r/167876
Change 167877 merged by jenkins-bot:
PopupWidget: Remove references to 'show' and 'hide' events

https://gerrit.wikimedia.org/r/167877
Change 167877 had a related patch set uploaded by Alex Monk:
PopupWidget: Remove references to 'show' and 'hide' events

https://gerrit.wikimedia.org/r/167877
Change 167876 had a related patch set uploaded by Alex Monk:
CategoryPopupWidget: Track popup hiding again so sortkey changes are applied

https://gerrit.wikimedia.org/r/167876
Steps to reproduce:

1.  Open a page in Firefox (my version is 32).

2.  Select some text.

3.  Press Ctrl-X or Command-X.

4.  Notice that nothing happened.


Paste (Ctrl-V) might be working intermittently, but you have to copy rather than cut the text to do that.

--------------------------
**Version**: unspecified
**Severity**: major
Re-verified in Chrome, FF, IE11, and Safari - cut/copy/paste look fine.
(In reply to etonkovidova from comment #8)
> Safari(1.25wmf6 (295d963) - when text is pasted, the page scrolls up
> momentarily. Otherwise, cut/paste seems to be working correctly in
> Safari(wmf6).
> 
> FF and Chrome do not display this "scroll-up" behavior

This is bug 71728.
Safari(1.25wmf6 (295d963) - when text is pasted, the page scrolls up momentarily. Otherwise, cut/paste seems to be working correctly in Safari(wmf6).

FF and Chrome do not display this "scroll-up" behavior
In case this needs to be re-opened in the futre:  

I can't cut text in Safari today.  I'm going to assume that this is fixed in the next release, because it happens at en.wp but not at Beta Labs or MediaWiki.org  Consequently, this Firefox-specific bug might not actually be Firefox-specific.
Safari does not handle Paste smoothly - when some text is pasted, the page swiftly(but noticeably) scrolls to the top and back to the place when the text is pasted.
Confirmed - the issue is fixed in test2 (wmf5).
Confirmed the fix(es) on Betalabs.
(In reply to Ed Sanders from comment #2)
> Fixed after various copy/paste related patches
> https://gerrit.wikimedia.org/r/#/q/status:merged+project:VisualEditor/
> VisualEditor+branch:master+topic:copy-fix,n,z
> 
> Works on beta labs, but apparently hasn't been deployed yet. Wasn't this
> supposed to be backported?

Backports due on Monday morning.
Fixed after various copy/paste related patches https://gerrit.wikimedia.org/r/#/q/status:merged+project:VisualEditor/VisualEditor+branch:master+topic:copy-fix,n,z

Works on beta labs, but apparently hasn't been deployed yet. Wasn't this supposed to be backported?
This is a serious issue. I actually managed to get the program to start deleting whole sections of text with this bug.

Steps to reproduce: 
1. Select some text
2. Ctrl-x
3. Ctrl-v at a different location. The cursor should (shouldn't, but it does) go to the top of the page, above everything else.
4. Right-click at a different location and click "paste". Should (n't) have pasted the text at the top of the page.
6. Select this stray text, right click, and press delete (use the mouse, not keyboard).
7. Watch the article get randomly deleted in completely unpredictable ways.

I tried this on multiple articles and got wacky behaviour both times. Browser: Firefox 33.0.
Start a selection inside a link and drag to outside it. The context menu never disappears.

--------------------------
**Version**: unspecified
**Severity**: normal
**gerritadmin** wrote:

Change 167217 merged by jenkins-bot:
Fix contextChange events from annotations

https://gerrit.wikimedia.org/r/167217
**gerritadmin** wrote:

Change 167217 had a related patch set uploaded by Jforrester:
Fix contextChange events from annotations

https://gerrit.wikimedia.org/r/167217
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Open Cite>Book or Cite>Journal
3.Place the cursor inside the Title field

Observed Result:

A weird red border is surrounding the textfield instead of light blue highlight

See the screenshot attached.

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

**Attached**: {F15258}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
**gerritadmin** wrote:

Change 167334 merged by jenkins-bot:
Only validate required template params after blur

https://gerrit.wikimedia.org/r/167334
**gerritadmin** wrote:

Change 167334 had a related patch set uploaded by Jforrester:
Only validate required template params after blur

https://gerrit.wikimedia.org/r/167334
**gerritadmin** wrote:

Change 167226 merged by jenkins-bot:
Only validate required template params after blur

https://gerrit.wikimedia.org/r/167226
**gerritadmin** wrote:

Change 167226 had a related patch set uploaded by Alex Monk:
Only validate required template params after blur

https://gerrit.wikimedia.org/r/167226
Looks like a regression from the "highlight invalid text inputs" change.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert a bullet or numbered list
3.Keep on adding indentation to the list to create slugs
4.Place your cursor inside the slug to add an item to the list
Observed Result:
It throws error in the console:TypeError: Cannot read property 'getSelection' of null

See the screenshot attached

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

**Attached**: {F15252}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
**gerritadmin** wrote:

Change 166884 merged by jenkins-bot:
Followup 2432cbf: add recursion guard to updateSlug

https://gerrit.wikimedia.org/r/166884
**gerritadmin** wrote:

Change 166884 had a related patch set uploaded by Catrope:
Followup 2432cbf: add recursion guard to updateSlug

https://gerrit.wikimedia.org/r/166884
Rephrasing the bug its not only for slugs created from the list but rather a generic issue for all kind of slugs.It happens if you place your cursor in a slug and then place your cursor anywhere in the page which follows the slug.
If you place your cursor somehwere above the slug , you wont get the error.
Sorry for the noise, but after all the nagging I also wanted to thank for this great improvement. I can now easily run the QUnit tests headlessly without having to clone `integration/jenkins`, it supports two browsers we actually support, and it's so fast: Down from 33 seconds to 18 seconds in Chromium and 23 seconds in Firefox. Awesome!
More issues I had when running `grunt karma:main` locally:

* I had to pass `MW_SERVER` and `MW_SCRIPT_PATH` (which makes sense), but it's a) not documented anywhere and b) the error message is not helpful at all.
* In `karma-qunit` (`lib/adapter.js`), `QUnit.load` and `QUnit.start` are executed (which is fine), and they try to set `QUnit.config.autostart` to `false`, but that doesn't work somehow in my setup. Instead, `QUnit.config.autostart` is `undefined` right before `QUnit.load` is called, and thus QUnit fails on trying to `start()` twice. I had to patch it locally to set `autostart` to `false` directly before calling `load`.
The reported number of tests ran differs widely between running QUnit manually in the browser and running it via Karma. For example, [some recent mediawiki-core-qunit run](https://integration.wikimedia.org/ci/job/mediawiki-core-qunit/38693/console) reports `Executed 259 of 259`, while [this run from last Thursday](https://integration.wikimedia.org/ci/job/mediawiki-core-qunit/38575/console) said `1576 assertions passed`. I suppose `karma-qunit` counts tests, while `Special:JavaScriptTest/qunit` counts assertions? Even if that is the explanation, it should be mentioned somewhere.
Change 198293 merged by jenkins-bot:
mwext-{name}-qunit: To hhvm/karma/chromium from zend/php53/phantomjs

[[https://gerrit.wikimedia.org/r/198293]]
Change 198293 had a related patch set uploaded (by Krinkle):
mwext-{name}-qunit: To hhvm/karma/chromium from zend/php53/phantomjs

[[https://gerrit.wikimedia.org/r/198293]]
Change 198257 merged by jenkins-bot:
mwext-VisualEditor-qunit: To trusty/karma/chromium from precise/phantomjs

[[https://gerrit.wikimedia.org/r/198257]]
Change 198257 had a related patch set uploaded (by Krinkle):
mwext-VisualEditor-qunit: To trusty/karma/chromium from precise/phantomjs

[[https://gerrit.wikimedia.org/r/198257]]
Change 198210 merged by jenkins-bot:
mediawiki-core-qunit: To trusty/hhvm/mysql/chrome from precise/zend/sqlite/phantomjs

[[https://gerrit.wikimedia.org/r/198210]]
Change 198210 had a related patch set uploaded (by Krinkle):
Update mwcore-qunit to trusty/hhvm/mysql/chrome from precise/zend/sqlite/phantomjs

[[https://gerrit.wikimedia.org/r/198210]]
Change 186934 merged by jenkins-bot:
Add qunit-karma macro and various *-qunit-karma jobs

[[https://gerrit.wikimedia.org/r/186934]]
Change 187638 merged by jenkins-bot:
mediawiki-core-qunit: Migrate to simplified mw-set-env-qunit.sh

[[https://gerrit.wikimedia.org/r/187638]]
First passing build using local Karma and Chromium!
https://integration.wikimedia.org/ci/job/mediawiki-core-qunit-karma/5/console
Change 186934 had a related patch set uploaded (by Krinkle):
[WIP] Add qunit-karma macro and mediawiki-core-qunit-karma job

[[https://gerrit.wikimedia.org/r/186934]]

#patch-for-review
Change 187638 had a related patch set uploaded (by Krinkle):
mediawiki-core-qunit: Migrate to simplified mw-set-env-qunit.sh

[[https://gerrit.wikimedia.org/r/187638]]

#patch-for-review
Change 173512 merged by coren:
contint: Add tmpfs mount in jenkins-deploy homedir for labs slaves

[[https://gerrit.wikimedia.org/r/173512]]
Change 178551 merged by jenkins-bot:
SpecialJavaScriptTest: Add export feature

[[https://gerrit.wikimedia.org/r/178551]]
Change 178551 had a related patch set uploaded (by Krinkle):
SpecialJavaScriptTest: Add export feature

[[https://gerrit.wikimedia.org/r/178551]]

#patch-for-review
Change 173529 merged by jenkins-bot:
Migrate mediawiki/qunit jobs from production slaves to labs

[[https://gerrit.wikimedia.org/r/173529]]
>>! In T74063#787333, @Krinkle wrote:
> Blocked on https://gerrit.wikimedia.org/r/#/c/175949/ which removes the test that was leaking jQuery animations.

This has been merged.

>>! In T74063#765974, gerritadmin wrote:
> 
> Change [173529](https://gerrit.wikimedia.org/r/173529) in `integration/config` by Krinkle:
>> Migrate mediawiki/qunit jobs from production slaves to labs
>>
>> Change-Id: I69c4d6db114e2960c76ac01c4b255b7fb7bf8962

This change has been deployed to Jenkins. The QUnit jobs now install MediaWiki on a labs slave and also run PhantomJS there.
Blocked on https://gerrit.wikimedia.org/r/#/c/175949/ which removes the test that was leaking jQuery animations.
Change 173529 had a related patch set uploaded by Krinkle:
Migrate mediawiki/qunit jobs from production slaves to labs

https://gerrit.wikimedia.org/r/173529
Tested a few in labs, and are now running fine. The compared runs in labs are an N+1 run since the first one involve zuul-cloner cloning mediawiki-core.

--

on gallium in 1m18s:
https://integration.wikimedia.org/ci/job/mwext-VisualEditor-qunit/12309/

on integration-slave1003 in 1m34s:
https://integration.wikimedia.org/ci/job/mwext-VisualEditor-qunit/12365/

--

on gallium in 1m23s:
https://integration.wikimedia.org/ci/job/mwext-VisualEditor-qunit/12362/

on integration-slave1003 in 1m31s:
https://integration.wikimedia.org/ci/job/mwext-VisualEditor-qunit/12366/

--

on gallium in 29s:
https://integration.wikimedia.org/ci/job/mediawiki-core-qunit/32092/

on integration-slave1003 in 32s:
https://integration.wikimedia.org/ci/job/mediawiki-core-qunit/32094/
The sqlite installer auto-detects presence of a tmpfs mount in $HOME via mw-set-env:

 https://github.com/wikimedia/integration-jenkins/blob/8abc7b6/bin/mw-set-env.sh#L19

I've mounted tmpfs drive in the $HOME of jenkins-deploy on the integration slaves

 https://gerrit.wikimedia.org/r/173511
 https://gerrit.wikimedia.org/r/173512
Change 173512 had a related patch set uploaded by Krinkle:
[WIP] contint: Add tmpfs mount in jenkins-deploy homedir for labs slaves

https://gerrit.wikimedia.org/r/173512
I've copied one of the qunit2 jobs to a static directory on integration-slave1008 and proxied it through ssh to my local Chrome to use Dev Tools to investigate the QUnit failures.

They are indeed timing out, on load.php requests. Some of which are taking over 12 seconds (the QUnit timeout for an individual test is 10 seconds, defined in our testrunner.js in mediawiki-core:/tests/qunit/data).

The main slowdown is the database layer. Increasing the timeout to 30 seconds made it work, but we don't want our tests to be that slow. I'll first try to match production speed more, and we could resort to increasing the timeout otherwise.

Will add a tmpfs to the integration slaves and make Jenkins use that when appropriate.
Step 1: Move qunit from prod/precise to labs/trusty.
Step 1a: Refactor puppet for localhost/qunit and apply to labs.
Step 1b: Refactor puppet for mediawiki testing and apply to labs (sqlite, php5-cli, imagemagic, etc.)
Step 2: Change integration/jenkins:bin/wmfgrunt to use Karma instead of Grunt-contrib-qunit/grunt-lib-phantomjs

localhost/qunit:
* https://gerrit.wikimedia.org/r/#/c/170792/
* https://gerrit.wikimedia.org/r/#/c/168630/
* https://gerrit.wikimedia.org/r/#/c/168631/

Looks like the qunit test doesn't pass in labs. Some seeminly-random API calls are failing.

https://integration.wikimedia.org/ci/job/mwext-VisualEditor-qunit2/6/console
Change 168631 had a related patch set uploaded by Krinkle:
[WIP] contint: Apply contint::qunit_localhost to labs slaves

https://gerrit.wikimedia.org/r/168631
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Add some categories
3.Try to open the context menu for it

Observed Result:
Observe that the context menu is appearing far towards left side of the dialog box and it is not closing when you navigate to other options.

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

**Attached**: {F15142}
*** Bug 71999 has been marked as a duplicate of this bug. ***
Verified the fix in production
Verified the fix in Betalabs and test2
**gerritadmin** wrote:

Change 166709 merged by jenkins-bot:
Put category popups in the inner overlay for now

https://gerrit.wikimedia.org/r/166709
SWATting in the morning.
**gerritadmin** wrote:

Change 166709 had a related patch set uploaded by Jforrester:
Put category popups in the inner overlay for now

https://gerrit.wikimedia.org/r/166709
**gerritadmin** wrote:

Change 166701 merged by jenkins-bot:
Put category popups in the inner overlay for now

https://gerrit.wikimedia.org/r/166701
**gerritadmin** wrote:

Change 166701 had a related patch set uploaded by Catrope:
Put category popups in the inner overlay for now

https://gerrit.wikimedia.org/r/166701
**gerritadmin** wrote:

Change 166279 had a related patch set uploaded by Catrope:
Correctly place CategoryPopupWidget in LTR and RTL

https://gerrit.wikimedia.org/r/166279
Steps to reproduce:

1.  Open a page containing the <references /> block (so you can see what happens as you change citations).

2.  Create a new citation or edit an existing one, using a citation template (e.g., Cite web) in the Cite menu.

3.  See a blank line displayed before and after the citation.  

This can be reproduced in Safari 6.2 and Firefox 32 on Mac OS 10.8.5.  It happens with Marielle's script for Citoid and with manually completed citation templates. cannot be reproduced by adding text to the Basic citation dialog (although it can be reproduced by using the Cite menu within the Basic citation dialog).

This is a display-only problem.  When the page is saved, everything is normal (e.g., https://en.wikipedia.org/w/index.php?diff=629488479&oldid=629487984).

--------------------------
**Version**: unspecified
**Severity**: minor
I can't reproduce this (any more?).
Is this caused by our recent changes to how references are evaluated?
Reported at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Irrelevant_tags , quoting below:

> Why would [this edit](http://en.wikipedia.org/w/index.php?title=M.R._Organisation_Limited&curid=44080416&diff=629153289&oldid=629153016) get tagged with copyright violation template removed and speedy deletion template removed if the edit did not remove the templates? Is this a bug in the tags system? The user used HHVM and VisualEditor, is this relevant? 109.79.177.119 09:43, 11 October 2014 (UTC)

(The page in question has unfortunately been deleted since, but the data is still there, just hidden.)

I did some quick investigating:

* If you review the page history a bit (which I managed to do before
  it was deleted), the two templates were indeed removed at a point
  (and that was correctly tagged) and then restored, with the next
  edit being tagged incorrectly.
* You can examine the logic that led to that edit being tagged at
  [[Special:AbuseFilter/examine/log/10945503]] – if you look at the
  row described as "Unified diff of changes made by edit", you can see
  that AbuseFilter really thinks these tags were removed in that edit
  (although they were not).

--------------------------
**URL**: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29/Archive_131#Irrelevant_tags
**See Also**:
* {T74329}
This bug has been fixed and the fix will be deployed to Wikimedia wikis this week, with MediaWiki version 1.27.0-wmf.21, per https://www.mediawiki.org/wiki/MediaWiki_1.27/Roadmap.
Change 282100 merged by jenkins-bot:
Avoid crippled APIEditBeforeSave hook, use new features of EditFilterMergedContent instead

[[https://gerrit.wikimedia.org/r/282100]]
This proved easier to fix than I expected thanks to @tstarling's wonderful work in 09a5febb7b024c0b6585141bb05cba13a642f3eb.
Change 282100 had a related patch set uploaded (by Bartosz Dziewoński):
Avoid crippled APIEditBeforeSave hook, use new features of EditFilterMergedContent instead

[[https://gerrit.wikimedia.org/r/282100]]
I suppose no one else is going to work on this.
> Any chance of a fix?

Any contributed patches are welcome to speed up progress here. 
See https://www.mediawiki.org/wiki/Developer_access and https://www.mediawiki.org/wiki/Gerrit/Tutorial for more information.
https://en.wikipedia.org/wiki/WP:Village_pump_%28technical%29?oldid=694005525#Edit_filter_problem
This came up on the English Wikipedia again this week. Any chance of a fix? It seems like a pretty big issue that we are sometimes tagging and disallowing entirely the wrong edits.
@He7d3r Hunm, well. At least the cause of this bug was identified, but the solutin does not seem to be simple...
As far as I can see, they are the same thing;
@He7d3r This bug is the cause of the problem related in  T100530, right?
From the duplicated bug:

>On
>https://pt.wikipedia.org/wiki/Special:AbuseLog?wpSearchUser=189.5.174.202&wpSearchFilter=1&wpSearchTitle=Lygia+Moura+Rassi&uselang=en
>we have two logs:
>>* 13:39, 27 May 2015: 189.5.174.202 (Talk | block) triggered filter 1, performing the action "edit" on Lygia Moura Rassi. >Actions taken: Tag; Filter description: Remoção de proposta de eliminação (details | examine | diff)
>>* 13:39, 27 May 2015: 189.5.174.202 (Talk | block) triggered filter 1, performing the action "edit" on Lygia Moura Rassi. Actions taken: Warn; Filter description: Remoção de proposta de eliminação (details | examine)
>
>For some reason AbuseFilter is using the same wikitext for both attempts to save the page. This is wrong! In fact, after the user received the warning, he fixed the issue and submitted the edit again, but the filter was triggered a second time, as if the user used the same wikitext twice. 
>
>Originally reported on
>https://pt.wikipedia.org/wiki/WP:Filtro_de_edi%C3%A7%C3%B5es/1#Falsos_positivos
I have found the cause: The problem is that edits through API (that is the difference, @Catrope [re your comment](https://phabricator.wikimedia.org/T99000#1283126)) pass through the AbuseFilter //twice//: The first time, via the `onAPIEditBeforeSave` hook, the second time via the `onEditFilterMergedContent` hook. Only the second hooks gets the post-merged content.

And, because AbuseFilter makes sure it processes every edit only once, it sets `editAlreadyFiltered` in `filterEdit` and on every subsequent hook call for the same edit it just returns without further processing. It means AbuseFilter sees and processes the pre-merged content in `onAPIEditBeforeSave`, and ignores the post-merged content in `onEditFilterMergedContent`.

You could check this by adding `unset($context->getTitle()->editAlreadyFiltered);` at the end of `onAPIEditBeforeSave` – the filter will run correctly the second time and see the postmerged content, however, the edit will be noted twice in the abuse log, so this is (obviously) not a correct solution.

I’d think the correct solution would be to make a variant of `APIEditBeforeSave` hook which would include the post-merged text and AbuseFilter would then switch to that new hook. Maybe. (Or, some voodoo with making sure `APIEditBeforeSave` is read-only, immutable test-this-edit, saving nothing into the abuse log, and //not// setting the `editAlreadyFiltered` flag. But that could be a bit brittle, I guess.)
@Oriodrim: Yep, I guessed the same in the linked dupe, AbuseFilter seems to see the pre-automerged version of edits from VisualEditor.
readding VisualEditor: was removed without explanation and the correlation seems obvious.
I found how to reproduce this bug, at least in some cases. If you edit a page with VisualEditor and an automatic merge happens when you submit (i.e. someone submits a change between the moment you click "edit" and the moment you press "submit"), then AbuseFilter sees the revision before the merge.
added VE Project as it's mentioned here and for all edits in merged T76063
Here is another example on Portuguese Wikipedia:
https://pt.wikipedia.org/wiki/Special:AbuseFilter/examine/log/1898713?uselang=en
https://pt.wikipedia.org/w/index.php?diff=40613438&uselang=en
The string "{{ESR2|" is in "removed_lines" but not in "added_lines". However, it should not be in the "removed_lines", because it is still in the new revision:
https://pt.wikipedia.org/w/index.php?title=Zats_Boy&action=edit&oldid=40613438

This was reported on
https://pt.wikipedia.org/wiki/WP:CP?oldid=40613984#Falso_positivo_na_etiqueta
(Adding 'hhvm' keyword just in case it's related to that.)
Also: https://en.wikipedia.org/wiki/Special:AbuseLog?wpSearchUser=&wpSearchFilter=224&wpSearchTitle=M.R.+Organisation+Limited
Screenshot

Link inspector icon in the toolbar seems to be missing in 
https://en.m.wikipedia.org/

However, it is appearing in test2 and Betalabs.

See the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F14753}
Argh, yes, this was fixed in wmf3 I believe.
Which browser? Link icon appears to be showing for me...
It's ve-ui-mwSaveDialog-editSummary-count in MWSaveDialog, but there are several issues with it:

* It should be stored in a variable, not searched for using jQuery .find() every time
* It should be modified with methods on OO.ui.LabelWidget, not jQuery .text()
* It should actually be visible

I don't know why it's being hidden, but display: none; is set on it, so maybe .hide() is called somewhere?

--------------------------
**Version**: unspecified
**Severity**: normal
**gerritadmin** wrote:

Change 165871 merged by jenkins-bot:
Bringing back the edit summary byte counter in the save dialog

https://gerrit.wikimedia.org/r/165871
**gerritadmin** wrote:

Change 165871 had a related patch set uploaded by SuchetaG:
Bringing back the edit summary byte counter in the save dialog

https://gerrit.wikimedia.org/r/165871
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert a new image
3.Open the media settings dialog again
4.Click on "Choose a different image" button
5.Select a different image
6.Click on "Apply Changes" button

Observed Result:

User gets stuck inside Media Settings dialog.Cannot close the dialog anymore

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

**Attached**: {F15264}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Fall-out from selection rewrite; fixed by Roan.
Screenshot

Steps to reproduce:

1.Open a new page with VE
2.Go to Insert>Formula
3.Insert "\pi"

Observe that, nothing appears on CE. But if you save the page or review your changes , you will see it actually got added in the page .

If you reopen the page after saving, and try again adding the same math expression it will appear immediately.

But if you try adding a different math expression or modify the existing math function , say for example: make "\pi" to "\sqrt\pi", it wont render on CE again. 

Environment:Betalabs

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=71852

**Attached**: {F15254}
Verified the fix in Betalabs, test2 and en.wiki
Now appears to work in production. Success.
Probably the same cause as bug 71852.
demonstration from office-wiki

When typing at the end of a line of an item in a bulleted list some character are duplicated or appear on the wrong line, delete/backspace behaves erratically.

--------------------------
**Version**: unspecified
**Severity**: major

//attachment VE character insertion.m4v ignored as private//
This is the exact bug that https://gerrit.wikimedia.org/r/#/c/164514/ was designed to fix; Rachel F showed me the exact same thing the day before I wrote it. I don't think it ever got cherry-picked, but it should be on mediawiki.org some time later today as part of wmf3. We may need to cherry-pick it to wmf2.
yes just reproduced on mediawiki.org too on this page:https://www.mediawiki.org/wiki/User:RYasmeen_(WMF)?veaction=edit

However, it does not happen in any other test wikis
I didn't test on multiple platforms but I'm on Chrome 38.0.2125.101 beta / OS X 10.9
I certainly didn't get a warm feeling while it was happening.
This sounds bad.
Steps to reproduce:


1.Open a page with VE
2.Insert Cite>Website/News/Journal etc

Observed Result:
All citation notes are getting added as basic reference, opening them opens the basic reference dialog instead of the citation dialog.

Environment:Betalabs

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
(Core pull-through not yet merged but otherwise fixed.)
Change 165593 merged by jenkins-bot:
Followup b8d8a5b: pass selections, not ranges, to SurfaceFragment#clone

https://gerrit.wikimedia.org/r/165593
Change 165592 merged by jenkins-bot:
Followup b8d8a5b: pass selections, not ranges, to SurfaceFragment#clone

https://gerrit.wikimedia.org/r/165592
Change 165593 had a related patch set uploaded by Catrope:
Followup b8d8a5b: pass selections, not ranges, to SurfaceFragment#clone

https://gerrit.wikimedia.org/r/165593
Change 165592 had a related patch set uploaded by Catrope:
Followup b8d8a5b: pass selections, not ranges, to SurfaceFragment#clone

https://gerrit.wikimedia.org/r/165592
This is happening because the references inserted by the citation dialog are empty, they don't have a template in them like they should.
Created attachment 16719
Screenshot

**Attached**: {F15243}
But not only when typing fast.

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix in production
Verified the fix for double-typing issue in test2
The issue of double-typing of characters is resolved but the cursor is still appearing on readmode after saving the page.
Change 165537 merged by jenkins-bot:
Followup b8d8a5b: fix stray check for !selection

https://gerrit.wikimedia.org/r/165537
Change 165537 had a related patch set uploaded by Catrope:
Followup b8d8a5b: fix stray check for !selection

https://gerrit.wikimedia.org/r/165537
Also, after saving a page or discarding an edit, the cursor appears on the Read Mode which could be a related issue, if not will file a separate bug later.
While trying to login to betalabs i get "404 file Not Found Error" after clicking the Log In button.

--------------------------
**Version**: unspecified
**Severity**: major
Another example of why beta shouldn't have a diverged apache config from production.

Docroot paths fixed in https://gerrit.wikimedia.org/r/165649

Puppet force run on deployment-mediawiki0[1-3], apache and hhvm restarted.

WFM now :)
http://login.wikimedia.beta.wmflabs.org/ is entirely down.  Normally there is a whole wiki there (albeit one normally used only for login).
Raising priority (and changed summary) since most Flow browser tests are failing.

Login through the API may be working.
I can confirm comment 3, same outcome here, simply because http://login.wikimedia.beta.wmflabs.org/wiki/Special:CentralLogin/start does not exist.

This feels unrelated to VE, hence correcting product/component.
(In reply to Ritu Swain from comment #2)
> > Also, URLs to reproduce the problem are welcome.

I followed this link http://en.wikipedia.beta.wmflabs.org/wiki/User:Swainr?veaction=edit

and clicked on Log in.After entering id and password in the page when I click on log in button it takes me to this page
http://login.wikimedia.beta.wmflabs.org/wiki/Special:CentralLogin/
> start?token=bbdd420df13bbf427dba8b3a38d6f947 .
> Also, URLs to reproduce the problem are welcome.
http://login.wikimedia.beta.wmflabs.org/wiki/Special:CentralLogin/start?token=bbdd420df13bbf427dba8b3a38d6f947
How is that problem related to VisualEditor (which you set as a product here)? 
I don't see VisualEditor mentioned in your steps to reproduce?
Also, URLs to reproduce the problem are welcome.
1. Open https://www.mediawiki.org/wiki/QA/Selenium_Workshop in latest stable Chrome.
2. Click "Edit"
3. Put cursor in the first paragraph, insert a single character.

Expected:

Save button enables, allowing the user to save the page.

Actual:

Save button stays disable, user is unable to save the edit.

No exceptions or warnings on the dev console.

--------------------------
**Version**: unspecified
**Severity**: major
This appears to now be fixed in wmf3.
Only happens on first click.
Works for me in latest Chrome
This works fine if the first cursor position is in the Header, or before the first character of the paragraph. Very complex behaviour…
Could this be fixed by https://gerrit.wikimedia.org/r/164514 ?
It seems the model is consistently one character behind. When I worked-round the bug in comment #0 by backspacing over my new character and typing it again, and then changing another word on the page, clicking Save page and reviewing my change showed only the first word change in the wikitext diff.
See https://office.wikimedia.org/w/index.php?diff=118847&oldid=118846

Steps to reproduce:

1.  Start with a paragraph that says "Foo '''bar''' baz blah blah".

2.  Cut paragraph.

3.  Paste paragraph elsewhere.

4.  Notice that it now says ""Foo '''bar'''baz blah blah" (i.e., minus one space immediately after the word in bold-face formatting).

This also happened with <mark> formatting.

This edit was made in Safari 6 on Mac OS 10.8.5.  I was not immediately able to reproduce this in Firefox 32.

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in betalabs and test2.
Change 173256 merged by jenkins-bot:
Safari copy-paste fix

https://gerrit.wikimedia.org/r/173256
Change 173256 had a related patch set uploaded by Esanders:
Safari copy-paste fix

https://gerrit.wikimedia.org/r/173256
*** Bug 73333 has been marked as a duplicate of this bug. ***
*** Bug 72901 has been marked as a duplicate of this bug. ***
* Insert a reference (Cite > Basic)
* Insert an MWLink node (Ctrl + K > http://www.amazon.com)

Observe magic zero-width node. Converting to an annotation makes it work fine.

Same happens in media caption dialogs.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 167335 merged by jenkins-bot:
Apply mw-body-content styles to SurfaceWidget

https://gerrit.wikimedia.org/r/167335
Change 167335 had a related patch set uploaded by Jforrester:
Apply mw-body-content styles to SurfaceWidget

https://gerrit.wikimedia.org/r/167335
Verified the fix on test2.
Change 166918 merged by jenkins-bot:
Apply mw-body-content styles to SurfaceWidget

https://gerrit.wikimedia.org/r/166918
Change 166918 had a related patch set uploaded by Trevor Parscal:
Apply mw-body-content styles to SurfaceWidget

https://gerrit.wikimedia.org/r/166918
This is because the CSS for these link nodes (and pretty much everything else from Parsoid CSS) is scoped to .mw-body-content, a class that we set on the main ce.Surface but not on surfaces inside of dialogs.

I tried applying mw-body-content to the surface in the dialog, and that does cause the link node to appear, but it also messes up the font size. Someone with a better understanding of our various layers of font size manipulation (coughtrevorcough) should look at this.
When selecting text with the keyboard (Shift-arrow), starting the selection range in adjacency to a comment icon repeatedly selects and deselects the icon. Starting the selection not in adjacency to the icon works as expected.

If this is hard to understand, see this page:
https://en.wikipedia.org/wiki/User:Amire80/comment

It has detailed instructions to reproduce.

This is broken in both LTR and RTL. RTL test page:
https://he.wikipedia.org/wiki/%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9%D7%AA:Amire80/ve-comment-selection

Thanks to David Chan for helping with minimizing the test case :)

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/wiki/User:Amire80/comment
This should have been resolved with the switch to native cursoring that goes out in wmf17. Please say if not.
Uncaught Error: Syntax error, unrecognized expression: div[id ^= mittoHidden appears while trying to save a page in Betalabs

--------------------------
**Version**: unspecified
**Severity**: blocker
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
**gerritadmin** wrote:

Change 164122 merged by jenkins-bot:
Fix syntax error in mittoHidden selector

https://gerrit.wikimedia.org/r/164122
**gerritadmin** wrote:

Change 164122 had a related patch set uploaded by Catrope:
Fix syntax error in mittoHidden selector

https://gerrit.wikimedia.org/r/164122
Environment- test2

1> In VE, open Basic citation dialog and enter any citation(book,news,Web or Journal). For ex- enter a book citation.
2> Now while the citation is still highlighted select Insert  -> Template.Notice the Add a Template window does not open , instead it opens the Cite Book dialog.

But if you enter a book citation in the CE and while it is still highlighted try to open the Template dialog(Insert  -> Template) . Notice the Add a Template dialog opens.

--------------------------
**Version**: unspecified
**Severity**: major
Thank you once again :), will keep that in mind.
(In reply to Ritu Swain from comment #7)
> (In reply to James Forrester from comment #6)
> > (In reply to Ritu Swain from comment #5)
> > > I checked with a clear history.It still does not open the "Add a Template"
> > > dialog ,when a  book citation is highlighted in Basic reference dialog.
> > > 
> > > Instead it opens the Cite Book dialog.
> > 
> > Oh, right, you weren't talking about the other bug in this report. Yes,
> > opening any of the dialogs when you've selected that item (selecting a
> > template and clicking the template button; an image and the media button; a
> > reference and the reference button) will always open the item for editing
> > rather than insert a new one, by design. Sorry for the confusion.
> 
> Thank you, i got it now. 
> 
> But when i try the above steps in the Content Editor or the Editor in the
> Media Settings Caption.
> 
> For ex- 
> 1> click on cite -> book and insert a book citation.
> 2> Now while the citation is still highlighted select Insert  ->
> Template.Notice the Add a Template modal opens , and not the Cite Book
> dialog.
> 
> If this is how it is supposed to behave in different editors, then please
> ignore this issue.

It is. When you insert "Cite > Book" in the editor, it inserts a citation – a reference with a template inside it. When you try this inside a reference, it cleverly inserts the template, not a reference inside a reference (which isn't allowed). It's a little confusing, clearly. :-(
(In reply to James Forrester from comment #6)
> (In reply to Ritu Swain from comment #5)
> > I checked with a clear history.It still does not open the "Add a Template"
> > dialog ,when a  book citation is highlighted in Basic reference dialog.
> > 
> > Instead it opens the Cite Book dialog.
> 
> Oh, right, you weren't talking about the other bug in this report. Yes,
> opening any of the dialogs when you've selected that item (selecting a
> template and clicking the template button; an image and the media button; a
> reference and the reference button) will always open the item for editing
> rather than insert a new one, by design. Sorry for the confusion.

Thank you, i got it now. 

But when i try the above steps in the Content Editor or the Editor in the Media Settings Caption.

For ex- 
1> click on cite -> book and insert a book citation.
2> Now while the citation is still highlighted select Insert  -> Template.Notice the Add a Template modal opens , and not the Cite Book dialog.

If this is how it is supposed to behave in different editors, then please ignore this issue.
(In reply to Ritu Swain from comment #5)
> I checked with a clear history.It still does not open the "Add a Template"
> dialog ,when a  book citation is highlighted in Basic reference dialog.
> 
> Instead it opens the Cite Book dialog.

Oh, right, you weren't talking about the other bug in this report. Yes, opening any of the dialogs when you've selected that item (selecting a template and clicking the template button; an image and the media button; a reference and the reference button) will always open the item for editing rather than insert a new one, by design. Sorry for the confusion.
(In reply to James Forrester from comment #4)
>
> 
> 

I checked with a clear history.It still does not open the "Add a Template" dialog ,when a  book citation is highlighted in Basic reference dialog.

Instead it opens the Cite Book dialog.
I can't; have you refreshed?

The citation template now opens as expected.
(In reply to James Forrester from comment #2)
> I believe this has now been fixed and backported as part of the fix for bug
> 71418.

I can still reproduce it, in both test2 and beta.
I believe this has now been fixed and backported as part of the fix for bug 71418.
http://youtu.be/sy91ReXk_f4
1. Open VisualEditor
2. Find or create a paragraph with a link followed by some non-linked text
3. Inspect the link
4. While the link inspector is open, click to drop the cursor in the non-linked text

The link inspector does not close, and instead moves to follow your selection.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=71151
Verified the fix in test2 and production
Merged into master and deployed to wmf1.
Change 163852 merged by jenkins-bot:
Followup b149390: fix dm.Surface's concept of "selectedNode" to match SurfaceFragment's

https://gerrit.wikimedia.org/r/163852
Change 163852 had a related patch set uploaded by Jforrester:
Followup b149390: fix dm.Surface's concept of "selectedNode" to match SurfaceFragment's

https://gerrit.wikimedia.org/r/163852
Change 163783 merged by jenkins-bot:
Followup b149390: fix dm.Surface's concept of "selectedNode" to match SurfaceFragment's

https://gerrit.wikimedia.org/r/163783
Change 163783 had a related patch set uploaded by Catrope:
Followup b149390: fix dm.Surface's concept of "selectedNode" to match SurfaceFragment's

https://gerrit.wikimedia.org/r/163783
(In reply to Bartosz Dziewoński from comment #2)
> Related? Bug 71151.

Yes, absolutely. While investigating this, I wished I had "git bisect concerning" in addition to "good" and "bad". At first, nothing was wrong, then the flicker started happening, and now it doesn't close at all.

I think this happened because Ed changed the context to reposition itself directly from events emitted by the surface. The surface also emits a contextChange event that causes the context to realize that it should close (or did; this bug is about that event not being emitted any more), but that event listener is debounced, so we close the context after moving it.
Related? Bug 71151.
This broke in https://gerrit.wikimedia.org/r/#/c/162495/ , which made it so contextChange is no longer emitted when the selection moves from inside a link to outside a link.
See https://office.wikimedia.org/w/index.php?diff=118520&oldid=118519

This was all supposed to be on one line, essentially changing ===One=== to ===One and two===  It displays almost correctly, the equivalent of:

===One and two===
a

but saves completely wrong:

===One===
ndtwoa


James F has a screenshot in e-mail.

--------------------------
**Version**: unspecified
**Severity**: normal
This is almost certainly a duplicate of the bug that was fixed by https://gerrit.wikimedia.org/r/#/c/164514/
Checked Safari/Chrome - cannot reproduce.
Looks like the issue we had in Safari selections that Ed fixed a couple of weeks ago?
Can't reproduce this issue...
We have isValid() functions for similar inputs, but not this one, so it's possible to try to create a redirect to "|" (which Parsoid turns into MediaWiki:Badtitle).

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to etonkovidova from comment #8)
> test2 has the same validation that is in betalabs: 
> 
> - cannot add Talk: as a template - 'Add template' is disabled
> - cannot add a template or a  category with |(a pipe), < and > chars
> - if 'Page settings' redirection has aforementioned  symbols -
> MediaWiki:Badtitletext is displayed.  Does it need some improvement?

That sounds like it covers all our needs.
test2 has the same validation that is in betalabs: 

- cannot add Talk: as a template - 'Add template' is disabled
- cannot add a template or a  category with |(a pipe), < and > chars
- if 'Page settings' redirection has aforementioned  symbols - MediaWiki:Badtitletext is displayed.  Does it need some improvement?
Change 169623 merged by jenkins-bot:
Introducing isValid() in MWTitileInputWidget

https://gerrit.wikimedia.org/r/169623
Change 169623 had a related patch set uploaded by SuchetaG:
Introducing isValid() in MWTitileInputWidget

https://gerrit.wikimedia.org/r/169623
This is scarily close to what I filed bug 72468 about. While filing it I was thinking that an isValid() implementation should also be provided. I'll add that to that bug.
(In reply to James Forrester from comment #3)
> (In reply to Alex Monk from comment #1)
> > Currently the redirect section of the page settings dialog and the template
> > placeholder page use MWTitleInputWidget.
> > 
> > The template placeholder page can be fixed with a simple change from value
> > === '' to !mw.Title.newFromText( value ) in
> > MWTemplatePlaceholderPage#onTemplateInputChange. It will no longer allow you
> > to add a template with an invalid name. No need for isValid here.
> 
> What happens when you use a parser function or a magic word?

I imagine it would break. So let's not do that.

> > As for the redirect settings, that seems more difficult. I don't think we
> > should just silently ignore the value if it was set to an invalid title...
> > And I don't think we should disable the apply button either.
> 
> We show "invalid title" for link searches; presumably that's evaluated
> server-side?

That is shown when the page does not seem to exist (based on the search results) and we get a false-y value from mw.Title.newFromText on the given title.
(In reply to Alex Monk from comment #1)
> Currently the redirect section of the page settings dialog and the template
> placeholder page use MWTitleInputWidget.
> 
> The template placeholder page can be fixed with a simple change from value
> === '' to !mw.Title.newFromText( value ) in
> MWTemplatePlaceholderPage#onTemplateInputChange. It will no longer allow you
> to add a template with an invalid name. No need for isValid here.

What happens when you use a parser function or a magic word?

> As for the redirect settings, that seems more difficult. I don't think we
> should just silently ignore the value if it was set to an invalid title...
> And I don't think we should disable the apply button either.

We show "invalid title" for link searches; presumably that's evaluated server-side?
Bump.
Currently the redirect section of the page settings dialog and the template placeholder page use MWTitleInputWidget.

The template placeholder page can be fixed with a simple change from value === '' to !mw.Title.newFromText( value ) in MWTemplatePlaceholderPage#onTemplateInputChange. It will no longer allow you to add a template with an invalid name. No need for isValid here.

As for the redirect settings, that seems more difficult. I don't think we should just silently ignore the value if it was set to an invalid title... And I don't think we should disable the apply button either.
Looking at the network traffic from visiting a page on enwiki, I saw that when editing a page (both with VE enabled and without it) a few GET requests get performed to API, like in example:

https://en.wikipedia.org/w/api.php?format=json&uselang=en&action=visualeditor&paction=parse&page=Moravian-Silesian_Region

these requests go out as XHR requests and my browser does not attach any cookie to the request. Of course, this means that any cookie-based test we might want to perform (like using HHVM) will not work as expected.

This would effectively block us from testing hhvm on the API cluster.

--------------------------
**Version**: unspecified
**Severity**: major
Upon further analysis; this happened because of a bug in a chromium adblocking extension I was using, which blocked cookies in GET requests to api based on a regex I must have added years ago. Disabling the adblocking extension effectively sent the cookies correctly.
I cannot reproduce this. According to Firebug the cookies are being included in XHR requests to the API when I visit enwiki pages, including the request to https://en.wikipedia.org/w/api.php?format=json&uselang=en&action=visualeditor&paction=parse&page=Moravian-Silesian_Region if I enable the VE beta feature and then attempt to edit that page using VE.

Further, I'd expect we'd have had many more bug reports if this were a widespread problem, since lacking cookies in the API requests would cause the VE edits to be performed as an IP.

My browser is Iceweasel 32.0 (which is Debian's rebranded version of Firefox 32.0). While it shouldn't matter for this particular case, I have "Accept third-party cookies" set to "Always".


At any rate, this certainly isn't an API bug since the API has no control over whether the client sends any cookies. I'm going to tentatively reassign it to "JavaScript".
No UI

Steps to reproduce:

1.Open a page with VE
2.Open the link inspector/math inspector for an existing link
3.Close the inspector by clicking on "Done" button or you can keep the inspector open
4.Now scroll down the page so that the inspector goes outside the current surface
5.Now click somewhere else in the document
6.Now go back and reopen the previous inspector

Observed Result:
There is no UI for the inspector,if you try inspecting some other inspector on the current viewport that will also appear without any UI.

for link inspector if you switch tab and come back to VE, the link inspector will have only the link target suggestions inside it .

Environment: Betalabs, test2

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F14854}
Verified the fix in Production
Verified the backport in test2
Verified the fix in Betalabs
**gerritadmin** wrote:

Change 162474 merged by jenkins-bot:
Re-clip popups after resizing them

https://gerrit.wikimedia.org/r/162474
**gerritadmin** wrote:

Change 162474 had a related patch set uploaded by Catrope:
Re-clip popups after resizing them

https://gerrit.wikimedia.org/r/162474
Created attachment 16543
Link inspector

**Attached**: {F14856}
video capture of the bug

Steps to reproduce:

1.Open a page with VE
2.Open any inspector-Link/Math/Special Character for any existing node
3.Now while the inspector is open, place the cursor any where else in the document


Observed Result:
The inspector closes and flickers in the new position.

See the video capture attached

Environment:Betalabs

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=71373

**Attached**: {F14852}
I'm now not getting any flickering in Beta Labs or production. Fixed?
I am still getting this issue in Betalabs.

{F20118}
Not seeing any flicker in master.
Nope, still happening in en.wiki,test2 and Betalabs
Nope, still happening in en.wiki,test2 and Betalabs
This appears to now be fixed (testing on enwiki); can we confirm and close?
It's now worse, see bug 71373. I speculated about why this bug happens in bug 71373 comment 3.
Nope this is still happening.I guess it has something to do with the code change in https://gerrit.wikimedia.org/r/#/c/160034/
Possibly now fixed?
Steps to reproduce:


1.Open a page with VE
2.Insert a citation/a comment/math node
3.Now place your cursor at the beginning of the node that you just added
4.Drag the selection vertically, you will be able to do the selection over the next lines
5.Now again place the cursor at the beginning of the node added in step 2
6.Select the line of the node horizontally and then try to drag the selection vertically

Observed Result:
The selection stops at the focusable node and does not get extended towards the next lines.

Environment:Betalabs, test2

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in test2
**gerritadmin** wrote:

Change 162904 merged by jenkins-bot:
Don't perform focus node native selection trick while dragging

https://gerrit.wikimedia.org/r/162904
**gerritadmin** wrote:

Change 162904 had a related patch set uploaded by Esanders:
Don't perform focus node native selection trick while dragging

https://gerrit.wikimedia.org/r/162904
Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Formula
3.Attempt to insert "\pi" inside the inspector

Observed Result:
As soon as you type \ in the inspector , it closes and tries to parse that \ and shows error "Failed to parse (lexing error)"


Environment:Betalabs
Browser:Chrome

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix in test2 and Betalabs
Moving back to "FIXED" and re-using bug 72136.
*** Bug 72136 has been marked as a duplicate of this bug. ***
But the difference is, this time it does not try to parse each time a character is inserted , just closes the inspector
This started happening within last couple of hours
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 162495 merged by jenkins-bot:
Calculate selected node on change and emit contextChange

https://gerrit.wikimedia.org/r/162495
Change 162473 abandoned by Bartosz Dziewoński:
ve.ui.Context: Prevent context changes during opening/closing inspectors better

Reason:
Ed probably knows better.

https://gerrit.wikimedia.org/r/162473
Change 162495 had a related patch set uploaded by Esanders:
Calculate selected node on change and emit contextChange

https://gerrit.wikimedia.org/r/162495
Change 162473 had a related patch set uploaded by Bartosz Dziewoński:
ve.ui.Context: Prevent context changes during opening/closing inspectors better

https://gerrit.wikimedia.org/r/162473
(The cause is probably 49a239b4b68719dc59bacf79e5186aceca881c58.)
After dm.Surface emits 'contextChange', ve.ui.Context#afterContextChange thinks that the inspector should be closed, because `selectedNode !== this.lastSelectedNode` (this.lastSelectedNode is null). I spent way too much time debugging this and I still don't know why that happens. It worries me somewhat that `selectedNode` is a paragraph node rather than mwMath node.
Focus issue?
It only closes when you're inserting a new formula. Editing existing ones doesn't have this problem.
I don't think MediaWiki manages SQLite lock and concurrency at all.

In this case, it seems two different Apache PHP threads are attempting to update the message cache.   For CI purposes, maybe we want to repopulate the message cache in the DB or skip it entirely to use the good old messages PHP files.
https://ast.wikipedia.org/w/index.php?title=Peligru_Mariellu&diff=747158&oldid=747157

shows 1922 being replaced by [[MediaWiki:Badtitletext]].

https://ast.wikipedia.org/w/index.php?title=Peligru_Mariellu&diff=747160&oldid=747159

shows "sieglu XX" being replaced by [[MediaWiki:Badtitletext]].

Nothing is known about the user's browser, skin, or OS.  It appears that the editor wrote this article at the Spanish Wikipedia, pasted the wikitext code into VisualEditor, and was trying to translate it into Asturian and correct the resulting nowiki mess when this happened.

--------------------------
**Version**: unspecified
**Severity**: normal
Without knowing anything more about what HTML parsoid got, this is hard to reproduce, so for now, I am going to presume this is an instance of the yet to be fixed T72960 (or the now fixed T72894) and close this. Please reopen if you have any additional information that can help.
This may be a duplicate of bug 70960 if the user did insert a "./" in the link content part. Otherwise, it may be another instance of bug 70894. But leaving this open for now in case we can figure out more about what the user typed there in the links.
1. Open any article
2. Select the article title (firstHeading), copy, open the page settings, and set the default sort, and apply.
3. try to click any element - it fails.

Inspect element tells you there is "ve-ui-overlay-global ve-ui-overlay" over all...

--------------------------
**Version**: unspecified
**Severity**: major
Fixed as part of the fixes for 70731.
Steps to reproduce:

1.Open a page with VE
2.Try to open Link/Math/Language/Special Character inspector

Observed Result:
None of them opens and in the console it shows the following error:

Uncaught TypeError: Cannot read property 'top' of undefined 

Environment:test2.betalabs

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70770
https://bugzilla.wikimedia.org/show_bug.cgi?id=70768
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs.
Environment- test2, beta

1> open VE, I get JS console error as “Uncaught TypeError: Cannot read property 'top' of undefined” in Chrome.


In FF the error is TypeError: rect is undefined

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70782
https://bugzilla.wikimedia.org/show_bug.cgi?id=70768
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
**gerritadmin** wrote:

Change 160082 merged by jenkins-bot:
ve.getStartAndEndRects returns null for empty rect lists

https://gerrit.wikimedia.org/r/160082
**gerritadmin** wrote:

Change 160082 had a related patch set uploaded by Jforrester:
ve.getStartAndEndRects returns null for empty rect lists

https://gerrit.wikimedia.org/r/160082
**gerritadmin** wrote:

Change 160076 merged by jenkins-bot:
ve.getStartAndEndRects returns null for empty rect lists

https://gerrit.wikimedia.org/r/160076
**gerritadmin** wrote:

Change 160076 had a related patch set uploaded by Catrope:
ve.getStartAndEndRects returns null for empty rect lists

https://gerrit.wikimedia.org/r/160076
(In reply to Rummana Yasmeen from comment #4)
> RoanKattouw, Try opening a new page with VE, you will get this error.

Yup, that does the trick. Thanks.
RoanKattouw, Try opening a new page with VE, you will get this error.
I can't reproduce this, neither logged in nor logged out, neither on test2 nor on beta labs, using Chrome.
(In reply to Roan Kattouw from comment #1)
> I can't reproduce this on test2. Does it happen when logged out as well?

yes, it happens irrespective of my login status.
I can't reproduce this on test2. Does it happen when logged out as well?
I haven't tried to reproduce this.  

I copied a page title from Meta and pasted it into VisualEditor on another wiki.  The text was set to =Page title= and highlighted in very pale blue, with a dashed line underneath, so I set it to Paragraph (that worked) and went to the character formatting menu to clear the formatting.  The 'Language' item was highlighted, so I chose that.

The first time, the dialog box that popped up was tiny.  It was barely big enough to display the "done" button, which was overlapping with an odd "$1 AUTO" string in gray text.

The second time, the dialog box looked normal, but 'Remove' didn't actually remove anything.  'Clear formatting' also doesn't remove anything.  

Then the box got stuck open.  It would go away if I highlighted text, but 'Done' didn't close it and clicking outside it didn't close it.

I was able to keep editing and to save the page when I was finished, but it produced <span dir="auto"> tags, which I didn't want.

--------------------------
**Version**: unspecified
**Severity**: normal
**gerritadmin** wrote:

Change 160096 merged by jenkins-bot:
(Kind of) fix treatment of strange dir values

https://gerrit.wikimedia.org/r/160096
**gerritadmin** wrote:

Change 160098 merged by jenkins-bot:
Don't return undefined in ve.init.mw.Platform#getLanguageName

https://gerrit.wikimedia.org/r/160098
**gerritadmin** wrote:

Change 160098 had a related patch set uploaded by Catrope:
Don't return undefined in ve.init.mw.Platform#getLanguageName

https://gerrit.wikimedia.org/r/160098
**gerritadmin** wrote:

Change 160096 had a related patch set uploaded by Catrope:
(Kind of) fix treatment of strange dir values

https://gerrit.wikimedia.org/r/160096
It looks like page titles (at least on meta, possibly elsewhere) are wrapped in <span dir="auto">, which is recognized as a language annotation (because it has a dir attribute) but doesn't work very well once it's considered a language annotation (because it has no lang attribute). I'll poke at this. Earlier, Amir reported a problem with pages containing <span dir="rtl"> tags (also no lang attribute) so maybe this is semi-related.
link inspector

Steps to reproduce:

1.Open a page with mobile VE
2.Open a link inspector for any link
3.Tap on the text box to bring up the link target suggestions

Observed Result:
Link target suggestion drop down are appearing cut off to a small size.

See the screenshot attached

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

**Attached**: {F14991}
Verified the fix in production for desktop and mobile iOS
Yes, this one got fixed in wmf 22.Marking it as fixed.
Created attachment 16476
desktop

**Attached**: {F14993}
Created attachment 16475
In desktop

**Attached**: {F14992}
screenshot1

Environment-test2,beta, production.

1> open a page in VE, add a Basic citation.
2>Click to add Basic citation again ,in the modal click on “Use an Existing Reference “.Select the citation that you just added.
3>In the editor pane, delete all the citations.
4> Select  to add Basic citation again. In the modal notice the “Use an Existing Reference “ button is  still active, although there are no citations to add to. Click on it and it opens a blank Reference modal.
See screenshot.

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

**Attached**: {F14787}
Verified the fix in production
Verified the fix in test2
(Opened bug 70640 for that)
This bug is about a very specific way to break the existing disabling of a different button. What you propose makes sense but it's not in scope here. I'll take a look into doing it anyway, but I'm going to re-close this bug.
The Re-Use option in the Cite menu from the toolbar still remains enabled when there is no reference in the article.
**gerritadmin** wrote:

Change 159423 merged by jenkins-bot:
Properly mark reference search index as empty when setting internal list

https://gerrit.wikimedia.org/r/159423
Nice.
**gerritadmin** wrote:

Change 159423 had a related patch set uploaded by Alex Monk:
Properly mark reference search index as empty when setting internal list

https://gerrit.wikimedia.org/r/159423
In Safari, Go to Insert>Media, try to enter something in the search box.
you will get the following error in the console and wont be able to place your cursor in to the search box:


api.php:1TypeError: 'undefined' is not a function (evaluating 'jQuery111102360369882080704_1410208128038({"warnings":{"main":{"*":"Unrecognized parameter: 'uselang'"}},"query":{"searchinfo":{"totalhits":0}}})')

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
**gerritadmin** wrote:

Change 160503 merged by jenkins-bot:
Work around position: fixed; bug in Safari

https://gerrit.wikimedia.org/r/160503
**gerritadmin** wrote:

Change 160503 had a related patch set uploaded by Catrope:
Work around position: fixed; bug in Safari

https://gerrit.wikimedia.org/r/160503
This issue happens when you scroll down the page a bit and try adding reference/citation/media.

This happens everywhere: Betalabs, test2, production.
This is happening for all citation dialogs, basic reference dialog, transclusion dialog, reference list dialog, Page Settings dialog.

Environment:Betalabs
Screenshot

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/w/index.php?title=Help:Extension:GlobalCssJs&veaction=edit

**Attached**: {F14684}
Verified the fix in production
Verified the fix in test2
Yes.

*** This bug has been marked as a duplicate of bug 70423 ***
Isn't this bug 70423?
Probably related to similar link inspector behaviour?
Thanks for the quick investigation and fixing, Giuseppe!
the patch has solved the problem, and now the page loads correctly.
A patch for the problem has been created:

https://gerrit.wikimedia.org/r/#/c/159080/
While on varnish the url

https://bits.wikimedia.org/zh-yue.wikipedia.org/load.php?debug=true&lang=yue&modules=site&only=scripts&skin=vector&*

returns 404, the same url without the final parameter returns correctly 200:

https://bits.wikimedia.org/zh-yue.wikipedia.org/load.php?debug=true&lang=yue&modules=site&only=scripts&skin=vector


I confirmed that both urls, when properly translated, are answered with a 200 OK (and the same content) by the backend:

https://zh-yue.wikipedia.org/w/load.php?debug=true&lang=yue&modules=site&only=scripts&skin=vector
 * 200 OK 26761
https://zh-yue.wikipedia.org/w/load.php?debug=true&lang=yue&modules=site&only=scripts&skin=vector&*
 * 200 OK 26761

So this seems to be an issue at the varnish layer.

I'll update the ticket as I find out more.
Thanks for taking the time to report this!

I went to https://zh-yue.wikipedia.org/wiki/%E9%A0%AD%E7%89%88?debug=true and using the "Network" tab of Firefox' developer tools there are a few 404s for HTML/CSS stuff from bits, like

https://bits.wikimedia.org/zh-yue.wikipedia.org/load.php?debug=true&lang=yue&modules=site&only=scripts&skin=vector&* which is a 404.

Replacing lang=yue by lang=zh-yue works.

According to Operations mailing list there were issues with Bits which started on Friday around 16:33 UTC due to a serialisation of requests for one specific uncacheable URL which was extremely slow to render and piled up requests, but that should have been sorted out / worked around. I'll ask on the list.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Image
3.Try to type in a caption

Observed Result:


The text gets copied again in the text line and a pawn follows it.Also if you try to edit the caption of an existing image in a page , it is almost impossible to type in.

Enviornment:Betalabs
See the screenshot attached

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

**Attached**: {F15068}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
**gerritadmin** wrote:

Change 158797 merged by jenkins-bot:
Followup cb86c4f: fix call to renamed setChanged() function

https://gerrit.wikimedia.org/r/158797
**gerritadmin** wrote:

Change 158797 had a related patch set uploaded by Catrope:
Followup cb86c4f: fix call to renamed setChanged() function

https://gerrit.wikimedia.org/r/158797
Screenshot

See the screenshot attached

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

**Attached**: {F15012}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Fixed in https://gerrit.wikimedia.org/r/#/c/159243/
See https://en.wikipedia.org/wiki/File:VisualEditorTableCopyBugScreenshot.jpg for what the editor selected.  See https://en.wikipedia.org/wiki/File:VisualEditorTableCopyBugScreenshot2.jpg (top) for what he got when he pasted it into the new place.

This was found on Chrome and Windows 7.

Also, if he used Ctrl-X to cut the table, he was unable to save his changes.  Clicking on the Save button did nothing after that point.  Ctrl-C to copy the table did not disable the Save button.

--------------------------
**Version**: unspecified
**Severity**: normal
Re-checked with 1.25wmf24 (32a0b3f). The fix works reasonably well - just make sure that the table is selected along with some text.
In test2: selecting the above table and paste it will insert  the following symbol.☢
Verified in beta - for general cases it's fixed: tables can be copy/cut, the table format is preserved - and Save button is properly activated and functioning. 

However, in the issue refers to  **the particular table example**( https://en.wikipedia.org/w/index.php?oldid=624091874 ) due to <ref name="Tuck_U"></ref> will throw a lot of hiccups:
``` {| class="wikitable" style="font-size: 10pt; line-height: 11pt; margin-left: 2em; text-align: center; float: right"
! 
!
Winter
!
<nowiki> </nowiki>Spring 
!
Summer 
!
Autumn 
!
Winter
|-
!
1937
| 
| 
| 
| 
| bgcolor="#ccffff" |1
|-
!
1938
| 
| bgcolor="#ccffff" |2 
| bgcolor="#ccffff" |3 
| bgcolor="#ccffff" |4 
| bgcolor="#ccffff" |5
|-
!
1939
| 
| bgcolor="#ccffff" |6 
| bgcolor="#ccffff" |7 
| bgcolor="#ccffff" |8 
| bgcolor="#ccffff" |9
|-
!
1940
| 
| bgcolor="#ccffff" |10 
| bgcolor="#ccffff" |11 
| bgcolor="#ccffff" |12 
|
|-
!
1941
| bgcolor="#ccffff" |13 
| bgcolor="#ccffff" |14 
| 
| bgcolor="#ccffff" |15 
|
|-
!
1942
| 
| bgcolor="#ccffff" |16 
| 
| 
|
|-
| colspan="6" style="font-size: 8pt; text-align:left" |Issues of ''Tales of Wonder'', showing issue number.
Walter Gillings was editor throughout.<ref name="Tuck_U"></ref>
|}
<br>

``` 

Try to select, copy, and cut the above table: 
Uncaught Error: Offset could not be translated to a DOM element...
Uncaught TypeError: Cannot read property 'isWrapped' of null...
Uncaught Error: offset was inside a handlesOwnChildren...
Uncaught Error: Invalid retain length, cannot retain backwards:...
Change 158662 merged by jenkins-bot:
Fix unbalanced transaction when removing to/from the edge of an inline node

[[https://gerrit.wikimedia.org/r/158662]]
Change 158662 had a related patch set uploaded (by Catrope):
WIP Failing test case

[[https://gerrit.wikimedia.org/r/158662]]
**gerritadmin** wrote:

Change 158662 had a related patch set uploaded by Esanders:
WIP Failing test case

https://gerrit.wikimedia.org/r/158662
Minimal failure case in core to trigger the unbalanced delete which is causing this to happen:

<p></p>
<p>a<span rel="ve:Alien">b</span></p>

Select from the empty paragraph to after the b (range 1,6) and delete.
The problem appears after the cutting, not after the pasting.  Also, it's usually possible to switch to source editing.  Consequently, this is only a lost-work bug for most people (anyone who doesn't know about or doesn't try switching to source.)
Update:

To make this work, you have to select the table (just its own cells), without any text before and after.

If you select more than the table (text + table + more text), then the table formatting appears to be correct when pasted in VisualEditor, but isn't actually correct when it's saved.  See https://en.wikipedia.org/w/index.php?oldid=624091874 for the saved version, and compare it to the same table in previous versions.  

In addition to not being able to save after cutting and pasting, it's not possible to switch to source code editing.
Steps to reproduce:

1.Open a page with VE
2.Select a text
3.Press commann+K


Observed Result:
Link inspector flickers and applies the link text as link target without showing any link target names.

Environment:Betalabs
Browser:Chrome

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix in Production
Verified the fix in test2
Verified the fix in Betalabs
Change 158269 merged by jenkins-bot:
Only focus the paste target if focusedNode has changed

https://gerrit.wikimedia.org/r/158269
Change 158269 had a related patch set uploaded by Esanders:
Only focus the paste target if focusedNode has changed

https://gerrit.wikimedia.org/r/158269
Regression from https://gerrit.wikimedia.org/r/#/c/157199/
The message https://translatewiki.net/wiki/MediaWiki:Visualeditor-dialog-action-insert/he was translated on August 21, but still doesn't appear in the Hebrew Wikipedia: https://he.wikipedia.org/wiki/MediaWiki:Visualeditor-dialog-action-insert .

IRC:
James_F	aharoni: Yeah, I've been looking at this.
James_F	aharoni: It looks like the i18n job for VE-core hasn't run for a while.
James_F	aharoni: I fixed it in If68193e7c3c78beeeb47975dc63ebaaec21448f3 and it worked… maybe that didn't stick?

--------------------------
**Version**: wmf-deployment
**Severity**: normal
(In reply to Amir E. Aharoni from comment #3)
> The message that triggered this bug was imported successfully, so I guess
> that it's fixed now

And it still is.

(In reply to Niklas Laxström from comment #4)
> extensions//Parsoid/php/i18n/en.
> json in

That's not VisualEditor and it's caused by 9b986c9cb0169918d41e146096d4d73c3aca58f0
Sent https://gerrit.wikimedia.org/r/162548 / I0bf1db4b8 (19edff5a)
So REOPENED?
This has been going since August 14th so there is something broken still:
PHP Warning:  filemtime(): stat failed for /resources/projects/mediawiki-extensions/extensions//Parsoid/php/i18n/en.json in /www/translatewiki.net/w/extensions/Translate/utils/MessageGroupCache.php on line 196
The message that triggered this bug was imported successfully, so I guess that it's fixed now, but I don't know what caused or what fixed it.
Is this still a problem? If so, can someone (Niklas/Amir/?) on this bug help point out where the problem might be?
A better link to see that the translation is not updated:
https://he.wikipedia.org/w/index.php?title=%D7%9E%D7%99%D7%95%D7%97%D7%93%3A%D7%94%D7%95%D7%93%D7%A2%D7%95%D7%AA+%D7%94%D7%9E%D7%A2%D7%A8%D7%9B%D7%AA&prefix=Visualeditor-dialog-action-insert&filter=all&lang=he&limit=50
1. Open a page with some content (a few paragraphs)
2. Select all and delete
3. Insert a math node
4. Press undo

You'll get an exception as selectionBefore in the undo stack is still the range of the whole original document, but your document should be empty.

--------------------------
**Version**: unspecified
**Severity**: normal
**gerritadmin** wrote:

Change 157149 merged by jenkins-bot:
Track selectionBefore in staging transactions

https://gerrit.wikimedia.org/r/157149
**gerritadmin** wrote:

Change 157149 had a related patch set uploaded by Esanders:
Track selectionBefore in staging transactions

https://gerrit.wikimedia.org/r/157149
Screenshot

the following error is appearing in the console while trying to open Math inspector:

Uncaught TypeError: Cannot read property 'length' of null

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F14629}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
This was fixed by https://gerrit.wikimedia.org/r/#/c/155831/ , don't know why it hasn't deployed to beta labs yet.
This is still occurring in Betalabs while trying to open math inspector in an empty line.
Now appears to work for me – deployment issue?
Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Media and insert an image
3.Reopen the media settings dialog and change the image position to left/centre

Observed Result:
The following error appears in the con sole:
Uncaught TypeError: Cannot read property 'length' of null 

User gets stuck inside Media Settings dialog as it none of the button is working to escape from it.


Environment:Betalabs
Browser:Chrome

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 156192 merged by jenkins-bot:
Followup bbff57b, 8c71904: use getter for availableTools, again

https://gerrit.wikimedia.org/r/156192
Change 156192 had a related patch set uploaded by Mooeypoo:
Validate availableTools before loop in Context's 'hasInspector'

https://gerrit.wikimedia.org/r/156192
In MWLinkTargetInputWidget and other places, we perform API requests that give us exactly the kind of information (existence, redirect status, etc.) that goes into ve.init.mw.LinkCache, but we don't write it to the link cache. We should do that, so we can save ourselves some API requests.

Right now, when you make a link, we do another API request to check if the link should be blue or red, even if the link target came from a suggestion list and we already know it should be blue.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 159623 merged by jenkins-bot:
Refactor a bunch of CategoryInputWidget code, tear out dead/broken redirect handling that should be rewritten

https://gerrit.wikimedia.org/r/159623
Change 159623 had a related patch set uploaded by Alex Monk:
Refactor a bunch of CategoryInputWidget code, tear out dead/broken redirect handling that should be rewritten

https://gerrit.wikimedia.org/r/159623
Now just waiting for category existence checking, I believe?
Change 159418 merged by jenkins-bot:
Update LinkCache in MWTitleInputWidget

https://gerrit.wikimedia.org/r/159418
Change 159418 had a related patch set uploaded by Alex Monk:
Update LinkCache in MWTitleInputWidget

https://gerrit.wikimedia.org/r/159418
(In reply to James Forrester from comment #3)
> Do we want to do this from MWTitleInputWidget and MWCategoryInputWidget?

Re-opening after discussing with Roan.
Do we want to do this from MWTitleInputWidget and MWCategoryInputWidget?
Change 156955 merged by jenkins-bot:
In LinkTargetInputWidget, put existence status into LinkCache

https://gerrit.wikimedia.org/r/156955
Change 156955 had a related patch set uploaded by Alex Monk:
In LinkTargetInputWidget, put existence status into LinkCache

https://gerrit.wikimedia.org/r/156955
This mess:

[[Help:Installing Japanese character sets|<span class="t_nihongo_icon" style="color: #00e; font: bold 80% sans-serif; text-decoration: none; padding: 0 .1em;">?</span>]]) [[Category:Articles containing Japanese-language text]]

was added in https://en.wikipedia.org/w/index.php?curid=31216768&diff=621842944&oldid=600210359

to produce this:

;Track & road events<ref name="JAAF20120611">[http://www.jaaf.or.jp/fan/news/2012/20120611.html {{Nihongo||ロンドンオリンピック トラック・フィールド種目・競歩種目の日本代表選手|The Japanese national team of Track & Field and Race Walk at the 2012 Olympic Games}}][[Help:Installing Japanese character sets|<span class="t_nihongo_icon" style="color: #00e; font: bold 80% sans-serif; text-decoration: none; padding: 0 .1em;">?</span>]]) [[Category:Articles containing Japanese-language text]]{{ja icon}}. Japan Association of Athletics Federations (2012-06-11). Retrieved 19 June 2012.</ref>

The editor says s/he didn't edit this line.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=69876
**gerritadmin** wrote:

Change 155634 merged by jenkins-bot:
Fix the newline bunny-hop bug harder

https://gerrit.wikimedia.org/r/155634
(In reply to Gerrit Notification Bot from comment #2)
> Change 155634 had a related patch set uploaded by Catrope:
> Fix the newline bunny-hop bug harder
> 
> https://gerrit.wikimedia.org/r/155634

This addresses the VE part of the bug. With this patch, VE will no longer corrupt whitespace around categories and the like (I've been seeing this a bunch in needcheck diffs, so that should fix those too). This will prevent Parsoid from corrupting the reference on this page, *unless* you edit it, in which case it'll still get messed up. I'll file a Parsoid bug for that.
**gerritadmin** wrote:

Change 155634 had a related patch set uploaded by Catrope:
Fix the newline bunny-hop bug harder

https://gerrit.wikimedia.org/r/155634
Ugh, I found the cause, it's another whitespace bunny-hop bug.

This whole mess is made because we have something like )[category] <span> and it gets turned into ) [category]<span> . The space jumps to the other side of the category.

Additionally, there's a template leakage bug in Parsoid here. That parenthesis, category, space and span tag should have been marked as template-generated content but aren't. This means that if you try to edit this reference, Parsoid will make a big mess of it. As long as you don't edit it, it'll be fine, but the space jump bug in VE causes it to be edited.
From https://bugzilla.wikimedia.org/show_bug.cgi?id=50749#c2

Look at [[Otto I]].  It has 63 references, including ref #18 ("Thompson") from explanatory footnote [d].  This ref doesn't appear in VisualEditor.

http://en.wikipedia.org/wiki/Otto_I%2C_Holy_Roman_Emperor?oldid=621934593
http://parsoid.wmflabs.org/enwiki/Otto_I%2C_Holy_Roman_Emperor?oldid=621934593

--------------------------
**Version**: unspecified
**Severity**: normal
Now deployed. Please reopen if necessary.
Change 155661 merged by jenkins-bot:
(Bug 69827): Supported nested <ref> tags once more

https://gerrit.wikimedia.org/r/155661
Change 155661 had a related patch set uploaded by Subramanya Sastry:
(Bug 69827): Supported nested <ref> tags once more

https://gerrit.wikimedia.org/r/155661
This broke in https://gerrit.wikimedia.org/r/#/c/143362/
I'm not sure why, but wgBetaFeaturesFeatures is incomplete on my local MediaWiki-Vagrant install.

In the actual preferences UI, I see the following BetaFeatures:

* Hovercards
* Compact personal bar
* Fixed header
* VisualEditor
* VisualEditor language tool

But wgBetaFeaturesFeatures is only:

{ popups: null, visualeditor-enable-language: null }

That in turn means that these are the only ones looped over in betafeatures.js, which means other features don't have the JavaScript/browser blacklist processing.

This bug affects production as well.

Side note, you can use:

.client-js .mw-ui-feature-requirements-javascript {
  display: none;
}

for a simpler way to do the JS-hiding, but that doesn't address the underlying problem.

--------------------------
**Version**: master
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70371
(In reply to Matthew Flaschen from comment #0)
> Side note, you can use:
> 
> .client-js .mw-ui-feature-requirements-javascript {
>   display: none;
> }
> 
> for a simpler way to do the JS-hiding, but that doesn't address the
> underlying problem.

Done in https://gerrit.wikimedia.org/r/161690
Underlying issue is only fixed by James's patch, but Seb35's patch has already fixed the display for the beta features I tested.
**gerritadmin** wrote:

Change 159538 merged by jenkins-bot:
Populate $features even if there aren't any requirements

https://gerrit.wikimedia.org/r/159538
Ah, sorry. I meant https://gerrit.wikimedia.org/r/160213.
https://gerrit.wikimedia.org/r/161629 should have resolved this bug. Is it confirmed?
This bug is a consequence of bug 70814, see https://bugzilla.wikimedia.org/show_bug.cgi?id=70814#c5 : the fix there correctly populates the wgBetaFeaturesFeatures array. (I make this bug depend of bug 70814, but it is similar to a duplicate.)
**gerritadmin** wrote:

Change 159538 had a related patch set uploaded by Jforrester:
Populate $features even if there aren't any requirements

https://gerrit.wikimedia.org/r/159538
Alt+Shift+F is shortcut for search box (very useful to validate a name of article...)

Pressing Alt+Shift+F when the cursor is in the begining of article or in the dummy paragraph (slug) will cause a white pawn ♙ to appear. 

(appears in https://he.wikipedia.org/wiki/%D7%90%D7%99%D7%9C%D7%9F_%D7%9E%D7%9C%D7%9B%D7%90?veaction=edit)

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed.
(But can in Firefox.)
Cannot reproduce on Chrome...
With which browser(s) was this tested?
Observed on iPad. Steps to repro:

1. Go into VE edit mode on an article and enter the link inspector
2. Use browser back to exit the link inspector

Expected: you get a message asking if you want to abandon changes and get taken back to the content if you say yes

Actual: no message about abandoning changes, and you're taken to the top of the page but can't scroll below the fold

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in Betalabs and test2
**jgonera** wrote:

All patches merged, marking as fixed.
**gerritadmin** wrote:

Change 155668 merged by jenkins-bot:
Destroy WindowManagers in Context and Surface destructors

https://gerrit.wikimedia.org/r/155668
**gerritadmin** wrote:

Change 155668 had a related patch set uploaded by Catrope:
Destroy WindowManagers in Context and Surface destructors

https://gerrit.wikimedia.org/r/155668
**gerritadmin** wrote:

Change 155657 merged by jenkins-bot:
Remove global overlay classes when destroying MobileSurface

https://gerrit.wikimedia.org/r/155657
**gerritadmin** wrote:

Change 155657 had a related patch set uploaded by JGonera:
Remove global overlay classes when destroying MobileSurface

https://gerrit.wikimedia.org/r/155657
(In reply to Juliusz Gonera from comment #3)
> I thought it could be easily fixed by adding this.inspectors.clearWindows()
I haven't reported this in Bugzilla yet, but I discovered yesterday that clearWindows() is completely broken. It will only clean up the current window (i.e. the one that's currently open), and it won't touch any others.

> in ve.ui.Context.prototype.destroy, but unfortunately that results in:
> 
> "Uncaught TypeError: Cannot read property 'getComputedStyle' of undefined "
> 
> This happens when WindowManager invokes OO.ui.Window.prototype.hold. I
> suspect it's because everything in WindowManager is async/delayed (to
> accommodate for animations), so DOM nodes no longer exist when WindowManager
> tries to tear windows down.
Yeah that sounds likely. Maybe WindowManager needs a destroy function that destroys everything immediately? I also don't really understand why WindowManager not cleaning up is causing problems if the WindowManager's DOM element is removed.
**jgonera** wrote:

This actually seems to be a VE/OOUI bug. The problem lies in WindowManager not cleaning up after itself.

I thought it could be easily fixed by adding this.inspectors.clearWindows() in ve.ui.Context.prototype.destroy, but unfortunately that results in:

"Uncaught TypeError: Cannot read property 'getComputedStyle' of undefined "

This happens when WindowManager invokes OO.ui.Window.prototype.hold. I suspect it's because everything in WindowManager is async/delayed (to accommodate for animations), so DOM nodes no longer exist when WindowManager tries to tear windows down.
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/kzlyuZku
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/ttlYWwkt
I copied part of a header from one page on se.wikimedia and pasted in an already started header on another page. After my paste the symbol ☀ was added:

https://se.wikimedia.org/w/index.php?title=Projekt%3AWikidata_2014%2FAns%C3%B6kan_till_Vinnova&diff=34844&oldid=34843

(Page I copied from: https://se.wikimedia.org/wiki/Projekt:Offentligkonst.se_2014/Ans%C3%B6kan_till_Vinnova )

I used Google Chrome Version 35.0.1916.153 on Ubuntu 14.04.

--------------------------
**Version**: unspecified
**Severity**: normal
**gerritadmin** wrote:

Change 154407 merged by jenkins-bot:
Ignore whitespace when generating paste context

https://gerrit.wikimedia.org/r/154407
**gerritadmin** wrote:

Change 154407 had a related patch set uploaded by Esanders:
Ignore whitespace when generating paste context

https://gerrit.wikimedia.org/r/154407
This happens when pasting into any node with inner whitespace in it's Parsoid HTML (e.g. <h2> Foo </h2>)
Nevermind, managed to reproduce.
Can you give more detailed steps to reproduce. Did you copy from read mode, or from VE? Where exactly did you select, and where exactly did you paste?
screenshot

environment- test2, production, beta

1> open page in VE, insert a comment.
2> Open to edit the comment.
3>Now click on the Text Style Menu and select  any style, for ex-Page Title or the Heading style.
4> Notice the edit comment dialog turns blank.Please see screenshot.

same behavior found in FF.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows XP

**Attached**: {F14201}
Odd.
This seems fixed now. Cannot Reproduce it anymore.
Also see [[ https://phabricator.wikimedia.org/T78308 | T78308 ]]
In addition to my previous comment: the edit comment pop-up box changes its display(the comment that being edited is still displayed, not blanked out).
Confirmed test2, Betalabs, production (FF, Chrome). The error is displayed as the following: 

Uncaught Error: Cannot set attributes on closing element VM86:325
ve.dm.Transaction.newFromAttributeChangesVM86:325 
(anonymous function)VM86:699 
(anonymous function)VM86:45 
OO.ui.Process.executeVM86:45 
OO.ui.Window.teardownVM86:31 
(anonymous function)
Issue is reproducible and is related to Bug 70888.Please ses "Screenshot 1.25wmf2".
Created attachment 16678
Screenshot 1.25wmf2

**Attached**: {F14202}
JS Console error- Uncaught TypeError:Cannot Read Property 'getSurface of null'.
.

--------------------------
**Version**: unspecified
**Severity**: major
Change 156494 merged by Catrope:
Make the Resolve conflict button actually appear

https://gerrit.wikimedia.org/r/156494
Change 156493 merged by jenkins-bot:
Make the Resolve conflict button actually appear

https://gerrit.wikimedia.org/r/156493
Change 156494 had a related patch set uploaded by Catrope:
Make the Resolve conflict button actually appear

https://gerrit.wikimedia.org/r/156494
Change 156493 had a related patch set uploaded by Catrope:
Make the Resolve conflict button actually appear

https://gerrit.wikimedia.org/r/156493
Change 156491 merged by jenkins-bot:
Make the Resolve conflict button actually appear

https://gerrit.wikimedia.org/r/156491
Change 156491 had a related patch set uploaded by Jforrester:
Make the Resolve conflict button actually appear

https://gerrit.wikimedia.org/r/156491
If TemplateData is added to a template page (not a /doc subpage), then it needs to be wrapped in <noinclude> tags.

--------------------------
**Version**: unspecified
**Severity**: enhancement

**See also**
* {T52512}
* {T56140}
(In reply to JAn Dudík from comment #10)
> really fixed?
> https://cs.wikipedia.org/w/index.php?title=%C5%A0ablona:Infobox_-
> _s%C3%ADdlo&diff=11940098&oldid=11761581

It will be deployed to cswiki in a few hours…
really fixed?
https://cs.wikipedia.org/w/index.php?title=%C5%A0ablona:Infobox_-_s%C3%ADdlo&diff=11940098&oldid=11761581
Change 165908 merged by jenkins-bot:
Add <noinclude> tags to new <templatedata> strings

https://gerrit.wikimedia.org/r/165908
Change 165908 had a related patch set uploaded by Mooeypoo:
Add <noinclude> tags to new <templatedata> strings

https://gerrit.wikimedia.org/r/165908
(In reply to Alex Monk from comment #2)
> Well how would we distinguish a documentation subpage from a "proper"
> template page?


If the title has a "/" in it assume that it's OK to put in without <noinclude>s?
This has caused a few problems on the en wiki. As I discuss at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=prev&oldid=628346583 it affected over 100 article space pages as anons and newer users have used the button and created template data blocks outside of <noinclude> tags. This then gets transcluded into main space articles. 

Examples include
 http://en.wikipedia.org/w/index.phptitle=Template:Roman_Catholic_Cathedrals_in_Great_Britain_and_Ireland&diff=prev&oldid=626352880 

 http://en.wikipedia.org/w/index.php?title=Template:Punknews&diff=prev&oldid=628254485

 http://en.wikipedia.org/w/index.phptitle=Template:List_of_Philippine_seas&diff=prev&oldid=625635816 

 http://en.wikipedia.org/w/index.phptitle=Template:ABC_Mindanao&diff=prev&oldid=622140533 

A list of page affect is at
http://en.wikipedia.org/w/index.php?title=Wikipedia:TemplateData/List&oldid=628258871
I've fixed all the current boken templates.
I assume that the system would be essentially like this:

* If the TemplateData is being added to Template:Foo, then add noinclude tags around it.
* If the TemplateData is being added to Template:Foo/subpage, then check the name of the subpage.
** If $local-variable is set, amd the subpage matches the local variable, then skip the noinclude tags.
** If $local-variable is not set, and the subpage is $mw-default-subpage (which should be set to "/doc"), then skip the noinclude tags.
** Otherwise, assume the subpage is a real template and add noinclude tags.

This means that the way it would work on some future Swahili Wikia is "the local sysops would set the local variable".  At the Swahili Wikipedia, local admins would set it to /hati (their preferred page name).

If local sysops did not define the variable, and also didn't use the default subpage name, and someone added TemplateData to a documentation page that the extension treated as a real template, then it would get an "extra" set of noinclude tags (one that it adds and one that the doc page's transclusion adds).  I'm not sure that this would harm anything at all, but it's preseumably something to test.
(In reply to WhatamIdoing from comment #3)
> Otherwise, I think we'd have to make assumptions based on the page name. 
> Different wikis use different names, but most use /doc (and/or one other
> variant), and I've not yet seen an actual template subpage using those names.

Okay, how do you plan for this to work on the ... Swahili Wikia? (if such a thing exists)
It's possible that TemplateData could be noinclude'd no matter what. (Would nested noinclude tags cause problems?) 

Otherwise, I think we'd have to make assumptions based on the page name.  Different wikis use different names, but most use /doc (and/or one other variant), and I've not yet seen an actual template subpage using those names.
Well how would we distinguish a documentation subpage from a "proper" template page?
Maybe. I'd rather we just fix bug 54140 instead.
Screenshot

Steps to reproduce:

1.Open a page with mobile VE
2.Go to the end of a line
3.Press return to go the next line and click on link inspector or comment icon from the toolbar

Observed Result:
The link inspector and the comment box opens at the end of the previous line
After adding a link or a comment it appears on the next line though.


See the screenshot attached

Environment:Betalabs and test2

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

**Attached**: {F14434}
Got fixed with Ed's selection re-write I believe? I have not seen it happening recently too.Marking as fixed
Can't reproduce...
(In reply to Rummana Yasmeen from comment #14)
> This is again happening for both link inspector and comment box in Betalabs
This is again happening for comment box in Betalabs
*Verified the fix in production*
Verified the fix in Betalabs
Verified the fix in test2
Verified the fix in betalabs
Change 157868 merged by jenkins-bot:
Don't use three different coordinate systems in getSelectionRect()

https://gerrit.wikimedia.org/r/157868
Change 157868 had a related patch set uploaded by Catrope:
Don't use three different coordinate systems in getSelectionRect()

https://gerrit.wikimedia.org/r/157868
Created attachment 16282
Screenshot

This is still happening,the inspectors are now opening not at the end of previous line, but somewhere along the preceding 4/5 lines 

See the screenshot attached, where I tried to add a link inside the bullet list and it appears at some position in page title.

**Attached**: {F14435}
Change 155619 merged by jenkins-bot:
Fallback to node position when getting selection rectangle

https://gerrit.wikimedia.org/r/155619
Change 155619 had a related patch set uploaded by Esanders:
Fallback to node position when getting selection rectangle

https://gerrit.wikimedia.org/r/155619
Yeah, selection is going very wonky here.
Language inspector also behaves in the same way
Right Alex :) This bug is not for mobile VE but for desktop. Sorry about that!
(In reply to Rummana Yasmeen from comment #0)
> Created attachment 16137 [details]
> Screenshot
> 
> Steps to reproduce:
> 
> 1.Open a page with mobile VE

That screenshot does not appear to be from a mobile device...

**Attached**: {F14434}
Screenshot

Steps to reproduce:

1.Open any page with VE
2.Go to Insert>Media

Observe that ,the progress bar is active on the text field and never stops
If you retype the search string, the search results comes up but very slowly, some of the images are not even loading completely inside the dialog box.

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

**Attached**: {F14212}
Seems fine now.
Happening on Betalabs and test2

Cannot open the new comment box

Getting following error in the console:
TypeError: ve.ui.WhitespaceTextInputWidget is not a constructor

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in test2
*** Bug 69012 has been marked as a duplicate of this bug. ***
This was backported and deployed just now.
Change 150990 merged by jenkins-bot:
Followup 23a949844: fix typo in class name for WhitespacePreservingInputWidget

https://gerrit.wikimedia.org/r/150990
Change 150990 had a related patch set uploaded by Catrope:
Followup 23a949844: fix typo in class name for WhitespacePreservingInputWidget

https://gerrit.wikimedia.org/r/150990
Change 150989 merged by jenkins-bot:
Followup 23a949844: fix typo in class name for WhitespacePreservingInputWidget

https://gerrit.wikimedia.org/r/150989
Change 150989 had a related patch set uploaded by Catrope:
Followup 23a949844: fix typo in class name for WhitespacePreservingInputWidget

https://gerrit.wikimedia.org/r/150989
On enwiki:

* Inspect an existing link
* Type "N" in the text box
* Click "North America" in the suggestions list
* Click Done
* Observe that the link now points to "North American B-25 Mitchell"

What seems to happen is:
* you click North America
* the textbox is changed to North America
* a new suggestions list opens, with "North America" as the second item and "North American B-25 Mitchell" as the first
* this closes again, setting the annotation to NAB25M while keeping the text as NA
* when you click Done, the annotation is what's saved, not the text

--------------------------
**Version**: unspecified
**Severity**: major
Still a dupe of bug 65343 :-)

*** This bug has been marked as a duplicate of bug 65343 ***
Change 155673 had a related patch set uploaded by Trevor Parscal:
Select the correct annotation in MWLinkTargetInputWidget

https://gerrit.wikimedia.org/r/155673
*** This bug has been marked as a duplicate of bug 65343 ***
1. Click on a link to show the context menu.
2. Right click on the description of the link in the context menu (eg. name of page the link points to).
3. Choose "Inspect element" which will defocus the page.
4. Click on the link again, thus putting the cursor back in the page; somewhere in the linked word.

After the context menu re-appears, a callback from AnnotagionInspector run via a OO.ui.Process throws:

Uncaught TypeError: Cannot read property 'isCollapsed' of null 
> ve.ui.AnnotationInspector.prototype.getSetupProcess = function () {
>   ..
>   .. fragment.getRange().isCollapsed()
 (anonymous function) ve.ui.AnnotationInspector.js:159
 (anonymous function) oojs-ui.js:3030
 (anonymous function)
 jQuery.extend.Deferred
 promise.then
 OO.ui.Process.execute oojs-ui.js:3067
 OO.ui.Window.setup oojs-ui.js:1902

--------------------------
**Version**: unspecified
**Severity**: major
Can't reproduce.
Shows that redirect page Save page (=Uložit stránku) is gray

In this case, I am adding a template to the redirect page (delete template), but I cannot safe it. The safe button stay gray (attachment).

Steps to reproduce this bug (Windows Vista, FF 31.0):
1) open https://cs.wikipedia.org/w/index.php?title=Cristina_Fern%C3%A1ndez_de_Kirchner&redirect=no
2) click on Edit
3) Cencel options
4) Insert > Template > Smazat (Add more information: 1; randoom text) > Insert template
5) Save page = but you cannot!

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F14552}
Change 150772 merged by jenkins-bot:
ve.ui.MWMetaDialog: Really *ALWAYS* return to normal tracking behavior

https://gerrit.wikimedia.org/r/150772
Change 150772 had a related patch set uploaded by Bartosz Dziewoński:
ve.ui.MWMetaDialog: Really *ALWAYS* return to normal tracking behavior

https://gerrit.wikimedia.org/r/150772
It gets better: the state of the 'Save' button stops being updated always when you open the "Options" dialog and cancel it instead of applying.
Indeed.

In step 4), it also suffices to just input any text – the "Save" button doesn't become enabled.

However, if in step 3) you click "Apply changes" rather than "Cancel", everything works correctly.
If an exception occurs while processing a transaction, we should roll it back safely, so the converter will still work and the user can still save or bail to source mode.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 195361 merged by jenkins-bot:
Make transaction processing exception-safe

[[https://gerrit.wikimedia.org/r/195361]]
Change 195361 had a related patch set uploaded (by Catrope):
Make transaction processing exception-safe

[[https://gerrit.wikimedia.org/r/195361]]
Operations are now queued but exceptions aren't caught yet.
Change 152776 merged by jenkins-bot:
Queue up annotation changes to make operations safer

https://gerrit.wikimedia.org/r/152776
Change 152776 had a related patch set uploaded by Jforrester:
Queue up annotation changes to make operations safer

https://gerrit.wikimedia.org/r/152776
Right now we build it blindly every time, which is inefficient. Can we listen to the internal list or get its hash or something so that we don't have to re-build except if a reference is added, removed or altered?

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 151234 merged by jenkins-bot:
Only build reference search index when it's been changed

https://gerrit.wikimedia.org/r/151234
Change 151234 had a related patch set uploaded by Alex Monk:
Only build reference search index when it's been changed

https://gerrit.wikimedia.org/r/151234
Steps to reproduce:

1.Open a page with VE
2.Add a reference (Basic/Citation)
3.Check Re-use existing reference dialog (The reference appears in the dialog though the reference name is missing which is a different bug:https://bugzilla.wikimedia.org/show_bug.cgi?id=67342)
4.Now add some citation/basic references 
5.Check re-use existing reference dialog again

Observed Result:
Except the first one , none of the newly added references are appearing in the use existing dialog

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=67342
https://bugzilla.wikimedia.org/show_bug.cgi?id=68582
Verified the fix in production
Verified the fix in test2
Change 150711 merged by jenkins-bot:
Follow-up I569098: Rebuild reference list when reopening as it can change

https://gerrit.wikimedia.org/r/150711
Change 150711 had a related patch set uploaded by Alex Monk:
Don't refuse to rebuild reference list when reopening re-using existing citation widget

https://gerrit.wikimedia.org/r/150711
Could it be that the list of references in the "Use existing" panel is just never cleared?
Steps to reproduce:

1.Open a page with mobile VE
2.Place the cursor somewhere at the top of the page
3.When the cursor is active on Ce and the keyboard is open, try scrolling down the page

Observe dResult:
Scrolling does not work

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix for original issue in production.
This seems to still be broken-ish due to bug 68832, which means you can't scroll all the way up to reveal the toolbar, but scrolling down works.

Closing this one, we'll track the remaining problems over at bug 68832.
This issue did not get resolved with the revert
**jgonera** wrote:

Should be fixed by https://gerrit.wikimedia.org/r/#/c/150719/
This is happening now but following a different steps to reproduce:
1.Open a page with Mobile VE
2.Open link inspector
3.Click on the "Done" button
4.Once you are back to CE, tap on it to activate the cursor
5.Now try scrolling up/down

The scrolling wont work
Reopening it again,since I just reproduced it.
Beta Labs gremlins.
This is also happening while scrolling down the link suggestions inside link inspector.
This is an apparent separate bug discovered in the course of bug 67805.

Niklas suggested, "LC issue is possibly caused by incorrect fallback merging, because L10nupdate contains update for ru, but not for uk (because the translation is already up to date for uk):"

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=67805
https://bugzilla.wikimedia.org/show_bug.cgi?id=70686
I think it's safe to mark this fixed now, although we still have to force-update all the l10n caches to make sure brokenness doesn't stay cached somewhere. Reedy says on IRC that he'll do that once he finishes the train deploy that's going on right now.
Change 158423 merged by jenkins-bot:
LocalisationCache: Process one fallback at a time

https://gerrit.wikimedia.org/r/158423
Change 158421 merged by jenkins-bot:
LocalisationCache: Process one fallback at a time

https://gerrit.wikimedia.org/r/158421
Change 158422 merged by jenkins-bot:
Use new LocalisationCacheRecacheFallback hook

https://gerrit.wikimedia.org/r/158422
Change 158423 had a related patch set uploaded by Reedy:
LocalisationCache: Process one fallback at a time

https://gerrit.wikimedia.org/r/158423
Change 158422 had a related patch set uploaded by Reedy:
Use new LocalisationCacheRecacheFallback hook

https://gerrit.wikimedia.org/r/158422
Change 158421 had a related patch set uploaded by Reedy:
LocalisationCache: Process one fallback at a time

https://gerrit.wikimedia.org/r/158421
Now theoretically FIXED (once the code is deployed)?
Change 158146 merged by jenkins-bot:
LocalisationCache: Process one fallback at a time

https://gerrit.wikimedia.org/r/158146
Change 158147 merged by jenkins-bot:
Use new LocalisationCacheRecacheFallback hook

https://gerrit.wikimedia.org/r/158147
The problem is over-optimization: in LocalisationUpdate you're storing only the changed messages for each language, but that's causing problems when the current language doesn't have a change but a fallback language does. We've had this bug before, and it was worked around in r104041.

Rather than doing the same thing as r104041 again and having this recur again the next time someone tries to optimize things, let's really fix it: LocalisationUpdate needs a hook to call for each fallback before it's merged into the final array, rather than one hook after we've already lost the information as to which language each message came from. But to do that, we have to rearrange the processing in LocalisationCache so it accumulates the data for each fallback language
Change 158147 had a related patch set uploaded by Anomie:
Use new LocalisationCacheRecacheFallback hook

https://gerrit.wikimedia.org/r/158147
Change 158146 had a related patch set uploaded by Anomie:
LocalisationCache: Process one fallback at a time

https://gerrit.wikimedia.org/r/158146
(In reply to Nemo from comment #5)
> https://git.wikimedia.org/blob/mediawiki%2Ftools%2Fscap.git/HEAD/
> bin%2FrefreshCdbJsonFiles (authors Bryan and Antoine, AFAICS).

Yeah, I asked them. They said they didn't know anything about the actual generation of the json stuff.

(In reply to Niklas Laxström from comment #6)
> To clarify, are we talking about the json created by LocalisationUpdate
> (which are then included in the CDB files by LocalisationCache), or the json
> files created from the CDB files by the deployment scripts for efficient
> syncing?

There's two different json files? I'm glad I asked for help: I didn't know that it generated json files for the updated messages, then built cdbs, then generated more json files from the cdbs, and then generated cdbs again from the json files.

I was referring to the json files that are created from the cdbs and then used to recreate the cdbs. Now that I know better how things work, I'm digging further into it.
To clarify, are we talking about the json created by LocalisationUpdate (which are then included in the CDB files by LocalisationCache), or the json files created from the CDB files by the deployment scripts for efficient syncing?
(In reply to Brad Jorsch from comment #4)
> point to
> who knows anything about the json-generating code.

https://git.wikimedia.org/blob/mediawiki%2Ftools%2Fscap.git/HEAD/bin%2FrefreshCdbJsonFiles (authors Bryan and Antoine, AFAICS).
(In reply to Greg Grossmeier from comment #3)
> Niklas: Can you give any pointers to Brad to help him get up to speed on
> this?

More specifically, I tracked the problem down as far as "the .json files are wrong". When I asked around, you were the only person anyone could point to who knows anything about the json-generating code. Where do I find this code? If it's not going to be obvious, how generally does that code work? Is there a known way to run just the json-generator and output files to some temporary directory?
Niklas: Can you give any pointers to Brad to help him get up to speed on this?
(In reply to Brad Jorsch from comment #1)
> So the problem seems to be in the (new JSON-based) l10nupdate process.

Moving to "Deployment systems"; feel free to move back.
Further detail from bug 67805: "I tracked that one as far as observing that the json file for uk that the cdb file gets built from has "Править вики-текст" as the value for messages:visualeditor-ca-editsource rather than "Редагувати код"."

So the problem seems to be in the (new JSON-based) l10nupdate process.
screenshot

Environment- test2

Steps-
1>1> Open a blank page in VE and type in some text.
2>At the end of the text insert a comment.
3>Click on the Comment , to open the comment edit dialog.
4> Now while the cursor is still in the comment edit dialog , click to insert a Template.
5> As you start typing, add any template from the list that shows likely matches. For Example -select the “Bar” template.
6>Type in Field name and insert the template.
7>Notice the template does get added and then a snowman like character gets triggered after it.

Behavior found in Chrome,FF and Safari.

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F14172}
In FF, the highlight seems to mask the comment icon.See screenshot_FF.
Created attachment 16120
screenshot_FF

**Attached**: {F14173}
Issue fixed in beta and test2
Should be now fully fixed in master; deployment to production scheduled for 4 hours' time.
Change 150224 merged by jenkins-bot:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150274 merged by jenkins-bot:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150274
Change 150224 restored by Catrope:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150274 had a related patch set uploaded by Catrope:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150274
Change 150224 abandoned by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

Reason:
I give up.

https://gerrit.wikimedia.org/r/150224
Change 150224 restored by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150224 abandoned by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150224 had a related patch set uploaded by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150222 abandoned by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150222
Change 150222 had a related patch set uploaded by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150222
Change 149920 merged by jenkins-bot:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/149920
Change 149920 had a related patch set uploaded by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/149920
Change 149920 had a related patch set uploaded by Catrope:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/149920
confirmed in betalabs. Try the template "Bar chart"
If a paragraph contains a template, and VisualEditor is used to insert two characters somewhere after the template, and the second character is deleted with backspace, then the first character will be replaced by another character that is duplicated from several positions before that character.

To reproduce, go to 

https://en.wikipedia.org/w/index.php?title=User:AxelBoldt/Sandbox&oldid=618813650&veaction=edit

and change the word "Italian" in the first sentence to "Itaxxlian", then delete the second x. Result: "Itatlian", where the second "t" results from duplication of the first "t". 

This is a consequence of the IPA template earlier in the paragraph. The test file also contains a paragraph without template, where the bug does not occur, and a paragraph with a convert template, where the bug does occur.

Wikipedia is at MW 1.24wmf15 and I'm on Windows 7 running Chrome 36.0.1985.125 m.

--------------------------
**Version**: unspecified
**Severity**: normal
Should be now fully fixed in master; deployment to production scheduled for 4 hours' time.
*** Bug 68789 has been marked as a duplicate of this bug. ***
Change 150224 merged by jenkins-bot:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150274 merged by jenkins-bot:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150274
Change 150224 restored by Catrope:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150274 had a related patch set uploaded by Catrope:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150274
Change 150224 abandoned by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

Reason:
I give up.

https://gerrit.wikimedia.org/r/150224
Change 150224 restored by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150224 abandoned by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150224 had a related patch set uploaded by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150222 abandoned by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150222
Change 150222 had a related patch set uploaded by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150222
Change 149920 merged by jenkins-bot:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/149920
Change 149920 had a related patch set uploaded by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/149920
Change 149920 had a related patch set uploaded by Catrope:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/149920
The effect seems to occur whenever you insert two or more characters in a paragraph after a template and then delete any one of them. The inserted characters do not have to be contiguous. The distance between first inserted character and duplicated character depends on the template.

I believe VE internally uses the length of the unexpanded template where it should use the length of the expanded template.
Yeah, this looks a bit like bug 67862 but less severe.
Maybe related: bug 67862?
Take any article long enough to notice the effect (i.e. Cake on en.wp).
Delete any of the pics at the bottom of the article.
Notice the focus jumps back at the top.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=58038
https://bugzilla.wikimedia.org/show_bug.cgi?id=68589
Change 151400 merged by jenkins-bot:
Set selection before focusing document

https://gerrit.wikimedia.org/r/151400
Change 151400 had a related patch set uploaded by Jforrester:
Set selection before focusing document

https://gerrit.wikimedia.org/r/151400
It also happens with templates, so I'm guessing this is probably worrying but maybe a duplicate.
1) VEdit https://fr.wikipedia.org/wiki/Marie_Coutant?veaction=edit .

2) Reach the end of the second paragraph, find the word Métivier.

3) Start typing right before the "M" or after the "r". Pawns appear and random letters can appear in the word. Click on the word again, and watch letters and pawns multiply.

4) Abandon the edit, go back to step 1 and 2.

5) Add an "h" after the "t": Méthivier.

6) Enter the link tool and click Supprimer to suppress the link.

7) Notice the "h" has become an "é": Météivier. This is just an example, you can get different results adding other letters.

--------------------------
**Version**: unspecified
**Severity**: major
I think this was caused by the pawning/snowmen issue that we fixed and pushed to production yesterday.
1. Create a document with two paragraphs, and make both of them entirely bold
2. Put the cursor at the beginning of the first paragraph, and type a character. This character will be bold
3. Put the cursor at the beginning of the second paragraph, and type a character. This character will not be bold

#2 and #3 should be consistent. In fact, #2 *only* happens at the very start of the document, #3 happens everywhere else.

The reason this is broken is that the code computing the new insertionAnnotations in ve.dm.Surface#setSelection by pulling from the left does not take paragraph boundaries into account at all. In case #3, it tries to pull from the left across the paragraph boundary, but because getAnnotationsFromOffset() doesn't work the way it thinks it does (the offset at the end of the first paragraph is a content offset, but getting its annotations returns an empty set) that doesn't work, and so text inserted at the beginning of this paragraph is not annotated. However, at the very start, the getRelativeContentOffset() call that computes the offset to the left bounces back and returns the offset to the right instead (1), so left === right, and we end up pulling from the right and bolding the inserted text.

So really, the code is trying to achieve the wrong behavior (#2), but in most cases that breaks and we end up with the right behavior (#3). So the correct behavior is achieved completely by accident, except in one edge case where the code successfully achieves the wrong behavior.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 155260 merged by jenkins-bot:
Fix check for left/right annotations

https://gerrit.wikimedia.org/r/155260
Change 150378 abandoned by Catrope:
Fix pulling of annotations when typing at the beginning of the document

Reason:
https://gerrit.wikimedia.org/r/155260 fixes this bug

https://gerrit.wikimedia.org/r/150378
Change 155260 had a related patch set uploaded by Catrope:
Fix check for left/right annotations

https://gerrit.wikimedia.org/r/155260
Change 150378 had a related patch set uploaded by Alex Monk:
[WIP] Fix pulling of annotations when typing at the beginning of the document

https://gerrit.wikimedia.org/r/150378
Change 150120 abandoned by Alex Monk:
Fix pulling of annotations when inserting new character at start of document

Reason:
Breaks other things.

https://gerrit.wikimedia.org/r/150120
Change 150120 had a related patch set uploaded by Alex Monk:
Fix pulling of annotations when inserting new character at start of document

https://gerrit.wikimedia.org/r/150120
Steps:

1. Open http://en.wikipedia.beta.wmflabs.org/wiki/7thfeb?veaction=edit
2. Scroll to bottom
3. Place cursor in slug between gallery and references list
4. Cursor right twice

Expected outcome: Cursor ends up in slug at end of the page after the references list

Actual outcome: Error thrown: "offset was inside a handlesOwnChildren node"

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://en.wikipedia.beta.wmflabs.org/wiki/7thfeb?veaction=edit
Change 155260 merged by jenkins-bot:
Fix check for left/right annotations

https://gerrit.wikimedia.org/r/155260
Change 155260 had a related patch set uploaded by Esanders:
Fix check for left/right annotations

https://gerrit.wikimedia.org/r/155260
This doesn't seem to be related to focusable nodes or the end of the document. All you need to do is put the cursor in a block slug after a references list.

Suppose the references list is at (23,25). What happens is this:
* setSelection (25,25) is called
* It tries to compute insertion annotations by pulling from the left
* It does so by calling getNearestContentOffset( 24, -1 )
* Two stack levels deeper, getRelativeOffset() notices that 24 is inside of a handlesOwnChildren node and throws an exception

Questions:
* Why is reference list a handlesOwnChildren node? Is it because <ref> can be nested inside of <references>?
* Why do we do offset-1 here? There is a Math.max() to guard against ending up at -1, but this bug uncovers another reason why subtracting one from an offset is dangerous and should ideally never be done
VE get stucks when saving settings

How to reproduce:
1) click "Options" and then "cancel"
2) click "Advanced settings" and then "apply changes"

After this it gets stuck. It's "applying changes" even if you didn't do any changes. You must reload the page to make your changes again.

--------------------------
**Version**: unspecified
**Severity**: normal
Yes, this is fixed in wmf15 (as on MediaWiki.org right now) but not in wmf14 (on enwiki etc.).
I think Ed fixed this in Gerrit change 148671
(In reply to Alex Monk from comment #1)
> Can't reproduce this issue.
> 
> Stryn, do you get an error in the JS console when this happens?

Yup, with Firefox and Chrome

Firefox gives:
TypeError: bindings[i] is undefined load.php:608

and Chrome:
Uncaught TypeError: Cannot read property 'context' of undefined VM51:8oo.EventEmitter.disconnect VM51:8ve.ui.MWCategoriesPage.teardown VM53:224(anonymous function) VM53:229(anonymous function) VM51:42OO.ui.Process.execute VM51:43OO.ui.Dialog.executeAction VM51:33OO.ui.ProcessDialog.executeAction VM51:74OO.ui.Dialog.onActionClick VM51:31oo.EventEmitter.emit VM51:7oo.EventEmitter.emit VM51:7OO.ui.ButtonWidget.onClick VM51:102proxy load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140724T1…:6jQuery.event.dispatch load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140724T1…:65elemData.handle
Can't reproduce this issue.

Stryn, do you get an error in the JS console when this happens?
screenshot

Test Environment-test2 and betalabs
Steps-
1> open a blank page in VE.
2>type some text and at the end of the last character (could be a space after the text or the last character in the text itself) insert a comment.
3>Now click to move the cursor after the comment, this closes the comment dialog too.
4> Insert a whitespace.I cannot see the cursor at this point.
5> click on the page again and the cursor appears before the start of the line. 
6>Hit the spacebar and then press backspace key. A pawn appears next to the comment. Please see screenshot_chrome.

In Safari-
Try the same steps and at step#6 I get the WebKit2WebProcess.exe  dialog saying “WebKit2WebProcess.exe has encountered a problem and needs to close.”. After I click to send the error report and I get logged out of my account. 

In FF 31- no issues were found when whitespace was inserted after a comment.

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F14311}
(In reply to James Forrester from comment #9)
> (In reply to Ritu Swain from comment #8)
> > thank you. just for future.. this is not the right forum ..
> 
> No problem. :-)
> 
> > but how can i find the  release version of beta?
> 
> Unhelpfully, it's not present of beta (because it doesn't exist yet), but
> the specific version of VisualEditor can be found inside VE itself:
> 
> If you go to a page and enter VisualEditor, click on the help menu – "(?)"
> in the toolbar on the right (left if RTL). The version hash will be at the
> bottom of the menu.
> 
> mediawiki.org is currently running "Version ce427f4 18:49, 29 July 2014".
> 
> en.wikipedia.beta.wmflabs.org is currently running "Version 3dd63f7 20:00,
> 30 July 2014".
> 
> > if a bug is not reproducible in beta , but it is in test2 , then can it be
> > called fixed?
> 
> Normally, as long as we think it's actually fixed. Sometimes other changes
> can have ripple effects, but sometimes it's caused by the local wiki's
> configuration (or something else), so it's not a perfect call each time,
> sadly.

thank you :)
(In reply to Ritu Swain from comment #8)
> thank you. just for future.. this is not the right forum ..

No problem. :-)

> but how can i find the  release version of beta?

Unhelpfully, it's not present of beta (because it doesn't exist yet), but the specific version of VisualEditor can be found inside VE itself:

If you go to a page and enter VisualEditor, click on the help menu – "(?)" in the toolbar on the right (left if RTL). The version hash will be at the bottom of the menu.

mediawiki.org is currently running "Version ce427f4 18:49, 29 July 2014".

en.wikipedia.beta.wmflabs.org is currently running "Version 3dd63f7 20:00, 30 July 2014".

> if a bug is not reproducible in beta , but it is in test2 , then can it be
> called fixed?

Normally, as long as we think it's actually fixed. Sometimes other changes can have ripple effects, but sometimes it's caused by the local wiki's configuration (or something else), so it's not a perfect call each time, sadly.
thank you. just for future.. this is not the right forum .. but how can i find the  release version of beta?

if a bug is not reproducible in beta , but it is in test2 , then can it be called fixed?
Sorry, yes, I meant wmf16. My apologies!
(In reply to James Forrester from comment #5)
> Sounds like it was fixed in wmf15 then.

a bit confused, i can reproduce it in test2 with the release version  1.24wmf15 (148011a).
Sounds like it was fixed in wmf15 then.
(In reply to Alex Monk from comment #3)
> I can't reproduce this now, Roan couldn't either. Ritu, does this still
> happen for you?

I can reproduce it in test2 , but not in beta.
I can't reproduce this now, Roan couldn't either. Ritu, does this still happen for you?
Confirmed
did a fresh install of Safari, still getting WebKit2WebProcess.exe message.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Page Settings option>Categories
3.Try to add categories 

Observed Result:
After typing into a category name, it getting added twice and trying again throws error:

TypeError: categoryItem is undefined 

See the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F14192}
Verified the fix in production
Verified the fix in test2
Hmm, I can't either. Marking it as fixed.
And I can't reproduce it on deployment-prep any more. Rummana?
Also, I am getting a different error this time while closing the dialog second time:
Uncaught TypeError: Cannot read property 'disconnect' of undefined
Can now successfully reproduce on deployment-prep, but not my local wiki...
This is still happening on Betalabs
Silly Gerrit.
Change 151088 merged by jenkins-bot:
Tear down meta dialog pages when cancelling

https://gerrit.wikimedia.org/r/151088
The patch is not even merged yet, assuming the bug was closed by mistake.
Change 151088 had a related patch set uploaded by Alex Monk:
Tear down meta dialog pages when cancelling

https://gerrit.wikimedia.org/r/151088
Reproduced it today following these steps

1.Open a page with VE
2.Go to Page Settings option>Categories
3.Type a category name in the text field
4.When the drop down box appears, close the dialog
5.Again, reopen the Page Settings option>Categories
6.Now select a category from the drop down box

Observed Result:

It gets added twice,if you cancel the dialog box again it will throw the error:
TypeError: categoryItem is undefined 

If you reopen the Page Settings option>Categories, you will get stuck inside it.
Seems to be working again. Probably a deployment gremlin. Again. :-(
Can't reproduce...
Please upgrade gerrit to 2.12.

Following plugins needs to be tested and fixed in the new version (and blocks an upgrade):

```
its-phabricator	2.8.1	Enabled
its-phabricator-from-bugzilla	2.8.1	Enabled
github-create-1.0-rc0	1.0-rc0	Enabled
deleteproject	2.8.1	Enabled
```

Release notes for 2.12 are at https://gerrit-documentation.storage.googleapis.com/ReleaseNotes/ReleaseNotes-2.12.html

--------------------------
See Also: T65847
Change 300815 abandoned by Chad:
TESTING STUFF

Reason:
Yay stuff works now.

[[https://gerrit.wikimedia.org/r/300815]]
Change 300815 had a related patch set uploaded (by Chad):
TESTING STUFF

[[https://gerrit.wikimedia.org/r/300815]]
```
2016-07-25

    03:26 hashar: scandium: migrating zuul-merger repos from lead to gerrit.wikimedia.org: find /srv/ssd/zuul/git -path '*/.git/config' -print -execdir sed -i -e 's/lead.wikimedia.org/gerrit.wikimedia.org/' config \;
    02:03 ostriches: gerrit: reindexing lucene now that we have new data. searches/dashboards may look a tad weird for a bit
    01:53 hashar: starting Zuul
    01:51 mutante: restarted grrrit-wm
    01:39 ostriches: lead: turning puppet back on, here we go
    01:38 jynus: m2 replication on db2011 stopped, master binlog pos: db1020-bin.000968:1013334195
    01:37 hashar: scandium: restarted zuul-merger
    01:36 ostriches: ytterbium: Stopped puppet, stopped gerrit process.
    01:34 mutante: switched gerrit-new to gerrit in DNS
    01:30 ostriches: lead: stopped puppet for a few minutes
    01:17 hashar: scandium: migrating zuul-merger repos to lead find /srv/ssd/zuul/git -path '*/.git/config' -print -execdir sed -i -e 's/ytterbium.wikimedia.org/lead.wikimedia.org/' config \;
    01:10 hashar: stopping CI
    01:09 jynus: reviewdb backup finished, available on db1020:/srv/tmp/2016-07-25_00-54-31/
    01:02 ostriches: rsyncing latest git data from ytterbium to lead
    00:57 mutante: manually deleted reviewer-counts cron from gerrit2 user, runs as root and puppet does not remove crons unless ensure=>absent
    00:55 jynus: starting hot backup of db1020's reviewdb
```
2016-07-25

    03:26 hashar: scandium: migrating zuul-merger repos from lead to gerrit.wikimedia.org: find /srv/ssd/zuul/git -path '*/.git/config' -print -execdir sed -i -e 's/lead.wikimedia.org/gerrit.wikimedia.org/' config \;

    02:03 ostriches: gerrit: reindexing lucene now that we have new data. searches/dashboards may look a tad weird for a bit
    01:53 hashar: starting Zuul
    01:51 mutante: restarted grrrit-wm
    01:39 ostriches: lead: turning puppet back on, here we go
    01:38 jynus: m2 replication on db2011 stopped, master binlog pos: db1020-bin.000968:1013334195
    01:37 hashar: scandium: restarted zuul-merger
    01:36 ostriches: ytterbium: Stopped puppet, stopped gerrit process.
    01:34 mutante: switched gerrit-new to gerrit in DNS
    01:30 ostriches: lead: stopped puppet for a few minutes
    01:17 hashar: scandium: migrating zuul-merger repos to lead find /srv/ssd/zuul/git -path '*/.git/config' -print -execdir sed -i -e 's/ytterbium.wikimedia.org/lead.wikimedia.org/' config \;
    01:10 hashar: stopping CI
    01:09 jynus: reviewdb backup finished, available on db1020:/srv/tmp/2016-07-25_00-54-31/
    01:02 ostriches: rsyncing latest git data from ytterbium to lead
    00:57 mutante: manually deleted reviewer-counts cron from gerrit2 user, runs as root and puppet does not remove crons unless ensure=>absent
    00:55 jynus: starting hot backup of db1020's reviewdb
Change 300660 abandoned by Dzahn:
switch gerrit-new to gerrit

Reason:
duplicate of https://gerrit.wikimedia.org/r/#/c/299007/

[[https://gerrit.wikimedia.org/r/300660]]
Change 300660 had a related patch set uploaded (by Dzahn):
switch gerrit-new to gerrit

[[https://gerrit.wikimedia.org/r/300660]]
Change 300657 merged by Dzahn:
gerrit: lower TTLs to 600

[[https://gerrit.wikimedia.org/r/300657]]
Change 300657 had a related patch set uploaded (by Dzahn):
gerrit: lower TTLs to 600

[[https://gerrit.wikimedia.org/r/300657]]
> Yeah I know these hours weren't ideal for you, but I'm pretty sure from our testing that things will be ok. And "broken CI" is a condition for rolling things back.

There is never a good time.  I should be to make a personal arrangement to show up without waking up the whole house!
>>! In T70271#2483146, @hashar wrote:
> We would want to keep the ssh host fingerprint for the Gerrit embedded SSH daemon.  If it changes bunch of bots will stop until manually accepted.
> 

This has been done. I'll get it done in puppet too so we don't miss it next time.

> 1am-4am UTC turns to 3am-7am CET, I can't reasonably work from home at those hours. not much opportunity until 6:30am UTC at best.
> 
> Then it is very low traffic at those hours, so I guess we can afford to have CI potentially broken somehow for a few hours.

Yeah I know these hours weren't ideal for you, but I'm pretty sure from our testing that things will be ok. And "broken CI" is a condition for rolling things back.
We would want to keep the ssh host fingerprint for the Gerrit embedded SSH daemon.  If it changes bunch of bots will stop until manually accepted.

1am-4am UTC turns to 3am-7am CET, I can't reasonably work from home at those hours. not much opportunity until 6:30am UTC at best.

Then it is very low traffic at those hours, so I guess we can afford to have CI potentially broken somehow for a few hours.
@demon Sounds sane! :) Thanks for your work and the work of any other one involved so far :)
Sounds good to me. I can be there Sunday night Pacific time.
@MoritzMuehlenhoff Gerrit should show a little orange bubble near the "Parent(s)" section of the commit information, which indicates, that the parent isn't the latest one (which normally allows you to rebase). See this example:
{F4271015}

Merge conflicts (the current "Can merge: No" section), btw., is now a string with a red font in the change information box:
{F4271027}
>>! In T70271#2456703, @demon wrote:
>>>! In T70271#2456522, @AlexMonk-WMF wrote:
>> I don't think the VE backport submodule update issue has been fixed :/
>> I made https://gerrit-new.wikimedia.org/r/#/c/298010/ but it doesn't look like the submodule update showed up against mediawiki/core.git's wmf/1.28.0-wmf.1 branch
> 
> It probably will require a manual fix in the database where the old registration took place. Check with `gsql`?

```gerrit> select * from submodule_subscriptions where submodule_path like '%VisualEditor%' and submodule_branch_name = 'refs/heads/wmf/1.28.0-wmf.1';
 submodule_project_name | submodule_branch_name       | super_project_project_name | super_project_branch_name   | submodule_path
 -----------------------+-----------------------------+----------------------------+-----------------------------+------------------------
 VisualEditor           | refs/heads/wmf/1.28.0-wmf.1 | mediawiki/core             | refs/heads/wmf/1.28.0-wmf.1 | extensions/VisualEditor
(1 row; 18 ms)```
The old gerrit version only showed the "Rebase" button if the patch was in need of the rebase, while on gerrit-new the option is always displayed. If that's configurable it would be nice to revert to the old behaviour (since it makes it more obvious whether a patch needs to be rebased before merging)
@demon hi, I noticed that it dosent show the links to phabricator from the changes or from project pages.

And it seems zuul is not testing in gerrit-new.

And it the performance has really increased, loads instantly for me on a 80mbps connection from BT.
>>! In T70271#2456476, @AlexMonk-WMF wrote:
> I've been messing around with gerrit-new. On the projects list, a lot appear to be duplicated under the 'git/' prefix?

Looks like a mistake on-disk from my part from when we were doing replication of repositories via rsync. Deleted the git/* ones.
>>! In T70271#2456522, @AlexMonk-WMF wrote:
> I don't think the VE backport submodule update issue has been fixed :/
> I made https://gerrit-new.wikimedia.org/r/#/c/298010/ but it doesn't look like the submodule update showed up against mediawiki/core.git's wmf/1.28.0-wmf.1 branch

It probably will require a manual fix in the database where the old registration took place. Check with `gsql`?
I don't think the VE backport submodule update issue has been fixed :/
I made https://gerrit-new.wikimedia.org/r/#/c/298010/ but it doesn't look like the submodule update showed up against mediawiki/core.git's wmf/1.28.0-wmf.1 branch
I've been messing around with gerrit-new. On the projects list, a lot appear to be duplicated under the 'git/' prefix?
Change 298041 merged by Dzahn:
gerrit: make Apache config compatible with 2.4

[[https://gerrit.wikimedia.org/r/298041]]
Change 298041 had a related patch set uploaded (by Dzahn):
gerrit: make Apache config compatible with 2.4

[[https://gerrit.wikimedia.org/r/298041]]
Paladox spoke to hashar after the comment above and the user does not have to be created (?)
The user jenkins-bot will need to be created in lead 

https://github.com/wikimedia/operations-puppet/blob/30ffadcb6d8e6925affd55958981dce8c2c448d9/modules/role/manifests/zuul/configuration.pp#L8
We need to update 

https://github.com/wikimedia/operations-puppet/blob/30ffadcb6d8e6925affd55958981dce8c2c448d9/modules/role/manifests/zuul/configuration.pp#L8

and 

https://github.com/wikimedia/operations-puppet/blob/30ffadcb6d8e6925affd55958981dce8c2c448d9/modules/contint/manifests/firewall.pp#L60
We need to update https://github.com/wikimedia/operations-puppet/blob/30ffadcb6d8e6925affd55958981dce8c2c448d9/modules/role/manifests/zuul/configuration.pp#L8
Also the zuul seems to work perfectly with gerrit 2.12 (no lost in connection or ssh connection) It seems to me that may have been a bug in gerrit 2.8.
@hashar Ive been testing zuul, jenkins and gerrit 2.12 and it works. See 

* https://gerrit-zuul.wmflabs.org/

* https://gerrit-jenkins.wmflabs.org/

* https://gerrit-test.wmflabs.org/
Ive been testing zuul, jenkins and gerrit 2.12 and it works. See 

* https://gerrit-zuul.wmflabs.org/

* https://gerrit-jenkins.wmflabs.org/

* https://gerrit-test.wmflabs.org/
The upgrade of Gerrit definitely has an impact on Zuul.

The version we run is based on upstream 66c8e52 which is:
* from early December 2015 (7 months ago)
* when they were still running Gerrit 2.8.4
* before a massive refactoring of how Zuul connects to Gerrit

I tried to upgrade Zuul further but a mysteriously issue happened related to the Zuul / Gerrit ssh connection: T137525 . I haven't managed to reproduce it locally or on labs though :-(

OpenStack has (since December) switched to Gerrit 2.11.x + patches and I haven't looked at Zuul code whether there are changes that are needed. They will most probably be based on massive refactoring that we still do not have in our version.


The, maybe the Zuul version will just work with Gerrit 2.12.  If `stream-events` hasn't changed and the `review` command is still compatible, we might be just fine.


----------

As part of the migration we also have to:
* update various Zuul related bits that points to ytterbium
* most probably manually change the remote URL of zuul-merger repos on scandium in /srv/ssd/zuul/git


----

Also I think the old change screen is gone and that is going to cause major havoc  and complains for sure. So wanna communicate about that user facing change ahead of time.
Re timing:
I guess email Ops list with the plan, ask for a volunteer for Sunday (offer $drinks), if someone replies before tomorrow (Saturday) when Chad wake up then he should send out the announcement that we'll do the Sunday maintenance window.
Tested the upgrade path today using copies of production data (Sql and Git) and the 2.12.2 package we built for Jessie. It went well. Couple of more tests this afternoon and then it looks like we can run the upgrade ASAP. Workflow will be:

1) Decide/announce a window
2) Stop puppet on `ytterbium`, stop Gerrit processes
3) Do a last snapshot of the Gerrit database, in case we have to roll back
4) Apply puppet manifest to new server `lead`
5) Run puppet on `lead`, which will issue the schema upgrades to m2-master (will take about 4-5 minutes from testing)
6) Stop puppet on `lead` until (7) is done to keep Gerrit from being brought up just yet
7) Run the reindexing process on new `lead`, will take about 45-60m from testing.
8) Re-enable puppet so systemd can take over running gerrit
9) Verify installation
10) Point DNS from ytterbium to `lead`

The whole process, ideally, should only take about an hour to an hour and a half based on my testing. I want to give myself 3 hours in case. This is highly disruptive so needs to be announced widely, but soon (as in days, not weeks). I'm almost thinking this weekend since less disruption than on a workday...

I will need a root user on hand to take the snapshot and merge puppet changes (which can all be staged beforehand). @Dzahn has been super helpful so far, but I know @jcrespo is the DBA.
Tested the upgrade path today using copies of production data (Sql and Git) and the 2.12.2 package we built for Jessie. It went well. Couple of more tests this afternoon and then it looks like we can run the upgrade ASAP. Workflow will be:

1) Decide/announce a window
2) Stop puppet on `ytterbium`, stop Gerrit processes
3) Do a last snapshot of the Gerrit database, in case we have to roll back
4) Apply puppet manifest to new server `lead`
5) Run puppet on `lead`, which will issue the schema upgrades to m2-master (will take about 4-5 minutes from testing)
6) Stop puppet on `lead` until (7) is done to keep Gerrit from being brought up just yet
7) Run the reindexing process on new `lead`, will take about 30-45m from testing.
8) Re-enable puppet so systemd can take over running gerrit
9) Verify installation
10) Point DNS from ytterbium to `lead`

The whole process, ideally, should only take about an hour to an hour and a half based on my testing. I want to give myself 3 hours in case. This is highly disruptive so needs to be announced widely, but soon (as in days, not weeks). I'm almost thinking this weekend since less disruption than on a workday...

I will need a root user on hand to take the snapshot and merge puppet changes (which can all be staged beforehand). @Dzahn has been super helpful so far, but I know @jcrespo is the DBA.
Another feature/bug in 2.11 (and with it in 2.12, too) would be a fix for:
https://bugs.chromium.org/p/gerrit/issues/detail?id=1207

Yes... on a german keyboard you can't use the shortkeys for next/previous file in the diff view, which isn't really great  :(
@demon Hi, any news here? :) Is it possible to have a look at a test instance running the newer Gerrit version?
I don't think, that such a hidden feature, especially because it isn't mentioned in the changelog and only available by adding a query to the url, is something which could be named as a "near" feature we've after upgrading :)
There's polygerrit, gerrit said next version but built into gerrit to test at moment. Once updated to gerrit 2.12 add this to your url ?polygerrit=1 the new design is really nice.
I guess ops may like https://code.google.com/p/gerrit/issues/detail?id=3293
>>! In T70271#2107030, @siebrand wrote:
> Is there any way to find out if this will or won't be scheduled?

When I have a firm date/time for switching to the new machine & version I'll let everyone know. Right now I'm getting the box prepped and testing the new version.
I believe that they have a setup a new server and that will use gerrit 2.12  they will be switching soon I think. I may be wrong.
Is there any way to find out if this will or won't be scheduled?
Gerrit 2.12 includes support for signed pushes now which some users on Wikipedia use.

Release notes at https://gerrit-documentation.storage.googleapis.com/ReleaseNotes/ReleaseNotes-2.12.html
Maybe create a test site with gerrit and test weather upgrading gerrit will cause zuul and jenkins too break.
OpenStack is upgrading to 2.11 on Dec 16th (from 2.8.4+).  They already wanted to upgrade a couple weeks ago but cancelled it, maybe because it was not working properly.

No idea whether 2.12 will work.

Upgrade of Gerrit usually have side effect with Zuul.
Yes and plus makes it really easy to edit in browser. Some users like using the gerrit tool provided by Wikimedia to upload there patches with this update they can do it from gerrit supper easy.
Although Phabricator is the glorious future, we should upgrade Gerrit at least for stability + security improvements if nothing else. 2.12 is basically ready to go, testing it now.
Gerrit 2.11.1 has been released doesent show it on its front page but in the release notes it does. Please visit https://gerrit-documentation.storage.googleapis.com/ReleaseNotes/ReleaseNotes-2.11.1.html which I think fixed the problem that blocked us from upgrading.
And delete project can be downloaded at https://ci.gerritforge.com/view/Plugins-stable-2.11/job/Plugin_delete-project_stable-2.11/ and already compiled to works with gerrit 2.11.
And includes more features and no longer uses google to generate charts.
If you doint want to compile gitblit use this https://ci.gerritforge.com/job/Plugin_gitblit_stable-2.11/ which is already complied and works for me.
Me too.
It's been a while since I looked at upstream…

* Keyboards shortcuts in diff view all work correctly again, so do long lines; unified diff is back, as well as prefs. There's an inline button to leave a comment when you select text; no one is going to miss double-clicking (you can effectively triple-click now). There is literally no reason not to prefer the new diff view now. https://gerrit-review.googlesource.com/#/c/68292/1/gerrit-server/src/main/java/com/google/gerrit/server/config/GerritGlobalModule.java
* Automated comments (bots, new patchsets) in change view are collapsed by default.
* "Size" column in changes lists! *drools* https://gerrit-review.googlesource.com/#/q/status:open
* "Conflicts with" pane! "Merge conflict" status in changes lists!

so much awesome

seriously

can we update already plz?
And improvements to list of projects because it doesent show all of projects In one list it now puts them on different pages.
Yes get them to look at that is better.
Or they can just [[ https://gerrit-review.googlesource.com/#/c/68304/ | look at upstream ]].
I doint mean the current new screen in gerrit on Wikimedia. Wikimedia could set up a test gerrit server with the new screen and get feedback since they wont upgrade unless the majority like it. And when they moved bug software from bugzilla to phabricator that was a big user ajust ment. so the same can be applied here.
Note that the new screen in 2.11 is said to have received much improvement, so asking users based on the current new screen makes no sense.
Yep. Since that would be a breaking change I suggest to create a feedback online and ask users to say would they like the new change screen or not. And say the improvements it would have if we upgrade.
That release seems to include the patch QChrist identified as missing and according to my reading of the source it will ship with jgit 4.0.0.201505050340-m2. If that works for openstack...

Then the only thing remaining we identified is living with the old ChangeScreen being gone.
Hi 2.11.1 release notes at https://gerrit.googlesource.com/gerrit/+/refs/heads/stable-2.11/ReleaseNotes/ReleaseNotes-2.11.1.txt looks like they may have fixed performance bug.
>>! In T70271#1296359, @Paladox wrote:
> we could upgrade to latest 2.8.x release

...which isn't handled in this task (now i feel like a parrot o.O) - See {T65847}.
Hi yes we could upgrade to latest 2.8.x release which would includes fixes.
>>! In T70271#1285022, @Paladox wrote:
> Hi what about upgrading to 2.8.6.1

Not handled in this task. - See T65847.
And then once 2.11 is fixed. then disccuss about upgrading since it removes the old screen which everyone is used too.
2.10 should be the version we upgrade to since it still has the old change screen but not default you would have to set it default and you can now customise the my page
or 2.9 or 2.10. Note 2.9 onwards the bugzilla plugin uses the new its-bugzilla instead of old plugin and plugins list are now shown.
Hi what about upgrading to 2.8.6.1 since it is a minor upgrade from 2.8.1 to 2.8.6.1 and in preparation for if people are in favour of upgrading to 2.11 when the bug is fixed.
That definitively sounds like a blocker (i assume we have a comparable traffic in our gerrit-instance).
>>! In T70271#1281258, @QChris wrote:
> I guess @hashar was instead refering to the post about gerrit complaining about corrupt pack files. See also https://groups.google.com/forum/#!topic/repo-discuss/CYYoHfDxCfA

Yup that is the one I wanted to refer to sorry. OpenStack definitely want to upgrade so I am sure they will push to get it fixed (or fix it themselves).
>>! In T70271#1280109, @Paladox wrote:
> I believe they fixed problem but haven't released a new version of gerrit for 2.11 with the fix they only released it with 2.10. Please see https://gerrit-documentation.storage.googleapis.com/ReleaseNotes/ReleaseNotes-2.10.4.html

The fix you mentioned is for [[https://code.google.com/p/gerrit/issues/detail?id=3300|Gerrit Issue 3300]]. That was the bug for the performance degradation in 2.10.

I guess @hashar was instead refering to the post about gerrit complaining about corrupt pack files. See also https://groups.google.com/forum/#!topic/repo-discuss/CYYoHfDxCfA
I believe they fixed problem but haven't released a new version of gerrit for 2.11 with the fix they only released it with 2.10. Please see https://gerrit-documentation.storage.googleapis.com/ReleaseNotes/ReleaseNotes-2.10.4.html
For what is worth, OpenStack has upgraded from Gerrit 2.8 to 2.11 and had to revert due to JGit issue.

Revert announce with some details is: http://lists.openstack.org/pipermail/openstack-infra/2015-May/002750.html

Jeremy Stanley (fungi) and James E. Blair (jeblair) can be reached on IRC in #openstack-infra (or one can mail them).
This extension its-phabricator has been fixed and is now compatible with 2.11 whereas I am not sure about its-phabricator-from-bugzilla since I carnt find source code.
>>! In T70271#1271255, @QChris wrote:
> Not sure about `github-create` ... is the code for that anywhere in the open?

No, that's my secret sauce. I have to make sure I still have the code even.
>>! In T70271#1271255, @QChris wrote:
> * 'Generate HTTP Password' is gone. I know that at least a few people used this at WMF.

https://gerrit-documentation.storage.googleapis.com/ReleaseNotes/ReleaseNotes-2.11.html#remove-generate-http-password-capability reads:
> Remove the Generate HTTP Password capability.
>
> The Generate HTTP Password capability has been removed to close a security vulnerability. Now only administrators are allowed to generate and delete other users' http passwords via the REST or SSH interface.
>
> It is encouraged to clean up your project.config settings after upgrading.

This reads as if the ability for users except admins to do that for other users is gone, but users are still able to do that for themselves. ( https://android-review.googlesource.com/ is on 2.11 but integrated with Google Account so that one can still use the feature there possibly doesn't mean anything for our setup. )
Hi here is link for updates for its-phabrictor https://gerrit.googlesource.com/plugins/its-phabricator/+/master
>>! In T70271#1269328, @demon wrote:
> We currently have the following plugins:

I added them (the ones need an update/test) to the task description :)
We currently have the following plugins:
```
commit-message-length-validator	v2.8.1	Enabled
deleteproject	2.8.1	Enabled
download-commands	v2.8.1	Enabled
github-create-1.0-rc0	1.0-rc0	Enabled
its-phabricator	2.8.1	Enabled
its-phabricator-from-bugzilla	2.8.1	Enabled
replication	v2.8.1	Enabled
reviewnotes	v2.8.1	Enabled
```
`its-phabricator-*` ones are mission-critical and must be upgraded and functioning. `github-create` primarily affects me and @qchris but would be nice to still have working. `deleteproject` we don't maintain but will have to rebuild. The remaining 4 are all bundled and should Just Work.
[08:59:05] <^d> Somebody convince qchris to redo the plugins and I'll do it :p

@qchris, are you up for that? :)
+1. I still have hope that there is someone who can do this and who doesn't hate Gerrit so much as to not touch it with a stick.
>>! In T65847#1268664, @Nemo_bis wrote:
> The request for 2.11 should be moved to T70271. This report is for requesting a minor version upgrade within 2.8.x.

Then this task should be reopened.
(In reply to christian from comment #6)
> Since people asked for more reasons, why to not upgrade:

Thanks, that's useful. None of these points applies to 2.8.x upgrades (bug 63847), correct?
Since people asked for more reasons, why to not upgrade:

* Search backend gets switched. And the first test I made with it some time back
  were not super solid. That might have changed in the meantime, and the old
  (=current) search system has it's warts too, but we know them, and can live
  with them. No hidden dangers there.

* At first glance, it seems there are database schema changes. Those typically
  make it hard to downgrade if something goes wrong. So the upgrade would need
  good preparation. We cannot “just try it out”.

* We'd need new plugins, since part of the functionality that was in core before
  got put into separate plugins.

* We'd need to rebuild our bugzilla integration.
So if it's just some new random features with questionable gain in our usecase, I will close this as WILL NOT FIX.
It also has a new plugin for bugzilla.
Well the new design that is an option in the current version of gerrit on wikimedia is a part of the new design but they also redesigned it complete in 2.9. It also includes a new side by side diff and also Fix truncated long lines in new side-by-side diff screen.
Gerrit 2.9 includes the new change screen which is worse. That's a reason not to upgrade.

Plus we're planning a Phabricator migration soon-ish. What's to gain?
I don't consider "please upgrade some software to some latest version" very useful if there are not 1) very good reasons to do this 2) urgently.
Your list above does not provide any good reasons.
We get "Unknown error" (not internationalised) when saving on officewiki.

This is because the response object given to ve.init.mw.Target.onSave is actually a jqXhr(?) object here for some reason, which has an error function. The data we actually want is in the responseJSON property of this, and we can also get it via .done( ... ).

This stuff comes through tryWithPreparedCacheKey and the way it fits together with everything else wasn't very clear here (lots of chaining deferreds etc.)

--------------------------
**Version**: unspecified
**Severity**: major
I fixed it up in the remaining places:
```commonswiki         MediaWiki:LAPI.js
dewikiversity       MediaWiki:LAPI.js
enwiki              MediaWiki:LAPI.js
fawiki              MediaWiki:LAPI.js
huwiki              MediaWiki:LAPI.js
huwikiquote         MediaWiki:LAPI.js
kawiki              MediaWiki:LAPI.js
mlwiki              MediaWiki:LAPI.js
nnwiki              MediaWiki:LAPI.js
rowiki              MediaWiki:LAPI.js
ruwikibooks         MediaWiki:LAPI.js
srwikibooks         MediaWiki:Common.js/Core.js
svwiki              MediaWiki:LAPI.js
zhwiki              MediaWiki:LAPI.js```
>>! In T70235#719892, @Krenair wrote:
> So that last srwikibooks entry appears to be in an unused file... Roan, can you release and upstream the LAPI.js changes to the other wikis? I don't think I can do it (I'd have to do it as staff, but my global editinterface is personal, so...).

Sorry for the extreme delay: https://eo.wikipedia.org/w/index.php?title=MediaWiki:LAPI.js&diff=prev&oldid=5628789
So that last srwikibooks entry appears to be in an unused file... Roan, can you release and upstream the LAPI.js changes to the other wikis? I don't think I can do it (I'd have to do it as staff, but my global editinterface is personal, so...).
https://dpaste.de/JS7k/raw courtesy of legoktm is an mwgrep of all of the redefinitions of bind on the cluster. Yay.
This was caused by local JS overwriting Function.prototype.bind with a broken polyfill that ignores additional parameters rather than passing them to the bound function.

We were using something like onSave.bind( this, doc, saveData ) which should have resulted in a call like onSave( doc, saveData, responseData, statusText, jqXHR ) but the broken polyfill dropped doc and saveData, causing the remaining arguments to be shifted two places to the left. Then when we check if responseData.error is defined, we're really looking at jqXHR.error, which is in fact a method on the jqXHR object, so it's always defined and we always believe there is an error, even if there isn't one. But of course we can't find an error code or error text because we're looking in the wrong place, so we say "Unknown error". In fact, we would say that even if there was an error, because the error data got shifted over into the doc parameter, which we don't look at.

https://office.wikimedia.org/w/index.php?title=MediaWiki:LAPI.js&diff=115901&oldid=24064 fixes the unconditional overwrite so Function.prototype.bind isn't overwritten if it's already present. This check was already being done for everything else that the script polyfills.

https://office.wikimedia.org/w/index.php?title=MediaWiki%3ALAPI.js&diff=115904&oldid=115902 fixes the polyfill to correctly pass additional parameters along.
Mis-fire.
Change 148757 had a related patch set uploaded by Catrope:
Followup b141a7d23: don't display:none; the popup in the DesktopContext

https://gerrit.wikimedia.org/r/148757
officewiki is important, actually
Does not affect other private wikis (checked otrswiki, collabwiki), not major/high priority.
Screenshot

1.Open a page with VE in FF
2.Click on Link inspector icon 
3.The inspector does not open up
4.Now again click on the link tool on the toolbar

Observed Result:
The link inspector opens up with distorted UI and the following error appears in the console

TypeError: manager.opening is null

See the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F14196}
Verified the fix in production
Verified the fix in Betalabs and the backport on test2
Change 148770 merged by jenkins-bot:
Followup b141a7d23: don't display:none; the popup in the DesktopContext

https://gerrit.wikimedia.org/r/148770
Change 148770 had a related patch set uploaded by Jforrester:
Followup b141a7d23: don't display:none; the popup in the DesktopContext

https://gerrit.wikimedia.org/r/148770
Change 148757 merged by jenkins-bot:
Followup b141a7d23: don't display:none; the popup in the DesktopContext

https://gerrit.wikimedia.org/r/148757
Change 148757 had a related patch set uploaded by Catrope:
Followup b141a7d23: don't display:none; the popup in the DesktopContext

https://gerrit.wikimedia.org/r/148757
This is also happening for Language inspector,math inspector,special character.
Its not that they are not opening on the first attempt, it takes too long to open it , so when I tried to open them second time , it throws that error and appears in broken way.
Screenshot

Open language inspector in betalabs and observe the brokenness

See the screenshot attached

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

**Attached**: {F14642}
Verified the fix in production en.wiki
Verified the fix in test2
Verified the fix in test2
Fixed in gerrit 147179; will pull through and back-port.
Also , Special Character inspector has its UI distorted.Are they related?
1. Place the cursor in a paragraph and change it to a heading the the popup tool
2. Open the popup tool again and observe that nothing is selected (with a tick)
3. Change the context (click in another paragraph/heading, then back)
4. Open the popup tool, the correct item is now selected

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed in gerrit 4b874d42206e988844367eccacb9503fe6c3ddb5.
This may well be a oojsui bug, tbd.
When I have created an article in the hebrew version of wikipedia, ☃ symbol replicated.

The operations I did:
1. I copied an tamplate from another article.
2. I edited it's fields by the visual editor.
3. I started to write text in bold.
4. I changed the text state to normal.
5. The symbol ☃ started to replicate.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68151
Should be now fully fixed in master; deployment to production scheduled for 4 hours' time.
Change 150224 merged by jenkins-bot:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150274 merged by jenkins-bot:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150274
Change 150224 restored by Catrope:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150274 had a related patch set uploaded by Catrope:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150274
Change 150224 abandoned by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

Reason:
I give up.

https://gerrit.wikimedia.org/r/150224
Change 150224 restored by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150224 abandoned by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150224 had a related patch set uploaded by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150222 abandoned by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150222
Change 150222 had a related patch set uploaded by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150222
Change 149920 merged by jenkins-bot:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/149920
*** Bug 68148 has been marked as a duplicate of this bug. ***
Change 149920 had a related patch set uploaded by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/149920
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Make an edit 
3.Click on the "Save Page"
4.While the saving is in progress,keep on clicking on the "Save Page" button on the Save dialog

Observed Result:
The following error appears in the console:

Uncaught TypeError: Cannot read property '$saveOptions' of null

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F14424}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Going to mark as FIXED but please re-open if there's an issue.
Does this still happen? I was able to replicate it on deployment-prep at the time (not on my local machine, as I said), but now I can't...

I get "Uncaught TypeError: Cannot read property 'getModel' of null" when trying to load VE after it's been saved (again, only on deployment-prep, not my local machine), but that seems unrelated.
I can reproduce both the UI as well as the logic problem.

Both the "Review your changes" and the "Save page" buttons in the save dialog remain clickable.

Their apparent state looks clickable, their response to clicking is appeared pressed, and the result is the event handler firing internally.

The exception usually doesn't happen until after the first save attempt has finished and the view goes back to "read" mode, but it does throw:

ve.init.mw.ViewPageTarget.prototype.onSave = function ( ..  ) {
	if ( !this.pageExists || this.restoring ) {
		..
	} else {
		if ( mw.page.watch && mw.page.watch.updateWatchLink ) {
			watchChecked = this.saveDialog.$saveOptions
.. ^
I don't think that fixed it, unfortunately. But I can't reproduce this error locally.
Change 146810 merged by jenkins-bot:
Don't allow document save if we're already tearing down the surface

https://gerrit.wikimedia.org/r/146810
Change 146810 had a related patch set uploaded by Alex Monk:
Don't allow document save if we're already tearing down the surface

https://gerrit.wikimedia.org/r/146810
Seems that I can only get "Uncaught TypeError: Cannot read property 'messages' of null " on my local machine
Steps to reproduce:

1.Open a page with VE
2.Make an edit to the page
3.Click on the "Cancel" button next to "Save Page"

Observed Result:
Nothing happens, the confirmation dialog box does not appear neither it lets user close VE

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix in production en.wiki
Verified the fix in test2
Verified the fix in Betalabs
Change 146639 merged by jenkins-bot:
Make a message dialog for cancelling VE

https://gerrit.wikimedia.org/r/146639
Change 146639 had a related patch set uploaded by Alex Monk:
Make a message dialog for cancelling VE

https://gerrit.wikimedia.org/r/146639
Screenshot

Steps to reproduce:

1.Select a math node/ a reference/image /open any inspector
2.Scroll down the page

Observed Result:
The highlights, context menus and inspectors everything is appearing over the toolbar

See the screenshot attached

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

**Attached**: {F14413}
Verified the fix in production en.wiki
Verified the fix in production en.wiki
Verified the fix in test2
Change 146981 merged by jenkins-bot:
Update VE core submodule to master (8bb3848)

https://gerrit.wikimedia.org/r/146981
Change 146981 had a related patch set uploaded by Jforrester:
Update VE core submodule to master (8bb3848)

https://gerrit.wikimedia.org/r/146981
Screenshot

The Link inspector in mobile became completely broken and unusable after new windows refactor change

See the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F14399}
Verified the fix in production en.wiki
Verified the fix in test2
Change 146296 merged by jenkins-bot:
Get OOUI working with mobile again

https://gerrit.wikimedia.org/r/146296
Change 146296 had a related patch set uploaded by Jforrester:
[WIP] Get OOUI working with mobile again

https://gerrit.wikimedia.org/r/146296
Tapping on a math node is still bringing up the context menu on top of the page,letting user to open math inspector.

--------------------------
**Version**: unspecified
**Severity**: normal
Example with cyrillic text where one button overflows.

When the dialog to switch from VisualEditor to wikicode edition is shown, its dimensions are sufficient to show all the buttons when the interface text is in English. However, in fr, crh-Cyrl and possibly in other languages, the text on the buttons is longer, and the buttons can fall and flow over the edge of the dialog (overflow). This makes it impossible to read the text on them.

This issue is best described by the screenshot attached to this message, and by the subsequent screenshots.

To reproduce:

- Browse to this URL: https://en.wikipedia.org/w/index.php?title=User:Rastus_Vernon/VisualEditor_Sandbox&veaction=edit&uselang=fr.
- Open the VisualEditor menu.
- Click “Passer à l'édition de code”.

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

**Attached**: {F14277}
Happily we just fixed this in gerrit 139550 which means the buttons on ConfirmationDialogs will automatically re-order and re-size based on the length of the label.
Created attachment 15937
Example of the expected behavior, in English, for comparison.

**Attached**: {F14281}
Created attachment 15936
Example with French text where two buttons overflow.

**Attached**: {F14278}
Based on feedback and test by French Wikipedians, which we always thank.

An editor reported getting a snowman here https://fr.wikipedia.org/w/index.php?title=Lucien_Dayle&diff=next&oldid=105411841 when all he did was removing a comma (Chrome, Mac OS X).
I wasn't able to reproduce https://fr.wikipedia.org/w/index.php?title=Utilisateur%3AElitre_%28WMF%29%2FProve2&diff=105432197&oldid=105432184 .

Then another user created a sandbox with similar templates in it and I tested there as well; https://fr.wikipedia.org/w/index.php?title=Utilisateur%3AZebulon84%2FBrouillon&diff=105432505&oldid=105431985 the snowman showed up in the exact place where I had added a comma.

In another case instead https://fr.wikipedia.org/w/index.php?title=Utilisateur%3AZebulon84%2FBrouillon&diff=105432576&oldid=105432561 the letter "e" shows up where I had put the comma. The user had previously replaced the template {{e}} with <sup> tags (https://fr.wikipedia.org/w/index.php?title=Utilisateur:Zebulon84/Brouillon&diff=prev&oldid=105422272 ).

--------------------------
**Version**: unspecified
**Severity**: major
Should be now fully fixed in master; deployment to production scheduled for 4 hours' time.
Change 150224 merged by jenkins-bot:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150274 merged by jenkins-bot:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150274
Change 150224 restored by Catrope:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150274 had a related patch set uploaded by Catrope:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150274
Change 150224 abandoned by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

Reason:
I give up.

https://gerrit.wikimedia.org/r/150224
Change 150224 restored by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150224 abandoned by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150224 had a related patch set uploaded by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150222 abandoned by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150222
Change 150222 had a related patch set uploaded by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150222
Change 149920 merged by jenkins-bot:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/149920
*** Bug 68124 has been marked as a duplicate of this bug. ***
Change 149920 had a related patch set uploaded by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/149920
Change 149920 had a related patch set uploaded by Catrope:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/149920
Note from Jay8g:

In this edit [https://en.wikipedia.org/w/index.php?title=Hong_Kong_International_Airport&diff=618742880&oldid=618629367], I got a snowman after rearranging (copy and paste) a sentence with {{convert}}. This did not show up in VE itself, and appeared in place of the comma that I had actually added (and that had displayed in VE).

This seems to be the same problem.
Comments from Erica on another bug:

> I believe this is happening again at it.wp.
> See https://it.wikipedia.org/w/index.php?title=AA.VV.&diff=prev&oldid=67188720 (snowmen) or https://it.wikipedia.org/w/index.php?title=Utente:Elitre_(WMF)/Pagina_delle_prove_VE&diff=next&oldid=67195802 (pawn).
> What you need to reproduce: just create a base reference, add the template Cita, add something as its first parameter, then hit Space/type something else in the reference before saving.
> 
> More examples from it.wp: https://it.wikipedia.org/w/index.php?title=Natale_Ciravolo&diff=67212907&oldid=67197341 , https://it.wikipedia.org/w/index.php?title=Utente:Nnvu/Sandbox1&diff=prev&oldid=67108020 .
**Author:** `and1eternal1`

**Description:**
When typing, inserting templates, hitting "backspace", and possibly more actions, the cursor moves two characters left after every action. Obviously, this makes editing nearly impossible.

Confirmed and repeatable on: https://en.wikipedia.org/wiki/Corcovado_Volcano?veaction=edit

--------------------------
**Version**: unspecified
**Severity**: major
*** Bug 67933 has been marked as a duplicate of this bug. ***
Fixed by the fix for bug 67432.
Interesting. It looks like the template IPA-es is causing this. If you delete the template, everything works fine.
Yesterday a user reported on the Italian Wikipedia that several Mediawiki messages which have a local version there are being ignored (I guess the system is showing the original message available at Translatewiki, but can't check since that site is currently down). This doesn't seem to be targeting one product only.

Examples:
The button to launch the new TemplateData editor says "Gestisci documentazione template" (you can check at the top left of https://it.wikipedia.org/w/index.php?title=Template:Cassetto/man&action=edit ). It should read "Gestisci TemplateData" instead, as per https://it.wikipedia.org/wiki/MediaWiki:Templatedata-editbutton .

Or see Table 1 at https://it.wikipedia.org/wiki/Discussioni_utente:Rotpunkt#Messaggi_che_non_funzionano . The link says "Comprimi"/"Espandi", but the correct messages, linked a few lines above the table, should actually be "Nascondi"/"Mostra".

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68781
(In reply to Matthew Flaschen from comment #37)
> > And is "II) Localisation cache returns ru when uk exists" still a problem?
> 
> No one has identified a fix, so I would assume yes (even if the symptoms are
> not exposed right now).
> 
> Filed as bug 68781.

Thanks. CLosing this ticket about I) as FIXED as II) is handled there now.
(In reply to Andre Klapper from comment #36)
> (In reply to Andre Klapper from comment #35)
> > NickK: Is this still a problem on Ukrainian Wikimedia sites?
> 
> And is "II) Localisation cache returns ru when uk exists" still a problem?

No one has identified a fix, so I would assume yes (even if the symptoms are not exposed right now).

Filed as bug 68781.
(In reply to Andre Klapper from comment #35)
> NickK: Is this still a problem on Ukrainian Wikimedia sites?

And is "II) Localisation cache returns ru when uk exists" still a problem?
NickK: Is this still a problem on Ukrainian Wikimedia sites?
Lorenzo: Please create a separate ticket. This is offtopic.
(In reply to Niklas Laxström from comment #32)
> (In reply to Lorenzo Marconi from comment #31)
> > Hello. On it.wiki we had changed the shortcut for the button "Show preview"
> 
> This is separate issue and the cause is that "-" means that the message is
> disabled and thus "-" cannot be used as an accesskey.

Excuse me for the OT, but why it doesn't work only since a few days?
(In reply to Lorenzo Marconi from comment #31)
> Hello. On it.wiki we had changed the shortcut for the button "Show preview"

This is separate issue and the cause is that "-" means that the message is disabled and thus "-" cannot be used as an accesskey.
Hello. On it.wiki we had changed the shortcut for the button "Show preview" from alt+shift+v to alt+shift+- (see it:MediaWiki:Accesskey-diff). That shortcut doesn't work for a few days (or weeks, dunno). Since I thought that problem had been solved (comment #27), it may be related to this bug or not?
(In reply to Nemo from comment #29)
> Does the nutcracker issue completely explain findings I-II in comment 9? If
> there are further underlying causes or possible improvements, separate bug
> reports would be very useful once this one about the specific incident is
> closed.

Finding I, yes. Probably not finding II.

I tracked that one as far as observing that the json file for uk that the cdb file gets built from has "Править вики-текст" as the value for messages:visualeditor-ca-editsource rather than "Редагувати код". That seems to be a separate issue from this one, and so should have its own bug report if it doesn't already.
Does the nutcracker issue completely explain findings I-II in comment 9? If there are further underlying causes or possible improvements, separate bug reports would be very useful once this one about the specific incident is closed.
Do the ResourceLoader caches need to be flushed to take care of any lingering issues? The entries in msg_resource with mr_timestamp less than 20140715002850 (based on comment 24) and mr_blob != '{}' are potentially problematic.

At a quick look, this might apply to the following languages on wikis still on 1.24wmf12: ak af aln am ang anp arc ary as ast avk bbc bcl bg bi bo br brh ch ceb chr chy cr cps crh crh-latn cu dv dz ee en en-ca en-gb eu ext fj fo fy ga gom-latn got grc gu gv ha haw hi hif hif-latn hil hy ie ig ik ike-cans ike-latn ilo io iu jam jbo ka kab kbd kbd-cyrl kg khw ki km kri krj ks ks-arab ks-deva ku ku-latn kw ky la lfn lg li lo loz lrc lt lus lzh mai mdf mi mn mr my na ne new niu nl nl-informal nov nrm nso nv ny oc om or pag pam pap pi pih pnb pnt prg ps rif rm roa-tara rup rw sa sat sc sco sd sdc se sei sgs sh shi si sm sma sn so sq srn ss st sw te tet tg tg-cyrl tg-latn ti tk tl tly tn to tokipona tpi tru ts tt-latn tw ug ug-arab ug-latn ur uz ve vls vo war xh xmf yo yue zea zu. Other languages (except maybe uselang hacks) should have been updated already by the l10nupdate run at 02:00 UTC this morning.

It looks like all languages on 1.24wmf13 wikis should have been updated by the l10nupdate run at 02:00 UTC this morning. This afternoon's update of non-Wikipedias to wmf13 should fix them too, BTW.
It. and de.wp look fine though.
Not sure if I should've actually closed it...
reedy@tin:~$ mwscript eval.php itwiki
> var_dump( MessageCache::singleton()->load( 'it' ) );
bool(true)

>
<jgage> andre__: nutcracker is now updated on tin
[01:09:35] <Reedy> I suspect it just hasn't had nutcracker updated on it
[01:09:40] <Reedy> tin
[01:09:41] <Reedy> nobody   23483  0.0  0.0  18732  1704 ?        Sl   Apr25   8:59 /usr/local/bin/nutcracker -m 65536 -a 127.0.0.1 -c /usr/local/apache/common-local/wmf-config/twemproxy-eqiad.yaml
[01:09:46] <Reedy> mw1017
[01:09:47] <Reedy> 112      14857  0.1  0.0  21652  2144 ?        Ssl  Jul07  13:11 /usr/sbin/nutcracker --mbuf-size=65536 --stats-port=22223
[01:10:04] -*- jgage takes a look
[01:10:10] <Reedy> Yeah
[01:10:15] <Reedy> tin still is on "twemproxy"
[01:10:20] <Reedy> apaches are on "nutcracker"
More information: Something is screwy on tin, which is where the cache flush is run.

This command:

 wfMessage( 'collapsible-collapse' )->inLanguage( 'it' )->plain()

returns "nascondi" on terbium (and presumably other servers) but "Comprimi" on tin.
Certainly RL cache clearing: after the fix above, I reset the timestamp on the new row and re-ran the RL cache clearer (refreshMessageBlobs.php in WikimediaMaintenance) on itwiki. And it's re-broken.
Yeah, when we ran into this with a VE message a few days ago, I checked this. wfMessage( $msg )->plain() returned the correct version, but mw.msg( msg ) did not.
As a test, I removed the database row for ResourceLoader's message cache for jquery.makeCollapsible for Italian on itwiki. And upon reload, it started serving the correct messages for that expand/collapse example.

Which makes me suspect even more that the RL cache clearing is broken.
Are there any examples where the incorrect message is being displayed in the served HTML, rather than being served via ResourceLoader for use in JavaScript? I'm suspecting not, since I can open https://it.wikipedia.org/wiki/Discussioni_utente:Rotpunkt#Messaggi_che_non_funzionano and add "{{int:Collapsible-expand}} {{int:Collapsible-collapse}}" and see the correct messages despite the JS-added link in the table being wrong.

That makes me suspect either RL's message cache isn't being cleared properly, or else something in it is broken such that it's not picking up the customized messages.
Re-adjusting importance fields. I'd say this constitutes a "major loss of functionality", and definitely should not take "one to six months" to fix.
Please not that this bug is critically important for Ukrainian: the message affected (VE Edit tab) is a prominent one, and the fallback displayed (Russian despite both local and global translations being correct) is very badly received by the community (to the point that some people suggest disabling VE).
In case this wasn't clear enough, this is affecting several wikis, including large ones like the French or the German WP.
In reply to Niklas Laxström from comment #12)
Understood. Thanks.
(In reply to Володимир Ф from comment #11)
> Maybe first space in this message in database causes error?

That is just how MessageCache::loadFromDB presents them internally. There is no space in front of that message in the database.
>   string(28) " Редагувати код"
or "Редагувати код"?
Maybe first space in this message in database causes error?
(In reply to Niklas Laxström from comment #9)
> III) (bonus) Unicode does not work on eval.php at WMF
> For III) It would be nice for someone to file a separate bug.

Done, see bug 67924
Updated importance fields per https://mediawiki.org/wiki/Bugzilla/Fields#Priority
Doesn't fit the definition of "critical", AFAICS.

Did someone try rebuilding the l10n cache? Were there changed to the LocalisationUpdate or deploy scripts in the last few days? Did someone inspect their logs?
*** Bug 67911 has been marked as a duplicate of this bug. ***
Yes, this is pretty bad.

Amir/Niklas: Can you take a look into this ASAP?
Escalating as this is now active on Ukranian Wikipedia too – https://uk.wikipedia.org/wiki/MediaWiki:Visualeditor-ca-editsource is correct but instead the Russian version, "Править викитекст" is showing in production.
When I open this link in a private browsing window:

https://it.wikipedia.org/w/index.php?title=Template:Cassetto/man&action=edit&uselang=it

I see the default, non-customized button label for TemplateData, but I see the local, custom message for https://it.wikipedia.org/wiki/MediaWiki:Anoneditwarning
It is indeed the original CDB translation (see https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FTemplateData.git/7136f55975d1f275e1c42fb0ad722c00e3ec5d82/i18n%2Fit.json).
The original can be checked in the i18n directory of the source repo, e.g. https://git.wikimedia.org/tree/mediawiki%2Fcore.git/HEAD/languages%2Fi18n
(Or in Special:AllMessages *if* it works.)

Important note, Rotpunkt said this started happening between the 8th and the 9th, dates when no new MediaWiki version was deployed on it.wiki AFAICS.
I don't see the option to add Cite/References in Mobile Ve anymore in any mode .Is it switched off intentionally?

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production en.wiki
Verified the fix in test2
Change 146962 merged by jenkins-bot:
Enable mwreference, mwtransclusion modules on all targets including mobile

https://gerrit.wikimedia.org/r/146962
Change 146962 had a related patch set uploaded by Jforrester:
Enable mwreference, mwtransclusion modules on all targets including mobile

https://gerrit.wikimedia.org/r/146962
Inspired by comments at various wikis and at bug 63389:
pretty much what the summary says.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63389
Change 163029 merged by jenkins-bot:
Let help link target be locally over-ridden; default to the MW help page

https://gerrit.wikimedia.org/r/163029
Change 163029 had a related patch set uploaded by Jforrester:
Let help link target be locally over-ridden; default to the MW help page

https://gerrit.wikimedia.org/r/163029
Looks like it is. Thanks!
Have pointed it to https://www.mediawiki.org/wiki/Help:TemplateData instead – hope that's OK.
James, if the link can't point to the local help page for each wiki, please redirect it to https://www.mediawiki.org/wiki/VisualEditor/Portal/TemplateData .
Change 134928 merged by jenkins-bot:
Refactor TemplateData Editor

https://gerrit.wikimedia.org/r/134928
Change 134928 had a related patch set uploaded by Jforrester:
Refactor TemplateData Editor

https://gerrit.wikimedia.org/r/134928
Change 134928 had a related patch set uploaded by Mooeypoo:
Refactor TemplateData Editor

https://gerrit.wikimedia.org/r/134928
Steps to reproduce:

1.Open a page with VE
2.Open the language inspector
3.Now Open the language selector dialog
4.Select any language or just close the dialog

Observed Result:
The following error appears in the console:
Uncaught Error: ve.dm.Document.getNodeFromOffset(): offset 1 is out of bounds


Environment:Betalabs

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production en.wiki
Verified the fix in test2
Verified the fix in Betalabs
Yeah, fixed probably by Trevor's re-write of windows.
Appears to be fixed in master.
https://pt.wikipedia.org/w/index.php?diff=39208742

--------------------------
**Version**: unspecified
**Severity**: normal
Merging with bug 57884 then.

*** This bug has been marked as a duplicate of bug 57884 ***
Not really. I found that page by chance (while playing the Wikidata Game).
Any reproduction steps? :-(
See at http://en.wikipedia.beta.wmflabs.org/wiki/0.37197036937123?veaction=edit

--------------------------
**Version**: unspecified
**Severity**: normal
Change 144136 merged by jenkins-bot:
Fixes to getRelativeOffset and getRelativeRange

https://gerrit.wikimedia.org/r/144136
Change 144136 had a related patch set uploaded by Esanders:
Fixes to getRelativeOffset and getRelativeRange

https://gerrit.wikimedia.org/r/144136
Also pressing left in the first slug takes you forward.
Currently Hovercards just takes the title attribute and uses that value as the article that it wants to preview.

This does not handle many types of links, nor is not very reliable in combination with image links.

Hovering an image like: [[File:S can.gif|18px|link=Cancer (astrology)|Cancer]] Will show you the article 'Cancer' instead of 'Cancer (astrology)' for instance, because inline images set their link title attribute to the caption.


A link interpreter is also much more flexible and would be able to identify, different types of links.

--------------------------
**Version**: master
**Severity**: enhancement
As @ricordisamoa points out, we did switch to using a link interpreter when @wctaiwan fixed {T93605}.
>>! In T69466#1691123, @Ricordisamoa wrote:
> I'm not aware of any steps that could be made to improve the status quo without needing Parsoid

BTW, according to [[ //www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Wiki_links | spec ]], Parsoid does nothing to make parsing the title easier, in fact here's what VisualEditor does:
https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/867c63e9b235968f2a9f92c75b483b719b222609/modules/ve-mw/dm/annotations/ve.dm.MWInternalLinkAnnotation.js#L92
>>! In T69466#1690148, @Jdlrobson wrote:
> Thanks for the clarification @Ricordisamoa but still `href` is not ideal. Can you update the title/description accordingly?

I'm not aware of any steps that could be made to improve the status quo without needing Parsoid (which would be very bad for small wikis) or T40598.
And after all, the current mechanism is kind of a link interpreter already.
Thanks for the clarification @Ricordisamoa but still `href` is not ideal. Can you update the title/description accordingly?
>>! In T69466#1681893, @Jdlrobson wrote:
> To obtain the title of the page associated with the wiki link it relies on the title attribute, which is sometimes accurate.

Wrong. It has been relying on href since https://gerrit.wikimedia.org/r/199694.
So my interpretation of this is:
Hovercards hijacks wiki links and gives a preview of the pages they refer to to save clicks to them.
To obtain the title of the page associated with the wiki link it relies on the title attribute, which is sometimes accurate.
My question is, does Parsoid mark up links so that it is clear which page title they relate to?
>>! In T69466#1681157, @Jdlrobson wrote:
> @ssastry I assume this is something Parsoid solves? If we used Parsoid as the main parser would this be given for free? 

I don't fully understand how hovercards work, but from the description, it looks like it relies on the title attribute? Right now, Parsoid doesn't set the title attribute for images.

But, the description / title also says "link intepreter" and I don't know what that means either.

So, need more specifics about what hovercards needs to function properly and we can talk more if Parsoid can support that out of the box.
@ssastry I assume this is something Parsoid solves? If we used Parsoid as the main parser would this be given for free?
@ssastry I assume this is something Parsoid solves? If we switched Hovercards to use a Parsoid based service would this solve this problem?
Screenshot

1.Open a page with VE
2.Select an image
3.Click on the "Change Image" button
4.It will take you back to the Media Search dialog box


Observed Result:
Observe that,the "Apply Changes" button is enabled on the search dialog box
Clicking on that will not have any effect.

See the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F14223}
Verified the fix in production
Verified the fix in test2
Change 143749 merged by jenkins-bot:
UX Improvements to the Media Dialog

https://gerrit.wikimedia.org/r/143749
Change 143749 had a related patch set uploaded by Jforrester:
UX Improvements to the Media Dialog

https://gerrit.wikimedia.org/r/143749
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Type a text
3.Select the text
4.Open the link inspector to apply link on it
5.Type something inside the link inspector

Observed Result:
No link suggestions are appearing in the link inspector.

See the screenshot attached

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

**Attached**: {F14198}
Verified the fix in Betalabs
Change 161150 merged by jenkins-bot:
Followup 6c862e8: position before AND after showing in TextInputMenuWidget

https://gerrit.wikimedia.org/r/161150
Change 161150 had a related patch set uploaded by Catrope:
Followup 6c862e8: position before AND after showing in TextInputMenuWidget

https://gerrit.wikimedia.org/r/161150
This got broken again apparently in last few hours.
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 143782 merged by jenkins-bot:
Followup 96ff968: use this.$element after it's initialized, not before

https://gerrit.wikimedia.org/r/143782
Change 143782 had a related patch set uploaded by Catrope:
Followup 96ff968: use this.$element after it's initialized, not before

https://gerrit.wikimedia.org/r/143782
It's pretty much impossible to open the references context toolbar to edit an existing reference.

Steps to reproduce:

1. Open an article in VE editing mode on an iPad
2. Tap on any reference footnote in the body of the article – sometimes the reference context toolbar appears, sometimes it doesn't, and sometimes it appears for a second and scrolls away.
3. If you've managed to get the reference context toolbar to appear, tap it – sometimes it takes you to the link inspector, and sometimes it takes you to a new blank citation form

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=67390
https://bugzilla.wikimedia.org/show_bug.cgi?id=67637
Looks like this is now fixed thanks to Juliusz's new context menu changes.
Copied from my Russian Wikipedia talk page:

After reference VE added symbol "♙".

sample for https://ru.wikipedia.org/w/index.php?title=Гёрлфренд&oldid=58928673&veaction=edit

find ref№3 -> "к подруге.[3]"
click after the dot -> "к подруге.|[3]"
delete the dot with backspace  back  ->"к подруге|[3]"
press en:Arrow keys  →  two times ->"к подруге[3]|"
press key dot  .  ->
expected that will be shown the symbol "." -> "к подруге[3].|"
but it shows the symbol "♙" ->"к подруге[3]♙|"

--------------------------
**Version**: unspecified
**Severity**: normal
Change 145346 merged by jenkins-bot:
Make sure the document is focused when setting a selection

https://gerrit.wikimedia.org/r/145346
Upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1037004
Change 145346 had a related patch set uploaded by Esanders:
Make sure the document is focused when setting a selection

https://gerrit.wikimedia.org/r/145346
Monitoring document.activeElement (the currently focussed element) it's apparent that simply setting a selection on the document (back from the paste target) doesn't changed the focussed element. This means you can move your cursor in one textbox and type in another. What the hell Firefox...
This happens just by typing anything after an inline focusable node after cursoring off it (nothing to do with deletion). If the node is at the end of a paragraph you get a pawn, but if it isn't you get equally broken behaviour with the cursor not moving properly.
(In reply to Elitre from comment #2)
> If this happens in FF, can it be related to bug 54917?

Doesn't look like it; this was caused by insertion, not cursoring.
If this happens in FF, can it be related to bug 54917?
Sounds like a VE issue. Moving there.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Media and select any image after searching

Observed Result:
When the Media settings dialog pop-up, observe that all the icons for the tabs General Settings, Advanced Settings and the headings Caption,Alternative text, Position,Image Type, Image Size etc are missing

See the screenshot attached

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

**Attached**: {F14179}
Verified the fix in production
Verified the fix in betalabs and test2
Almost certainly a Beta Labs problem of the moment.
This is also happening for Basic reference, cite news , cite journal and reference list dialog as well.
Screenshot

Steps to reproduce:

1.Open a page with mobile VE
2.Do not place your cursor anywhere on CE but try to select a node 
Observed Result:
The semi-highlight of lighter shade appears over the node and tapping on it for the second time selects it with darker highlight.

It might get resolved with :https://bugzilla.wikimedia.org/show_bug.cgi?id=57177

Still I am filing it as a separate issue.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57177

**Attached**: {F14690}
Verified the fix in production
This is not happening anymore,Checked in Betalabs and test2 .
Marking it as fixed
Screenshot

Steps to reproduce:

1.Open a page with mobile VE in iOS Safari
2.Select a text
3.Click on the link icon from the toolbar
4.Type a link target page inside link inspector and apply it

Observed Result:
The cursor that was appearing inside the search box of a link inspector remains on the screen appearing over the title of the page

See the screenshot attached

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

**Attached**: {F14689}
Verified the fix in production en.wiki
Verified the fix in test2
Fixed by Trevor's mobile styling work.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Template
3.Type a template name such as "Cite Web"

Observed Result:
In the template suggestion drop dwon box all template names are appearing with a prefix "Template:"

See the screenshot attached
Environment:Betalabs

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

**Attached**: {F14680}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 143685 merged by jenkins-bot:
Try some more to handle template namespace properly

https://gerrit.wikimedia.org/r/143685
Change 143685 had a related patch set uploaded by Alex Monk:
Try some more to handle template namespace properly

https://gerrit.wikimedia.org/r/143685
Writing https://gerrit.wikimedia.org/r/143322 , I realized that the `ve.ce.isShortcutKey( e )` check in ve.ce.Surface (which rejects every keypress event where Ctrl or Cmd is pressed) sometimes prevent legit keypresses from being handled.

To reproduce (in any browser):

* Place cursor on an empty line.
* Input 'ą' ([[ą]]). This is accomplished by pressing AltGr+a (right Alt+a, Alt+Ctrl+a) when using the "Polish (Programmers)" keyboard layout on Windows 7 (this is the default layout for Polish).
* Type in something else. The 'ą' disappears, because it was never handled by ve.ce, only by native contenteditable element.

I only tested this on Windows 7, but I believe other operating systems all use the same method. Other letters with diacritics from the [[Polish alphabet]] are input in the same way (AltGr + base key), we have nine of them.

On Windows 7 you can enable this keyboard layout by typing "keyboard layout" into the Start menu, choosing "Change keyboards…" and adding the input method.

--------------------------
**Version**: unspecified
**Severity**: normal
Proper fixed!
Change 181174 merged by jenkins-bot:
ve.ce: Remove hacks from Surface#onDocumentKeyPress; add related IME test

[[https://gerrit.wikimedia.org/r/181174]]
Change 181173 merged by jenkins-bot:
imetests: Add a regression test for Polish keyboard input

[[https://gerrit.wikimedia.org/r/181173]]
Change 181174 had a related patch set uploaded (by Bartosz Dziewoński):
ve.ce: Remove hacks from Surface#onDocumentKeyPress, add related IME test

[[https://gerrit.wikimedia.org/r/181174]]

#patch-for-review
Change 181173 had a related patch set uploaded (by Bartosz Dziewoński):
imetests: Add a regression test for Polish keyboard input

[[https://gerrit.wikimedia.org/r/181173]]

#patch-for-review
Let's do that.
Yes! See fakeIMETests. Please use the script to generate a previously-failing test case so we lock this in. :-)
This no longer happens. Just for the kicks I bisected and found that the commit that fixed the bug is 40101e42a4544768ac624ef2b4da0e7d44b69b65 (https://gerrit.wikimedia.org/r/#/c/151046/).

I wonder if we could have a browser test to prevent this from regressing? (It was fixed accidentally, could be broken accidentally again.)

I also wonder if we need the checks in `ve.ce.Surface.prototype.onDocumentKeyPress` at all anymore? Removing them doesn't seem to cause the issue they're supposed to prevent ("Unexpected content deletion when selection is not collapsed and the user presses, for example, the Home key (Firefox fires 'keypress' for it)").
Hmph, we can't kill this code yet. It's not just to prevent pawning, it's also to prevent the selection from being deleted when you press a shortcut key. We'll need David's next project (prepare-observe-fixup) to be done before we can get rid of this, I think.
I can still reproduce on betalabs.
(In reply to Roan Kattouw from comment #2)
> (In reply to James Forrester from comment #1)
> > Is this now fixed, given that we've killed pawns?
> 
> We haven't quite killed them yet, the chimera commit does that.

But we should make sure that that commit also kills this logic; which right now I'm not sure that it does.
(In reply to James Forrester from comment #1)
> Is this now fixed, given that we've killed pawns?

We haven't quite killed them yet, the chimera commit does that.
Is this now fixed, given that we've killed pawns?
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert a reference
3.Go to the option Use an existing reference

Observed Result:
In the dialog for using an existing reference, the reference name for the reference just added is missing just the reference number appears inside the bracket.
Opening it for the second time brings up the reference name

See the screenshot attached

Environment:http://en.m.wikipedia.beta.wmflabs.org/
Both on Desktop browser and iOS Device

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68869

**Attached**: {F14576}
Verified the fix in production for both desktop and mobile
Verified the fix in test2
Should be solved.
Change 150736 merged by jenkins-bot:
Don't clone internal item node element used for references in re-use citation dialog

https://gerrit.wikimedia.org/r/150736
Change 150736 had a related patch set uploaded by Alex Monk:
Don't clone internal item node element used for references in re-use citation dialog

https://gerrit.wikimedia.org/r/150736
This is happening in desktop as well , not when you add Basic reference but cite references.
**Author:** `oliver.buchtala`

**Description:**
Probably a matter of taste, but we find the embedded control not too appealing.
In our case (a block equation) the button to open the inspector is typically below. However, when the element is growing (2+ lines), it is suddenly on the right-hand side.

It would be great if there was a way to control that and override the present behavior if desired.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 66542 ***
The original request was about optional disabling embedding, but this I suppose "fixes" the issue (though really that was bug 66542).
Change 143393 merged by jenkins-bot:
Never embed the context when an inspector is present

https://gerrit.wikimedia.org/r/143393
Change 143393 had a related patch set uploaded by Esanders:
Never embed the context when an inspector is present

https://gerrit.wikimedia.org/r/143393
It would be nice to keep it consistent, although for a live-updating node it would certainly make sense to keep the context menu out of the way (at least when it is open).
(Chrome mobile)
Clicking on a focusable node doesn't bring up the keyboard so there is no access to the backspace key. Even if you click on text then the focusable node, the backspace key doesn't work.

Regardless a mobile user would expect to have a separate control for deleting focusable nodes.

--------------------------
**Version**: unspecified
**Severity**: major
Same problem as on iOS. Merging.

*** This bug has been marked as a duplicate of bug 60110 ***
The same node sometimes is deleted and sometimes isn't. Appears to apply to block and inline nodes alike. Can't work out exact reproduction steps. Race condition?

--------------------------
**Version**: unspecified
**Severity**: major
Change 142527 merged by jenkins-bot:
Always refocus the paste target when a node is selected

https://gerrit.wikimedia.org/r/142527
Change 142527 had a related patch set uploaded by Esanders:
Always refocus the paste target when a node is selected

https://gerrit.wikimedia.org/r/142527
I can reproduce by clicking directly from one node to another. Looks like a focus issue.
Definitely no clean repro - comes and goes as you click on templates. But once it stops working in a session, it seems to stop for good.
Correct outcome:

* Select an inline image (or a reference or alien or…).
* Press "a".

Observe that the reference has been deleted, and an 'a' is in its place.


Bad outcome;

* Select a block image (or block template or…).
* Press "a".

Observe that the block image has not been deleted, and the 'a' is not in its place (and no transaction has occurred).

--------------------------
**Version**: unspecified
**Severity**: normal
Change 146808 merged by jenkins-bot:
Prevent deletion of focusable nodes by typing

https://gerrit.wikimedia.org/r/146808
Change 146808 had a related patch set uploaded by Esanders:
Prevent deletion of focusable nodes by typing

https://gerrit.wikimedia.org/r/146808
Real world comparison:
* Open/Libre office: typing while selecting an image does nothing
* Google docs: typing replaces the image

I think it's a rare workflow where you select a block image and want to replace it with a paragraph, and if you really do you can just press backspace/delete. We have taken other measures to prevent the accidental deletion of focusable nodes elsewhere (e.g. adjacent backspace only selects) so this seems like a logical extension.
References defined inside a {{reflist}} aren't editable – but double-click now opens the reference dialog (to empty content).

I imagine this happens for a few things.

--------------------------
**Version**: unspecified
**Severity**: major
Change 143352 merged by jenkins-bot:
Hide context tools when the model they match isn't "inspectable"

https://gerrit.wikimedia.org/r/143352
Change 143352 had a related patch set uploaded by Esanders:
Hide context tools when the model they match isn't "inspectable"

https://gerrit.wikimedia.org/r/143352
(In reply to Ed Sanders from comment #1)
> Link to an example?

First reference on https://en.wikipedia.org/wiki/Anne_Dallas_Dudley?veaction=edit – appears to be an issue with references more generally, and affects the context too. Bother.
Link to an example?
This original problem reported seems to be fixed now.
Hoever, there is another unrelated error
```
ok 948 - ResourcesTest::testStyleMedia with data set #13 ('skins.vector.styles', 'screen and (min-width: 982px)', 'screen-hd.less', stdClass Object (...))
ok 949 - ResourcesTest::testIllegalDependencies
not ok 950 - Failure: ResourcesTest::testMissingDependencies
  ---
  message: 'The module ''ext.visualEditor.mwcore'' required by ''ext.math.visualEditor'' must exist'
  severity: fail
  ...
not ok 951 - Error: ResourcesTest::testUnsatisfiableDependencies
ok 952 - ResourcesTest::testMediaWikiTestCaseParentSetupCalled
```
This original problem reported seems to be fixed now.
However changing the order or inclusion in the way that math is included before echo leads to the following error
```
ok 948 - ResourcesTest::testStyleMedia with data set #13 ('skins.vector.styles', 'screen and (min-width: 982px)', 'screen-hd.less', stdClass Object (...))
ok 949 - ResourcesTest::testIllegalDependencies
not ok 950 - Failure: ResourcesTest::testMissingDependencies
  ---
  message: 'The module ''ext.visualEditor.mwcore'' required by ''ext.math.visualEditor'' must exist'
  severity: fail
  ...
not ok 951 - Error: ResourcesTest::testUnsatisfiableDependencies
ok 952 - ResourcesTest::testMediaWikiTestCaseParentSetupCalled
```
And the number of tests that were executed reduces from 1818 to 1547
Would need to be tried again, it might have been fixed.
**physik** wrote:

This Bug is not related to the math extension.
My experience is the following
At first I could reproduce a similar error as reported in the bug report. But the error indicated that database access related to the echo extension caused the error.
To investigate further I changed the order in the Localsettings.php an loaded Math before echo.
I wanted to reproduce exactly the problem that you had reported before. But no error occurred. After switching the order back the error did not come back.
AS a result I think the error is not related to the Math extension, rather to the sqllite db backend. Especially given the fact that the error does not occur with mysql
*** Bug 68628 has been marked as a duplicate of this bug. ***
Still the same error with latest master of Math Echo and core:

not ok 588 - Error: MathDatabaseTest::testCreateTable
A database query error has occurred.
Query: DELETE FROM unittest_math
Function: MediaWikiTestCase::resetDB
Error: 1 no such table: unittest_math
Antoine, is it fine for you now?
Change 142739 merged by jenkins-bot:
Fix MathDatabaseTest

https://gerrit.wikimedia.org/r/142739
Sure! See comment 1. Install a stock MediaWiki core with extensions Echo and Math.  That should trigger the issue.
**physik** wrote:

does the problem disappear if you disable the Echo module?
Are those tests using sqlite?
We really need tests to pass when all wmf extensions are installed together. That is preventing us from progression toward the HHVM migrating. Raising priority to High.
Change 142739 had a related patch set uploaded by Physikerwelt:
Fix MathDatabaseTest

https://gerrit.wikimedia.org/r/142739
I did ran update.php

A slightly more complicated test I ran in Jenkins is:

https://integration.wikimedia.org/ci/job/mediawiki-core-extensions-integration/38/consoleFull


It clones a bunch of extensions, load their entry points then run install.php and then update.php

 00:01:04.861 Creating math table ...done.


The dberror:

 Thu Jun 26 16:15:01 UTC 2014	gallium	build38-unittest_	MediaWikiTestCase::resetDB		1	no such table: unittest_math	DELETE FROM unittest_math
**physik** wrote:

did you run update.php before?
As far as I understand the database tests copy the schema with and prefix the tables with untitest. If there is no math table in the base schema no table will be created in the copied unittest schema.
The database test tries to delete the test schema and creates a new one.
We should either improve the error message or ignore the missing math table in the  main database. I don't know which option is better?
tests/MathDatabaseTest.php has:

 public function testCreateTable() {
  ...
  $dbu->doUpdates( array( "extensions" ) );
  ...

among other. Commenting out the function let us continue the test suite.
Screenshot

Steps to reproduce:

1.Open a page with VE in FireFox
2.Without editing just click on "Cancel" button 

Observed Result:
The cursor is still appearing at the end of the page in read mode.

See the screenshot attached
Environment:Betalabs

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

**Attached**: {F14619}
I think we fixed this a long time ago (and then it recurred and we fixed that one too).
This is happening in production now, so environment is not just Betalabs now.
(from bug 67086)

1. Press "Link" tool.
2. Enter a link target (url or page name).
3. Select the url or page name from the suggestions.
- Notice that the surface still shows your blinking cursor with no link or text
4. Click back into the surface and type text.

Expected behaviour:

The link becomes a pre-annotation and the entered text the label.
Or, alternatively, the link autosaves and inserts itself and my text appears after the link.

Actual behaviour:

* First character is eaten.
* Link is inserted.
* First character of link is unlinked.
* Pawn appears.
* Second and further characters inserted will remove the link and insert plain text

See http://cl.ly/3s460Q442L3S

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68590
No longer an issue (Trevor-rewrite probably), but bug 68590 is a related problem.
(In reply to Krinkle from comment #1)
> Reduced test case video of only the steps for this bug (without existing
> links before the list item):
> 
> http://cl.ly/2P2h473b2A20

Dead link.

Also, on step 3, my cursor is in the target box... Not the surface. Is this still valid with the window rewrite and everything?
Reduced test case video of only the steps for this bug (without existing links before the list item):

http://cl.ly/2P2h473b2A20
Screenshot-1

Steps to reproduce:

1.Open a page with safari in any iOS device which contains image in it
2.Now tap on the image to select it

Observed Result:
The highlight for the image is appearing much below the image 

See the screenshots attached

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=65326

**Attached**: {F14511}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs.
The highlight for images appearing in wrong position is now fixed ! :)
However the tapping on link or image redirecting to the link target or image file page and second tap on reference closing the VE is still there.Therefore, I suppose the following bugs are not related:

https://bugzilla.wikimedia.org/show_bug.cgi?id=65326
https://bugzilla.wikimedia.org/show_bug.cgi?id=67002
Change 142260 merged by jenkins-bot:
FocusableNode: Use getClientRects()[0] instead of getBoundingClientRect()

https://gerrit.wikimedia.org/r/142260
Change 142260 had a related patch set uploaded by Esanders:
Use getClientRects()[0] instead of getBoundingClientRect()

https://gerrit.wikimedia.org/r/142260
Want to write up a bug report for Apple?
In every browser except iOS7 getClientRects is relative to the viewport. In iOS7 it is relative to document. Thanks Apple.
Created attachment 15726
Screenshot-2

**Attached**: {F14512}
It's easiest to understand this from the screenshot.  This is a display bug.

Steps to reproduce:

1.  Open a page containing a (long-ish) citation dialog.

2.  Select the ref and go to Insert > References.

3.  Select the citation template (e.g., to copy it).

4.  Ask yourself, "Why is only the first line of this template being selected?  Why is the cite tag in the middle instead of underneath the template?"

--------------------------
**Version**: unspecified
**Severity**: trivial

**Attached**: {F14508}
Works on beta labs.
*** This bug has been marked as a duplicate of bug 52339 ***
https://www.mediawiki.org/wiki/VisualEditor:Test1234?veaction=edit

Dragging the image on this page on Chrome Version 35.0.1916.153 on Mac OSX 10.9.3 does not relocate the image. The "shadow" and magic line appear as expected, but when the click is released the image does not move.

The entire interaction works properly for me on latest Firefox.

--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Mac OS X 10.9
**Platform**: Macintosh
Verified the fix in test2
Change 141949 merged by jenkins-bot:
Cache block drop position data before setTimeout

https://gerrit.wikimedia.org/r/141949
Change 141949 had a related patch set uploaded by Esanders:
Cache block drop position data before setTimeout

https://gerrit.wikimedia.org/r/141949
Update to my earlier comment. It's working for me on Firefox 30, Mac OSX 10.9.3
Works for me in Chrome 34 but broken for me in Firefox 30 (both on Ubuntu 14.04)
**kirkburn** wrote:

https://www.mediawiki.org/wiki/VisualEditor:Test1234?veaction=edit

Similarly, the interaction is not working for me on Chrome 35.0.1916.153 m on Windows 8.1 - I see the shadow and magic line, but nothing happens on mouseup.

However, unlike Trevor, it is also not working for me in pre-release Firefox - on Firefox Aurora 32.0a2 (19-06-14), on Windows 8.1. No effect on mouseup.
**Author:** `jgonera`

**Description:**
As mentioned in bug 66999 references require two taps on iOS Safari. Often, the first tap results in a lighter "semi-selection" appearing a bit below the actual reference. When that happens, second tap on the reference suddenly closes the editor (first video).

The editor doesn't crash though, somehow cancel action is triggered. If you have unsaved changes, you'll see a dialog asking you if you want to abandon the edit (second video).

Tested and recorder in iOS Safari 7.1.1. Does not happen on Chrome for Android.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=66999
https://bugzilla.wikimedia.org/show_bug.cgi?id=65326
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
This seems to got fixed by:

Select highlights on touchend event

https://gerrit.wikimedia.org/r/142839
Ok, the behavior got slightly changed here, it wont close the VE now if your second tap on the same reference follows right after your first tap

To reproduce it now you need to first tap on a reference say [1], then tap on another reference [2], then go back and tap [1].Now it will close the VE .
For images, second tap on it opens up the image which might also be the effect of this same bug.
This bug did not get fixed by :

Use getClientRects()[0] instead of getBoundingClientRect()

https://gerrit.wikimedia.org/r/142260
Probably (?) fixed by the fix to bug 67063.
Pushing to Ed because it appears to be a shield/highlight issue.
**jgonera** wrote:

Editor shows confirmation dialog

**Attached**: {F14382}
**jgonera** wrote:

Editor closes

**Attached**: {F14376}
**Author:** `jgonera`

**Description:**
Double tap required

If you open VE on mobile and want to edit an existing reference, you need to tap it twice. This is really hard, especially given that the tap target is quite small (which is a separate issue).

Tested and recorder in iOS Safari 7.1.1. Does not happen on Chrome for Android (just a single tap needed there).

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=65326
https://bugzilla.wikimedia.org/show_bug.cgi?id=67002

**Attached**: {F14364}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs.
Change 142839 merged by jenkins-bot:
Select highlights on touchend event

https://gerrit.wikimedia.org/r/142839
Change 142839 had a related patch set uploaded by Esanders:
Select highlights on touchend event

https://gerrit.wikimedia.org/r/142839
This bug did not get resolved by Ed's fix.

The issue here is, the first tap is showing a lighter highlight which is equivalent to the hover effect in the desktop and for the second tap it is actually selecting that node.

This is why, even if you have selected a reference (with two tap) , you can still semi-select another node (with lighter highlight)at the same time  

For mobile, it should require one single tap to select any reference/image etc.
Looks like it's fixed by bug 67063's fix.
(In reply to Ed Sanders from comment #3)
> Isn't this fixed then (comment 1)?

… no?

Comment 1 says that the context being useless ("the tap target is quite small") is  fixed by some other patches and you should ignore.

Comment 0 is mostly about "If you open VE on mobile and want to edit an existing reference, you need to tap it twice." which remains a bug.
Isn't this fixed then (comment 1)?
Pushing to Ed because it appears to be a shield/highlight issue.
**jgonera** wrote:

Ignore wrong positioning of mobile context (second toolbar), it's fixed now. To actually see the context though you need those patches:
https://gerrit.wikimedia.org/r/#/c/141085/
https://gerrit.wikimedia.org/r/#/c/141087/
Screenshot

Steps to reproduce:


1.Open a page with VE
2.Go to Insert>Template
3.Type a template name with matching suggestion in the text box

Observed Result:
There are no suggestions for template appearing in the dialog

See the screenshot attached

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

**Attached**: {F14341}
Verified in production (en.wiki)
Verified in test2
This is fixed now.
*** Bug 66981 has been marked as a duplicate of this bug. ***
1. Edit [[mw:API:Meta]] in VisualEditor
2. Select the "MediaWiki version 1.8" template

A popup appears showing the template's correct name ("MW 1.8").

3. Open the transclusion editor for the template

VE thinks it is editing a template called "MW 1".

Also note that when you try to insert a template with a period in its name, like "MW 1.8", you get a whole lot of suggestions for "MW 1".

--------------------------
**Version**: unspecified
**Severity**: minor
Should be fixed now.
Change 142372 merged by jenkins-bot:
Don't remove 'extension' from template names

https://gerrit.wikimedia.org/r/142372
Change 142372 had a related patch set uploaded by Alex Monk:
Don't remove 'extension' from template names

https://gerrit.wikimedia.org/r/142372
Yeah, I worked that out soon after moving the bug.

Still, I wonder if the documentation should be improved for those methods.
btw, This is a compatibility/legacy left-over from when mw.Title was part of UploadWizard and they got dibs on the more intuitive name "getNameText". Unfortunately this mistake was not uncovered until after it was merged in mediawiki-core and released in an LTS.
getNameText() explicitly leaves out any faux extension. That's by design. To get the page title, use getMainText.


https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.Title-method-getNameText
Yep.

mw.Title.newFromText( 'Template:Asd.com' ).getNameText()
"Asd"
I blame mwTitle. Because it's always at fault.
Until Parsoid removes metadata, large articles are going to consist of several megabytes of data (en:Barack_Obama = 3.4MiB). As browsers doesn't provide any mechanism for compressing post data, this is takes about 20s to upload on a typical 1Mbps up ADSL line.

Using a JS implementation of deflate, we could achieve 80-90% compression in a few hundred ms on a decent machine: http://jsperf.com/js-deflate

A couple of considerations with performing such a complex calculation in pure JS:

* Really bad JS engines or slow devices (old browsers, IE, mobile) may offer to little to overall speed benefit. We may want to detect these cases by user agent or performance profiling.
* The compression function will be synchronous and lock browser interaction. On slower machines this may give the appearance of crashing, or with memory leaks may actually crash. If this proves to be a significant problem we could look into encoding in chunks of 100k at a time so we could at least provide progress, and maybe improve memory usage (at the cost of overall compression).

--------------------------

**See Also**:
* {T61659}
* {T61660}
* {T66171}
Change 141678 merged by jenkins-bot:
Compress HTML data with deflate before POSTing

https://gerrit.wikimedia.org/r/141678
(In reply to Ed Sanders from comment #0)
> * The compression function will be synchronous and lock browser interaction.

You could look at doing it asynchronously in the background, with a Web Worker (i.e. thread) (https://developer.mozilla.org/en-US/docs/Web/API/Worker), in supported browsers (IE 10+, and Firefox/Chrome/Safari/Opera going back pretty far).
*** Bug 59659 has been marked as a duplicate of this bug. ***
There are a number of things we can do to avoid this heavy payload:
* Section editing
* Separating Parsoid metadata
* Sending differential linmod data using a server-side converter

None of these are ready or close to being ready yet, and 20s to save a page is fairly significant problem in the present that compression can mitigate.
Change 141678 had a related patch set uploaded by Esanders:
Compress HTML data with deflate before POSTing

https://gerrit.wikimedia.org/r/141678
Supporting section editing (bug 48429), and submitting only modified section to the server, might be a better way to increase performance.
Screenshot

Formula icon is missing in the Insert menu

--------------------------
**Version**: unspecified
**Severity**: trivial

**Attached**: {F14131}
Verified in production (en.wiki)
Verified in test2
Works in Betalabs too now.
Definitely works in master, must be a deployment issue.
Did the registration in the Math extension not work?
Steps to reproduce:


1.Open a page with VE
2.Insert an image
3.Open the Media Settings dialog for the image
4.Go to Advanced Settings tab
5.Click on "Make full size"

Observed Result:
It switches to the Custom tab and keeps the size value as default instead of making it full size.

Environment:Betalabs,test2, en.wiki

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 144637 merged by jenkins-bot:
Apply 'original size' to images

https://gerrit.wikimedia.org/r/144637
Change 144638 merged by jenkins-bot:
Apply 'original size' to images and enable apply button in ve-MW

https://gerrit.wikimedia.org/r/144638
Change 144638 had a related patch set uploaded by Mooeypoo:
Apply 'original size' to images and enable apply button in ve-MW

https://gerrit.wikimedia.org/r/144638
Change 144637 had a related patch set uploaded by Mooeypoo:
Apply 'original size' to images

https://gerrit.wikimedia.org/r/144637
Its changing the size value in the dialog but after clicking on "Apply Changes" button it is not making it full size.So, reopening it .
Verified the fix on test2
Backported to wmf11 and working great.
Change 142855 merged by jenkins-bot:
Update VisualEditor to Iba4e6b32

https://gerrit.wikimedia.org/r/142855
Change 142855 had a related patch set uploaded by Jforrester:
Update VisualEditor to Iba4e6b32

https://gerrit.wikimedia.org/r/142855
We need to backport the fix for this one,it did not make it to test2.
Verified the fix in betalabs
Change 142171 merged by jenkins-bot:
Correctly update full size in MediaSizeWidget

https://gerrit.wikimedia.org/r/142171
Change 142171 had a related patch set uploaded by Mooeypoo:
Correctly update full size in MediaSizeWidget

https://gerrit.wikimedia.org/r/142171
Steps to reproduce:

1.Open a page with VE
2.Insert a cite option/references/formula/image

Observed Result:
Observe that the,context menus are appearing for these items for a second and then suddenly disappears right after adding

Environment: Betalabs

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production (en.wiki)
Verified the fix in test2
Verified the fix in Betalabs.
Verified the fix in Betalabs.
Change 141940 merged by jenkins-bot:
Revert "Accessibility: Restore element focus when a window closes"

https://gerrit.wikimedia.org/r/141940
Change 141940 had a related patch set uploaded by Esanders:
Revert "Accessibility: Restore element focus when a window closes"

https://gerrit.wikimedia.org/r/141940
Updated MW core and it broke, must be an OOJS regression.
Verified working in master.
On English Wikipedia, tabbing in the citation dialog is broken.  To reproduce:

1. Edit an article with VE.
2. Choose 'News' from the Cite menu.
3. Click the first field.
4. Tab to try to get to the next field.

Focus goes to a help icon, and even tabbing repeatedly will not get it to leave that icon.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=65554
*** Bug 67159 has been marked as a duplicate of this bug. ***
Well that's at least a workaround. I wonder if this might be an upstream bug...
Change 142718 merged by jenkins-bot:
Set tabindex for template dialog info/remove buttons on parent <div> rather than <a>

https://gerrit.wikimedia.org/r/142718
Change 142718 had a related patch set uploaded by Alex Monk:
Set tabindex for template dialog info/remove buttons on parent <div> rather than <a>

https://gerrit.wikimedia.org/r/142718
Weird... I can replicate this in Firefox, but not Chrome.

I tried copying the inner HTML out of the dialog iframe and into a separate file - it worked there.
I also tried moving the tabindex attribute from the <a>s to their parent <div>s... That seems to work. Not sure why.

(I've been testing with any template which has TemplateData, btw - not specifically Cite stuff)
Created attachment 15765
Tabbing issue in Firefox

I can still reproduce it.  I should have said, I tested in Iceweasel/Firefox 30.0 on Debian Wheezy.

I'm attaching a video.  It shows how I got there, and that it tabs to the help icon.  I tab multiple times and it sticks, though you can't see that in the video.

**Attached**: {F14064}
Actually:

* in Firefox, the tabbing doesn't take you to the help icon (or delete icon), only in Chrome (instead it takes you to the next field);
* in neither can you tab to the "add field" button;
* when the add field panel opens your cursor doesn't open in the search field;
* when in the add field search box tabbing doesn't take you to the field options.

However, yeah, I can't replicate the original report – Matt, can you clarify?
It's supposed to go to the help icon (that was Gerrit change 137152 - bug 65474), but 'tabbing repeatedly will not get it to leave that icon' is WFM
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Attempt to insert a formula or a hiero with the inspectors

Observed Result:
The math inspector jumps to the beginning of the article then comes back to the right position where it was intended to open

For hiero, it gets stuck at that position.

See the screenshot attached

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

**Attached**: {F14045}
Verified the fix in production (en.wiki)
Verified in test2
Fixed for Math inspector.Will check for Heiro later, when it is available
Verified the fix in Betalabs
Change 141985 merged by jenkins-bot:
Render a placeholder when extension contents are empty

https://gerrit.wikimedia.org/r/141985
Change 141985 had a related patch set uploaded by Esanders:
Render a placeholder when extension contents are empty

https://gerrit.wikimedia.org/r/141985
as a logged in user on any page in http://en.wikipedia.beta.wmflabs.org/

edit a page and attempt to save.

Save your changes interface shows "Error: unknown error"

fatal.log shows 

[2014-06-18 16:18:37] Fatal error: Call to a member function getDisplayTitle() on a non-object at /srv/common-local/php-master/extensions/VisualEditor/ApiVisualEditorEdit.php on line 120
Server: deployment-apache01
Method: POST
URL: http://en.wikipedia.beta.wmflabs.org/w/api.php
Cookie: enwiki-gettingStartedUserId=kJSYCjZCvJa3o9xl48ODXiGk1DaduG2m; centralauth_LoggedOut=1402329725; ve-beta-welcome-dialog=1; optin=beta; centralnotice_bucket=0-4.2; edittoolscharsubset=0; GeoIP=US:Tucson:32.2217:-110.9265:v4; uls-previous-languages=%5B%22en%22%5D; mediaWiki.user.sessionId=2vKzOP6dVykMZfazhyIC7OKY5jkC0O3t; enwikiUserID=54; enwikiUserName=Cmcmahon; enwikiSession=29dd771993d2f54b0eb86b9ccc4e85df; centralauth_User=Cmcmahon; centralauth_Session=caf75694c6a3d741ef094fac43c50f47
Backtrace:
#0 /srv/common-local/php-master/extensions/VisualEditor/ApiVisualEditorEdit.php(120): ApiVisualEditorEdit::execute()
#1 /srv/common-local/php-master/includes/api/ApiMain.php(908): ApiVisualEditorEdit->execute()
#2 /srv/common-local/php-master/includes/api/ApiMain.php(363): ApiMain->executeAction()
#3 /srv/common-local/php-master/includes/api/ApiMain.php(334): ApiMain->executeActionWithErrorHandling()
#4 /srv/common-local/php-master/api.php(85): ApiMain->execute()
#5 /srv/common-local/w/api.php(3): require('/srv/common-loc...')
#6 {main}

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=66717
Change 140558 merged by jenkins-bot:
Revert "Update displaytitle on save"

https://gerrit.wikimedia.org/r/140558
Change 140558 had a related patch set uploaded by Catrope:
Revert "Update displaytitle on save"

https://gerrit.wikimedia.org/r/140558
There's no way to apply heading styles.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Yeah, this was intentionally left out of the MVP.
Screenshot

Steps to reproduce:

1.Open a page with mobile VE 
2.Type a text in CE
3.Select that text
4.Click on Link inspector icon from the toolbar

Observed Result:
The link inspector dialog opens but there is no suggestion for link target, also the text selected should appear in the text field inside link inspector, which is not happening as well

Device: Nexus 7(Android 4.4.2)
Environment:Betalabs

See the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F13913}
Verified the fix in production en.wiki for iOS only, for Android there is a different issue, where the link text is not appearing inside the link inspector,   so cannot follow the exact steps to reproduce to check it there.
Verified the fix in test2 with iOS and Android.
Verified the fix in Betalabs with Android as well
Verified the fix in Betalabs with iOS
Yay deployment.
Possibly a deploy issue.
Still happening on Betalabs
Change 143524 merged by jenkins-bot:
Use globalOverlay as the contextOverlay in MobileContext

https://gerrit.wikimedia.org/r/143524
Change 143524 had a related patch set uploaded by Catrope:
Use globalOverlay as the contextOverlay in MobileContext

https://gerrit.wikimedia.org/r/143524
Found the steps.
This happens every second attempt on adding a link where the keyboard gets hidden after adding the first link in CE

So the steps are:

1.Open a page with mobile VE 
2.Type a text in CE
3.Select that text
4.Click on Link inspector icon from the toolbar
5.Select a suggestion that appears in the dropdown box
6.After this link gets added successfully, hide the keyboard
7.Again type a new text and try to add a link to it from the link inspector

Observed Result:
No link suggestions appear, cannot close the link inspector.
I am getting this issue intermittently now. Surely the behavior got changed/improved which is why it is not reproducible anymore in a straight forward way.

I will see if I can find any consistent step that ensures this issue to happen.
This is not android specific issue, its happening for iOS as well.
Also, it has gone to production now.So, the environment is not just Betalabs now :(
Screenshot

Steps to reproduce:

1.Open a page with VE in Firefox
2.Go to Insert>Language
3.Close the language inspector without making any change

Observed Result:
An error appears in the console:
TypeError: sel.nativeSelection is null

See the screenshot attached

Environment:test2 and Betalabs

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

**Attached**: {F13853}
Verified the fix in production
Verified the fix in test2
After re-deployment , it is now fixed :)
Note: doesn't appear in Beta Labs for some reason, but does in production.
Indeed, not working. Sigh.
It's still not working on test2.
Actually yes, just a deployment issue.
Apparently not. :-(
Change 140426 merged by jenkins-bot:
Catch rangy exception thrown in FF

https://gerrit.wikimedia.org/r/140426
Change 140426 had a related patch set uploaded by Catrope:
Catch rangy exception thrown in FF

https://gerrit.wikimedia.org/r/140426
Change 140326 merged by jenkins-bot:
Catch rangy exception thrown in FF

https://gerrit.wikimedia.org/r/140326
Change 140326 had a related patch set uploaded by Esanders:
Catch rangy exception thrown in FF

https://gerrit.wikimedia.org/r/140326
on https://www.mediawiki.org/wiki/Extension:Gadgets and edit throws following error:
TypeError: title is null
https://bits.wikimedia.org/static-1.24wmf9/resources/src/mediawiki/mediawiki.Title.js
Line 123

--------------------------
**Version**: unspecified
**Severity**: normal
Change 145055 merged by jenkins-bot:
MWTemplatePage: Account for template.title being null

https://gerrit.wikimedia.org/r/145055
Change 145055 had a related patch set uploaded by Krinkle:
MWTemplatePage: Account for template.title being null

https://gerrit.wikimedia.org/r/145055
Yep. It used to throw 
> Uncaught TypeError: title is null

It now fails earlier because the code changed. Namely on 

> Uncaught TypeError: Cannot read property 'replace' of null
I wanted to open a new bug, but here is still one :) Actually i become the message:
Uncaught TypeError: Cannot read property 'replace' of null

fyi :)
(In reply to Gabriel Wicke from comment #3)
> Simple test case: {{{{echo|echo}}|foo}}
> 
> The Parsoid output looks correct to me.

Thanks!


Ed – I guess in these cases we should just detect that it's an invalid title somehow and mark the template as uneditable?
Hmm, actually there is an issue in the Parsoid output for this test case, but it's not likely to be related to this bug.

{{{{echo|echo}}|foo}}

data-mw looks good, but the string 'foo' is missing in the span for some reason.

<span about="#mwt1" typeof="mw:Transclusion" data-mw='{"parts":[{"template":{"target":{"wt":"{{echo|echo}}"},"params":{"1":{"wt":"foo"}},"i":0}}]}'></span>

Reported in bug 66820.
Simple test case: {{{{echo|echo}}|foo}}

The Parsoid output looks correct to me.
(In reply to Ed Sanders from comment #1)
> Looks like we don't support evaluated template names:
> {{ {{TNTN:Extension}}
>   |...
> }}
> 
> Not sure if this a VE or Parsoid problem.

Feels like this template should have been ExpandedAttrs'ed by Parsoid?
Looks like we don't support evaluated template names:
{{ {{TNTN:Extension}}
  |...
}}

Not sure if this a VE or Parsoid problem.
VE editable div remains after Save

As a logged in user on beta labs http://en.wikipedia.beta.wmflabs.org/

Edit any page and Save

User can continue to type in the saved page in a VE documentNode div

See screen shot

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=66792

**Attached**: {F13826}
(In reply to Alex Monk from comment #5)
> How did you guys reproduce this before the revert (outside of
> deployment-prep)?

We didn't.
How did you guys reproduce this before the revert (outside of deployment-prep)?
I fixed the server errors, and now I can't reproduce this.
(In reply to Gerrit Notification Bot from comment #2)
> Change 140558 had a related patch set uploaded by Catrope:
> Revert "Update displaytitle on save"
> 
> https://gerrit.wikimedia.org/r/140558

This was unrelated we think.
Change 140558 had a related patch set uploaded by Catrope:
Revert "Update displaytitle on save"

https://gerrit.wikimedia.org/r/140558
Getting server errors on beta, but can't reproduce in master.
Screenshot

Steps to reproduce:

1.Open a page with VE in Firefox
2.Go to Insert>Language
3.Close the language inspector without making any change
4.Click on "Save Page"

Observed Result:
After step 3 you get the error: TypeError: sel.nativeSelection is null
After saving there is another error in the console:
TypeError: this.debugBar is null

If you had categories add on this page, they move to the top of the page
The context menu for Language Inspector is still open in read mode
Try to reopen VE , clicking on Edit button, VE does not open.

Environment: test2 and Betalabs

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

**Attached**: {F13751}
Verified the fix in production(en.wiki)
Ignore my last comment, added the comment on wrong bug
The backport did not work in test2
Verified the fix in Betalabs
(In reply to ryasmeen from comment #5)
> Sorry, the language inspector throwing "TypeError:sel.nativeSelection is
> null"-
> this is in both test2 and betalabs,but not the issue with tearing down the
> debug bar.
> Initially I thought both of them are related.I am opening a different bug
> for that one.

OK, thanks.
Sorry, the language inspector throwing "TypeError:sel.nativeSelection is null"-
this is in both test2 and betalabs,but not the issue with tearing down the debug bar.
Initially I thought both of them are related.I am opening a different bug for that one.
Are you sure this is a fault for test2? The code this follows up wasn't present for wmf9 unless I'm missing something.
Change 140039 merged by jenkins-bot:
Followup 00af434: only tear down debug bar if it exists

https://gerrit.wikimedia.org/r/140039
Change 140039 had a related patch set uploaded by Catrope:
Followup 00af434: only tear down debug bar if it exists

https://gerrit.wikimedia.org/r/140039
The second error: TypeError: this.debugBar is null
appears after selecting any language from the language selector
Steps to reproduce:

1.Open a pag with VE
2.Insert a Heiro
3.While the cursor is at the end of hiero, hit return to go the next line


Observed Result:
Error: Inserted data is trying to close the root node (at index 0) appears and cannot go to the next line

Environment:

Betalabs, test2

--------------------------
**Version**: unspecified
**Severity**: normal
Looks like it is now.
This is not yet fixed in Betalabs.
Change 140345 merged by jenkins-bot:
Prevent getOffset from return an offset inside a content node

https://gerrit.wikimedia.org/r/140345
Change 140345 had a related patch set uploaded by Esanders:
Prevent getOffset from return an offset inside a content node

https://gerrit.wikimedia.org/r/140345
When a page is opened in the wikitext editor with section=0, the top of the page is presented for editing The is the desired and expected behavior:

https://en.wikipedia.org/w/index.php?title=Armadillo&action=edit&section=0

However, VisualEditor does not do this when vesection=0 is opened up for editing. The cursor is placed at the top of the page, but the screen scrolls down to the bottom of the page. The expected behavior is that the scree stay at the top of the window:

https://en.wikipedia.org/w/index.php?title=Armadillo&veaction=edit&vesection=0

This does not occur when using section=0:

https://en.wikipedia.org/w/index.php?title=Armadillo&veaction=edit&section=0

This is particularly important to the Russian Wikipedia, where they regularly use edit&section=0 links and it's easy to wind up with vesection=0.

Here's the report on my ru.wp talk page, with ru.wp links:
https://ru.wikipedia.org/w/index.php?title=%D0%9E%D0%B1%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5_%D1%83%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA%D0%B0:Keegan_(WMF)&oldid=prev&diff=63662618

--------------------------
**Version**: unspecified
**Severity**: normal
Change 141977 merged by jenkins-bot:
Don't try to change offset for vesection=0

https://gerrit.wikimedia.org/r/141977
Change 141977 had a related patch set uploaded by Esanders:
Don't try to change offset for vesection=0

https://gerrit.wikimedia.org/r/141977
Verified the fix in Betalabs
Change 139879 merged by jenkins-bot:
Followup e48ecbc5: fix fatal error due to undefined variable

https://gerrit.wikimedia.org/r/139879
Change 139879 had a related patch set uploaded by Catrope:
Followup e48ecbc5: fix fatal error due to undefined variable

https://gerrit.wikimedia.org/r/139879
*** Bug 66681 has been marked as a duplicate of this bug. ***
I am seeing this error modal dialog also intermittently on test2wiki (and presumably mediawiki.org) when switching modes from VE to wikitext editor.
Note: saving changes works correctly
1. Click on an image
2. Press delete

Nothing happens

Contrast with focussing an image by keyboard navigation.

--------------------------
**Version**: unspecified
**Severity**: major
Change 139679 merged by jenkins-bot:
Defer focusableNode selection fix until after native selection change

https://gerrit.wikimedia.org/r/139679
Change 139679 had a related patch set uploaded by Esanders:
Defer focusableNode selection fix until after native selection change

https://gerrit.wikimedia.org/r/139679
When converting between block and inline images we hide the <figcaption> with CSS instead of removing it from the DOM tree. We need to preserve the caption in case the user converts from inline back to block, but this can be done in the model.

--------------------------
**Version**: unspecified
**Severity**: enhancement
What's left to do here?
* Move your cursor anywhere in the document, don't select anything.
* Open the link inspector
* Set target anywhere
* Click back to document in the same position
* Press any key
* New character is shown, but is highlighted. If you undo and then redo, a pawn character appears.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68590
Yeah, I'm going to declare this one also fixed in the re-write. The block slug issue is… interesting, and may deserve its own bug, but I'll comment on bug 68590.
Doesn't seem to happen anymore. Although we do now have bug 68590, which is pretty much these same steps but with another undo instead of redo at the end. Not sure about Roan's comment.
Sometimes I've managed to get this to create a pawn character at the same time as making the highlighted text. Appears to be to do with the target text.
Additionally, if you put your cursor in a block slug, open the link inspector in creation mode, and click back into the surface in the same place, the link inspector doesn't close. Then when you start typing, the same behavior as in comment 0 appears.
After a fresh installation of MW 1.23 (from the tarball), adding VisualEditor and configuring parsoid, the "Edit" (or "Create") link of any page is not working.

I am not the only one having this problem: https://www.mediawiki.org/wiki/Extension_talk:VisualEditor#Can_not_get_VisualEditor_extension_for_MediaWiki_REL1_23_working_on_freshly_installed_system_44018

What I saw when I checked with FireBug:
* In an old (1.22) installation clicking "Edit" results in a POST-request with action=visualeditor&paction=parse&page=Main_Page&format=json as its content.
* In the new installation no request is visible in FireBug when clicking on "Edit".

One more finding: It seems to work in 1.23alpha. I used wikiapiary to search for sites using VisualEditor and found e.g. this one: http://techwiki.umbel.org/index.php/Special:Version where it works...

Some more investigation:
using the Poster-extension of Firefox to manually POST 
"action=visualeditor&paction=parse&page=Main_Page&format=json" (application/x-www-form-urlencoded) to .../api.php
returns good looking content of type "application/json; charset=utf-8" (see attachment "visualeditor_postresponse.json").

But the JS-compoments of VisualEditor are not displaying anything!

--------------------------
**Version**: unspecified
**Severity**: major
(In reply to Tony Mach from comment #10)
> Ok, VisualEditor is now running on my system!
> 
> And I found the problem:
> 
> If you download the VisualEditor via the web-interface at
> http://git.wikimedia.org/branches/mediawiki%2Fextensions%2FVisualEditor.git
> then you will *NOT* get any submodules, like e.g. lib/ve/. 
> 
> The problem is, that web-interface for git at git.wikimedia.org can not
> handle git submodules. If you download an archive of VisualEditor (e.g.
> REL1_23) then lib/ve will be missing. If you try to access a submodule like
> lib/ve, then the web-interface will give you an error message.
> 
> If you download VisualEditor via
> https://www.mediawiki.org/wiki/Special:ExtensionDistributor/VisualEditor
> then everything is fine.
> 
> If you manually download VisualEditor via git commandline, and do a "git
> submodule update --init" afterwards, then everything is fine.

Yeah, the instructions say this pretty clearly, though I see you've now gone rather over-board in saying this several times in big boxes. :-)

> What is really annoying was the lack or error-messages.

Yeah; we should raise an issue with MediaWiki core about the lack of user-visible errors, though gerrit 155177 will at least make it more obvious for VisualEditor users in future.
**bugzilla.wikimedia.org** wrote:

Ok, VisualEditor is now running on my system!

And I found the problem:

If you download the VisualEditor via the web-interface at http://git.wikimedia.org/branches/mediawiki%2Fextensions%2FVisualEditor.git then you will *NOT* get any submodules, like e.g. lib/ve/. 

The problem is, that web-interface for git at git.wikimedia.org can not handle git submodules. If you download an archive of VisualEditor (e.g. REL1_23) then lib/ve will be missing. If you try to access a submodule like lib/ve, then the web-interface will give you an error message.

If you download VisualEditor via https://www.mediawiki.org/wiki/Special:ExtensionDistributor/VisualEditor then everything is fine.

If you manually download VisualEditor via git commandline, and do a "git submodule update --init" afterwards, then everything is fine.

What is really annoying was the lack or error-messages.
Please explain how you installed VE and its dependencies and which exact guide you followed; might be better to ask/discuss on IRC in #mediawiki-visualeditor or https://www.mediawiki.org/wiki/Talk:VisualEditor or https://www.mediawiki.org/wiki/Extension_talk:VisualEditor
**bugzilla.wikimedia.org** wrote:

D:\xampp\apps\mediawiki\htdocs\extensions\VisualEditor/lib/ve/ is missing on my system!!! There is only jquery.uls ...

Where do I get the ve lib? Why don't I have the ve lib?
I've updated REL1_23 to just simply use 1.23wmf22 instead, which should fix the incompatibility. Sorry about this.
Relevant commits that were in wmf/1.23wmf22 but not in REL1_23 yet:

https://github.com/wikimedia/mediawiki-extensions-VisualEditor/compare/REL1_23...wmf/1.23wmf22

https://github.com/wikimedia/VisualEditor/compare/55a5cdc047...b3e5759654

I reckon one or more of those should be backported.
Hello Kevin,

thank you for the confirmation and the additional information!

Switching to the git-Version of VisualEditor and using branch wmf/1.23wmf22 did indeed make it work for me as well!

But I do not want to use this work-around in a production environment without anyone in the know confirming it's the way to go...
I can confirm this bug.  It is throwing the following JS exception:

Exception thrown by ext.visualEditor.core
Error: constructor must be a function, cannot be a undefined

The exception gets throwing trying to call:

ve.ui.windowFactory.register( OO.ui.ConfirmationDialog );

From line 22 of lib/modules/ve/ui/ve.ui.js

The problem goes away if I switch from branch REL1_23 to wmf/1.23wmf22 (and run git submodule update).
Created attachment 15635
Response of POST to api.php

**Attached**: {F13953}
Right now they're not, which is irritating when I'm writing about how VE supports the functionality. :-)

--------------------------
**Version**: unspecified
**Severity**: normal
Change 140194 merged by jenkins-bot:
(Bug 66514) Fix bug in nowiki-escaping of magic words

https://gerrit.wikimedia.org/r/140194
Change 140194 had a related patch set uploaded by Subramanya Sastry:
(Bug 66514) Fix bug in nowiki-escaping of magic words

https://gerrit.wikimedia.org/r/140194
[subbu@earth lib] echo "Fails when not in <b>sol context</b> __TOC__" | node parse --html2wt --trace wt-escape
[wt-esc]       | EWT: "Fails when not in "
[wt-esc]       | ---No-checks needed---
[wt-esc]       | EWT: "sol context"
[wt-esc]       | ---No-checks needed---
[wt-esc]       | EWT: " __TOC__"
[wt-esc]       | SOL: false " __TOC__"
[wt-esc]       | ---Not-SOL and safe---
Fails when not in '''sol context''' __TOC__
[subbu@earth lib] echo "Works when node is in sol context __TOC__" | node parse --html2wt --trace wt-escape
[wt-esc]       | EWT: "Works when node is in sol context __TOC__"
[wt-esc]       | SOL: true "Works when node is in sol context __TOC__"
[wt-esc]       | nl: true :text= "Works when node is in sol context __TOC__"
[wt-esc]       | T: "Works when node is in sol context "
[wt-esc]       | T: {"type":"SelfclosingTagTk","name":"behavior-switch","attribs":[{"k":"word","v":"__TOC__"}],"dataAttribs":{"tsr":[34,41],"src":"__TOC__"}}
[wt-esc]       | ---Found WT tokens---
Works when node is in sol context <nowiki>__TOC__</nowiki>
[subbu@earth lib] echo "<b>__TOC__</b>" | node parse --html2wt
'''__TOC__'''
[subbu@earth lib] echo "<foobar>__DISAMBIG__</foobar>" | node parse --html2wt
<foobar>__DISAMBIG__</foobar>
See e.g. https://www.mediawiki.org/w/index.php?title=VisualEditor/status&diff=prev&oldid=1034135 for an insertion without <nowiki>s, or https://www.mediawiki.org/w/index.php?title=VisualEditor:Bug_66514&oldid=1039124 for a more minimal test.

The problem appears to be that <code>__Foo__</code> stops __Foo__ being recognised.
See https://en.wikipedia.org/w/index.php?title=User%3ASsastry%2FVE_Test&diff=613314757&oldid=584723202

and also this:

[subbu@earth lib] echo "This is a test of __DISAMBIG__ getting nowikied" | node parse --html2wt
This is a test of <nowiki>__DISAMBIG__</nowiki> getting nowikied
It's unused now.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Done in gerrit 141089.
Fair point. Whoops. :-) Relabelling.
We still need to 1) get Trevor to look at whether it actually needs to die and 2) update callers, including ones which pass the parameter through
* Create two references, one above the fold and one below
* Scroll down to the one below the fold, inspect it, and use the "Use existing reference" feature to swap it out for the first one
* The page is now scrolled to the top

I think this might be because we delete and reinsert the reference?

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=65882
Verified the fix in test2 and Betalabs.
It is indeed fixed. Thanks Ed!
May have been fixed by https://gerrit.wikimedia.org/r/#/c/138833/ ?
* Create a page with <syntaxhighlight lang="javascript">foo && bar</syntaxhighlight>
* Open the page in VE
* Inspect the syntaxhighlight block and change bar to baz
* Observe &amp;&amp; instead of && in the preview

Saving the change doesn't double-encode the ampersands though.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 60332 ***
Screenshot

Steps to reproduce:

1.Open a page in VE with Firefox
2.Add a link or reference
3.Select the node
4.When the context menu appears, hover over it

Observed Result:
Its not highlighting the entire context menu, but some part of it

See the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F13767}
Verified the fix in production (en.wiki)
Verified the fix in test2 running wmf9
Verified the fix in Betalabs
Fixed by gerrit 138906.
QUnit is complaining whenever I try and +2 code and it is preventing merges from happened e.g. https://gerrit.wikimedia.org/r/#/c/138375/ https://integration.wikimedia.org/ci/job/mwext-MobileFrontend-qunit/6228/console

After talking to Antoine we think it might be a side effect of the warnings produced by: https://gerrit.wikimedia.org/r/#/c/135429/

--------------------------
**Version**: unspecified
**Severity**: major
Change 138682 merged by jenkins-bot:
Revert "Revert "Officially deprecate skin autodiscovery""

https://gerrit.wikimedia.org/r/138682
Change 138648 merged by Krinkle:
defaults: Make values for 'wipe-workspace' and 'clean' explicit

https://gerrit.wikimedia.org/r/138648
Change 138682 had a related patch set uploaded by Bartosz Dziewoński:
Revert "Revert "Officially deprecate skin autodiscovery""

https://gerrit.wikimedia.org/r/138682
Thank you!
Confirmed fix by seeing that old files in skins/* are gone in workspaces on gallium, and confirmed again by touching a file `krinkle.txt` and confirming it was gone the next build.
Change 138657 merged by jenkins-bot:
mw-core-get: Clean workspace first

https://gerrit.wikimedia.org/r/138657
Change 138657 had a related patch set uploaded by Krinkle:
mw-core-get: Clean workspace first

https://gerrit.wikimedia.org/r/138657
Change 138648 had a related patch set uploaded by Krinkle:
defaults: Make values for 'wipe-workspace' and 'clean' explicit

https://gerrit.wikimedia.org/r/138648
(In reply to Krinkle from comment #7)
> Taking mwext-VisualEditor-qunit as a usecase there's a couple facts:
> 
> 1) As being a repo not having the target git repo (VE) at its root, it has
> git:clean:false and git:wipe:true (defaults), see 'use-zuul-for-mw-ext' in
> jenkins-job-builder-config and confirmed on
> https://integration.wikimedia.org/ci/job/mwext-VisualEditor-qunit/configure
> (expand the Advanced sections)
> 
> * [ ] Clean after checkout [_]
>       (runs `git clean`)
> * [x] Wipe out workspace before build
> 
> 
> 2) Looking at an example build:
>   
> https://integration.wikimedia.org/ci/job/mwext-VisualEditor-qunit/10021/
> consoleFull
>    - Wiping out workspace first.
>    - Cloning repository
> git://zuul.eqiad.wmnet/mediawiki/extensions/VisualEditor
>    - /srv/deployment/integration/slave-scripts/bin/mw-core-get.sh master
> 
>    In that order.
> 
> 3) Even if this wouldn't happen, I think it's fine to use full wipe instead
> of git-clean since all these run on the local system and should be able to
> use hardlinks during the cloning (for the extension repo), and for mwcore we
> use archive from a central repo /srv/ssd/gerrit/mediawiki/core.git so its'
> fine to wipe the workspace of the extension repo)
> 
> 4) Confirmed by running mkdir ~/test; export WORKSPACE=~/test;
> /srv/ssd/gerrit/mediawiki/core.git master; that the central git repo is not
> dirty, the old files and skin directories are not in there.
> 
> 
> So then why do we have RELEASE-NOTES-1.22 and skins/Modern.php in
> mwext-VisualEditor-qunit workspace still?


Looks like the real underlying bug is that the 'non-git' wipe option we have (the one that fully removes the work tree and will require a new git-clone on each build, the option we actually *are* using for extensions jobs) that wipe option (not git-clean) still restricts itself to where the git-clone will be. It doesn't wipe the workspace, it wipes workspace/{basedir}.
Let's get this issue fixed now so we can work towards merging Bartosz's patch again.
Change 138626 merged by jenkins-bot:
Revert "Officially deprecate skin autodiscovery"

https://gerrit.wikimedia.org/r/138626
I went ahead and merged Jon's revert so that mobile and VE development are not blocked.
Rephrasing bug summary. For the record, this only affects files that have actually landed in master. We do clean out files from proposed patches properly, this bug is specifically due to and related to fetching of latest master within extensions.
Taking mwext-VisualEditor-qunit as a usecase there's a couple facts:

1) As being a repo not having the target git repo (VE) at its root, it has git:clean:false and git:wipe:true (defaults), see 'use-zuul-for-mw-ext' in jenkins-job-builder-config and confirmed on https://integration.wikimedia.org/ci/job/mwext-VisualEditor-qunit/configure (expand the Advanced sections)

* [ ] Clean after checkout [_]
      (runs `git clean`)
* [x] Wipe out workspace before build


2) Looking at an example build:
   https://integration.wikimedia.org/ci/job/mwext-VisualEditor-qunit/10021/consoleFull
   - Wiping out workspace first.
   - Cloning repository git://zuul.eqiad.wmnet/mediawiki/extensions/VisualEditor
   - /srv/deployment/integration/slave-scripts/bin/mw-core-get.sh master

   In that order.

3) Even if this wouldn't happen, I think it's fine to use full wipe instead of git-clean since all these run on the local system and should be able to use hardlinks during the cloning (for the extension repo), and for mwcore we use archive from a central repo /srv/ssd/gerrit/mediawiki/core.git so its' fine to wipe the workspace of the extension repo)

4) Confirmed by running mkdir ~/test; export WORKSPACE=~/test; /srv/ssd/gerrit/mediawiki/core.git master; that the central git repo is not dirty, the old files and skin directories are not in there.


So then why do we have RELEASE-NOTES-1.22 and skins/Modern.php in mwext-VisualEditor-qunit workspace still?
Sorry Kunal :-(  And you have no idea how much it piss me off to have to revert such a patch from core :-(
(In reply to Antoine "hashar" Musso from comment #2)
> The reason is that since mediawiki/core.git is so huge to clone, we are
> using git archive to grab a snapshot of MediaWiki in the Jenkins job
> workspace.  A side effect is that files removed from the repository are not
> removed from the workspace.

Uck :/

(In reply to Antoine "hashar" Musso from comment #4)
> We could clean up the /skins/ directory in all workspaces potentially, but I
> can't remember whether the same job could use a REL1_*** codebase which
> would bring back the skins.

Lets do that for now. People shouldn't be backporting stuff to REL branches in the near future, which gives us a little more time to fix jenkins to delete files properly.
We could clean up the /skins/ directory in all workspaces potentially, but I can't remember whether the same job could use a REL1_*** codebase which would bring back the skins.
Change 138626 had a related patch set uploaded by Hashar:
Revert "Officially deprecate skin autodiscovery"

https://gerrit.wikimedia.org/r/138626
https://gerrit.wikimedia.org/r/#/c/135429/ added a warning message whenever an old skin is found under Mediawiki /skins/ . The skins have been removed from core but are still present in Jenkins workspace.

The reason is that since mediawiki/core.git is so huge to clone, we are using git archive to grab a snapshot of MediaWiki in the Jenkins job workspace.  A side effect is that files removed from the repository are not removed from the workspace.


A potential way to solve it would be to have mediawiki core in a dedicated directory which we would be able to delete recursively before taking a snapshot with git archive.  From there we could symlink extensions from their dedicated directories under mediawiki /extensions/ .

I also have an ongoing project to clone multiple repositories which might let us solve the issue.

Meanwhile my recommendation is to revert the deprecation patch ( https://gerrit.wikimedia.org/r/#/c/135429/ ) until CI has catched up and ensure MediaWiki code base is clean in the Jenkins workspaces.
(In reply to Jon from comment #0)

> https://integration.wikimedia.org/ci/job/mwext-MobileFrontend-qunit/6228/

Since Modern is no longer in core, why is it in the skins directory?
I have been getting this issue since this morning, I think this has something to do with changing image size when the size of an image gets adjusted or changed.
I do not have the exact steps to reproduce for now.But it happened this one time when I changed the thumbnail left aligned image to centre float.

This is the page where you will see the image on which I made the change and getting the edit conflict error :
http://en.wikipedia.beta.wmflabs.org/wiki/9thjunechrome?veaction=edit

We had encountered similar kind of issue quiet a while ago, which was fixed:
https://bugzilla.wikimedia.org/show_bug.cgi?id=62172

I am not sure, if the same cause is behind the bug or not

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production (en.wiki)
Verified the fix in test2 running wmf 9
Verified the fix in Betalabs
Change 138521 merged by jenkins-bot:
Followup bd49f97: prevent MWExtensionNodes from having children

https://gerrit.wikimedia.org/r/138521
Change 138521 had a related patch set uploaded by Catrope:
Followup bd49f97: prevent MWExtensionNodes from having children

https://gerrit.wikimedia.org/r/138521
There is a very weird issue, probably introduced by Ed's extension nodes rewrite. Any extension node's children get duplicated on the way back to Parsoid: a hieroglyphs <table> gets two <tbody>s, a gallery <ul> contains all of its <li>s twice, etc.
Sometimes modules have dependencies that can't be determined until runtime; most obviously, code that requires shims for browser functionality that may be missing on a few clients.

It would be great if instead of static dependencies, modules could specify dependencies that are evaluated at run-time and only loaded if needed.

--------------------------
**Version**: 1.24rc
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56341
Change 135085 merged by jenkins-bot:
resourceloader: Implement "skip function" feature

https://gerrit.wikimedia.org/r/135085
Per discussion between Roan and me we're taking this use case as a story rather than a specific call to implementation.

We won't be adding a feature to conditionally declare something as a dependency. So the following will not be the how it is used:

visualeditor.dependencies = [es5]
->
visualeditor.dependencies = function (deps) {
  if ( browser doesn't support es5 ) {
    deps.push( es5);
  }
};


Instead we're going to take it the other way around and have the condition be on the target module (e.g. es5.js instead of visualeditor).

visualeditor.dependencies = [es5]
es5.skip = function () {
  return browser supports es5;
};

This way will result in much less duplication, and feels more semantically correct because it doesn't make sense for an application to have a dependency that can change. Modules are supposed to be a canonical representation of an interface, not a specific implementation, skin, language or file. Either the module to provide it or it doesn't. Instead visualeditor (or indeed, oojs) would declare it needs the thing that es5-shim.js provides. And es5-shim can decide to forego fetching of any actual files if it detects the environment has it already (either by native or another polyfill).

This will make the experience for developers much easier (no need to duplicate if -conditions for es5 all over the place) and practically removes any possibility of abusing this feature for implementing any bad ideas.
Change 135085 had a related patch set uploaded by Jforrester:
[WIP] resourceloader: Implement "skip function" feature

https://gerrit.wikimedia.org/r/135085
**Author:** `vojtech.dostal`

**Description:**
A student of Education program at Czech Wikipedia noticed that she cannot resize an image which is inserted as a frame. It is well possible to adjust the size in the preview mode, but saving it does not produce appropriately resized image frame. 


see image under heading "Půdorys" at:
https://cs.wikipedia.org/wiki/Kostel_Nanebevzet%C3%AD_Panny_Marie_%28Charvatce%29

Thank you
Vojtěch Dostál

--------------------------
**Version**: unspecified
**Severity**: normal
Change 138388 merged by jenkins-bot:
Disable the size widget for 'frame' images

https://gerrit.wikimedia.org/r/138388
Scratch my last remark. There is still a technical debt (that is being taken care of) about default vs. custom size but the issue in this case is that we don't follow the wikitext rules properly. 

Frame images ignore size specification. 
See wikitext documentation here: https://www.mediawiki.org/wiki/Help:Images#Size_and_frame
Change 138388 had a related patch set uploaded by Mooeypoo:
Disable the size widget for 'frame' images

https://gerrit.wikimedia.org/r/138388
Yes, after a bit of analysis, I believe there's a problem with the way the scalable object analyzes default vs custom values. I'm working on refactoring the way that works; we have a tech debt about this, too, I believe.
Thanks for this bug; it seems like a regression(?!) in MediaWiki. Moriel, can you confirm?
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Change the Image type from Thumbnail to Frameless/Basic

Observed Result:

The checkbox for wrap option gets unchecked but the alignment tabs are still active

See the screenshot attached

This is happening in Betalabs but not on test2

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F13997}
Verified the fix in production (en.wiki)
Verified the fix in test2 running wmf 9
Verified the fix
I REALLY mean gerrit 138663
I mean gerrit 80d1240
Fixed in 80d1240
It's not really possible to subst MediaWiki templates in VE yet (bug 49904). According to James F., it should be possible to write "subst:Foo" when inserting the template with some caveats.

This doesn't seem to work at the time. For example, writing "subst:Clarify" in the English Wikipedia, shows the string "{{subst:Clarify}}", but as a template with a highlight. When the page is saved, the template {{Clarify|date=June 2014}} is inserted - not substed.

From IRC:

aharoni: Is there a way to do a subst to a template in VE?
James_F: aharoni: Ish.
James_F: aharoni: To add a template called "Foo", instead tell it to insert subst:Foo".
James_F: aharoni: But it doesn't get the TemplateData (so it's pretty icky).
James_F: aharoni: There's a bug asking for an actual checkbox.
[...]
aharoni: James_F: about that subst thing: It doesn't seem to work. It inserts a literal {{subst:Foo}}.
James_F: aharoni: Huh. That's a regression, then. :-(

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49904
Aha. Anti-subst tech? Whatever next?
I can't replicate this bug. But I think this is actually invalid.

This 'Clarify' template on enwiki uses some clever 'Unsubst' lua module hack to deliberately break subst - take a look at the source. Also notice how that 'date' parameter appeared from nowhere?

I tested this out using the normal editor (just added '{{subst:Clarify}}'): https://en.wikipedia.org/w/index.php?title=User:Krenair/sandbox&diff=611955311&oldid=492366611

If I try any other non-Unsubst template, it's fine. For example, I added 'subst:Cite web' from VE: https://en.wikipedia.org/w/index.php?title=User:Krenair/sandbox&diff=611955603&oldid=611955311
Screenshot

Steps to reproduce:

1.Open any page with VE in Firefox or Chrome

2.Make an Edit

3.Click on "Switch to source editing"

Observed Result:
It does not open the wikitext editor for the page, rather a message appears at the op of the page: 
Some parts of the edit form did not reach the server; double-check that your edits are intact and try again.

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F13873}
Verified the fix in production(en.wiki)
Verified the fix in test2 running wmf9
Verified the fix in Betalabs
Fixed by the fix for bug 66168.
This is happening even for a new page where no edit has been done yet :(
Obviously it'd also be nice if fatals didn't happen, but I have less faith that that is possible in shorter time…

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 200649 merged by jenkins-bot:
Don't break the editor if paste handling fails

[[https://gerrit.wikimedia.org/r/200649]]
Change 200649 had a related patch set uploaded (by Catrope):
Don't break the editor if paste handling fails

[[https://gerrit.wikimedia.org/r/200649]]
Mostly seems to be caused by elements it doesn't recognise (? like <section>), especially when copying bits of tables and other structures from non-MediaWiki sources (e.g. Google Docs, Bugzilla or other places). Lots of different mystical errors as well about e.g. refusing to insert a closing tag that hasn't been opened.
Need an example so I know where to put the try/catch.
*** Bug 64009 has been marked as a duplicate of this bug. ***
Screenshot

Steps to reproduce:

1.Open any page in Betalabs or test2 with VE in Firefox

2.Make an edit

3.Save the page

4.Reopen the page

Observed Result:

In the console the following error appears:


TypeError: this.documentView is null

Also, another issue that is happening is, after editing if you try to switch to edit source mode, it is not opening the wikitext editor.Rather showing a message:
Some parts of the edit form did not reach the server; double-check that your edits are intact and try again.

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F13849}
Verified the fix in production en.wiki
Not yet fixed in en.wiki
Change 139207 merged by Catrope:
*Actual* death and/or *actual* destruction

https://gerrit.wikimedia.org/r/139207
Change 139207 had a related patch set uploaded by Catrope:
*Actual* death and/or *actual* destruction

https://gerrit.wikimedia.org/r/139207
This is happening in production.Didn't we backport it?
Verified the fix in Betalabs
(In reply to Ed Sanders from comment #8)
> MW hasn't had a core update since this was merged.
> 
> FYI: If there isn't a commit called 'Update VE core submodule to master'
> above a core commit you are testing on this page:
> 
> https://gerrit.wikimedia.org/r/#/q/is:watched+status:merged,n,z
> 
For that link to work, you need to be logged in and be watching the right projects :)

More portable link: https://gerrit.wikimedia.org/r/#/q/status:merged+AND+%28+project:mediawiki/extensions/VisualEditor+OR+project:VisualEditor/VisualEditor+%29,n,z
MW hasn't had a core update since this was merged.

FYI: If there isn't a commit called 'Update VE core submodule to master' above a core commit you are testing on this page:

https://gerrit.wikimedia.org/r/#/q/is:watched+status:merged,n,z

it won't be in MW yet.
This is still happening in Firefox for Betalabs, So reopening it
Change 138014 merged by jenkins-bot:
*Actual* death and/or *actual* destruction

https://gerrit.wikimedia.org/r/138014
Change 138014 had a related patch set uploaded by Catrope:
*Actual* death and/or *actual* destruction

https://gerrit.wikimedia.org/r/138014
The error from comment 2 happens because the old destroyed surface is getting blurred, and DesktopContext is responding to that.

The fundamental issue is this.fragment.select(); in the teardown process of ve.ui.Dialog, which runs 200ms after the save dialog closes, at which point the surface is already hidden and lots of stuff goes wrong.

Beside that, though, we should be much more aggressive about destroying things properly. And also audit things we do after a delay like this (so potentially anything in a setup/teardown process) because the user might have deactivated the editor in the meantime.
The "Switching to edit source mode not opening the wikitext editor" issue is happening in Chrome as well, however the error found for Firefox in not appearing for Chrome, so I am taking this issue to a different bug, assuming it is not related.
Also getting this error now:

Error: Range error: Range is no longer valid after DOM mutation ([WrappedRange("link":0, "link":4)])
after applying link to the text "link"
This seems to be happening because, somehow, the old torn-down ce.Surface gets a focus event, calls this.surfaceObserver.startTimerLoop(), but this explodes because the SurfaceObserver has been detached already and its .documentView is null.

We should make sure we properly destroy the old surface.
<nowiki> tags appear when editing on the Hebrew Wikipedia:

Examples:
https://he.wikipedia.org/w/index.php?title=%D7%99%D7%A8%D7%95%D7%9F_%D7%9E%D7%A8%D7%92%D7%95%D7%9C%D7%99%D7%9F&curid=1154717&diff=15542199&oldid=15542181

https://he.wikipedia.org/w/index.php?title=%D7%99%D7%A8%D7%95%D7%9F_%D7%9E%D7%A8%D7%92%D7%95%D7%9C%D7%99%D7%9F&curid=1154717&diff=15542199&oldid=15542181

https://he.wikipedia.org/w/index.php?title=HOT&diff=15542428&oldid=15528284

From the given examples, it seems to be related to editing internal links?

--------------------------
**Version**: unspecified
**Severity**: major
Corruption bugs are handled independently on a case-by-case basis; nothing in this list indicates that the <nowiki> issue is specifically related to Hebrew or RTL.

Space in the beginning of paragraphs is followed up in this bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=66628

Transforming a star into bullet point (in the beginning of a line) is followed in this bug report: https://bugzilla.wikimedia.org/show_bug.cgi?id=51408

The rest seem to be errors in typing wikitext.
After further analysis, here are the results:

Most of the nowiki problems seem to happen due to typing wikitext in the editor. For instance, typing ''word'' or '''word''' instead of marking the word as italics or bold, or typing literal == which VE then marks as =<nowiki/>= to prevent wikitext'ifying the result.

There are, however, some typing issues we could work on to make the experience easier on users:

1. Users typing a space at the beginning of a paragraph; this seems to be a mistake most of the time. Since a space at the beginning of a paragraph in wikitext transforms the paragraph to a <pre>, VE adds a <nowiki /> tag after it. It might be better if we strip those spaces when we save the page.

2. Users sometimes add list items by typing the literal * at the beginning of a line. While this is wikitext function (so VE wraps it with <nowiki>) it actually might make sense to try and transform any * at the beginning of lines to new bullet points; this is a the behavior that LibreOffice and Word are following, so it might be reasonable to have VE follow suit.

There are very few <nowiki> tags that I saw that are actual corruption. A new one that was reported recently on hewiki might show a problem with reading the wikitext headings wrong, so upon deleting the heading all that's left are == which VE marks with =<nowiki>= (see here: https://he.wikipedia.org/w/index.php?title=%D7%A9%D7%95%D7%9C%D7%97%D7%9F&diff=15566083&oldid=154101 ) 

Some, like this one, seem to show a problem with existing <nowiki> tags that then get "worse" after edit: https://en.wikipedia.org/w/index.php?title=Rathmore,_County_Kildare&curid=43246971&diff=618885701&oldid=618885287

We might want to consider marking any existing <nowiki>, perhaps?

In any case, these seem to be fairly uncommon and we should treat them on a case to case basis.
This seems to also happen in the English wikipedia with quotes and asterix characters.

Examples:

https://en.wikipedia.org/w/index.php?title=Scar_(The_Lion_King)&curid=30258014&diff=619292425&oldid=619246147

https://en.wikipedia.org/w/index.php?title=Scar_(The_Lion_King)&curid=30258014&diff=619165895&oldid=619158383

https://en.wikipedia.org/w/index.php?title=Ravi_Babu&curid=24981592&diff=618944152&oldid=611211776

https://en.wikipedia.org/w/index.php?title=Adoni&curid=2329629&diff=618931054&oldid=618930241

https://en.wikipedia.org/w/index.php?title=Mia_Freedman&curid=10942134&diff=618755773&oldid=618669491

(Several <nowiki> tags right after quotes)
https://en.wikipedia.org/w/index.php?title=Rathmore,_County_Kildare&curid=43246971&diff=618885701&oldid=618885287

(Around an asterix)
https://en.wikipedia.org/w/index.php?title=Tulluru&curid=6910687&diff=618802171&oldid=618802085
Two URL fields visible.

The citation dialog field selector is case sensitive. This allows the same field to be added multiple times as long as it's a different case. This results in a "multiple <field>" error when the citation is inserted because the fields are treated as case insensitive. 

This issue could organically come up if a citation was added using wikitext and then another user inspected the citation in VE.

--------------------------
**Version**: unspecified
**Severity**: trivial

**Attached**: {F13823}
Not a VE bug :). Turns out this was actually because "URL," which is an accepted alias of "url" by module:citation/cs1, wasn't in the templatedata as an alias. This is probably true of a LOT of the other identifiers as well. I fixed this for url on en wiki for the "big 4" but this might also be an issue with other identifiers that are commonly capitalised as well, and probably on any template that is based on this module.
Created attachment 15574
Two fields error

**Attached**: {F13824}
See comments on https://gerrit.wikimedia.org/r/#/c/136981

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 138500 merged by jenkins-bot:
Initialize 'default' size properly in media edit dialog

https://gerrit.wikimedia.org/r/138500
Change 138497 merged by jenkins-bot:
Reorganize initialization of default size in MediaSizeWidget

https://gerrit.wikimedia.org/r/138497
Change 138500 had a related patch set uploaded by Mooeypoo:
Initialize 'default' size properly in media edit dialog

https://gerrit.wikimedia.org/r/138500
Change 138497 had a related patch set uploaded by Mooeypoo:
Reorganize initialization of default size in MediaSizeWidget

https://gerrit.wikimedia.org/r/138497
VE does not seem to accept the following link:

https://graphite.wikimedia.org/render/?width=588&height=310&_salt=1401910888.742&from=00%3A00_20140513&until=23%3A59_20140604&target=frontend.navtiming.totalPageLoadTime.desktop.authenticated.median&target=frontend.navtiming.totalPageLoadTime.desktop.anonymous.median

Instead, it reverts to the highlighted text as the link target.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=66139
Change 138016 merged by jenkins-bot:
Don't send invalid titles from the link inspector to the API

https://gerrit.wikimedia.org/r/138016
Change 138016 had a related patch set uploaded by Alex Monk:
Don't sent invalid titles from the link inspector to the API

https://gerrit.wikimedia.org/r/138016
External URLs can be valid titles, we just want to ignore invalid titles (i.e. things over 255 characters).
The HTTP 400 error we get comes with an error: {"code":"request_too_long","info":"Prefix search request was longer longer than the maximum allowed length. (267 > 255)"}

This is sent by CirrusSearch. Which explains why some wikis don't have this issue.
I can replicate this on mediawiki.org but not en.wikipedia.org or my local dev wiki.
This is two separate bugs – we shouldn't be sending these to the API anyway, but we also should cope with the 400 error, which I've made into bug 66139.
This shows up in the JS console:

Failed to load resource: the server responded with a status of 400 (Bad Request) https://www.mediawiki.org/w/api.php?format=json&action=query&generator=pref…edian&gpsnamespace=0&prop=info%7Cpageprops&ppprop=disambiguation&redirect=
Browser: Chromium 35.0.1916.114 Debian Linux
So odd behaviour untested in MSIE11 for CE isn't done differently…

--------------------------
**Version**: unspecified
**Severity**: enhancement
Fixed by Roan by the simple expediency of deleting this function.
Screenshot

Steps to reproduce:

1.Open a page
2.Open a link inspector
3.Click on the Add label link

Observed Result:
TypeError: this.linkNode is null shows up in the console and cannot close the link inspector afterwards.

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

**Attached**: {F14090}
Verified the fix in test2
Verified the fix in Betalabs
Change 136899 merged by jenkins-bot:
Remove link node inspector from insert menu

https://gerrit.wikimedia.org/r/136899
Change 136899 had a related patch set uploaded by Catrope:
Remove link node inspector from insert menu

https://gerrit.wikimedia.org/r/136899
To reproduce:
1. Edit an article in the Hebrew Wikipedia.
2. Click Insert (הוספה) -> Reference (הערת שוליים).
Observed: The "Cite" item in the toolbar is in English.
There seems to be a message for it - visualeditor-toolbar-cite-label, and it was translated to Hebrew on May 12 and exported to the code, but it doesn't appear.

--------------------------
**Version**: unspecified
**Severity**: trivial
Cherry-picks going out tomorrow.
Change 136782 merged by jenkins-bot:
Use <visualeditor-toolbar-cite-label> correctly in the Media and Reference toolbars

https://gerrit.wikimedia.org/r/136782
Change 136783 merged by jenkins-bot:
Use <visualeditor-toolbar-cite-label> correctly in the Media and Reference toolbars

https://gerrit.wikimedia.org/r/136783
Change 136783 had a related patch set uploaded by Jforrester:
Use <visualeditor-toolbar-cite-label> correctly in the Media and Reference toolbars

https://gerrit.wikimedia.org/r/136783
Change 136782 had a related patch set uploaded by Jforrester:
Use <visualeditor-toolbar-cite-label> correctly in the Media and Reference toolbars

https://gerrit.wikimedia.org/r/136782
Change 136767 merged by jenkins-bot:
Use <visualeditor-toolbar-cite-label> correctly in the Media and Reference toolbars

https://gerrit.wikimedia.org/r/136767
Change 136767 had a related patch set uploaded by Amire80:
Use the message visualeditor-toolbar-cite-label correctly

https://gerrit.wikimedia.org/r/136767
To reproduce:
1. Edit an article in the Hebrew Wikipedia.
2. Click Insert (הוספה) -> Reference (הערת שוליים).
Observe: The contenteditable div for writing the footnote text is forced to dir="ltr".
Expected: It must be in the direction of the wiki - dir="rtl", or simply without the dir, and inherit the direction.

--------------------------
**Version**: unspecified
**Severity**: minor
This seems to be fixed now with the new reference/cite system.
To reproduce:

1. Edit an article with the words Dog and Cat.
2. Select the word "Dog". Press Ctrl-K and add an internal link to Dog.
3. Select the word "Cat".
4. Press Ctrl-K.

Observe: In the auto-suggestions, "Dog" appears for a few moments before it is replaced by "Cat".
Expected: Linking to "Dog" is irrelevant here. The previous target and auto-suggestions shouldn't be reused here.

I find this rather disruptive because I want to use the link inspector for its primary purpose of adding links quickly, and this actually delays me by a few seconds. What's worse is that if I'm not careful, I can add a link with the wrong target.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 138113 merged by jenkins-bot:
[BREAKING CHANGE] Update OOjs UI to v0.1.0-pre (9f4f250f88) for window process cleanup

https://gerrit.wikimedia.org/r/138113
Change 138113 had a related patch set uploaded by Jforrester:
[BREAKING CHANGE] Window process cleanup

https://gerrit.wikimedia.org/r/138113
Steps to reproduce;

1.Open a page 
2.Open the reference dialog 
3.Click on use existing reference or just simply close it

Observed Result:
TypeError: sel.nativeSelection is null aappears in the console

Environment:test 2 and Betalabs

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix in en.wiki running wmf8
Verified the fix in test2
Verified the fix in Betalabs
Change 136451 merged by jenkins-bot:
Cleanup createSurface methods

https://gerrit.wikimedia.org/r/136451
Change 136451 had a related patch set uploaded by Jforrester:
Cleanup createSurface methods

https://gerrit.wikimedia.org/r/136451
Almost certainly the same cause as bug 65934
This is also happening while closing Media Settings dialog in Firefox
Screenshot

Steps to reproduce

1.Open a page
2.Go to Insert>Reference
3.Type in a text as reference

Observed Result:
Each letters are getting added in each line , ends with a pawn then the text appears.The following error appears in the console:

Error: ve.dm.Document.getNodeFromOffset(): offset -1 is out of bounds

After clicking on "Insert Reference":

TypeError: sel.nativeSelection is null

After saving the page:
TypeError: elem.ownerDocument.defaultView is null

This issue is happening on Firefox only.

Environmen:test2

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F13820}
Verified the fix in en.wiki running wmf8
Verified the fix in test2
Verified the fix in Betalabs
Change 136451 merged by jenkins-bot:
Cleanup createSurface methods

https://gerrit.wikimedia.org/r/136451
Change 136451 had a related patch set uploaded by Jforrester:
Cleanup createSurface methods

https://gerrit.wikimedia.org/r/136451
Caused by https://gerrit.wikimedia.org/r/#/c/135012/ being a breaking change but not marked as such. Will be fixed once https://gerrit.wikimedia.org/r/#/c/135014 is merged.
James's suggestion: never split a paragraph with a block image. It's not at all obvious what happened, especially if the image is floated right. Instead, we should put the image at the beginning of the paragraph. This would apply when inserting an image, converting an inline image to a block image, and when drag-and-dropping an image.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51666
Please discuss Tech News issues by going to Tech News (e.g. Talk page) and not to a VE bug report in Bugzilla. General questions like at the end of comment 5, even if you might consider image maps somehow related to block images in general, should better go to IRC or mailing lists. Thanks.
(In reply to James Forrester from comment #4)

See Bug 66896 (general RFE plus a real bug)

For allowing max-height and general improvement to client-side (and text-friendly) image rescaling which should also be frienfly with the current (broken) Mobile view.
- It is a bug of the Tech News that incorrectly says it applies to all images.
- This is in our control (Tech News can be fixed to say it applies only to "block images", i.e. images with left/right/center/thumb parameters, and not to other inline images; notably the many emoticon images used in may places in the middle of paragraphs: these images must not be constrained to be only at the start of paragraphs, when inserted or modified with the VisualEditor! Asian users will immediately think that the change is undesirable if they think they can't use their emojis without a supporting font !)
(In reply to Philippe Verdy from comment #5)
> So the current Tech News needs correction.

Our submissions to Tech News are generally re-written to be "simpler" and wrong. This is not (a) a bug and (b) within our control.

The rest of this is not germane for this bug; please take discussion to a venue for proper discussion, like MediaWiki.org or a mailing list.
So the current Tech News needs correction.
The expressions "block image" is ambiguous, at first reading I wondered who was right.

Yes having client-side image resizing with just the addition of support of custom CSS for images would be a bonus.

I know this works because this is already visible and used on the Mobile view even if it works with "max-width:100%" (used with the "box-model" quirk that should have never been used in its specific stylesheet, and which is absolutely not needed)

It also works best with the support of "image sets" (now enabled by default in MediaWiki that can lists several thumbnail sizes, at resolutions 1x, 1.5x and 2x; but it could also add 0.5x and 0.75x for best results, letting browsers select the best interpolations depending on screen resolution and/or zoom mode; and ideally, the image sets for SVG images could also list the native SVG format for the best quality needed for images replacing complex text)

----

For now the current Tech News for this week (referencing this bug) needs fixing as it is interpreted as meaning all images.

And what you call a "block image" is in MediaWiki an [[image:]] or [[file:]] with "left" or "right" floating-mode attribute, or "center", or "thumb(nail)" (your terminology is strange, because in HTML images are always inline by default, and even MediaWiki keeps them inline by placing the generated <img> element, possibly surrounded by an <a> element, within a block element).

----

Also, what is happening to image maps in the VisualEditor ? (they are also inline by default, and probably should be resizable by the client)
Change 140037 merged by jenkins-bot:
Insert images at the start of paragraphs

https://gerrit.wikimedia.org/r/140037
Change 140037 had a related patch set uploaded by Mooeypoo:
Insert images at the start of paragraphs

https://gerrit.wikimedia.org/r/140037
Go to a page with an image that's below the fold (i.e. you have to scroll down to see it). Drag it and drop it in a position that's also below the fold.

The viewport scrolls up to the top, scrolling the image out of view :(

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=62420
https://bugzilla.wikimedia.org/show_bug.cgi?id=66462
Change 138833 merged by jenkins-bot:
Don't refocus the document in onModelSelect

https://gerrit.wikimedia.org/r/138833
Change 138833 had a related patch set uploaded by Esanders:
Don't refocus the document in onModelSelect

https://gerrit.wikimedia.org/r/138833
Screenshot

Steps to reproduce:

1.Open this page with VE:http://en.wikipedia.beta.wmflabs.org/wiki/28thmayff?veaction=edit

2.Insert a special character in the block slug just on top of the last image in the page

3.Press enter to go to the next line

Observed Result:
Cannot go to the next line, the following error appears:

Error: Inserted data is trying to close the root node (at index 0)

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

**Attached**: {F13657}
Appears to work now.
Yay for things in block slugs. :-(
Since a few days, there are reports of the version dropdown being empty even though the branches exist. This makes it impossible to download extensions from ExtensionDistributor.

https://www.mediawiki.org/wiki/Thread:Extension_talk:CirrusSearch/CirrusSearch_download
https://www.mediawiki.org/wiki/Thread:Project:Current_issues/Can%27t_download_extensions

--------------------------
**Version**: master
**Severity**: major
We're no longer using github at all, so this should no longer be an issue.
I203d635b2a5e42197913d7d8b7cd8da083dd8981 was also merged, which will provide negative cache entries when a branch doesn't exist, which should make this a lot better in the short term.

After discussing with ^d and James_F, we're going to stop using github and instead use a labs setup I created (ex: http://extdist.wmflabs.org/?version=REL1_23&ext=VisualEditor) which will make it so we don't need to worry about ratelimiting at all.
Change 146386 merged by jenkins-bot:
Allow making API requests as an authenticated user

https://gerrit.wikimedia.org/r/146386
Change 146394 merged by jenkins-bot:
Display an error if no branches are found

https://gerrit.wikimedia.org/r/146394
Change 146394 had a related patch set uploaded by Florianschmidtwelzow:
Display an error if no branches are found

https://gerrit.wikimedia.org/r/146394
Change 146386 had a related patch set uploaded by Legoktm:
Allow making API requests as an authenticated user

https://gerrit.wikimedia.org/r/146386
legoktm@terbium:~$ curl --proxy url-downloader.wikimedia.org:8080 -i https://api.github.com/repos/wikimedia/mediawiki-extensions-MassMessage/tarball/REL1_23

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0

and the content body:

{
  "message": "API rate limit exceeded for <ip>. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)",
  "documentation_url": "https://developer.github.com/v3/#rate-limiting"
}
Are we being hit by github's ratelimiting? (I don't know if we have a special exemption or anything...)

Via eval.php:

> $httpOptions = array( 'followRedirects' => false );

> $httpOptions['proxy'] = $wgExtDistProxy;

> $req = MWHttpRequest::factory("https://api.github.com/rate_limit", $httpOptions);

> var_dump($req->getContent());
string(177) "{"resources":{"core":{"limit":60,"remaining":0,"reset":1405398906},"search":{"limit":10,"remaining":10,"reset":1405396979}},"rate":{"limit":60,"remaining":0,"reset":1405398906}}"
Seems to be somewhat random. Versions appearing and disappearing regardless of their branches existing.
These extensions shows an empty dropdown here and seem to have RELX_XX branches:
* https://www.mediawiki.org/wiki/Special:ExtensionDistributor/LoopFunctions
* https://git.wikimedia.org/branches/mediawiki%2Fextensions%2FLoopFunctions

* https://www.mediawiki.org/wiki/Special:ExtensionDistributor/MediaFunctions
* https://git.wikimedia.org/branches/mediawiki%2Fextensions%2FMediaFunctions

* https://www.mediawiki.org/wiki/Special:ExtensionDistributor/AbuseFilter
* https://git.wikimedia.org/branches/mediawiki%2Fextensions%2FInterwiki

And I guess some more...
I confirm this, while the extensions has RELX_XX branches: https://git.wikimedia.org/branches/mediawiki%2Fextensions%2FNonlinear
Created attachment 15932
Example extension Nonlinear

https://www.mediawiki.org/wiki/Special:ExtensionDistributor/Nonlinear

This extension actually doesn't work for me.

**Attached**: {F13612}
Works here also, couldn't find any extension where ExtensionDistributor fails. Btw, is that URL in this bugs' settings really needed?
Hmm, now it works for me, too :/
(In reply to Florian from comment #11)
> One more example:
> https://www.mediawiki.org/wiki/Special:ExtensionDistributor/
> ExtensionDistributor
> 
> (It's ExtensionDistributor itself)

Works for me at this moment
One more example:
https://www.mediawiki.org/wiki/Special:ExtensionDistributor/ExtensionDistributor

(It's ExtensionDistributor itself)

And there are some RELX_XX branches:
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/ExtensionDistributor,branches
Oh, yeah, i thought there was one, will create it, thanks :) i will look into some extensions i remember tomorrow, when i'm at pc again.
(In reply to Florian from comment #8)
> One example that doesn't work:
> 
> https://www.mediawiki.org/wiki/Special:ExtensionDistributor/GoogleLogin

That one has an explanation. It doesn't have any REL1_XX branch [1]

https://git.wikimedia.org/branches/mediawiki%2Fextensions%2FGoogleLogin.git

ED shouldn't be listed in the extension's page
One example that doesn't work:

https://www.mediawiki.org/wiki/Special:ExtensionDistributor/GoogleLogin
I've checked all extensions linked in comments from this bug and all of them list 1.23 and older in their dropdown. It's still an issue?

Note that some extensions weren't properly branched for 1.23, downloading an old (and probably incompatible) version, but that's bug 64157
Hmm, now i have now list of versions, too, on some Extensions :/
Created attachment 15498
branches exist

Hmm, anything i do false :?

Now i have tested with FF, Chrome and Android/HTC Stock Browser

**Attached**: {F13611}
Problem does also exist for downloading Oversight (is that extension even downloadable?), see https://www.mediawiki.org/wiki/Special:ExtensionDistributor/Oversight. Status can be changed to CONFIRMED.
https://www.mediawiki.org/wiki/Special:ExtensionDistributor/MaintenanceShell (original report) does have empty dropdown for me, how common is this? How are they picked?
I see 1.22 and master for CirrusSearch. Giving me https://codeload.github.com/wikimedia/mediawiki-extensions-CirrusSearch/legacy.tar.gz/REL1_22 to download

There is no 1.23, but that isn't setup in CommonSettings.php
-> https://www.mediawiki.org/wiki/Special:ExtensionDistributor/CirrusSearch
I see a master and 1.22 branch :/

-> https://www.mediawiki.org/wiki/Special:ExtensionDistributor?extdist_extension=AbuseFilter
Abuse Filter all branches up from 1.19 :) Tested with Firefox 17.0.1 ESR and Google Chrome 34.0.1847.116m
Error: Unknown dependency: mediawiki.skinning.content.parsoid Error {stack: (...), message: "Unknown dependency: mediawiki.skinning.content.parsoid"} load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Cl…:160

logload.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Cl…:160
handlePendingload.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Cl…:169
runScriptload.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Cl…:170
checkCssHandlesload.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Cl…:171
(anonymous function)load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Cl…:171
fireload.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Cl…:44
self.fireWithload.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Cl…:46
self.fireload.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Cl…:46
addEmbeddedCSSload.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Cl…:166
(anonymous function)load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Cl…:165

--------------------------
**Version**: unspecified
**Severity**: critical
Should now be fixed.
Change 135606 merged by jenkins-bot:
Enable mediawiki.skinning.content.parsoid on Mobile target too

https://gerrit.wikimedia.org/r/135606
Change 135606 had a related patch set uploaded by Jforrester:
Enable mediawiki.skinning.content.parsoid on Mobile target too

https://gerrit.wikimedia.org/r/135606
Aha. I'm a complete fool; my apologies. Fix inbound.
See also bug 64607
It's not invalid. This is on beta labs which mirrors production. It sounds like Parsoid is declaring a module that has not been set to the mobile target. We had this exact issue before with another RL module.
mediawiki.skinning.content.parsoid is provided by MW-core as of Wednesday – see gerrit 130770.
Sounds like you just didn't install the Parsoid *extension* when it became required (used to be optional).
No manual repro or network trace so far, this is for tracking

VE loses user token: 
https://wmf.ci.cloudbees.com/job/VisualEditor-en.wikipedia.beta.wmflabs.org-linux-firefox/9/testReport/(root)/VisualEditor%20multi-edit%20workflow/Make_multiple_edits_to_the_same_article/

VE logs user out:
https://wmf.ci.cloudbees.com/job/VisualEditor-en.wikipedia.beta.wmflabs.org-linux-firefox/12/testReport/junit/(root)/Switching%20between%20wikitext%20and%20Visual%20Editor%20modes/Switch_editing_modes_via_toolbar/

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=65710
https://bugzilla.wikimedia.org/show_bug.cgi?id=66076
https://bugzilla.wikimedia.org/show_bug.cgi?id=67171
Handled this by better managing test users. There was a rogue test logging out.
Given this is a duplicate of non-VE bugs, it's clearly a MediaWiki issue that the Editing team haven't been able to track down. :-( Moving.
*** Bug 62583 has been marked as a duplicate of this bug. ***
Created attachment 15686
Something went wrong... session no longer valid

Slightly different manifestation of error message for this issue.

**Attached**: {F13886}
also still getting this in automated tests launched from WMF Jenkins (not Cloudbees) for example https://saucelabs.com/tests/5c4697a6618543708b7a59382e9813f6
Created attachment 15608
Screenshot

**Attached**: {F13885}
Created attachment 15607
Screenshot

I reproduced this issue, after clicking on Switch to edit source and then again coming back to VE,I tried to save the page from VE.
It showed an error: there might be an edit conflict in the save dialog and then I got logged out

See the screenshots attached

**Attached**: {F13882}
Now seen in Chrome also https://wmf.ci.cloudbees.com/job/VisualEditor-en.wikipedia.beta.wmflabs.org-linux-chrome/535/
I should have said: 

Note: a close look at the screencast of the logout instance shows the logout happens instantly upon clicking Edit source for logged-in user while the user is in VisualEditor.
Note: a close look at the screencast of the logout instance shows the logout happens instantly upon clicking Edit source for logged-in user.  

In attempting to recreate the problem I encountered Bug 65710.  

Since the beta warning is controlled by a cookie, these issues may be related.
Steps to reproduce:

1.Open a page with VE
2.Go to Insert>References list
3.Observe the animation that happens when you open it.

Observed Result:
In both Chrome and Firefox , there is a bit of irregular animation when you try to open the reference list for the first time

Environment:Betalabs

--------------------------
**Version**: unspecified
**Severity**: minor
Verified the fix in production (en.wiki)
Verified the fix in test2 running wmf9
Change 138114 merged by jenkins-bot:
[BREAKING CHANGE] Update VE core submodule to master (43a48cb) for window process cleanup

https://gerrit.wikimedia.org/r/138114
Change 138114 had a related patch set uploaded by Jforrester:
[BREAKING CHANGE] Window process cleanup

https://gerrit.wikimedia.org/r/138114
It's simultaneously opening (animating from 0.5 scaling factor to 1.0) and animating from normal size to small size, that's why it looks weird.
PageTriage shown after saving edit.

I've seen this a few times, but this is the first time I've been in a position to take a screen shot.  

After saving an edit in VE, the PageTriage pager UI exists on the saved page.  See screen shot.

Note: the page is still viable at http://en.wikipedia.beta.wmflabs.org/wiki/Special:NewPagesFeed

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F13852}
Change 135587 merged by jenkins-bot:
Follow-up I7b49a6dd0: Fix page curation bar reappearing after VE closes

https://gerrit.wikimedia.org/r/135587
Change 135587 had a related patch set uploaded by Alex Monk:
Fix page curation bar appearing after VE closes for some users

https://gerrit.wikimedia.org/r/135587
Steps to reproduce:


1.Open a page with VE
2.Go to Insert>Reference
3.Type something in the text box
4.Click on "Insert Reference"
5.Again re-open that reference
6.Delete the content inside the text field

Observed Result:
issue 1: The "Use an existing reference" button remains enabled when user has entered something in the textbox (step 3), it should be disabled as soon as user enters types something in the field.

issue 2:After clicking on "insert reference" , when user reopens that reference, there is no "Use an existing reference" button in the reference dialog box (step5), the button should appear there but as "Disabled"

Once user deletes the content inside the text field (step 6), the button should again re-anabled.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Verified the fix in production(en.wiki)
Verified the fix in test2 running wmf 9
Verified the fix in Betalabs
Change 136599 merged by jenkins-bot:
MWReferenceDialog: Allow swapping of existing references for others

https://gerrit.wikimedia.org/r/136599
Change 136599 had a related patch set uploaded by Alex Monk:
Allow swapping of existing references for others.

https://gerrit.wikimedia.org/r/136599
(In reply to ryasmeen from comment #4)
> When I will delete the content of that already added reference, it should
> re-enable that button.

This bit is being dealt with already in Gerrit change 136505
The issue 2 stated above in the bug report is still there:

When I reopen an already added reference , there should be "Use an existing reference" button in that dialog but disabled , right now the button is not there at all.

When I will delete the content of that already added reference, it should re-enable that button.
Change 136443 merged by jenkins-bot:
"Use an existing reference" in the reference dialog should be disabled when there is content

https://gerrit.wikimedia.org/r/136443
Change 136443 had a related patch set uploaded by Alex Monk:
"Use an existing reference" in the reference dialog should be disabled when there is content

https://gerrit.wikimedia.org/r/136443
James says it should disable when the surface is not empty and re-enable when empty, and also appear for existing references.
Steps to reproduce:


1.Open a page with VE
2.Insert an image
3.Make it Thumbnail or Frame
4.Make it left aligned
5.Now uncheck the wrap option 
6.Click on "Apply Changes"

Observed Result:

The image gets moved to the right side of the page


Environment : Betalabs

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in test2
Verified the fix on Betalabs
Steps to reproduce:

1.Open a oage with VE
2.Insert an image
3.Make it right aligned and framless
4.Hover over it

Observed Result:
It throws the following error:
Uncaught TypeError: Cannot read property 'getSurface' of null

--------------------------
**Version**: unspecified
**Severity**: normal
Change 134363 merged by jenkins-bot:
[BREAKING CHANGE] Merge ProtectedNode into FocusableNode

https://gerrit.wikimedia.org/r/134363
Verified the fix in production.
Verified the fix in Betalabs and test 2
Still fixed.
Change 134363 had a related patch set uploaded by Esanders:
[BREAKING CHANGE] Merge protected node into focusable node

https://gerrit.wikimedia.org/r/134363
Fixed and backport going out in SWAT.
Change 134363 had a related patch set uploaded by Esanders:
[BREAKING CHANGE] Merge protected node into focusable node

https://gerrit.wikimedia.org/r/134363
Created attachment 15455
Screenshot

**Attached**: {F13647}
It also happens for the following case:

1. Change alignment of any image
2. Delete the image
3. Observe that, the phantom of the image is still there after deleting the image
4.Now hover over the phantom

Observed Result:
As soon as you delete the image the error: Cannot read property 'getSurface' of null appears, also everytime you hover over the phantom , you will get this same error.

See the screenshot attached
Steps to reproduce:

1.Open a page with VE
2.Insert an image of any type
3.Now uncheck the wrapping option
4.Click on "Apply Changes"
5.Open the media settings dialog box again

Observed Result:
The wrap option is getting checked again

Environment:Betalabs

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Provisionally, fixed in gerrit 135699.
This should be resolved now following the change of default alignment pt II
This is still happening on Betalabs
This should be resolved now following the change of default alignment.
screenshot

Steps to reproduce:

1.Go to this page: http://en.wikipedia.beta.wmflabs.org/wiki/21stmaychrome?veaction=edit

2.Open the Media settings>Advanced Settings dialog for the first image

3.Click on Custom tab for the image

4.Once you get the size values are invalid, click on default tab

Observed Result:

The fields for default size gets empty , switching back to custom also shows empty fields and the "MAke full size" button gets disabled


See the screenshot attached

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

**Attached**: {F13636}
Verified the fix in Betalabs
Change 135832 merged by jenkins-bot:
Decode URL encoding in resource attriute for images

https://gerrit.wikimedia.org/r/135832
Change 135832 had a related patch set uploaded by Catrope:
Decode URL encoding in resource attriute for images

https://gerrit.wikimedia.org/r/135832
This is because the image in question is the feared Image With A Question Mark of Doom. Moriel is looking at it.
Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Make it frameless/basic
4.Change the alignment to Left
5.Now try to change the alignment to Right
6.Click on "Apply changes"

Observed Result:
The alignment is still set as left , not moving it to Right

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 135167 merged by jenkins-bot:
Followup dd1c7f7fd7: fix LESSification errors in Parsoid styles

https://gerrit.wikimedia.org/r/135167
Change 135167 had a related patch set uploaded by Catrope:
Followup dd1c7f7fd7: fix LESSification errors in Parsoid styles

https://gerrit.wikimedia.org/r/135167
This is happening for all image types now.Not just Frameless and Basic
Reopening since I can still reproduce this issue for both the image types in Betalabs.
Marking as such.
The latest fix (https://gerrit.wikimedia.org/r/#/c/134660/) should fix this too (tested on master)
Clean up the mess I made in https://gerrit.wikimedia.org/r/134546

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 134621 merged by jenkins-bot:
Clean up interaction with confirmation dialog

https://gerrit.wikimedia.org/r/134621
Change 134620 merged by jenkins-bot:
[BREAKING CHANGE] Emit a single event from confirmation dialog

https://gerrit.wikimedia.org/r/134620
Change 134621 had a related patch set uploaded by Alex Monk:
Clean up interaction with confirmation dialog

https://gerrit.wikimedia.org/r/134621
Change 134620 had a related patch set uploaded by Alex Monk:
Emit a single 'done' event from confirmation dialog instead of 'ok' and 'cancel'

https://gerrit.wikimedia.org/r/134620
Screenshot

Steps to reproduce:

1. Insert a frameless-left aligned image 
2.Save the page
3.Reopen the page
4.Open the Media Settings dialog for the image


Observed Result:
There is no text field for the caption,Cannot close the Media Settings dialog box.
The following error appears in the console:
TypeError: node.getCaptionNode is not a function


See the screenshot attached

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

**Attached**: {F13542}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
(In reply to Roan Kattouw from comment #4)
> Well, you can most certainly trust node.getType() to tell you if calling
> node.getCaptionNode() will cause it to explode or not, and you apparently
> can't trust imgModel.getImageNodeType() in this case ;)
Yes, fallbacks should be included. I think the current (merged) commit dealt with that, I hope no more bugs will come with it, but I'll go over the code to verify.

> Yup, that sounds reasonable. However, we'd also have to define what happens
> when we inspect a node whose type appears to be "wrong"; we probably
> shouldn't change its type if the user didn't change any of the flags. OTOH,
> this just shouldn't happen.

That would be a problem, though -- how would we know that the type is wrong? It's not like the user consciously chooses inline vs block. The inline/block type is defined by seemingly arbitrary flags. They're not completely arbitrary, which is good, but they're also not entirely intuitive either. The only way to know for sure is through the tests in the getImageNodeType. It just has to be verified to follow the right conditions.

In this case, I had a typo in there, and from my tests so far this *should* be true for all the cases I tested, but I am slightly concerned we may be missing things with wikitext, or that if new types are added we will have to adjust as well.
Change 134554 merged by jenkins-bot:
Fix MWImageModel's getImageNodeType()

https://gerrit.wikimedia.org/r/134554
Change 134554 had a related patch set uploaded by Mooeypoo:
Fix MWImageModel's getImageNodeType()

https://gerrit.wikimedia.org/r/134554
(In reply to Moriel Schottlender from comment #3)
> Most times, we can't trust the node.getType() because changes in the model
> changes the node's type -- that's what the model's test was for.
> 
Well, you can most certainly trust node.getType() to tell you if calling node.getCaptionNode() will cause it to explode or not, and you apparently can't trust imgModel.getImageNodeType() in this case ;)

> It should, however, not lie or make mistakes. This is going to be somewhat
> complex, since wikitext's way of transforming between inline/block can be
> extremely arbitrary-looking.
> 
Yeah, it should be improved, but if it makes mistakes the consequences shouldn't be /this/ bad.

> One more thing that we could do, however, is use node.getType() whenever
> that *can* be trusted. This means that on loading the node (like in this
> bug) the node's type can be used, and same with after inserting a new node.
> 
Yes, exactly.

> In the other cases, though (like checking whether we're going to change a
> node type or just change the attributes) the node.getType() won't help us,
> we'll have to use a custom test inside the model to check.
Yup, that sounds reasonable. However, we'd also have to define what happens when we inspect a node whose type appears to be "wrong"; we probably shouldn't change its type if the user didn't change any of the flags. OTOH, this just shouldn't happen.
Most times, we can't trust the node.getType() because changes in the model changes the node's type -- that's what the model's test was for.

It should, however, not lie or make mistakes. This is going to be somewhat complex, since wikitext's way of transforming between inline/block can be extremely arbitrary-looking.

One more thing that we could do, however, is use node.getType() whenever that *can* be trusted. This means that on loading the node (like in this bug) the node's type can be used, and same with after inserting a new node.

In the other cases, though (like checking whether we're going to change a node type or just change the attributes) the node.getType() won't help us, we'll have to use a custom test inside the model to check.
This happens because imgModel.getImageNodeType() returns 'mwBlockImage', but the actual node is an inline image.

So 1) we shouldn't base decisions on what to do with the node object on the image model's opinion of what class the node should be, 2) that opinion should be used in very very few places, everywhere else we should be using node.getType() and 3) the image model's opinion should not be wrong :)
Example page 1: The first image on:
http://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:RYasmeen_%28WMF%29&veaction=edit

Example Page 2: The first image on:
http://en.wikipedia.beta.wmflabs.org/w/index.php?title=20thmaychrome&veaction=edit
Steps to reproduce:

1.Open a page with VE 
2.Insert an image 
3.Change the Image type to "Frame"
4.Click on "Apply changes"
5.Reopen the media settings dialog

Observed Result:
Though the image is on the right , the alignment is set to Left on the Media Settings dialog, and if you click on "Apply Changes" button now, it will move the image to left

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in en.wiki running wmf 8
Verified the fix in test2
Verified the fix in Betalabs
Change 136971 merged by jenkins-bot:
Adjust default alignment when switching from inline to block

https://gerrit.wikimedia.org/r/136971
Change 136971 had a related patch set uploaded by Mooeypoo:
Adjust default alignment when switching from inline to block

https://gerrit.wikimedia.org/r/136971
This issue still happening but the behavior got slightly changed.Previouslt after changing the alignment of any image types to "Left" and then reopening the Media Settings dialog was setting the alignment as "Right" , even though it was still on the left.Now the same issue happens but you need to save the page first after changing the alignment to left and then reopen the media settings dialog to see it.

So the new steps to reproduce is:

1.Insert any type of image
2.Change the alignment to left
3.Click on "Apply Changes"
4.Click on "Save Page"
5.Reopen the page
6.Reopen the Media Settings dialog>Advanced Settings

Observed Result:
The alignment tab is set to "Right"
Change 135699 merged by jenkins-bot:
Another default alignment fix to MWImageModel

https://gerrit.wikimedia.org/r/135699
Change 135699 had a related patch set uploaded by Mooeypoo:
Another default alignment fix to MWImageModel

https://gerrit.wikimedia.org/r/135699
This is happening for all image types now in Betalabs.
Yes, that's intended. This happens to images that have default alignment; default in a block image is opposite the text direction ("right" in ltr) and default for inline images, which is what the basic change does, is with text direction ("left" in ltr).

This is intended.
Right now, when you add an image and make it basic and select Right alignment, it moves it to the left and sets alignment as "Left".
Change 134660 merged by jenkins-bot:
Don't update image model twice

https://gerrit.wikimedia.org/r/134660
Change 134660 had a related patch set uploaded by Mooeypoo:
Don't update image model twice

https://gerrit.wikimedia.org/r/134660
This issue is still occurring for image type Basic.
The issue of default alignment between inline and block is more complex than I initially thought. I made an additional fix to this behavior in this commit https://gerrit.wikimedia.org/r/#/c/134554/ (which is merged now)

This should fix the current bug as well (it did on my tests locally, but please verify)

I hope no more default-alignment problems pop up.
The same issue appears when you change the Image type to Basic too
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Make an edit
3.Click on "Switch to source editing "
4.Click on "No, cancel"
5.Now click on the "Cancel" button of the editor 
6.Click on "Continue Editing"
7.Now again go to ""Switch to source editing "
8.This time click on "Yes, switch"

Observed Result:
It does not switch to edit source mode and throws the following errors in the console:


Uncaught TypeError: Cannot read property 'css' of null and 
Uncaught TypeError: Cannot read property 'each' of null 

See the screenshot attached

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

**Attached**: {F13495}
Verified the fix in production.
Verified the fix on test 2
Verified the fix in Betalabs
Change 134546 merged by jenkins-bot:
Unbind confirm dialog handlers after either of the events fires once

https://gerrit.wikimedia.org/r/134546
Change 134546 had a related patch set uploaded by Catrope:
Unbind confirm dialog handlers after either of the events fires once

https://gerrit.wikimedia.org/r/134546
(In reply to Roan Kattouw from comment #1)
> Holy crap this is an obscure bug. Steps 3 and 4 (switching to source mode
> the first time) can be skipped, but other than that every step is necessary.
> 
As Rummana points out, the second error (with 'each') does not occur if you skip those steps, so there's something else going on too. There's some code in ViewPageTarget that gets run after this.$checkboxes has been cleared.

On second inspection, there's a lot more going on. For instance, the 'ok' handler executes twice, and so we attempt to serialize twice.
Holy crap this is an obscure bug. Steps 3 and 4 (switching to source mode the first time) can be skipped, but other than that every step is necessary.

This happens because the switch to source mode button and the cancel button share the same instance of the confirmation dialog. When you click OK in the source mode one, the cancel button code is still listening to the 'ok' event; we need to disconnect that on cancel.

Perhaps it would be nicer if these two were combined into one event so we could use .once() and not have to unbind explicitly.
Bug 50047 and bug 51918 have regressed for Firefox – possibly as a result of Ed's changes to how the buttons work? Yay for Firefox and its attitude to tab indexes.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=66824
*** Bug 67153 has been marked as a duplicate of this bug. ***
Well that's at least a workaround. I wonder if this might be an upstream bug...
Change 143055 merged by jenkins-bot:
Set tabindex on button <div> instead of <a>

https://gerrit.wikimedia.org/r/143055
Change 143055 had a related patch set uploaded by Alex Monk:
Set tabindex on button <div> instead of <a>

https://gerrit.wikimedia.org/r/143055
So adding this.reviewButton.$element.attr( 'tabindex', '0' ).find( 'a' ).removeAttr( 'tabindex' ); fixed this... Wtf firefox?
Looks like the same issue as bug 66824
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Open the link inspector : insert [http://yahoo.com]
3.Apply the link
4.Save the page

Observed Result:
The link appears inside VE with single brackets around it: [http://yahoo.com]
And when you save the page, the unicode for the ending single bracket appears at the end of the link as a part of that link:[http://yahoo.com&#x5D;

Expected Result:
The link inspector should say to user that it is an invalid external link format.

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

**Attached**: {F13473}
Change 139128 merged by jenkins-bot:
Wrap external URL protocols regex in brackets.

https://gerrit.wikimedia.org/r/139128
I don't think so. I think things including the wgUrlProtocols regex should be dealing with this issue themselves.
Do we need to upstream a fix for wgUrlProtocols?
Change 139128 had a related patch set uploaded by Alex Monk:
Wrap external URL protocols regex in brackets.

https://gerrit.wikimedia.org/r/139128
Currently, the regex looks something like this (based on wgUrlProtocols):

/^bitcoin\:|ftp\:\/\/|ftps\:\/\/|geo\:|git\:\/\/|gopher\:\/\/|http\:\/\/|https\:\/\/|irc\:\/\/|ircs\:\/\/|magnet\:|mailto\:|mms\:\/\/|news\:|nntp\:\/\/|redis\:\/\/|sftp\:\/\/|sip\:|sips\:|sms\:|ssh\:\/\/|svn\:\/\/|tel\:|telnet\:\/\/|urn\:|worldwind\:\/\/|xmpp\:|\/\//

Notice the '^' is only against 'bitcoin' and not any other protocol? Yeah I think we need to wrap everything after the '^' in brackets.
Is our regex not anchored to the start of the string somehow?
note that the wikitext for the saved string reads: 

&#x5Dhttp://yahoo.com&#x5D;
Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Language
3.Now click on "Find Language" button

Observed Result:

The language selector dialog box takes a long time to load, approx. 15 secs

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=66124
Verified the fix in production (en.wiki)
Verified the fix in test2 running wmf 9
Verified the fix in Betalabs
Change 137741 merged by jenkins-bot:
GroupElement: Improve performance by avoiding .add() overhead

https://gerrit.wikimedia.org/r/137741
Change 137736 merged by jenkins-bot:
Use this.$() in LanguageResultWidget#highlightQuery

https://gerrit.wikimedia.org/r/137736
These two patches get it down to 780ms on my computer. This breaks down in about 520ms for opening the dialog (including constructing all of the language entries), and 260ms for displaying the "search result" for an empty search bar. The latter is repeated every time you empty the search bar (press backspace when one character is left), which is noticeably laggy. That mostly has to do with the search query highlighting code (that's about 200ms of it), which needs to be optimized further. The dialog opening is also a bit slower than I'd like, but at least isn't as critical as responding quickly when the user presses backspace.

To be fair, without these patches, it's 520ms for opening the dialog (unchanged), and 14 seconds to display an empty search result (12 seconds for adding results, 2 seconds for highlighting), so this is already a pretty good improvement :)
Change 137741 had a related patch set uploaded by Catrope:
Fix GroupElement performance

https://gerrit.wikimedia.org/r/137741
Change 137736 had a related patch set uploaded by Catrope:
Use this.$() in LanguageResultWidget#highlightQuery

https://gerrit.wikimedia.org/r/137736
(Additional information from the duplicate bug)

The slowness also means the user can click somewhere on the screen to close the language inspector while the language list loads; it seems to allow the user to choose a language, but since the inspector is already closed, the chosen language isn't updated properly.
*** Bug 66124 has been marked as a duplicate of this bug. ***
In Firefox, it is comparatively faster than Chrome
a screenshot with the problem

To reproduce:

1. Edit an article in the Hebrew Wikipedia using VE.
2. Go to the categories dialog.
3. Start typing a category name.

Expected: autocompletion list appears under the input box.
Actual: autocompletion list appears to the side of the input box.

See screenshot.

This is similar to Bug 51490.

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

**Attached**: {F13994}
Change 138041 merged by jenkins-bot:
Correct TextInputMenuWidget position for RTL

https://gerrit.wikimedia.org/r/138041
Change 138041 had a related patch set uploaded by Mooeypoo:
[wip] Correct TextInputMenuWidget position for RTL

https://gerrit.wikimedia.org/r/138041
There is content in pt-BR after setting "uselang=en"

See the screenshot.

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F13936}
Change 138407 merged by jenkins-bot:
Send language when making API requests

https://gerrit.wikimedia.org/r/138407
Change 138407 had a related patch set uploaded by Alex Monk:
Send language when making API requests

https://gerrit.wikimedia.org/r/138407
ve.ce.Surface uses $.browser to do paste special casing; replace or remove this.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 136036 merged by jenkins-bot:
Remove last jQuery.browser uses with temporary ve.isMsie hack

https://gerrit.wikimedia.org/r/136036
Thanks Ed!
Change 136036 had a related patch set uploaded by Krinkle:
Remove last jQuery.browser uses with temporary ve.isMsie hack

https://gerrit.wikimedia.org/r/136036
Still one use in ve.ce.Surface.
Change 132431 merged by jenkins-bot:
Remove IE check (and possible compatibility) from beforepaste/paste event switch

https://gerrit.wikimedia.org/r/132431
Change 132431 had a related patch set uploaded by Jforrester:
[WIP] Remove IE check from beforepaste/paste event switch

https://gerrit.wikimedia.org/r/132431
See design mock-up at https://trello.com/c/xCo6uLAZ/9-5-references-dropdown-from-toolbar-styling.

Right now, I can give a popupToolGroup a label by using the 'label' param in a toolbarGroup definition:
{
    'label': 'Cite',
    'type': 'list',
    'icon': 'reference',
    'title': OO.ui.deferMsg( 'visualeditor-toolbar-cite-label' ),
    'include': [ { 'group': 'cite' } ]
}

However, this puts the label above the popup (in the popupToolGroup-handle) rather than within the popup itself (as needed by the design linked to above).

I can imagine two different ways of providing this functionality:

1. Add a new type of param for toolbarGroups called something like 'inner-label'

2. Allow creating non-functional labels from the on-wiki group definition, for example:
[
    { "label": "cite" },
    { "name": "web", "icon": "ref-cite-web", "template": "Cite web" },
    { "name": "book", "icon": "ref-cite-book", "template": "Cite book" },
    { "name": "news", "icon": "ref-cite-news", "template": "Cite news" },
    { "name": "journal", "icon": "ref-cite-journal", "template": "Cite journal" }
]

--------------------------
**Version**: unspecified
**Severity**: enhancement
Fixed by https://gerrit.wikimedia.org/r/#/c/134237/
I would recommend option 1.
After discussing with Trevor we decided the best way to implement this would be to have a parameter like 'label-position' which controls where the label appears.
Probably the same issue as we had for parameter fields?

--------------------------
**Version**: unspecified
**Severity**: minor
--------------------------
**Version**: unspecified
**Severity**: normal
Bah.

*** This bug has been marked as a duplicate of bug 65353 ***
Redlinks are displayed as blue links in templates inside the VisualEditor


https://en.wikipedia.org/wiki/Javier_Payo?veaction=edit

--------------------------
**Version**: unspecified
**Severity**: minor
(In reply to Alex Monk from comment #7)
> Well, it was you who changed this bug from being about just templates to
> being about "generated content nodes (e.g. templates)"... We can just make
> it about templates only again if you want.

Created that as bug 71900.
Well, it was you who changed this bug from being about just templates to being about "generated content nodes (e.g. templates)"... We can just make it about templates only again if you want.
(In reply to Alex Monk from comment #5)
> Transclusion nodes are not the only generated content nodes

They are, however, almost exclusively the GCNs with wikitext links in them. Do we actually care about <easytimeline> blocks?
Transclusion nodes are not the only generated content nodes
Change 165240 merged by jenkins-bot:
Apply link styling logic to transclusion nodes

https://gerrit.wikimedia.org/r/165240
Change 165240 had a related patch set uploaded by Alex Monk:
Apply link styling logic to transclusion nodes

https://gerrit.wikimedia.org/r/165240
We used to parse template content with action=parse from the PHP parser which naturally contained <a class="new">.

Nowadays we use Parsoid for the generated fragments as well, but this meant we lost the natural classes MediaWiki provided.

The mw.LinkCache logic should extend to the nodes inside generated content.

I think right now this isn't done because we use the same DOM for both the DM and the CE of generated content nodes, but, just as we do for practically everything else, it shouldn't be an issue to have our copy in CE be different from the copy in DM (thus not having to worry about needing to strip any classes when saving back to Parsoid).
*** Bug 65355 has been marked as a duplicate of this bug. ***
After saving an edit in the file namespace the big thumbnail of the file is not shown.

--------------------------
**Version**: unspecified
**Severity**: minor
Change 133897 merged by jenkins-bot:
On file pages, only replace the (local) image description when saving

https://gerrit.wikimedia.org/r/133897
Change 133897 had a related patch set uploaded by Alex Monk:
On file pages, only replace the (local) image description when saving

https://gerrit.wikimedia.org/r/133897
1. Edit some text (e.g the -> foo)
1. Edit existing link (e.g. on [[mw:VisualEditor]], link to "Parsoid")
2. Enter text that makes up part of a title (e.g. "ResourceLoade", note, the missing "r" at the end)
3. Select "ResourceLoader" from the suggestions
   (due to a bug in our search engine, this is the second suggestion, not the first:
   [ > ResourceLoade                                 ]
     - ResourceLoader/JavaScript Deprecations
     - ResourceLoader
     - ResourceLoader/Version 1 Design Specification

4. Observe that the suggestions close after selecting an item, and the text field now contains "ResourceLoader". Do not press enter or click anywhere.

5. Press Save Page

Video: http://cl.ly/11431q402d3A

Expected:

* Diff shows "the -> foo", and "Parsoid -> ResourceLoader".


Actual:

* Diff shows "the -> foo".

Because:

We both selected a value from the suggestions and then blurred the inspector by clicking "Save page". Either of those actions ought to save the value into the model, but doing both certainly should.

There are two weird things about this:

* Changing step 4 and pressing Enter there instead of Save page, makes it save correctly.

So it seems that we just don't save properly on selection or blurring and require one of Escape-key, Enter-key, Back-button or focussing surface (instead of blurring inspector / focussing anything in the main window, e.g. toolbar / save button as well, not just surface).

* Changing step 2/3 to type "ResourceLoader" straight up, and not pressing Enter or clicking anywhere before clicking Save page also works. 

So it seems that merely changing focus from input field to save page can be enough to have it saved. Maybe we have an exception for onkeyup/onchange and select is bypassing that?

--------------------------
**Version**: unspecified
**Severity**: major
*** Bug 68934 has been marked as a duplicate of this bug. ***
Change 155673 merged by jenkins-bot:
Select the correct annotation in MWLinkTargetInputWidget

https://gerrit.wikimedia.org/r/155673
Change 155673 had a related patch set uploaded by Catrope:
Select the correct annotation in MWLinkTargetInputWidget

https://gerrit.wikimedia.org/r/155673
*** Bug 68934 has been marked as a duplicate of this bug. ***
Following the steps exactly as per comment #0 still exhibits this bug exactly.

I can reproduce it locally on latest master by making a link to User:Root when typing "User:Ro" where the suggestions are [ "User:Root/common.js", "User:Root" ].
Change 138114 merged by jenkins-bot:
[BREAKING CHANGE] Update VE core submodule to master (43a48cb) for window process cleanup

https://gerrit.wikimedia.org/r/138114
Change 138114 had a related patch set uploaded by Catrope:
[BREAKING CHANGE] Update VE core submodule to master (43a48cb) for window process cleanup

https://gerrit.wikimedia.org/r/138114
Steps to reproduce:

1.Open a page with VE that has link inside it.
2.Tap on any link 

Observed Result:
The browser page gets redirected to the link target page

Test Environment: https://en.m.wikipedia.org/
Device: iPad Mini

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=66999
https://bugzilla.wikimedia.org/show_bug.cgi?id=67002
https://bugzilla.wikimedia.org/show_bug.cgi?id=67063
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 143152 merged by jenkins-bot:
Prevent iOS Safari from following links

https://gerrit.wikimedia.org/r/143152
Change 143152 had a related patch set uploaded by Esanders:
Prevent iOS Safari from following links

https://gerrit.wikimedia.org/r/143152
(In reply to Ed Sanders from comment #8)
> We don't even have event listeners on links at the moment but we might have to
> add some as a work around

Eww. If we do, let's keep it as local as possible (mobile-only, for instance).
Links don't have any custom highlights (and shields no longer exist) so this must just be a CE bug in iOS (should be filed upstream if possible). We don't even have event listeners on links at the moment but we might have to add some as a work around
did not get*
This bug did not resolved by :

FocusableNode: Use getClientRects()[0] instead of getBoundingClientRect()

https://gerrit.wikimedia.org/r/142260
**jgonera** wrote:

%%%*** Bug 66559 has been marked as a duplicate of this bug. ***%%%
Pushing to Ed because it appears to be a shield/highlight issue.
**jgonera** wrote:

Jon has never worked on this bug.
**jgonera** wrote:

Link is followed (kind of)

**Attached**: {F13597}
**jgonera** wrote:

This bug happens on any iOS Safari probably. The link doesn't seem to go to the destination in some cases (in my dev instance it goes to 127.0.0.1 even though I loaded the page from an external IP).

More importantly, this seems to be happening only when the keyboard is hidden (contenteditable is not focused). See attached video.

I tested it on iOS 7.1.1. It doesn't happen on Chrome for Android.
See inline comment on https://gerrit.wikimedia.org/r/#/c/133050/1/modules/ve-mw/ui/widgets/ve.ui.MWMediaSearchWidget.js

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 150001 merged by jenkins-bot:
Use $.when() in MediaSearchWidget

https://gerrit.wikimedia.org/r/150001
Change 150001 had a related patch set uploaded by Mooeypoo:
Use to $.when() in MediaSearchWidget

https://gerrit.wikimedia.org/r/150001
Screenshot

Steps to reproduce:

1.Go to this page:http://en.wikipedia.beta.wmflabs.org/wiki/14thmaychrome?veaction=edit
2.Select the image on the page
3.Go to Media Settings>Advanced Settings>Image Size
4.Change the tab from Default to custom or Custom to Default

Observed Result:

The "Make full size" button remains disabled for the image

See the screenshot attached

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

**Attached**: {F13562}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 133384 merged by jenkins-bot:
Revert "Cache image scalable promises by filename"

https://gerrit.wikimedia.org/r/133384
Change 133384 had a related patch set uploaded by Catrope:
Revert "Cache image scalable promises by filename"

https://gerrit.wikimedia.org/r/133384
It seems likely that this is due to cache pollution of the promise cache introduced in https://gerrit.wikimedia.org/r/#/c/132207/4/modules/ve-mw/dm/nodes/ve.dm.MWImageNode.js . The bug only happens when saving then reopening the editor in the same session without navigating away.
Found the steps to reproduce:

1.Insert any image
2.Go to Media Settings>Advanced Settings
3.Select Custom tab and change the values
4.Apply changes
5.Save the page
6.Reopen the page
7.Go to the Media Settings>Advanced Settings of that image again

Observed Result:
The "Make full size" button became disabled ,switching tabs/changing values again does not make it enabled anymore.
Screenshot

Steps to reproduce:

1.Go to this page:http://en.wikipedia.beta.wmflabs.org/wiki/12thmayff?veaction=edit

2.Select the first image on the page: Dau_ho_thoi_Ho.png

3.Make any edit on the image's caption field

4.Click on "Apply Changes"

Observed Result:

The Media Settings dialog does not get closed , the edit does not get saved

The following error appears in the console:


TypeError: originalDimensions is undefined

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

**Attached**: {F13995}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 133123 merged by jenkins-bot:
Make sure originalDimensions are available before use

https://gerrit.wikimedia.org/r/133123
Change 133123 had a related patch set uploaded by Mooeypoo:
Make sure originalDimensions are available before use

https://gerrit.wikimedia.org/r/133123
For Chrome the error appearing is a bit different:Uncaught TypeError: Cannot read property 'width' of undefined
The following steps ensure reproducing the issue for all images:

1.Insert a new image in a page and save the page
2.Reopen the page and go to the Advanced Settings of the image
3.Click on custom tab and click on Apply Changes
4.Save the page
5.Reopen the page and again go the Advanced Settings of the image
6.Click on Default tab and click on Apply changes

You will see the error and get stuck inside the media settings dialog box
Earlier today, the toolbar in VisualEditor stopped displaying "Cite" on the new citation tool, and instead started displaying "<visualeditor-toolbar-cite-label>".  

For me, it displayed correctly until I changed languages to qqx to check something else; when I went back, it was broken.  For James F, it was displaying correctly until he logged out.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=66543
(In reply to Antoine "hashar" Musso from comment #4)
> I tried to reproduce the issue with:
> 
>  eaction=edit&uselang=en
>  eaction=edit&uselang=qqx
>  eaction=edit
> 
> The Cite label in the toolbar was back to normal.

Indeed; a null edit to the message page brought it back into the l10n cache.

> Could it be that whenever that new Cite function got added the l10n cache
> did not get regenerated?   Without a way to reproduce it there is not much
> we can do unfortunately.

No. It was added in 1.23wmf20. It is very unlikely that the l10n cache having suddenly broken on Monday night was caused by a deploy two months ago. :-)
I tried to reproduce the issue with:

 eaction=edit&uselang=en
 eaction=edit&uselang=qqx
 eaction=edit

The Cite label in the toolbar was back to normal.


Could it be that whenever that new Cite function got added the l10n cache did not get regenerated?   Without a way to reproduce it there is not much we can do unfortunately.
(In reply to Andre Klapper from comment #2)
> Only in VisualEditor strings, or also other places been seen?

So far I've only seen it for this particular VE-related message, but the fun thing with deployment bugs is you never know…
Only in VisualEditor strings, or also other places been seen?
As a note, it was fixed by me making a null edit to [[MediaWiki:visualeditor-toolbar-cite-label]]. Apparently the same breakage (in pl rather than en) was experienced on plwiki earlier as well.
TeamGale doesn't recall that in order to fill the edit summary field you need to click on that first - if she doesn't, the text she's typing, although the dialog is visible, ends up in the article instead (FF29, Win8).

If I hit Save changes in any of my browsers (Chrome, FF and Opera) and don't click on the dialog, nothing happens if I keep typing.
However I believe that if it is technically possible, the extra click shouldn't happen, there are no other places where the cursor should end up, and editors seeing it flashing might be encouraged to use the field a little more.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=64521
*** Bug 64521 has been marked as a duplicate of this bug. ***
Change 134108 merged by jenkins-bot:
Initialise save panel on 'ready' so focus works

https://gerrit.wikimedia.org/r/134108
Change 134108 had a related patch set uploaded by Esanders:
Initialise save panel on 'ready' so focus works

https://gerrit.wikimedia.org/r/134108
Screenshot

Steps to reproduce:

1.Open any page with Mobile VE 
2.Make some Edit
3.Attempt to save the page

Observed Result:
The Page cannot be saved, the spinner does not go away from the page.
The following error appears in the console:
TypeError: s is undefined
	

...unction(s){return s.replace(/['"<>&]/g,escapeCallback);},element:function(name,a...

load.p...203716Z (line 168)

See the screenshot attached

Found on this page: https://en.m.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/sandbox

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

**Attached**: {F13680}
This issue got fixed after the wmf 4 deployment to production.Marking as fixed and verified .
It works on beta labs so I would suspect that this is an issue that got caught and will be fixed in next deployment... unless beta labs and enwiki differ in any way?
In chrome,the error that appears in the console while saving a page is:


Uncaught TypeError: Cannot read property 'replace' of undefined 

However,if you refresh the page , you will see the edit does get saved on the page
in ve.ce.Surface we the following line:

 if ( $.browser.msie === true && e.which === 229 ) {

Give we haven't tested IE in so longer I suspect this might not work anymore, but if it does, we need another way to detect that this hack is needed as $.browser is deprecated.

--------------------------
**Version**: unspecified
**Severity**: normal
Was fixed by https://gerrit.wikimedia.org/r/#/c/141457 .
Rephrasing to be the bug David wants to work on in general.

For the literal usage of $.browser, see bug 65404.
Bumping priority as this needs to be done very soon…
It needs to not use $.browser within 2 weeks tops.
I'm in the process of stripping these checks out anyway, because the inIme checks cannot be made realiable. Does this need removing immediately? If so I can submit a smaller patch that does this.
Screenshot showing link vs. formula icon to highlight difference

It's possible to get a link inspector icon shown as "selected" in the inspector menu, which is… confusing.

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

**Attached**: {F14013}
This was fixed a while ago with the new context.
Selections at non-content offsets are bad, e.g. pressing delete will throw an exception.

--------------------------
**Version**: unspecified
**Severity**: normal
*** Bug 57355 has been marked as a duplicate of this bug. ***
Change 131688 merged by jenkins-bot:
Special case for deleting the entire document

https://gerrit.wikimedia.org/r/131688
Change 131688 had a related patch set uploaded by Esanders:
Special case for deleting the entire document

https://gerrit.wikimedia.org/r/131688
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Media
3.Type something to search a media file

Observed Result:
When the search results appear observe that there is an extra empty column appearing at the right end in the search result dialog box.

See the screenshot attached


Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=64808

**Attached**: {F13839}
Verified the fix in en.wiki running wmf8
Verified the fix in Betalabs and test2
Change 136314 merged by jenkins-bot:
Change padding on media search results so we can display 4 results on a row with a scrollbar

https://gerrit.wikimedia.org/r/136314
Change 136314 had a related patch set uploaded by Alex Monk:
Change padding on media search results so we can display 4 results on a row with a scrollbar

https://gerrit.wikimedia.org/r/136314
Re-phrasing title based on feedback from Roan.
This is still happening for me, when I always have scroll bar showing on MAC OS
Change 131516 merged by jenkins-bot:
Remove unnecessary space in footless dialog

https://gerrit.wikimedia.org/r/131516
Change 131516 had a related patch set uploaded by JGonera:
Remove unnecessary space in footless dialog

https://gerrit.wikimedia.org/r/131516
Change 223853 merged by jenkins-bot:
MWMediaResourceProvider: Use exist instead of bool check on API values

[[https://gerrit.wikimedia.org/r/223853]]
Change 223853 had a related patch set uploaded (by Jforrester):
MWMediaResourceProvider: Use exist instead of bool check on API values

[[https://gerrit.wikimedia.org/r/223853]]
Thanks!
* https://gerrit.wikimedia.org/r/217444 (branch master): #mw1.26wmf10
Change 217444 merged by jenkins-bot:
MWMediaResourceProvider: Use exist instead of bool check on API values

[[https://gerrit.wikimedia.org/r/217444]]
This bug has popped up again because the check of config.local is wrong.
Change 217444 had a related patch set uploaded (by MarkAHershberger):
Fix check of JSON return value

[[https://gerrit.wikimedia.org/r/217444]]
Change 150054 merged by jenkins-bot:
MWMediaSearchWidget: Use json/jsonp for local/foreign api respectively

https://gerrit.wikimedia.org/r/150054
Change 150054 had a related patch set uploaded by Mooeypoo:
Switch between json/jsonp for local/remote api search

https://gerrit.wikimedia.org/r/150054
*** Bug 68141 has been marked as a duplicate of this bug. ***
(In reply to Krinkle from comment #7)
> (In reply to Barry Coughlan from comment #2)
> > The crossDomain logic will switch between the 'script' and 'xhr' transports,
> > but both requests will still have be JSONP and have the callback parameter.
> > 
> > See here: http://jsfiddle.net/yvzSL/228/
> > 
> > In your developer tools console you can see that the local request uses XHR,
> > but it is still a JSONP request over XHR. I have read through the $.ajax
> > docs a number of times now and I see no indication that it should behave
> > otherwise.
> 
> That example is broken. The first request is is malformed. "json jsonp" is
> not a valid dataType. This value is invalid and unsupported. It seems to
> default to a script tag instead, but as you can see the callback in that
> code never fires. Here's a forked version of that example where I added
> number "1" and "2". You'll find that "DONE 1" never appears.
> 
> http://jsfiddle.net/L5PtK/

To clarify, I know dataType supports multiple values, but that's for converting the response (e.g. xml over jsonp). But you can't convert the actual data from json to jsonp or from json to jsonp (unless an API would embed javascript inside json or something like that).

As for VisualEditor, it should use json when contacting the local API. and jsonp when contacting any foreign API (whether on the same domain or not).

There is logic for this in jQuery that automatically switches from "json" to "jsonp" for cross domain urls.

However that doesn't trigger the way I expected. It makes the assumption that 1) you should only make 'json' requests to APIs on the same domain or with CORS authentication set up. Then if a browser doesn't support CORS it will use script  with JSONP instead of XHR. So it functions like a fallback for browsers not supporting CORS, *not* as a convenience to switch to JSONP automatically for any cross domain url.

jquery.js
> if ( !options.crossDomain || support.cors ) {
(In reply to Barry Coughlan from comment #2)
> The crossDomain logic will switch between the 'script' and 'xhr' transports,
> but both requests will still have be JSONP and have the callback parameter.
> 
> See here: http://jsfiddle.net/yvzSL/228/
> 
> In your developer tools console you can see that the local request uses XHR,
> but it is still a JSONP request over XHR. I have read through the $.ajax
> docs a number of times now and I see no indication that it should behave
> otherwise.

That example is broken. The first request is is malformed. "json jsonp" is not a valid dataType. This value is invalid and unsupported. It seems to default to a script tag instead, but as you can see the callback in that code never fires. Here's a forked version of that example where I added number "1" and "2". You'll find that "DONE 1" never appears.

http://jsfiddle.net/L5PtK/
(In reply to Krinkle from comment #5)
> [callback] is only applied when the "jsonp" transport is activated (builds
> on top of the "script" transport).
> 
> And the "json" dataType only activates "json" in case of crossDomain.
> 

I mean, the "json" dataType only activates "jsonp" in case of crossDomain.
(In reply to Barry Coughlan from comment #2)
> The crossDomain logic will switch between the 'script' and 'xhr' transports,
> but both requests will still have be JSONP and have the callback parameter.
> 
> See here: http://jsfiddle.net/yvzSL/228/
> 
> In your developer tools console you can see that the local request uses XHR,
> but it is still a JSONP request over XHR. I have read through the $.ajax
> docs a number of times now and I see no indication that it should behave
> otherwise.

You read wrong. &callback= (or rather s.jsonpCallback) is only applied when the "jsonp" transport is activated (builds on top of the "script" transport).

And the "json" dataType only activates "json" in case of crossDomain.

Making a plain api request to a non-crossdomain url does NOT result in a callback parameter. Instead it results in a plain JSON response that is parsed by JSON.parse, no callback or javascript execution comes into play.

MediaWiki core uses $.ajax in this in many places. For example mediawiki.user.js[1] uses it to fetch user rights and groups information from the API. This behaviour has been this way for quite a while.

Like I said, if VisualEditor and/or your wiki is doing it differently, there is most likely a bug in the code invoking $.ajax.


[1] https://github.com/wikimedia/mediawiki-core/blob/08c17086e1/resources/src/mediawiki/mediawiki.user.js#L27-L41
I ran into the same problem myself my private wiki (1.23 and the REL1_23 branch of VE)

What are the security implications if I make the workaround change mentioned above? I have a foreign API configured, but it's one I control.

Thanks!
--Ryan
**b.coughlan2** wrote:

I did some more re-thinking about this.

I examined the jQuery code and the 'crossDomain' attribute is just for selecting the transport (XMLHttpRequest or <script> tag). It does not select data types (json/jsonp), i.e. if the datatype is 'jsonp' and the request is local, you will get a 'jsonp' request with a 'callback' parameter over XMLHttpRequest. The MW core will assume that any request with a 'callback' parameter is from another domain, and will treat the request as unauthenticated.

MW core needs a better way to detect if a request is really cross-origin. The solution is CORS, but this is not supported in a standard way on IE9 (http://caniuse.com/cors). The most "correct" fix would be to change the MW core to use CORS to detect cross-origin requests, but this might break plugins relying on the API in IE<=9, so it would be a risky fix until IE9 is no longer a concern for anyone.

I'm now convinced that the simplest fix for now is to add some logic in the VisualEditor JS to detect if the request will be local, based on the target URL of the request. Then use the 'json' datatype if it is local, and the 'jsonp' datatype if not. Here is jQuery's logic for checking that: https://github.com/jquery/jquery/blob/master/src/ajax.js#L518

Note that I tried this out by implementing custom prefilters/transports for jQuery (to leverage the crossDomain code already present), but this approach is hacky and a dead end.
**b.coughlan2** wrote:

The crossDomain logic will switch between the 'script' and 'xhr' transports, but both requests will still have be JSONP and have the callback parameter.

See here: http://jsfiddle.net/yvzSL/228/

In your developer tools console you can see that the local request uses XHR, but it is still a JSONP request over XHR. I have read through the $.ajax docs a number of times now and I see no indication that it should behave otherwise.
There is most certainly logic in $.ajax to switch between xhr/json and script/jsonp. This has been in jQuery for many years.

The reason it isn't working might be related to the usage of protocol-relative urls, or the presence of CORS support.

To cite the relevant parts:

	// A cross-domain request is in order when url parts mismatch
	if ( s.crossDomain == null ) {
		parts = rurl.exec( s.url.toLowerCase() );
		s.crossDomain = !!( parts[ 1 ] !== ajaxLocParts[ 1 ] || .. );
	}
	..
	jQuery.ajaxTransport( "script", function(s) {
		// This transport only deals with cross domain requests
		if ( s.crossDomain ) {
			..
		}
	});
	..
	if ( xhrSupported ) { jQuery.ajaxTransport(function( s ) {
		if ( !s.crossDomain .. ) {
			return { send: function() {
				var xhr = s.xhr();
				..
	..

Anyway, no work around is needed. It is a well-known feature of $.ajax, we just need to start using it. And if it isn't working, find out what we're doing wrong on our end.
Div wrapping of rendered templates causes problems, especially when the template generates something like a <tr>. We should try to get rid of this wrapping and instead put shields and what not directly in the tag itself.

Potential issues:
* may not work for all tags
* may not work for inline tags
* won't work for non-tag things (text nodes, comments)
* tricky for multi-sibling templates

--------------------------
**Version**: unspecified
**Severity**: enhancement
Fixed by Ed in https://gerrit.wikimedia.org/r/#/c/140439/
Right now there's a noticeable delay; we can speed up user experience at the expense of resources.
I think this is something we could do after the page has finished loading...
Slowing down load isn't something we're interested.
Unassigning for now. Already working with Roan on TargetLoader, {T91715}, and the blockers under {T74063}.
I started looking into this and found that MWTransclusionModel#fetchRequestDone actually wants to handle all sorts of data about normalisation and redirects and things which a current ApiResponseCache system (as part of the above link) would not provide (as it's not part of the data.query.pages part of the response). Waiting for @Catrope's input.
I started looking into this and found that MWTransclusionModel#fetchRequestDone actually wants to handle all sorts of data about normalisation and redirects and things which a current ApiResponseCache system (as part of the above link) would not provide (as it's not part of the data.query.pages part of the response).
I started looking into this and found that MWTransclusionModel#fetchRequestDone actually wants to handle all sorts of data about normalisation and redirects and things which a proper ApiResponseCache system would not provide (as it's not part of the data.query.pages part of the response).
Might be something that could take advantage of code in https://gerrit.wikimedia.org/r/#/c/180228/
(Needs performance investigation.)
Also pre-load the templates configured for the cite tools.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Open a reference dialog box or Media Settings for an image
3.Try open any of the inspectors:Math/Hiero/Special Character

Observed Result:
All inspector appearing with broken UI

See the screenshot attached

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65
OS: MAC OS X 10. 8. 5

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F13474}
(In reply to Rummana Yasmeen from comment #11)
> Ah I see, Sorry we didnt know that before the fix, opening a different one
> and tagging that against this week's target milestone.

No worries. :-)
Ah I see, Sorry we didnt know that before the fix, opening a different one and tagging that against this week's target milestone.
This bug didn't recur, it was a new bug with a totally different cause. Let's not confuse things by claiming we fixed the same bug. :-)
Change 173977 merged by jenkins-bot:
Followup ca6a16f: use parent selector both for hiding and showing windows

https://gerrit.wikimedia.org/r/173977
Change 173977 had a related patch set uploaded by Catrope:
Followup ca6a16f: use parent selector both for hiding and showing windows

https://gerrit.wikimedia.org/r/173977
Created attachment 17116
screenshot,  showing blank link inspector

**Attached**: {F13475}
Reopen this issue.
In test2 and beta only.

steps-

1> open the link/math/comment/special characters/ inspectors in Media Settings -> caption sub-editor or the References sub-editor. The inspectors are blank with no UI.

Also see Bug 68130 https://bugzilla.wikimedia.org/show_bug.cgi?id=68130.
Verified in production
Verified the fix in test2
Verified the fix on Betalabs
Change 131112 merged by jenkins-bot:
Fix regression in frame style scoping

https://gerrit.wikimedia.org/r/131112
Change 131112 had a related patch set uploaded by Catrope:
Fix regression in frame style scoping

https://gerrit.wikimedia.org/r/131112
* Go to the tools demo
* Click "auto-disabling list"
* Click "click to disable this tool"
* "auto-disabling list" now appears greyed out
* Click "auto-disabling list"
* An active effect appears, even though the dropdown is disabled and you can't interact with it at all

Other disabled toolgroups don't have this problem, it's only the one that gets disabled dynamically.

This causes a bug in VisualEditor as well: click out of the editor (this disables most tools and auto-disables the Insert toolgroup), then click Insert. An active effect appears.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=64601
(In reply to Rainer Rillke @commons.wikimedia from comment #2)
> Is this a duplicate of Bug 64601 ?

No; bug 64434.
Change 131120 merged by jenkins-bot:
Use .isDisabled() instead of .disabled to support inheriting

https://gerrit.wikimedia.org/r/131120
Is this a duplicate of Bug 64601 ?
Change 131120 had a related patch set uploaded by Trevor Parscal:
Use .isDisabled() instead of .disabled to support inheriting

https://gerrit.wikimedia.org/r/131120
In some cases, MediaWikiModuleStore can be quite large (over 1 MB). This can lead to local storage becoming full and causing random problems like T66716. According to https://support.mozilla.org/en-US/questions/963825 Firefox shares local storage space across all hosts on a single domain name, so this may be especially problematic for Firefox.

In theory, this shouldn't be an issue since people should always have some sort of fall-back behavior if there are problems with local storage, but in the interests of defensive programming, perhaps we should put a cap on the maximum size of MediaWikiModuleStore.

--------------------------
**See Also**:
* {T66716} (bug 64716)
* {T67566} (bug 65566)

**Upstream**;
* <https://bugzilla.mozilla.org/show_bug.cgi?id=1064466>
Replied at T85923#2471543 as it seems about a key disappearing, not a key being unable to be set.

As for the issue reported in this task, it's been resolved. In theory, it will always be possible for the storage quota to be reached, at which points random keys will fail to be set. (This is true for cookies as well.)

Task T101732 tracks moving the module cache to a different interface for that reason.
Replied at T85923#2471543 as it seems about a key disappearing, not a key being unable to be set.

As for the issue reported in this task, it's been resolved. In theory, it will always be possible for the storage quota to be reached, at which points random keys will fail to be set. (This is true for cookies as well.)

Task T101732 tracks moving the module cache into a different interface for that reason.
From {T85923}: `wgMediaViewerOnClick` apparently cannot be reliably saved to local storage; used space (as per `encodeURIComponent(JSON.stringify(localStorage)).length`) is 2600025, quota is (per [[https://arty.name/localstorage.html|this test]]) somewhere between 2600000 and 2700000. The browser is Safari. May be related, although 2600025 is 0b1001111010110001011001 which does not seem like something that would be very close to a quota limit.
No reports for over a month; closing.
Change 269625 merged by jenkins-bot:
resourceloader: Disable localStorage cache on FF, Opera

[[https://gerrit.wikimedia.org/r/269625]]
Change 269625 had a related patch set uploaded (by Ori.livneh):
ResourceLoader: disable localStorage cache on FF, Opera

[[https://gerrit.wikimedia.org/r/269625]]
Ok. I have been in denial about this long enough, I suppose. Let's start by disabling it completely in Firefox and Opera. I am still interested in more reports, because it will help determine where we go from there.
I still get this on every page view using Firefox 44.
I continue to get this error on every page view using Opera 12 (obviously, since you only blacklisted Firefox).
Has anyone encountered any bugs since {7787a85d5c6f} went out, just under a month ago?
Nothing has changed here since 2014 -- it was a mistake to enable this feature on Firefox at the time, and it is a mistake to enable it now with a 30KB per-module limit. On my browser at the moment, MediaWikiModuleStore:enwiki is using 655KB, which is hardly an improvement from when the bug was first reported. You only need to visit 7 or 8 wikis to exhaust the quota.

I don't think a <250ms performance improvement justifies randomly breaking the many extensions which use localStorage. 

mediawiki.js will keep writing module caches until it hits the quota and fails. The functionality of the site after such a failure depends on how much of the quota is left -- effectively the remainder of the division, 5MB modulo the per-wiki module store size. An unlucky combination could leave a user unable to dismiss dialog boxes or to choose a preferred language.

Some extensions try localStorage first, and fall back to a cookie if it fails. But the MW core does not provide a convenient interface for this, leaving each extension to implement it separately.
Change 263417 merged by jenkins-bot:
Module storage: set stricter storage quotas on Firefox

[[https://gerrit.wikimedia.org/r/263417]]
Change 263417 had a related patch set uploaded (by Ori.livneh):
Module storage: set stricter storage quotas on Firefox

[[https://gerrit.wikimedia.org/r/263417]]
FYI, i had an issue fixed in WikEd, which was throwing exceptions all over the place, because it wasn't expecting a full localStorage.

That's the problem with this issue. it's infectious....
Generally yes, regardless of this bug, even. localStorage likes to throw
exceptions. (For example, apparently it will be defined but throw exception
on access on Firefox if you disable it in browser settings.)
I assume anyone who wants to use `localStorage` is supposed to use `try`/`catch` on every attempt to save a value so that unrelated scripts are still executed? E.g.:
https://pt.wikipedia.org/wiki/MediaWiki:Gadget-fastbuttons.js?diff=43318591
https://meta.wikimedia.org/w/index.php?diff=13512749&oldid=13462279&diffonly=1
https://github.com/brion/MediaWiki-MobileSidebar/pull/5/files?w=1
I assume anyone who wants to use `localStorage` is supposed to use `try`/`catch` on every attempt to save a value? E.g.:
https://pt.wikipedia.org/wiki/MediaWiki:Gadget-fastbuttons.js?diff=43318591
https://meta.wikimedia.org/w/index.php?diff=13512749&oldid=13462279&diffonly=1
https://github.com/brion/MediaWiki-MobileSidebar/pull/5/files?w=1
I assume anyone who wants to use `localStorage` is supposed to use try/catch on every attempt to save a value? E.g.:
https://pt.wikipedia.org/wiki/MediaWiki:Gadget-fastbuttons.js?diff=43318591
https://meta.wikimedia.org/w/index.php?diff=13512749&oldid=13462279&diffonly=1
https://github.com/brion/MediaWiki-MobileSidebar/pull/5/files?w=1
Interesting and thanks for the counter-example.
I've taked to @ori about T96155 and the plan is for me to make this code use the new frontend api. When that's in place we could potentially be a bit more clever about what we are allowed to store e.g. limit number of bytes we allow saving for.

Given that MobileFrontend/Gather are only using this storage mechanism to decide whether to show onboarding tutorials for new features, mostly targeting readers who are not editing or newbies, if localStorage is exhausted not showing these things is not the end of the world.
>>! In T96155#1539605, @matmarex wrote:
>>>! In T96155#1528593, @Jdlrobson wrote:
>> Yup. I recognise this is an issue but I am saying that this issue mostly impacts power users (especially on Firefox). I'm yet to see this on the mobile site, where gadgets and user scripts are currently not available nor used.
> 
>Eh, I don't think that it mostly impact power users, it can impact even occasional editors too.
> 
>As an example:
>* Visit https://pl.wikipedia.org/wiki/Ostatnia_droga_Temeraire%27a, which is a pretty generic article on the Polish Wikipedia, as anonymous user. Run `JSON.stringify( mw.loader.store ).length` to see how much data ResourceLoader puts in localStorage (this is 707573 for me on first page load).
>* Open the MediaViewer, which is not a power-user feature. The length increases to 923750.
>* Open the VisualEditor, which is not a power-user feature either. The length increases to 2008078.
> 
>This is already 2 MB, and this is just one wiki and an anonymous user (I'm not sure how the browsers calculate the limit, but if anything, this is less than the number of bytes actually stored). Visit another wiki (say, the same article in English, if you're not satisfied with the content in Polish and speak two languages) and this doubles. Log in (which gets you features like Echo and lets you enable some gadgets or beta features), or visit a third wiki, and you're quickly over the 5 MB limit.
>>! In T66721#1418743, @Jdlrobson wrote:
> Could we use ServiceWorker for this now (see T101731) ?

Yes. We created T101732 last month.
Could we use ServiceWorker for this now (see T101731) ?
>>! In T66721#1411737, @ori wrote:
>>>! In T66721#1411731, @SamB wrote:
>> So, um, any tips on how to manually clean up the MediaWikiModuleStore keys from all of the wikipedias on Firefox/Iceweasel, including 31.7.0esr as included in Debian Jessie?
> 
> It should not be possible to fill it up now that the patch above has been pushed. You must have gotten into some weird state. Clear localStorage (either by nuking your browser history or by using https://addons.mozilla.org/en-US/firefox/addon/volatile-storage/?src=cb-dl-updated) and see if the problem recurs.

Hmm, I'm still a bit nervous about nuking localStorage entirely, though that certainly would be less tedious than visiting every Wikipedia I've ever loaded in this bowser (including mobile versions) one-by-one and clearing the relevant key from the JS console... (though, that might not be so bad if I used a greasemonkey script to do the actual cleanup for each wiki).

Anyway, this:

>>! In T66721#1340094, @gerritbot wrote:
> Change 216014 merged by jenkins-bot:
> mw.loader.store: decline to store items > 100 kB
> 
> [[https://gerrit.wikimedia.org/r/216014]]

... doesn't sound very promising to me.  Just because it only stores items < 100 kB does *not* prevent it from storing many such items, which could add up to a lot of usage on a single Wiki; factor in the fact that subdomains share quota on Firefox, and you could still easily hit 5 MiB, no?
That extension does not seems to be enough, since I still get this on every page on Portuguese Wikipedia using Firefox 38.0:
> "Exception in store-localstorage-update:" load.php:177:752
> "NS_ERROR_DOM_QUOTA_REACHED: Persistent storage maximum size reached" DOMException [NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"
> code: 1014
> nsresult: 0x805303f6
> location: https://pt.wikipedia.org/w/load.php?debug=false&lang=pt&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=CZ6SC%2Fzc:175] load.php:177:790
> log() load.php:177
> handler() load.php:155
> jQuery.Callbacks/fire() load.php:45
> jQuery.Callbacks/self.fireWith() load.php:46
> jQuery.Callbacks/self.fire() load.php:46
> mw.track() load.php:155
> flush() load.php:175
and running
> localStorage.clear();
in the console doesn't help either.
>>! In T66721#1411731, @SamB wrote:
> So, um, any tips on how to manually clean up the MediaWikiModuleStore keys from all of the wikipedias on Firefox/Iceweasel, including 31.7.0esr as included in Debian Jessie?

It should not be possible to fill it up now that the patch above has been pushed. You must have gotten into some weird state. Clear localStorage (either by nuking your browser history or by using https://addons.mozilla.org/en-US/firefox/addon/volatile-storage/?src=cb-dl-updated) and see if the problem recurs.
So, um, any tips on how to manually clean up the MediaWikiModuleStore keys from all of the wikipedias on Firefox/Iceweasel, including 31.7.0esr as included in Debian Jessie?
>>! In T66721#1340106, @matmarex wrote:
> While the last patch may be helpful, it still does not prevent the cache from taking up all available localStorage space.

Especially on Firefox, where e.g. all of the Wikipedias are sharing quota.  (There are a lot of Wikipedias, and there are reasons someone might look at quite a lot of them.)

Also, to clean up after this, you'll need to do something like what's described at <https://bugzilla.mozilla.org/show_bug.cgi?id=1064466#c11>: have a path on each wiki that will clean up the storage, and also a way to open an iframe to that path on *every* wiki for a given domain ...
On the topic of using IndexedDB for module store, beware that there is an important difference with localStorage.

localStorage, while having a lower quota by default (~ 5MB), doesn't have a way to expand that quota. Which means when it's full, the API returns a failure code but nothing is shown the user.

IndexedDB, while having a higher quota by default (~ 10-50MB), has a way of extending the quota. It's not clear to me what happens when you reach the quota. It appears that browsers default to asking the user to expand the quota.

For the purpose of caching modules, and for Wikipedia in general, I don't think we should ever allow that to happen. So we may have to somehow manually poll the aggregate size of database to prevent the browser from asking the user any such question.

See http://www.html5rocks.com/en/tutorials/offline/quota-research/
{F177107}
On the topic of using IndexedDB for module store, beware that there is an important difference with localStorage.

localStorage, while having a lower quota by default (~ 5MB), doesn't have a way to expand that quota. Which means when it's full, the API returns a failure code but nothing is shown the user.

IndexedDB, while having a higher quota by default (~ 10-50MB), has a way of extending the quota. It's not clear to me what happens when you reach the quota. It appears that browsers default to asking the user to expand the quota.

For the purpose of caching modules, and for Wikipedia in general, I don't think we should ever allow that to happen. So we may have to somehow manually poll the aggregate size of database to prevent the browser from asking the user any such question.
* https://gerrit.wikimedia.org/r/216014 (branch master): #mw1.26, #mw1.26wmf9
While the last patch may be helpful, it still does not prevent the cache from taking up all available localStorage space.
Change 216014 merged by jenkins-bot:
mw.loader.store: decline to store items > 100 kB

[[https://gerrit.wikimedia.org/r/216014]]
Change 216014 had a related patch set uploaded (by Ori.livneh):
mw.loader.store: decline to store items > 100 kB

[[https://gerrit.wikimedia.org/r/216014]]
>>! In T66721#1339632, @kaldari wrote:
> @Mattflaschen The last two solutions sound sensible. Do you have any idea how much that might reduce the average size of the cache by?

On a primed cache on enwiki, the top modules by size for me are:

| Module | Size |
|--------|------|
| ext.visualEditor.core | 624 kB |
| oojs-ui | 179 kB |
| oojs-ui.styles.icons | 132 kB |
| oojs-ui.styles | 90 kB |
| mmv.ui.canvasButtons | 71 kB |
| ext.visualEditor.mwmeta | 67 kB |
| jquery.ui.core | 66 kB |
| ext.visualEditor.mwtransclusion | 65 kB |
| ext.visualEditor.mwimage | 65 kB |
| oojs-ui.styles.icons-editing-advanced | 58 kB |
| ext.visualEditor.mwcore | 52 kB |
| jquery.ime | 50 kB |
| moment | 48 kB |
| mmv.ui.metadataPanel | 47 kB |
| unicodejs | 46 kB |
| ext.visualEditor.icons | 45 kB |
| jquery.chosen | 42 kB |
| jquery.uls | 37 kB |
| ext.visualEditor.mediawiki | 35 kB |
| jquery.uls.data | 33 kB |
"Assigned To: None" and "Priority: High" are at odds with each other. @ori, are you planning to work on this?
@Mattflaschen The last two solutions sound sensible. Do you have any idea how much that might reduce the average size of the cache by? Blacklisting Firefox might be good as a last resort, but I would favor trying other solutions first.
Yesterday, we talked on IRC about a few possibilities:

* Blacklisting Firefox (only seems to be an issue due to how it calculates quotas)
* Blacklisting certain large modules
* Only storing modules that are needed at page load
BTW at some point I played with a promise wrapper lib for indexedDB: https://gerrit.wikimedia.org/r/#/c/157818/
Might be useful if one wants to implement this ticket.
>>! In T66721#974945, @Mattflaschen wrote:
> @Ori plans to look into IndexedDB (which has very different quota rules) as a solution.

Is there a status update about this?
Happened to me too.  A thought occurs: could this be related to the repeated reports during the massive fundraiser in December of dismissed banners coming back? (i.e. because the hide was not remembered, as Kaldari suggested above?)
@Ori plans to look into IndexedDB (which has very different quota rules) as a solution.
>>! In T66721#946527, @Technical13 wrote:
> Apparently I had 1,772,879 characters in localStorage on test.wikipedia.org.  Since this is so large, I've been unable to find a pastebin to paste it all to.

There's no need to paste it.  We're aware of (most of, at least) the contents, and the underlying causes.
Apparently I had 1,772,879 characters in localStorage on test.wikipedia.org.  Since this is so large, I've been unable to find a pastebin to paste it all to.
```
"NS_ERROR_DOM_QUOTA_REACHED: Persistent storage maximum size reached" DOMException
[
   NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"
   code: 1014
   nsresult: 0x805303f6
   location: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141217T214024Z:173
]
```
on my `Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0` system indicates this is still a problem?
Change 176628 merged by jenkins-bot:
resourceloader: Clear module storage if disabled by configuration

[[https://gerrit.wikimedia.org/r/176628]]
I think we should turn $wgResourceLoaderStorageEnabled off for the WMF cluster (it's already off by default in DefaultSettings.php) for now.

>>! In T66721#795821, @tstarling wrote:
> I don't think localStorage can be used as a cache for large objects if there is no way for us to implement an LRU policy.

There is a way, but not if we use localStorage directly.  To solve this issue, I think we should ban direct use of localStorage, and require using a wrapper library that implements some kind of expiration (and also require expirations actually be used when setting).  jStorage (already in core) implements time to live/max-age (as does Storer.js, used by Flow).  Least recently used might be good for some kinds of data as an alternative to TTL, but I don't know if any of the libraries we currently use have it.
Actually the VE thing was disabled 18 months ago, but it will live on in my browser forever. The reason I saw an exception when I activated VisualEditor is because activating VE increased the module storage size to about 1.8MB.
Change 176628 had a related patch set uploaded (by Tim Starling):
Clear module storage if it is disabled by configuration

[[https://gerrit.wikimedia.org/r/176628]]

#patch-for-review
Actually, disabling the code is not enough -- localStorage has no expiry, so everyone's browser will stay broken until we explicitly clean up these old entries.
This is the first thing I saw on opening my web console on Wikipedia today -- localStorage exceptions from VisualEditor due to quota exhaustion, apparently due to module storage. I guess it should be reverted, or at least disabled on Firefox, if it can't be managed without breaking localStorage for everyone.

I don't think localStorage can be used as a cache for large objects if there is no way for us to implement an LRU policy.

%%%
sqlite> select sum(length(value))+sum(length(key)) from webappsstore2 where scope like 'gro.aidepikiw.%' and key like 'MediaWikiModuleStore%';
3731546
sqlite> select sum(length(value))+sum(length(key)) from webappsstore2 where scope like 'gro.aidepikiw.%' and key like 've-%';
535604
%%%

The VE thing will probably need to be removed or reduced as well.
Filed an upstream bug against Firefox at https://bugzilla.mozilla.org/show_bug.cgi?id=1064466
Michael M.: That sounds like a good idea, but doesn't solve the underlying issue of this bug (that mw.loader.store takes up too much of localStorage).
What about this approach?
1. Before saving a module to localStorage try to save a string of 20 KB* there.
2. If this fails, don't save the module in localStorage.
3. If it succeeds, try to save the module.
4. Whether or not putting the module in localStorage succeeds, remove the string from step 1.

This will make sure that the modules never will occupy the last 20 KB* of localStorage.

*) 20 KB is just the first number that came to my mind. Feel free to replace it with any other reasonable number. I have several user scripts that make use of localStorage, they take up 3 KB, but I know users who use them more heavily than me, they probably end up at about 10 KB or more.
Ori: Could you reply to comment 6 please if you have some ideas?
Ori: Any thoughts on this? It's still a significant problem, especially for Firefox users.
(In reply to Krinkle from comment #4)
> mw.loader.store falls back to fetching from the server. However other
> features that actually use localStorage in a more visible way will lose data
> in a much worse way (e.g. users unable to store drafts, or a "hide" button
> not being remembered etc.)

Yep, as you can see from bug 65566 (thanks for marking that as a see also), we've already had to switch to cookies for a feature due to this issue.
Raising priority as this will likely become increasingly more problematic as wikis and extensions register more modules and users enable more features.

mw.loader.store falls back to fetching from the server. However other features that actually use localStorage in a more visible way will lose data in a much worse way (e.g. users unable to store drafts, or a "hide" button not being remembered etc.)
*** Bug 65364 has been marked as a duplicate of this bug. ***
(In reply to Ryan Kaldari from comment #1)
> Any thoughts on this? This bug makes using Wikipedia very annoying for me.
> Surely I can't be the only person that cares about this.

This document explains how to clear localStorage:

https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage#Storage_location_and_clearing_the_data

You can also up the quota via about:config. Search for "dom.storage.default_quota" option. Its value is in kilobytes.

I'm not suggesting that these are adequate resolutions for this bug -- they're just workarounds. I want to try something like what DJ is proposing in <https://bugzilla.wikimedia.org/show_bug.cgi?id=65364#c3>.
Any thoughts on this? This bug makes using Wikipedia very annoying for me. Surely I can't be the only person that cares about this.
Running JavaScript profiling on both desktop and mobile the majority of time is spent in jQuery.extend.css - the majority of which seems to be caused by ve.ce.ProtectedNode.prototype.onProtectedSetup

On mobile this seems to be even more severe.

In desktop 7.9% of execution time to load VisualEditor was spent in jQuery.extend.css - this was the most heavy function. In mobile it was also the most heavy - however in mobile a whopping 23.76% of time was spent in jQuery.extend.css

Stubbing out the contents of the foreach loop 
this.$element.add( this.$element.find( '*' ) ).each( function () {

seems to remedy this problem.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51202
Based on the work that Ed did, I'm going to mark this as closed.
Additional fixes made for the 2014-05-15 release – but not sure what counts as "fixing" this bug. Jon, could you re-test?
https://gerrit.wikimedia.org/r/130823 (for bug 52499) should make this perform a bit better as well, by 1) reducing the number of elements protectedNode CSS is applied to and 2) targeting them with a class rather than a star selector: .ve-ce-protectedNode * is an expensive selector just like .header > *:nth-child(3)
I went deeper down the rabbit hole... 

Removing all button styling drops this by 23.76% to 16.4%
It drops to 8.6% with removal of 'skins.minerva.chrome.styles', 8.6% when I drop the use of ui.less

Both the stylings for buttons and ui.less use last-child, nth-child, first-child, not selectors. These seem to be the major pain point.

See bug 64719.
Specifically it is a style or styles in one of these modules:
http://localhost.alpha/w/load.php?debug=false&lang=en&modules=mediawiki.ui.button%7Cmobile.pagelist.styles%7Cmobile.styles.beta%7Cskins.minerva.chrome.styles%7Cskins.minerva.content.styles%7Cskins.minerva.drawers.styles&only=styles&skin=minerva&target=mobile&*


It drops to 8% with their removal.
So I tried removing #content element - no visible difference.
Killing our stylesheets - visible difference (drops 1.59%).

This must be linked to causing reflows, that are more expensive in the Minerva skin.
We have a lot more DOM nodes in mobile - 2 times the number of DOM nodes in an article. In desktop they replace the page rather than create an overlay..
**jgonera** wrote:

The question is, why is this more of a problem with mobile skin than with Vector?
There may be ways to improve this in the short term, but what we really need to do is experiment with using an SVG overlay.
The majority of time is spent in looking up the float property but importNode is also a relatively big performance hog here
Steps to reproduce:

1.Open a page 
2.Add few references
3.Now Go to Insert>Reference>Use an Existing Reference 
4.Select one of the existing references


Observed Result:

The selected reference does not get added in the page and the "Save Page" remains disabled

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/30thAprilChrome?veaction=edit

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix on production
Verified the fix on test2
Verified the fix in Betalabs
Change 130734 merged by jenkins-bot:
Make inserting existing references work again

https://gerrit.wikimedia.org/r/130734
Change 130734 had a related patch set uploaded by Jforrester:
Make inserting existing references work again

https://gerrit.wikimedia.org/r/130734
Also, if you have added a reference list on that session before attempting to add an existing reference,the "Save Page" button becomes enabled but if you go to the Review your changes section there is no entry for adding <references> there.

After clicking on "Save Page" , you will see the reference list did not get added in the page , but you open VE , you will the reference list
In particular, see comments on https://gerrit.wikimedia.org/r/#/c/130085/

--------------------------
**Version**: unspecified
**Severity**: enhancement
Fixed in gerrit 130717.
Screenshot

Steps to reproduce:

1.Go to Insert>Template

Observed Result:

Observe that, in the header of the dialog box , instead of text "Transclusion" ,"Null" is appearing

See the screenshot attached

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5

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

**Attached**: {F13912}
Verified the fix in production
Verified the fix in Betalabs and Test2
Change 130749 merged by jenkins-bot:
Bring the transclusion title back to life

https://gerrit.wikimedia.org/r/130749
Change 130749 had a related patch set uploaded by Jforrester:
Bring the transclusion title back to life

https://gerrit.wikimedia.org/r/130749
Larger reference dialog

Reference list dialog box is appearing much larger in size like the previous design that we had.

See the two screenshots attached and compare

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F13908}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 130796 merged by jenkins-bot:
Make reference list dialog small again

https://gerrit.wikimedia.org/r/130796
Change 130796 had a related patch set uploaded by Catrope:
Make reference list dialog small again

https://gerrit.wikimedia.org/r/130796
Created attachment 15253
Reference list dialog box in production and test2

**Attached**: {F13909}
The region you need to move the mouse over to get the inspector to popup.

Using the math editor beta feature. The region you need to position the mouse over the get the inspector icon to come up is quite small. Ideally it should be the whole size of the image.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50791

**Attached**: {F13812}
*** Bug 50776 has been marked as a duplicate of this bug. ***
The bug as reported (formula click areas)  is fixed now. It was probably fixed by https://gerrit.wikimedia.org/r/#/c/139805/
Screenshot of view and edit mode side-by-side

Ever since the typography update, the content looks malformed in the editor.

This is because the way the typography change in Vector was implemented, used rather specific selectors that cannot apply to VisualEditor's surface and thus it cascades in ways it wasn't supposed to.

The content line-height is squished, and the font size is too small.

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F13719}
Verified the fix on production
Verified the fix on Betalabs and test2
Change 130745 merged by Catrope:
mw.ViewPageTarget: Move .mw-body-content down to .ve-ce-surface

https://gerrit.wikimedia.org/r/130745
Change 130745 had a related patch set uploaded by Catrope:
mw.ViewPageTarget: Move .mw-body-content down to .ve-ce-surface

https://gerrit.wikimedia.org/r/130745
Change 130541 merged by jenkins-bot:
mw.ViewPageTarget: Move .mw-body-content down to .ve-ce-surface

https://gerrit.wikimedia.org/r/130541
(In reply to Krinkle from comment #7)
> Yeah, we fixed the page content font-size and line-height, but now those
> changes incorrectly apply to our overlays as well. This causes all our
> inspectors to have messed up line-heights and recursively smaller font-sizes
> inside e.g. link inspector suggestions and the context menu cursor.

https://gerrit.wikimedia.org/r/130541 addresses this.
Yeah, we fixed the page content font-size and line-height, but now those changes incorrectly apply to our overlays as well. This causes all our inspectors to have messed up line-heights and recursively smaller font-sizes inside e.g. link inspector suggestions and the context menu cursor.
Change 130541 had a related patch set uploaded by Krinkle:
mw.ViewPageTarget: Move .mw-body-content down to .ve-ce-surface

https://gerrit.wikimedia.org/r/130541
Still some mess here.
Change 130507 merged by jenkins-bot:
mw.ViewPageTarget: Use .mw-body-content for content styling

https://gerrit.wikimedia.org/r/130507
Change 129567 merged by jenkins-bot:
mw.ViewPageTarget: Use .mw-body-content for content styling

https://gerrit.wikimedia.org/r/129567
Change 130507 had a related patch set uploaded by Jforrester:
mw.ViewPageTarget: Use .mw-body-content for content styling

https://gerrit.wikimedia.org/r/130507
Change 129567 had a related patch set uploaded by Krinkle:
mw.ViewPageTarget: Use .mw-content for content styling

https://gerrit.wikimedia.org/r/129567
Intention:
Save a page.

Steps to Reproduce:
1. Rearrange a lot of text.

2. Click the save button.

3. Start typing the edit summary.

Actual Results:  
The edit summary appeared where I'd last been typing in the article, rather than in the Save dialog.

I tried to reproduce it once, with no success.


Reproducible: Couldn't Reproduce

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=65222
On reflection, I'm going to assume that this was caused by bug 65222 which is now resolved and so up-merging with that.

*** This bug has been marked as a duplicate of bug 65222 ***
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Formula
3.Without closing the Math Inspector keep on pressing tab

Observed Result:
An error appears in the console:

Uncaught  TypeError: Cannot read property 'start' of null

See the screenshot attached

Test Environment: https://en.wikipedia.org
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5

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

**Attached**: {F14000}
Verified the fix in production
Verified the fix on test2
Verified the fix on Betalabs
Change 129851 merged by jenkins-bot:
Clear the focusedNode when the document is blurred

https://gerrit.wikimedia.org/r/129851
Pressing tab actually blurs the surface, but blurring the surface doesn't clear the focusedNode highlighting, so I'm fixing that first.
Steps to Reproduce:
1. Open any page in VisualEditor.

2. Go to Insert > Reference to add a reference.  Do NOT click inside the reference box.

3. Go to Insert > Template to add a template.



Actual Results:  
You can't add a template, you can't exit the dialog, you can't do anything except close the browser tab and lose all of your work.


Reproducible: Always

This cannot be reproduced in Safari.  This cannot be reproduced if you first click inside the reference box.

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix in production
Verified the fix on test2
(In reply to Rainer Rillke @commons.wikimedia from comment #4)
> Where is the gerrit change?

https://gerrit.wikimedia.org/r/#/c/129806/ makes sure the tools correctly initialize as disabled if the initial selection is null

https://gerrit.wikimedia.org/r/#/c/130262/ makes sure the selection isn't 0,0 the second time you open the reference dialog
Where is the gerrit change?
*** Bug 64601 has been marked as a duplicate of this bug. ***
Verified the fix in Betalabs
Fixed in the Firefox-selection change Ed wrote.
--------------------------
**Version**: unspecified
**Severity**: normal
Moved to a different bug.
This is again happening on Betalabs
Verified the fix in production
Verified the fix in test2
Change 130804 merged by Catrope:
Always fix up selection after ce.Surface#focus

https://gerrit.wikimedia.org/r/130804
Change 130804 had a related patch set uploaded by Catrope:
Always fix up selection after ce.Surface#focus

https://gerrit.wikimedia.org/r/130804
Verified the fix in Betalabs with Firefox 27.0.1
Change 130262 merged by jenkins-bot:
Always fix up selection after ce.Surface#focus

https://gerrit.wikimedia.org/r/130262
Change 130262 had a related patch set uploaded by Esanders:
Always fix up selection on after ce.Surface#focus

https://gerrit.wikimedia.org/r/130262
Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Reference
3.Type something fast inside the reference dialog box

Observed Result:
The first character of the text moves to the next line in reference dialog box

Test Environment: production
Browser: FF 25
OS: MAC OS X 10. 8. 5
Created attachment 15208
Screenshot

**Attached**: {F13881}
screenshot of the loading spinner

There is a loading spinner appears on the Media Settings dialog box when I try to load it for the first time in a page.

See the screenshot attached

Test Environment: https://test2.wikipedia.org/
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5

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

**Attached**: {F13831}
Expected behaviour.
<Krenair> Move the cursor to the end of a line before the start of a new section header, delete, enter, enter, up, delete, type a random character.
<James_F> Backwards delete or forwards delete?
<Krenair> Um. The delete next to 'Home' and 'End'
<Krenair> not backspace
<James_F> Forwards, then. :-)
<James_F> Whee, snowmen.
<James_F> I blame edsanders.
<Krenair> observed on http://en.wikipedia.org/wiki/Hippeastrum_calyptratum, depending on what random character you try (I hit 'f'), stuff breaks in a difficult to explain but quite obvious
<Krenair> especially if you do it twice to the same document
<James_F> So the first thing that happens is that the cursor ends up outside of the document.
<James_F> Which is Bad™.
<James_F> Everything breaking after this is non-deterministic, but definitely also Bad™.

--------------------------
**Version**: unspecified
**Severity**: major
Change 129371 merged by jenkins-bot:
Re-render selection after deleting

https://gerrit.wikimedia.org/r/129371
Change 129371 had a related patch set uploaded by Catrope:
Rerender selection after deleting.

https://gerrit.wikimedia.org/r/129371
If you put the cursor at the end of a paragraph and press Delete, the cursor will go to the top left corner of the surface (range (0,0)). However, if the next thing after the cursor is not a paragraph (but e.g. a heading) this doesn't happen.

Once the cursor is at (0,0) and you start typing, things break completely.
Screenshot

Steps to reproduce:

1.Open a page with VE in FireFox
2.Go to Insert>Template
3.Type something in the textbox to search for templates
4.Now without selecting anything from the dropdown box, click on "Add template"

Observed Result:
The dropbox for the search results gets sticked to the template dialog box 
If you click on Show options button or just close the template dialog box and reopen again, it still stays


This problem also exists for the search result dropbox for Redirect Target Page and Categories 

See the screenshot attached

Test Environment: https://test2.wikipedia.org/
Browser:  FF 25

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

**Attached**: {F13701}
Verified in production
Verified the fix in test2
Change 131608 merged by jenkins-bot:
Make autoFocus default to true

https://gerrit.wikimedia.org/r/131608
Change 131608 had a related patch set uploaded by Catrope:
Make autoFocus default to true.

https://gerrit.wikimedia.org/r/131608
For template, if you click on add template button quickly as soon as the dropbox appears you will be able to reproduce it.
For Redirect Page and Categories, it can be reproduced in pretty straightforward way
This is still occurring in Betalabs and test2
Change 130767 merged by jenkins-bot:
Auto-choose selected item when adding a template

https://gerrit.wikimedia.org/r/130767
Change 130767 had a related patch set uploaded by Catrope:
Auto-choose selected item when adding a template

https://gerrit.wikimedia.org/r/130767
Created attachment 15189
Redirect page

**Attached**: {F13704}
Created attachment 15188
category

**Attached**: {F13702}
<Krenair> The issue I get after adding ConfirmEdit to my wiki is "Error: Unknown error" when saving >_>
<Krenair> {"visualeditoredit":{"result":"error","edit":{"captcha":{"type":"simple","mime":"text/plain","id":"586723432","question":"24+8"},"result":"Failure"}}}
<James_F> Hmm.
<James_F> That kind of CAPTCHA isn't supported yet.
<Krenair> meh. thought it would be something like that
<James_F> You'd need to add it to the save dialog's logic.
[...]
<James_F> Krenair: It's worth adding support, feel free to make a bug (I don't have a list of CAPTCHA methods to support).

I think at least Simple, Math, and Questy. Currently it looks like Fancy is supported though I haven't tested it

--------------------------
**Version**: unspecified
**Severity**: enhancement
From Alex: Yes.
QuestyCaptcha and MathCaptcha both done too.

Is Fancy sufficiently supported that we can close this?
Change 129570 merged by jenkins-bot:
Support QuestyCaptcha and (kind of) MathCaptcha

https://gerrit.wikimedia.org/r/129570
Change 129570 had a related patch set uploaded by Jforrester:
Support QuestyCaptcha and (kind of) MathCaptcha

https://gerrit.wikimedia.org/r/129570
Change 129315 merged by jenkins-bot:
Add support for SimpleCaptcha

https://gerrit.wikimedia.org/r/129315
Simple done. :-)
Change 129315 had a related patch set uploaded by Alex Monk:
Add support for SimpleCaptcha

https://gerrit.wikimedia.org/r/129315
Screenshot

I tried to save which was open for a long time (probably ~3-4 hrs)and got the following error in the console which stopped me from saving the edited content:

Uncaught TypeError: Object #<VeInitMwMobileViewTarget> has no method 'saveDocument' 

See the screenshot attached

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

**Attached**: {F13580}
Verified the fix in production
Verified the fix in test2
Change 129326 merged by Catrope:
Unbreak badtoken recovery on mobile

https://gerrit.wikimedia.org/r/129326
Change 129326 had a related patch set uploaded by Catrope:
Unbreak badtoken recovery on mobile

https://gerrit.wikimedia.org/r/129326
Change 129243 merged by jenkins-bot:
Unbreak badtoken recovery on mobile

https://gerrit.wikimedia.org/r/129243
Change 129243 had a related patch set uploaded by Catrope:
Unbreak badtoken recovery on mobile

https://gerrit.wikimedia.org/r/129243
This looks like a bug in ve.init.mw.Target :(
I challenge you!
VEdit https://it.wikipedia.org/w/index.php?title=Utente:Elitre_(WMF)/Sandbox_VE&oldid=65498176.
Make the first line bold. Then un-bold it. I don't manage to.
Win7, Vector, Chrome/FF.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 129074 merged by jenkins-bot:
Look for comparable annotations when toggling

https://gerrit.wikimedia.org/r/129074
Change 129074 had a related patch set uploaded by Esanders:
Look for comparable annotations when toggling

https://gerrit.wikimedia.org/r/129074
Before applying the changes

Steps to reproduce:

1.Open a page with VE
2.Go to Cite>Website/Book/Newspaper/Journal
3.Add some optional parameters from the parameter list 
4.Also add the parameter URL as an optional parameter
5.Apply changes

Observed Result:
Observe that, before applying changes the parameter URL does not have a trash icon beside but the other optional parameter does.But, after applying the changes , the trash icon does appear for the parameter URL but not for the other one.

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser:: Chrome Version 26.0.1410.65
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/21staprilchrome?veaction=edit

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

**Attached**: {F14025}
Change 129344 merged by jenkins-bot:
Make citation dialog display like transclusion dialog in single mode

https://gerrit.wikimedia.org/r/129344
Change 129344 had a related patch set uploaded by Trevor Parscal:
Make citation dialog display like transclusion dialog in single mode

https://gerrit.wikimedia.org/r/129344
This is only broken in the citation inspector, it works fine in the template inspector.
It seems that the logic here is that:
* When creating a new citation, none of the default parameters can be removed
* When inspecting an existing citation, only the first (topmost) parameter can be removed
* After adding a new parameter, only that parameter can be removed
Created attachment 15151
After applying changes

**Attached**: {F14026}
Current extension repositories have REL1_23 branch, but it was created when REL1_22 was created too, so basically it's outdated.

Examples:

https://git.wikimedia.org/branches/mediawiki%2Fextensions%2FCite.git

https://git.wikimedia.org/branches/mediawiki%2Fextensions%2FImageMap.git

https://git.wikimedia.org/branches/mediawiki%2Fextensions%2FCheckUser.git

They have REL1_23 updated as of 22-10-2013

I've only found one exception, though:

https://git.wikimedia.org/branches/mediawiki%2Fextensions%2FWidgets.git


One particular change introduced on 1.23 release was the migration from PHP to JSON files for i18n. I think all the extensions were migrated to JSON files in master, but REL1_23 still doesn't have that change.

--------------------------
**Version**: 1.23.0
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=67270
Thanks @hashar!

`defaultbranch` has since been removed from `.gitreview` (so now it submits to the upstream branch by default), so this is not an ongoing problem.
thanks!
For Bundled extensions:

for ext in Cite ConfirmEdit Gadgets ImageMap InputBox Interwiki LocalisationUpdate Nuke ParserFunctions PdfHandler Poem Renameuser SpamBlacklist SyntaxHighlight_GeSHi TitleBlacklist WikiEditor; do echo -n "$ext "; git -C $ext show REL1_23:.gitreview|grep defaultbranch; done;

|Cite | defaultbranch=master
|ConfirmEdit | defaultbranch=REL1_23
|Gadgets | defaultbranch=master
|ImageMap | defaultbranch=master
|InputBox | defaultbranch=master
|Interwiki | defaultbranch=master
|LocalisationUpdate | defaultbranch=master
|Nuke | defaultbranch=master
|ParserFunctions | defaultbranch=master
|PdfHandler | defaultbranch=master
|Poem | defaultbranch=master
|Renameuser | defaultbranch=master
|SpamBlacklist | defaultbranch=master
|SyntaxHighlight_GeSHi | defaultbranch=master
|TitleBlacklist | defaultbranch=master
|WikiEditor | defaultbranch=master

Fixed them all.

I also fixed extensions that had recent changes.

So it is mostly done. Given the traffic on `REL1_23` I don't think it is worth fixing all the rest.
Change 334546 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334546]]
Change 334546 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334546]]
Change 334545 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334545]]
Change 334545 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334545]]
Change 334544 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334544]]
Change 334544 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334544]]
Change 334543 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334543]]
Change 334543 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334543]]
Change 334542 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334542]]
Change 334542 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334542]]
Change 334540 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334540]]
Change 334539 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334539]]
Change 334538 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334538]]
Change 334537 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334537]]
Change 334536 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334536]]
Change 334535 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334535]]
Change 334534 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334534]]
Change 334533 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334533]]
Change 334532 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334532]]
Change 334531 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334531]]
Change 334530 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334530]]
Change 334529 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334529]]
Change 334528 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334528]]
Change 334527 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334527]]
Change 334526 merged by Hashar:
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334526]]
Change 334540 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334540]]
Change 334539 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334539]]
Change 334538 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334538]]
Change 334537 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334537]]
Change 334536 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334536]]
Change 334535 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334535]]
Change 334534 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334534]]
Change 334533 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334533]]
Change 334532 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334532]]
Change 334531 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334531]]
Change 334530 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334530]]
Change 334529 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334529]]
Change 334528 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334528]]
Change 334527 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334527]]
Change 334526 had a related patch set uploaded (by Hashar):
.gitreview: update defaultbranch to REL1_23

[[https://gerrit.wikimedia.org/r/334526]]
The initial requests was to bump MediaWiki extensions REL1_23 branches and I guess all the bump that were required have been done quite quickly. So that is essentially done.


The task apparently was left open to update `.gitreview` files. From July 2014 comment:

>>! In T66157#704385, @Tgr wrote:
> Not sure, if this is a bug in the one-off update process, or something that is generally not handled when creating new versions of extensions, but the .gitreview file in the root extension folder should have defaultbranch=REL1_23 but it has defaultbranch=master instead. (I have run into this in MultimediaViewer and UploadWizard; I assume it's the same for all others.)

I checked extensions from mediawiki/extensions.git with:

   git submodule foreach 'git show origin/REL1_23:.gitreview|grep defaultbranch||:'

A wide range of them still have a .gitreview file with `defaultbranch=master`


Looking in Gerrit for [[ https://gerrit.wikimedia.org/r/#/q/branch:REL1_23+project:%255Emediawiki/extensions/.*+NOT+project:%255Emediawiki/extensions/BlueSpice.* | branch:REL1_23 project:^mediawiki/extensions/.* NOT project:^mediawiki/extensions/BlueSpice.* ]] there are a few repo still active. And the .gitreview files are wrong :(
On my radar, but unsure of exact situation anymore. @MarkAHershberger can you give an update on this task?
Moving this into RelEng's orbit more clearly; however, I imagine this isn't going to get done given it's been two years, and can just be closed as Declined or somesuch?
I'll use this one.
hexmode:
> Are you going to use this bug to track that or open a new one?
(In reply to Mark A. Hershberger from comment #28)
> (In reply to Tisza Gergő from comment #27)
> > Not sure, if this is a bug in the one-off update process, or something that
> > is generally not handled when creating new versions of extensions, but the
> > .gitreview file in the root extension folder should have
> > defaultbranch=REL1_23 but it has defaultbranch=master instead. (I have run
> > into this in MultimediaViewer and UploadWizard; I assume it's the same for
> > all others.)
> 
> This is something we should update our branching script to take care of.

Are you going to use this bug to track that or open a new one? Just don't want this to be lost in the aether...
(In reply to Tisza Gergő from comment #27)
> Not sure, if this is a bug in the one-off update process, or something that
> is generally not handled when creating new versions of extensions, but the
> .gitreview file in the root extension folder should have
> defaultbranch=REL1_23 but it has defaultbranch=master instead. (I have run
> into this in MultimediaViewer and UploadWizard; I assume it's the same for
> all others.)

This is something we should update our branching script to take care of.
Not sure, if this is a bug in the one-off update process, or something that is generally not handled when creating new versions of extensions, but the .gitreview file in the root extension folder should have defaultbranch=REL1_23 but it has defaultbranch=master instead. (I have run into this in MultimediaViewer and UploadWizard; I assume it's the same for all others.)
Fixed the ones in Comment 19.  Emailed a couple of q's to developers about the right revision to use, but it should be fixed now.
*** Bug 67270 has been marked as a duplicate of this bug. ***
The upload wizard case is fixed by https://gerrit.wikimedia.org/r/141586
(In reply to Mark A. Hershberger from comment #16)
> After looking through the bugs with fixes for UW, I found the following
> three that seem like good candidates for backports:
> 
> Bug #54750 - UploadWizard allows two different files with same name at same
> time
> Bug #64067 - Pg Support
> Bug #65406 - Flikr support

Agreed, these are good candidates for backport. None of them are critical though.

> Without more information, it is impossible to tell if fixing these will
> address comment #12:
> > UploadWizard is also affected by this, and as a result it is completely
> > broken on 1.23.

That would be addressed by moving all the missing commits (between 2013-10-24 and 2014-04-10) into REL1_23. Specifically, UW is broken because this commit from 2013 December is missing:
http://git.wikimedia.org/commit/mediawiki%2Fextensions%2FUploadWizard/8bd13ac4317f48336f90a39723d142628eb906e9