(In reply to Mark A. Hershberger from comment #21)
> Others, like WikimediaMessages, suffer from the problem of
> d373fd87b17bfb67f6616011ec1faa2531e58878 -- where the committer "This, that
> and the other" made a commit indicating "Update for release of MW 1.23"
> without merging it with REL1_23 or requesting a backport.

I don't think that patch needs to be backported, as the change is only relevant to mediawikiwiki, which is on 1.24wmfX by now.

Since WikimediaMessages is a WMF-only extension I don't understand why it needs release branches in the first place.
Looks like UW -- and others branched before April 22 -- would benefit from a bit of work.

Others, like WikimediaMessages, suffer from the problem of d373fd87b17bfb67f6616011ec1faa2531e58878 -- where the committer "This, that and the other" made a commit indicating "Update for release of MW 1.23" without merging it with REL1_23 or requesting a backport.
Extensions that look like they were branched on Oct 24:

SolrStore REL1_23 5dabd1e Thu Oct 24 20:50:10 2013 +0000
SpamBlacklist REL1_23 d6bd4c1 Thu Oct 24 20:50:16 2013 +0000
SphinxSearch REL1_23 4a24249 Thu Oct 24 20:50:22 2013 +0000
SubPageList REL1_23 a68966d Thu Oct 24 20:50:26 2013 +0000
Sudo REL1_23 98bd893 Thu Oct 24 20:50:33 2013 +0000
SyntaxHighlight_GeSHi REL1_23 2f064f4 Thu Oct 24 05:51:03 2013 +0000
TemplateData REL1_23 26dacfc Thu Oct 24 20:50:37 2013 +0000
TemplateSandbox REL1_23 1e880cc Thu Oct 24 20:50:40 2013 +0000
Thanks REL1_23 22333e0 Thu Oct 24 20:50:46 2013 +0000
ThrottleOverride REL1_23 e122ac6 Thu Oct 24 20:50:50 2013 +0000
TimedMediaHandler REL1_23 7bd2b47 Thu Oct 24 20:50:54 2013 +0000
Translate REL1_23 dfee4f4 Thu Oct 24 20:51:04 2013 +0000
TranslateSvg REL1_23 5d30452 Thu Oct 24 20:51:11 2013 +0000
TranslationNotifications REL1_23 5537a12 Thu Oct 24 20:51:18 2013 +0000
TwnMainPage REL1_23 016ea86 Thu Oct 24 21:19:02 2013 +0000
TwoFactorAuthentication REL1_23 e2fb0cc Thu Oct 24 20:51:31 2013 +0000
UploadWizard REL1_23 9b39bd9 Thu Oct 24 20:51:37 2013 +0000
Validator REL1_23 3c3997a Thu Oct 24 20:51:44 2013 +0000
Created attachment 15695
differences between bundled version of spamblacklist in 1.22 and 1.23

I only see l10n diffs for the bundled versions of SpamBlacklist, but they aren't the same.

$ git log -1 --pretty=format:"%h%x09%an%x09%ad" origin/REL1_23
d6bd4c1 Translation updater bot Thu Oct 24 20:50:16 2013 +0000
$ git log -1 --pretty=format:"%h%x09%an%x09%ad" origin/REL1_22
f91ad56 Translation updater bot Tue Oct 22 19:21:30 2013 +0000

So, year, not the right place for a branch, but not the same thing. No clue yet why this happened.

**Attached**: {F13932}
non-l10n changes in UploadWizard since it was branched: https://gerrit.wikimedia.org/r/#/q/status:merged+project:mediawiki/extensions/UploadWizard+branch:master+-owner:L10n-bot,n,z
(Missed a couple of lines for the above script bit:
  rel123=`git log -1 --oneline origin/REL1_23 2>&1`
  rel122=`git log -1 --oneline origin/REL1_22 2>&1`
)

UploadWizard was branched on 2014-Apr-14.  Some bugs (bug #47161, bug #53245, bug #40147, bug #64908, bug #63921, bug #64067, bug #64883 and others below) were addressed with patches but no indication was made that a backport should be considered.

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

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.
Comment on attachment 15693
Submodules under extensions w/o commits for 1.23

The following script was used to create this file:

 lines=`git log --oneline --before 2014-04-10 --after 2013-10-10 | wc -l`
 branch123=`git branch -a | grep origin/REL1_23 | wc -l`
 branch122=`git branch -a | grep origin/REL1_22 | wc -l`
 echo REL1_23: $branch123 REL1_22 $branch122 lines $lines
 if [ "$lines" -eq "0" -a "$rel123" == "$rel122" ]; then
    echo REL1_23 == REL1_22 for $ext
    echo $ext >> /tmp/122=123
 fi
Created attachment 15693
Submodules under extensions w/o commits for 1.23

This file was generated by using an up-to-date extensions checkout (with updates submodules) and listing those submodules without any commit between 2014-04-10 (when REL1_23 was created) and 2013-10-10 (~when REL1_22 was created).  This will help determine when REL1_22 should be the same as REL1_23.

**Attached**: {F13931}
Greg / hexmode / Markus:  Will anybody fix this? It's been open for two months and creates followup issues, confusion, brokenness (bug 66866).
UploadWizard is also affected by this, and as a result it is completely broken on 1.23.
It looks like some extensions including SyntaxHighlight_GeSHi and SpamBlacklist were not fixed, and as a result the 1.22 versions of these two extensions are in the 1.23.0 tarball.
Wrote a script to remove the faulty REL1_23 branches (since I couldn't just push a new one).  Should all be fixed now.
Fixed BlueSpiceFoundation
Fixed those in comment #0, looking for more problems.
It looks like some of the problem is confusion between gerrit and gitblit.  For example, https://git.wikimedia.org/branches/mediawiki%2Fextensions%2FSemanticMediaWiki.git shows REL1_23 on 2013-10-24.

A fresh checkout from gerrit, though, shows the last commit on REL1_23 to be 26923ba5d306b24afe3e8d71f3f065139fd593c6 on 2014-04-14.

Hmmm, and part of what I'm running into here is caching.  Opening the branch listing in a new browser shows what I expect.

Another part of the problem is that I did initially make a mistake of branching the wrong code.  When I discovered that I got a pointer from Chad on how to fix the problem.  Evidently, though, this happened in more places than I realized.
Like I say, ProofreadPage was massively out of date too. Now fixed though
(In reply to Jesús Martínez Novo (Ciencia Al Poder) from comment #0)
> 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.

Any extensions that have i18n files will need to be updated, but some, like Auth_remoteuser, are fine as is.

Thank you for pointing out this problem before the release!
(In reply to Mark A. Hershberger from comment #3)
> That is, the dates you see on the branch page are the dates of the last
> commit on that branch, not when the branch was made.
> 
> I created most of these REL1_23 branches last week.

That doesn't seem right. As I said in comment #0, a lot of extensions were changed to have i18n messages in JSON files instead of PHP, and that was done weeks before REL1_23 was branched on master (it's in REL1_23 in core). But REL1_23 on the extensions I've linked as example doesn't include this change, among others that were merged on master after October 2013.

I've manually checked some of those extensions, downloading from git for that branch name and they aren't migrated, while if I switch to master they have the new JSON files.
If you look at Auth_remoteuser (https://git.wikimedia.org/branches/mediawiki%2Fextensions%2FAuth_remoteuser.git), you'll see that REL1_21, REL1_22, and REL1_23 were all apparently branched when REL1_20 was created.

From this I conclude that there were no changes on master between the time that REL1_20 was created and when REL1_23 was created.  And the history seems to confirm this: https://git.wikimedia.org/log/mediawiki%2Fextensions%2FAuth_remoteuser.git/refs%2Fheads%2Fmaster

That is, the dates you see on the branch page are the dates of the last commit on that branch, not when the branch was made.

I created most of these REL1_23 branches last week.
I fixed ProofreadPage by having Chad enable force push, and pushing to update the remote REL1_23 branch.


Why were the REL1_23 branches created at the branching point of REL1_22? :/
While we're on it, could please whoever is in charge of releasing new MediaWiki versions, add also a note to check extension branches to the steps to create a new release? Every major release since we're on git have the same problem!! (usually REL1_XX branch is not created when the new release is done in core)

See also bug 48837
Steps to reproduce:

1. Go to (say) https://en.wikipedia.org/w/index.php?title=Visual_editor&veaction=edit

2. Place the cursor after the end of a paragraph (e.g. after the full stop in "editors are.")

3. Hit the delete key to merge the paragraph with the subsequent one.

4. Type any character (a letter, blank, etc.)

Result: Chaos ;) - large swaths of text are deleted, and (apparently) random characters appear near the beginning of the page.

Reproduced in Chromium (Version 33.0.1750.152) and Firefox (28.0).

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=62333
Yes, works for me too now in Chromium and Firefox.
Works for me, probably resolved at some point in the last couple of months.
Steps to reproduce:

1.Open a page with VE
2.Insert a Cite option like Cite Website/Cite Journal
3.Add some value for a parameter
4.Click on "Add Parameter"
5.Select a parameter

Observed Result:

The cursor instead of moving to the new parameter, stays at the last edited parameter box


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
Verified the fix on production
Verified the fix on Betalabs
*** Bug 64201 has been marked as a duplicate of this bug. ***
Steps to reproduce:

1.Open a page with VE
2.Insert a citation or a reference

Observed Result:
The cursor jumps to the beginning of the document 

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
Verified the fix in production (en.wiki)
So, this issue did get re-introduced in wmf 10, and then got somehow resolved in wmf 11, Because I am getting it in production running wmf 10 but not on test2 running wmf 11.
Therefore , I am changing the target milestone accordingly.
(In reply to Ed Sanders from comment #9)
> Works in master.

Doesn't work in Beta Labs, which is running master AFAICT.
Works in master. Deployment issue?
This bug has been reborn in wmf 10
Verified on betalabs for Cite options too
Verified by adding template in test2
Change 127698 merged by Catrope:
Add focusing state flag to ce.Surface when programatically focusing

https://gerrit.wikimedia.org/r/127698
Change 127698 had a related patch set uploaded by Catrope:
Add focusing state flag to ce.Surface when programatically focusing

https://gerrit.wikimedia.org/r/127698
Change 127136 merged by jenkins-bot:
Add focusing state flag to ce.Surface when programatically focusing

https://gerrit.wikimedia.org/r/127136
Change 127136 had a related patch set uploaded by Esanders:
Add focusing state flag to ce.Surface when programatically focusing

https://gerrit.wikimedia.org/r/127136
This happens after adding a template too.
Screenshot

Steps to reproduce:

1.Open any page with mobile VE
2.Add a text
3.Save the page 
4.Reopen the page
5.Go to the next line of the text you added in step 2
6.Start typing something

Observed Result:
The following error appears in the console

Uncaught TypeError: Cannot read property 'nextSibling' of undefined

See the screenshot attached

Test Environment:http://en.m.wikipedia.beta.wmflabs.org/
Page:http://en.m.wikipedia.beta.wmflabs.org/wiki/0.4040571254571662?title=0.4040571254571662&campaign=random#editor/0

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

**Attached**: {F13635}
Verified the fix in: https://en.m.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/Sandbox
Verified the fix on test2
Change 127380 merged by jenkins-bot:
Also destroy target when exiting without saving changes

https://gerrit.wikimedia.org/r/127380
Change 127380 had a related patch set uploaded by Jforrester:
Also destroy target when exiting without saving changes

https://gerrit.wikimedia.org/r/127380
Change 127364 merged by jenkins-bot:
Also destroy target when exiting without saving changes

https://gerrit.wikimedia.org/r/127364
Change 127364 had a related patch set uploaded by Catrope:
Also destroy target when exiting without saving changes

https://gerrit.wikimedia.org/r/127364
Change 126881 merged by jenkins-bot:
Destroy the VE target after saving

https://gerrit.wikimedia.org/r/126881
Change 126881 had a related patch set uploaded by Catrope:
Destroy the VE target after saving

https://gerrit.wikimedia.org/r/126881
Screenshot

Steps to reproduce:'

1.Open a page with VE
2.Go to Insert>Template
3.Click on "Show options"

Observed Result
The template icon and the trash icon is overlapping with "Add template" button
The NEw template heading is appearing below the textbox

Try to add a content/parameter its broken for them too

See the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F13598}
Verified the fix on production
verified the fix on test 2
Verified the fix on Betalabs
Change 126869 merged by jenkins-bot:
Followup 099f26ec: fix $content in FieldsetLayout

https://gerrit.wikimedia.org/r/126869
Change 126869 had a related patch set uploaded by Catrope:
Followup 099f26ec: fix $content in FieldsetLayout

https://gerrit.wikimedia.org/r/126869
Created attachment 15121
parameter textbox

**Attached**: {F13599}
* Open https://www.mediawiki.org/w/index.php?title=Parsoid/Deployments&oldid=959448&veaction=edit
* Copy the section starting @ "Monday, April 14, 2014 around 1pm PST : Deployed fba548cb" including the list upto the next section
* Try pasting it -- nothing gets pasted.
* Now try copy-pasting othe things (even simple strings) .. everything fails.

Can consistently reproduce this.

--------------------------
**Version**: unspecified
**Severity**: normal
It's almost certainly because the copy-paste code fatals on come content currently, and doesn't bring itself back; up-merging into bug 66229 which asks for this to be fixed.

*** This bug has been marked as a duplicate of bug 66229 ***
Works for me.
**Author:** `swalling`

**Description:**
VE's edit surface has a body font size of 0.8em (equals 13px) which mismatches with the new default body font size (0.875em, which translates to 14px on Chrome and Firefox on most systems). The same is true for line-height, which is now 1.6em for body content. 

We should make sure the two are consistent. The body font stack and heading settings do get translated to VE edit mode correctly, so we're close. :)

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63540
Change 130481 merged by jenkins-bot:
vector: Apply content text style via .mw-body-content instead of #bodyContent

https://gerrit.wikimedia.org/r/130481
Will back-port to wmf2 at least.
Change 130481 had a related patch set uploaded by Jforrester:
vector: Apply content text style via .mw-body-content instead of #bodyContent

https://gerrit.wikimedia.org/r/130481
Change 129563 merged by jenkins-bot:
vector: Apply content text style via .mw-body-content instead of #bodyContent

https://gerrit.wikimedia.org/r/129563
Change 129563 had a related patch set uploaded by Krinkle:
Make new styles target .mw-content instead of #bodyContent

https://gerrit.wikimedia.org/r/129563
I'm not quite sure about the pre-typograpy-refresh situation, but it shouldn't be to different from the curent.

Here's the situation now . We have #mw-head-base (tabs and personal links) and #content (#firstHeading, #bodyContent, #catlinks and everything in between). Both have a base fontsize of 1em and left-margin of 10/11em. They need to match, no matter what, to align the tabs with the content part of the page.

Fontsize isn't actually set until deep inside the various parts:
#p-personal li {font-size: 0.75em;},
div.portal div.body ul li {font-size: 0.75em;},
div.vectorTabs li a {font-size: 0.8em;},
and in #bodyContent {font-size: 0.875em;}

The rest of the Vector layout relies on the base fontsize of 1em. If you must have 0.875em for #content, then the entire structure needs to be revised. So I don't know is VE can match the current situation, that would be the easiest way.
Change 129567 had a related patch set uploaded by Trevor Parscal:
Use .mw-content for content styling

https://gerrit.wikimedia.org/r/129567
(In reply to Erwin Dokter from comment #5)
> Just discovered that setting the 0.875em fontsize to #content instead of
> #bodyContent messes with the layout of the entire page; the navigation bar
> relies on the fontsize of #content to be 1em, otherwise it collapses.
> 
> To compensate, the left margin of #content would have to be modified from
> 10/11em to 11.43/12.57em. That seems quite an unsightly hack with a
> potential for alignment issues due to rounding errors.
> 
> Just so you know.

Suggests that we should probably revisit the margins a little, but yes. :-(

Can we get this fixed urgently? It's a quite disruptive regression for VisualEditor users.
Just discovered that setting the 0.875em fontsize to #content instead of #bodyContent messes with the layout of the entire page; the navigation bar relies on the fontsize of #content to be 1em, otherwise it collapses.

To compensate, the left margin of #content would have to be modified from 10/11em to 11.43/12.57em. That seems quite an unsightly hack with a potential for alignment issues due to rounding errors.

Just so you know.
(In reply to Erwin Dokter from comment #2)
> Both @body-line-height and @body-font-size are already applied to
> #bodyContent (see bug 63731). Don't you mean they should be moved to
> div#content instead, where everything else is defined?

Sorry, yes. Corrected title.
*** Bug 64124 has been marked as a duplicate of this bug. ***
Both @body-line-height and @body-font-size are already applied to #bodyContent (see bug 63731). Don't you mean they should be moved to div#content instead, where everything else is defined?
As discussed, we should apply the styling to bodyContent to affect other parts of the page like siteSub, contentSub, printfooter, catlinks, and also VE edit surface etc.
Steps to reproduce:

1.Open a page with VE
2.Go to page options
3.Select Page Settings
4.Go to Page options again
5.Select Advanced Settings from the menu

Observed Result:
It navigates to the tab that was last opened but not to Advanced Settings

Test Environment: https://test2.wikipedia.org/ and v
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5

--------------------------
**Version**: unspecified
**Severity**: minor
Verified the fix on production
Verified the fix on test2
Verified the fix on Betalabs
Change 126187 merged by jenkins-bot:
Fix name of advanced settings page in open command

https://gerrit.wikimedia.org/r/126187
Change 126187 had a related patch set uploaded by Alex Monk:
Fix name of advanced settings page in open command

https://gerrit.wikimedia.org/r/126187
Per bug 51245 Parsoid now has the start of a CSS module – gerrit 124785 – which we should pull into VE. Once we've done that we can start upstreaming a lot of our local CSS hacks into Parsoid and save the effort. :-)

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60017
https://bugzilla.wikimedia.org/show_bug.cgi?id=51245
Change 129810 merged by jenkins-bot:
Pull in Parsoid's new styling module

https://gerrit.wikimedia.org/r/129810
Change 129810 had a related patch set uploaded by Jforrester:
Pull in Parsoid's new styling module

https://gerrit.wikimedia.org/r/129810
So I think we need to:
* Start depending on the Parsoid extension. (At the moment it's optional and improves performance.) James says this will break Vagrant installations.
* Mark the VE RL module as depending on Parsoid's.
Intention:
See if I could reproduce Alex's bug.  I could.

Steps to Reproduce:
1. Click http://en.wikipedia.beta.wmflabs.org/wiki/User:Whatamidoing_(WMF)/Sandbox?veaction=edit or open another page in VisualEditor.

2. Click outside the main editing area.  For example, highlight part of the page title, or put the cursor in the search box.

3. While your cursor is still outside the editing area, click the page options menu (three bars icon) and choose any item.  For example, choose "Categories".  (Perhaps you just used the search box to figure out how to spell the name of the category you're interested in adding, and that's why your cursor is in the search box.)

Actual Results:  
Nothing happens.  "Switch to source editing" is the only menu item that produces a response.

Expected Results:  
Normal editing behavior.  It doesn't matter where my cursor is placed for these items, so they shouldn't care.

Reproducible: Always

Confirmed in Safari 6 and Firefox 28 on Mac OS 10.8.5, and assumed to affect everything.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63954
Verified the fix in production:https://en.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/sandbox&veaction=edit
Verified the fix in test2
Presuming that this is now FIXED.
Change 126058 merged by jenkins-bot:
Use document direction when a fragment has a null range

https://gerrit.wikimedia.org/r/126058
Change 126058 had a related patch set uploaded by Trevor Parscal:
Use document direction when a fragment has a null range

https://gerrit.wikimedia.org/r/126058
CCing Roan - James mentioned earlier that he was working on something like this yesterday.
I found this on Chrome 33 on Ubuntu 13.10.

Error if you try to open something like Page settings (or most other items on that list):
Uncaught TypeError: Cannot read property 'start' of null
ve.Document.selectNodes
ve.ce.Document.getDirectionFromRange
ve.ui.DialogAction.open
ve.ui.Surface.execute
ve.ui.Command.execute
ve.ui.Tool.onSelect
OO.ui.ToolGroup.onMouseUp
OO.ui.PopupToolGroup.onMouseUp
proxy
jQuery.event.dispatch
elemData.handle.eventHandle

Error if you try to type in the main text editing area:
Uncaught TypeError: Cannot call method 'isCollapsed' of null
ve.ce.Surface.handleInsertion
ve.ce.Surface.onDocumentKeyPress
proxy
ve.EventSequencer.onEvent
(anonymous function)
jQuery.event.dispatch
elemData.handle.eventHandle
Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Reference
3.Type something inside the reference dialog box

Observed Result:
As soon as you type the first word the first letter diappears.


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
Now , it does not look broken .Hence, marking it as Fixed.
I am again getting this issue in Chrome in Betalabs.
verified the fix in production for Chrome
Change 129323 merged by Catrope:
Prevent SurfaceWidgets from focussing themselves

https://gerrit.wikimedia.org/r/129323
Change 129323 had a related patch set uploaded by Catrope:
Prevent SurfaceWidgets from focussing themselves

https://gerrit.wikimedia.org/r/129323
Change 129081 merged by jenkins-bot:
Prevent SurfaceWidgets from focussing themselves

https://gerrit.wikimedia.org/r/129081
Change 129081 had a related patch set uploaded by Esanders:
Prevent SurfaceWidgets from focussing themselves

https://gerrit.wikimedia.org/r/129081
Also the following errors appear on the console while trying to delete the texts inside the reference dialog box:
TypeError: startNode is null
Error: Unbalanced set of replace operations found
Error: ve.dm.Document.getNodeFromOffset(): offset 3 is out of bounds
For FireFox, I am getting this problem in a slightly different manner:
Instead of getting missing the first letter of the first word you type inside reference dialog box , goes to the next line.
Verified the fix in test2
Verified the fix for the caption field in the Media Settings dialog in Betalabs
Change 126855 merged by jenkins-bot:
Also focus surface in media edit dialog

https://gerrit.wikimedia.org/r/126855
Change 126855 had a related patch set uploaded by Catrope:
Also focus surface in media edit dialog

https://gerrit.wikimedia.org/r/126855
This is now happening for the caption field inside Media Settings
Verified the fix on Betalabs
Change 125911 merged by jenkins-bot:
Focus the surface in the reference dialog after it opens

https://gerrit.wikimedia.org/r/125911
Change 125911 had a related patch set uploaded by Catrope:
Focus the surface in the reference dialog after it opens

https://gerrit.wikimedia.org/r/125911
With the reversion this should now be working again?
Correction:
Observed Result:

As soon as user types the first word, the first letter of it disappears.
If you click out of an inspector into some other text, it used to be that the cursor went to that text and stayed there, but now it jumps back to the text that was being inspected. I suspect this may have something to do with changes to ve.ui.DesktopContext. There seems to be a delay so maybe something's happening from a setTimeout( ..., 200 ) after the closing animation?

--------------------------
**Version**: unspecified
**Severity**: normal
Change 127805 merged by jenkins-bot:
Prevent annotation inspector from updating selection if using DesktopContext#hide

https://gerrit.wikimedia.org/r/127805
Change 127805 had a related patch set uploaded by Esanders:
Prevent annotation inspector for updating selection if using DesktopContext#hide

https://gerrit.wikimedia.org/r/127805
Steps to reproduce:


1.Open a page with VE
2.Insert a reference
3.Type in something in the reference dialog box
4.Save the page
5.Reopen the page
6.Open the reference


Observed Result:
There is no content in the reference dialog box

Test Environment: https://test2.wikipedia.org/
Browser: Chrome Version 26.0.1410.65
OS: MAC OS X 10. 8. 5

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix on productionhttps://en.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/sandbox&veaction=edit
Verified the fix on test2
Change 125431 merged by jenkins-bot:
Update VE core submodule to latest master (74353d9)

https://gerrit.wikimedia.org/r/125431
Verified the fix in Betalabs
Change 125431 had a related patch set uploaded by Jforrester:
Update VE core submodule to latest master (74353d9)

https://gerrit.wikimedia.org/r/125431
*** Bug 63829 has been marked as a duplicate of this bug. ***
Try to open math inspector on betalabs:
The following error appears on the console and the math function does not open up

Uncaught TypeError: Cannot call method 'getModel' of undefined VM2690:273
ve.ui.MWMathInspector.setup VM2690:273
(anonymous function) VM2688:23
proxy load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Cl…:10
listenerWrapper VM2688:6
oo.EventEmitter.emit VM2688:7
(anonymous function) VM2688:20
pollExternalStylesheets

--------------------------
**Version**: unspecified
**Severity**: normal
Change 129623 merged by jenkins-bot:
Update VE implementation to use model-only inspectors

https://gerrit.wikimedia.org/r/129623
Change 129623 had a related patch set uploaded by Jforrester:
Update VE implementation to use model-only inpsectors

https://gerrit.wikimedia.org/r/129623
Verified the fix on production with Chrome and FF
Verified the fix on test2
Change 126909 merged by jenkins-bot:
Update VE implementation to use model-only inpsectors

https://gerrit.wikimedia.org/r/126909
Change 126909 had a related patch set uploaded by Catrope:
Update VE implementation to use model-only inpsectors

https://gerrit.wikimedia.org/r/126909
Verified the fix in Betalabs
Change 125933 merged by jenkins-bot:
Update VE implementation to use model-only inpsectors

https://gerrit.wikimedia.org/r/125933
Change 125933 had a related patch set uploaded by Esanders:
Update VE implementation to use model-only inpsectors

https://gerrit.wikimedia.org/r/125933
how the ...

In my Windows 7 VMWare machine the icons render strangely in the toolbar.  Image attached.

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

**Attached**: {F13606}
I have, however, seen a number of interesting rendering problems in IE11. It seems like their hardware acceleration sometimes chokes on gradients or transitions or whatever it is that we do that it doesn't like, and you'll get things like black boxes or iframes being transparent while they should be opaque, or buttons appearing to be flat when they shouldn't be.
Works fine for me in IE10.
Forking from bug 43844. Not good.

--------------------------
**Version**: unspecified
**Severity**: major
Change 125745 merged by jenkins-bot:
Always replace state with VE tag when loading

https://gerrit.wikimedia.org/r/125745
Change 125745 had a related patch set uploaded by Alex Monk:
Always replace state with VE tag when loading

https://gerrit.wikimedia.org/r/125745
I think this is caused by Gerrit change 118357
On http://parsoid.wmflabs.org/enwiki/User:Tamravidhir?oldid=603142295 , I see two images that look like:

<figure><small><a href="..."><img src="..." /></a><figcaption>Caption text</figcaption></small></figure>

You can find them by opening that link in a browser and typing document.querySelectorAll('figure>small') in a console, then clicking on the result (Firebug) or right-clicking the result and choosing "Reveal in elements panel" (Chrome).

Putting a <small> inside a <figure> tag but wrapped around a <figcaption> tag is a violation of the image spec (in addition to just being insane), which causes VisualEditor to get very confused and corrupt the image, which causes Parsoid to output [[undefined|NaNxNaNpx|right|link=]], see https://en.wikipedia.org/w/index.php?title=User:Tamravidhir&diff=603142575&oldid=603142295 . This is reminiscent of bug 62805 (NaNxNaNpx).

The wikitext that triggers this is fairly complicated, and I haven't been able to isolate a test case locally. It seems to be something like:

* '''Text'''
<small>
[[File:Foo|right|200px|Caption]]

Text

[[File:Foo|right|200px|Caption]]
</small>
* '''Text'''
<small>
etc.

--------------------------
**Version**: unspecified
**Severity**: major
This is now fixed and will be deployed on Monday. Please reopen if you see this not fixed in production.
Change 215058 had a related patch set uploaded (by Subramanya Sastry):
T65642: Additional scenarios dealing with treebuilder fixup

[[https://gerrit.wikimedia.org/r/215058]]
That patch also fixes your example from Comment 14:

[subbu@earth lib] echo "<small>[[File:Foo.jpg|right|300px]]</small>" | node parse.js --wt2wt
<small>[[File:Foo.jpg|right|300px]]</small>

Okay, will revive it and try to get a resolution on it soon enough. I need to study behavior on more convoluted test cases and see what Tidy does and what we do now and see if I can fold that into this patch.
(In reply to ssastry from comment #15)
> Any thoughts about https://gerrit.wikimedia.org/r/#/c/162816/?

I don't understand the patch very well, but the changes to the test cases look promising.
Any thoughts about https://gerrit.wikimedia.org/r/#/c/162816/?
This is still causing problems. See https://ru.wikipedia.org/?diff=66125825 for instance.

$ echo "<small>[[File:Foo.jpg|right|300px]]</small>" | node tests/parse.js --wt2wt

<small>[[File:Foo.jpg|right|300px|link=]]

This seems to happen because of something similar to what I described in bug 66749 comment 7: there is a <small> inside a <figure>, which violates Parsoid's HTML spec, and causes a round-trip failure. Additionally, there's a frivolous <p><small></small></p> before and <p></p> after the image.
See bug 66749 which appears to be a dup?

Also, the WTS side of this ( https://gerrit.wikimedia.org/r/129818 ) never got finished/merged.
Will close this .. Please reopen if this is not fixed post deploy tomorrow.
This will be deployed on Wednesday.
Change 130109 merged by jenkins-bot:
(Bug 63642): Cleanup treebuilder fixup of formatting elts.

https://gerrit.wikimedia.org/r/130109
Change 130109 had a related patch set uploaded by Subramanya Sastry:
WIP: (Bug 63642): Cleanup treebuilder fixup of formatting elts.

https://gerrit.wikimedia.org/r/130109
Change 129818 had a related patch set uploaded by Cscott:
WIP: WTS: Handle tag fixup that floats inside <figure>.

https://gerrit.wikimedia.org/r/129818
For the WTS case, it's probably sufficient to tweak the code that looks for the various bits of <figure> and ensure it skips over any extraneous <small>/<b>/<i>/<s>/<u> as direct children of <figure>.  That part wouldn't require a separate fixup pass.
Firefox fixes this up as follows:

> div=document.createElement('div')
> div.innerHTML = "<p><small></p><figure><figcaption>foo</figcaption></figure</small>"
> div.outerHTML
"<div><p><small></small></p><figure><figcaption><small>foo</small></figcaption></figure></div>"

But:
> div.innerHTML = "<p><small></p><figure><a href='xxx'><img></a><figcaption>foo</figcaption></figure></small>"
> div.outerHTML
"<div><p><small></small></p><figure><small><a href="xxx"><img></a><figcaption>foo</figcaption></small></figure></div>"

So it seems to be the <a> tag in particular which causes the treebuilder to resurface the <small> tag.  The same thing happens if <small> is <b> or <i> or <s> or <u>, but not <a>:

> div.innerHTML = "<p><a href=yyy></p><figure><a href='xxx'><img></a><figcaption>foo</figcaption></figure></a>"
> div.outerHTML
"<div><p><a href="yyy"></a></p><figure><a href="xxx"><img></a><figcaption>foo</figcaption></figure></div>"

We might be able to handle this with a focused post-processing step which looks for <small>/<b>/<i>/<s>/<u> as the direct child of a <figure> and hoists the formatting safely inside the <figcaption>.  In theory we should have a similar check in WTS in case we get invalid HTML as input.
Reports from Roan on IRC:

* Not very common, but seen on a few user pages.
* This corrupts wikitext on save in pages where it is seen.
* Community liasion wants this fixed in some fashion.
* More important to protect content than provide editability.

If possible, we should probably wrap such images with uneditable protection (mw:Placeholder) and deal with the larger issue later.
node parse --trace html --dump dom:post-builder reveals that Parsoid generates a <p><small></p><figure>..</figure></small> (imagine them to be html tokens input to the HTML5 treebuilder) which the treebuilder helpfully fixes up to <p><small></small></p><figure><small>..</small></figure>

But, the odd thing is that the tree builder does this only when this is nested inside the table. Not sure if that is a feature or a bug. To be tested in Firefox and Chrome.

Replace <small> with <b>/<i>/.. and you see the same behavior. But, I think this is the same class of bugs around formatting tags wrapping certain kind of block tags and getting fixed up by HTML5 parsing semantics. In the case of unclosed tags, we have bug reports where a <s> or a <ul> formatting tag continues to the rest of the document (bug 50536, bug 57196). I am recording this info here for now. Unclear what the exact solution is for this here, but clearly, we need a generic solution for misnested formatting tags.
Reduced test case: Every newline in there is important to reproduce this.
```
{|
|
<small>
[[File:Foo.jpg|right|Test]]
</small>
|}
```
Reduced test case: Every newline in there is important to reproduce this.

{|
|
<small>
[[File:Foo.jpg|right|Test]]
</small>
|}
(02:34:55 PM) RoanKattouw: This structure is in a table cell BTW
(02:35:00 PM) RoanKattouw: It's like the 104th child of a <td>
(02:35:08 PM) RoanKattouw: Mismatched tags seems plausible
(02:35:15 PM) RoanKattouw: There's a +</div> elsewhere in the dirty diff
I'm fairly certain that LinkHandler never outputs <small>, so my guess is that this is a foster-parenting bug.
**Author:** `richlv`

**Description:**
visual editor from git f8d56e6804a12248b485c2d3b49d4ff0ffa7220c

opera 12.16 on linux.

in the save form, minor edit & watching checkboxes can not be marked

--------------------------
**Version**: unspecified
**Severity**: major
Not reproducible and no response from bug reporter :(
Can not reproduce using Opera 12.17 on Windows 7, on the page from comment 3. Clicking on both the checkboxes and their labels works as expected, checking the box.
Not good.
**richlv** wrote:

for the record, this still does not work for me at https://www.mediawiki.org/w/index.php?title=VisualEditor&veaction=edit - but i'll wait for 1.23 to be out before complaining more about it :)
**richlv** wrote:

sorry, with ve currently not working with 1.22, i'll have to wait for the release of 1.23 to test this again
It seems to work OK for me now – can you confirm?
QUnit tests for jquery.makeCollapsible are often failing on Jenkins. I've seen this at least three times in the last week or so, most recently on https://gerrit.wikimedia.org/r/#/c/124051/ . Every time the failure was within the jquery.makeCollapsible tests (but I'm not entirely sure if on the same exact test).

This might be related to the fake timers being used in them.

--------------------------
**Version**: 1.23.0
**Severity**: major
Change 145479 abandoned by Mattflaschen:
Fix spurious QUnit failures related to fake timers

Reason:
I'm okay with throwing an error (which is already merged), rather than having the test runner work to clean it up.  The important thing is the test author/maintainer has a clear indication of the problem, which allows them to easily fix it.

https://gerrit.wikimedia.org/r/145479
I disabled the GuidedTour GUI that was triggering this during tests (1e37db808e1f9cc8daffb61e4303ce53d701e25a).  Krinkle's b90c69cdf70ae55a7ae608b074893d140d0a96b6 ("QUnit: Detect unfinished jQuery effects or ajax requests in teardown") has been merged to core, which should detect similar issues in the future.

I will abandon the other patch, since if isolation deficiencies (e.g. running effects queue) are fully detected and error'ed, the runner doesn't need to enforce that isolation.
Change 143481 abandoned by Krinkle:
Use QUnit.asyncTest even for fake timers, to fix spurious failures

Reason:
See Ibada489a58295

https://gerrit.wikimedia.org/r/143481
Change 145487 merged by jenkins-bot:
Don't actually show guiders in unit tests

https://gerrit.wikimedia.org/r/145487
(In reply to Krinkle from comment #25)
> Also, this really should've been a separate bug. The bug as reported was
> fixed and affected core.

The original symptoms appeared very close (not just "it's something with timers and animations", but specifically jquery.makeCollapsible).

I didn't dive deeper to figure out the underlying interactions until later.
Change 145487 had a related patch set uploaded by Mattflaschen:
Don't actually show guiders in unit tests

https://gerrit.wikimedia.org/r/145487
Also, this really should've been a separate bug. The bug as reported was fixed and affected core. This looks similar (it's something with timers and animations), but a different exception is thrown, different unit tests are failing, and it's only affecting extensions (doesn't mean the bug isn;t in core, but it's a separate bug).

This isn't a "something is wrong with qunit and timers" tracking bug.
You were right, I didn't need to make it async.

Side note, the SinonJS docs imply that useFakeTimers() uses the current date by default.  Unfortunately (this would have fixed half of my patch), this is not true, so I submitted a patch for those docs at https://github.com/sinonjs/sinon-docs/pull/2 .
Change 145479 had a related patch set uploaded by Mattflaschen:
Fix spurious QUnit failures related to fake timers

https://gerrit.wikimedia.org/r/145479
Turning the tests from sync to async in core is the functional equivalent of removing the assertion "test framework works as expected". It's like boldly removing unit tests or parser tests because when executed with a certain extension, they no longer match expected behaviour.

I can reproduce this consistently but only with those extensions installed. With plenty of other extensions installed it works fine. I don't see anything obvious this extension that might cause it, but that wasn't the case earlier this year either and eventually we did find the problem there too.

After static analysis yielded nothing, I turned to removing code locally until you find out what's causing it. Maybe it'll turn out to be a trigger that calls back into mediawiki-core, maybe not. But the surface layer triggering it isn't in core.
Doesn't look like we have a GettingStarted example yet, so:

https://integration.wikimedia.org/ci/job/mwext-GettingStarted-qunit/58/consoleFull

(Jul 3, 2014 12:13:51 AM per https://integration.wikimedia.org/ci/job/mwext-GettingStarted-qunit/58/)

Seems to be the same set.  Again, jquery.color is the first error.

If it affects any other extensions, please add.
(In reply to Krinkle from comment #19)
> Considering it is only affecting tests related to asynchronous Date
> manipulation, I suspect one or more of the extensions the Growth team
> maintains is interfering with that interface.

I'm not sure what you mean by "asynchronous Date manipulation".  Sinon's fake timer methods are synchronous, AFAICT, just a simulation where you advance the clock manually.

As far as the actual code (jquery.color.js and jquery.makeCollapsible.js), they are both using .promise (https://api.jquery.com/promise/) to monitor completed actions in the fx queue.

GuidedTour (one of the extensions this bug affects) does not have any asynchronous tests, nor does GettingStarted.  Although we use setTimeout, we certainly don't do anything weird like redefining it.

EventLogging (one of our dependencies) does use asynchronous tests, but we're hardly the only extension to use EventLogging.  (Note, EventLogging is not a Growth extension).  I don't know if any extensions with QUnit tests use EventLogging, but I suspect they do.

If you see a bug (or unexpected interaction) which we can fix in a Growth extension, let us know.

However, practically speaking, we should focus on getting this bug fixed.  My next step (as mentioned on Gerrit) will be to try use PhantomJS's remote debugging to step through and find exactly what's happening.
Considering it is only affecting tests related to asynchronous Date manipulation, I suspect one or more of the extensions the Growth team maintains is interfering with that interface.

That was the case a few months back as well (that time it was an infrastructure library inside Grunt/Jenkins causing it).

I can't reproduce this in MediaWiki core or any of the other extensions I can find. The test for MediaWiki core alone or those run for extensions such as VisualEditor and other projects are all consistently passing.
Change 143481 had a related patch set uploaded by Mattflaschen:
Use QUnit.asyncTest even for fake timers, to fix spurious failures

https://gerrit.wikimedia.org/r/143481
Actually, the first failure (at least sometimes, such as 220 mentioned above) is jquery.color.

From the full log (https://integration.wikimedia.org/ci/job/mwext-GuidedTour-qunit/220/consoleFull) (without full it shows the tail):

19:08:06 jquery.color - animate...ERROR
19:08:06 >> Message: Expected 1 assertions, but 0 were run
This is really problematic… https://gerrit.wikimedia.org/r/#/c/137837/
I'm going to work on this as well, since it's a recurring problem affecting the Growth team.
Hm.. will give it another look. Although I doubt it's a bug in core.
This is an old report. Been fixed a while ago.
Krinkle/Antoine: can you take a look please.
Someone really needs to take a look at this.  It is causing major friction in the continuous integration pipeline due to spurious failures.
It's recurred.  See https://integration.wikimedia.org/ci/job/mwext-GuidedTour-qunit/220/console .  It's from about 6 hours ago.

It's causing spurious failures in GuidedTour (likely other extensions too).  E.g.:

19:08:11 >> Message: after expanding: contentItem is visible
19:08:11 >> Actual: false
19:08:11 >> Expected: true
This was resolved after the following upgrades were made:


* [jenkins] Update wmfgrunt dependencies to newer upstream versions 
  - grunt-contrib-qunit from v0.2.0 to v0.4.0
  - phantomjs from v1.8.1 to v1.9.7
  https://gerrit.wikimedia.org/r/#/c/125052/

* [mediawiki-core] Update QUnit from v1.11.0 to v1.14.0 
  https://gerrit.wikimedia.org/r/#/c/125533/

The latter is what made the false failures go away, so presumably the changes in those QUnit releases fixed it (possibly the changes in v1.12.0 and v1.14.0 that cache setTimeout and clearTimeout to protect against mocks).
The internal time out is 30 seconds.

It hanging for more than 30 seconds is new, that didn't happen until today.

Both that 30s timeout and the 360min timeout should not be triggered because the tests aren't actually taking more than < 10-20 seconds to run. Something is causing it to get stuck or in some kind of loop...
mediawiki-core-qunit is now sometime stuck. I killed a few jobs earlier today that ran for multiple hours.

Just killed  https://integration.wikimedia.org/ci/job/mediawiki-core-qunit/19068/console which was running for 10 minutes.

Might want to add adjust the timeout of jobs to something more reasonable than the current 360 minutes.
Somewhat interestingly, the job sometimes hangs for real.

From <https://gerrit.wikimedia.org/r/#/c/125370/>: "https://integration.wikimedia.org/ci/job/mediawiki-core-qunit/19052/console : ABORTED in 5h 51m 36s"
This has nothing to do with a time limit of any kind. The qunit tests run quicker than ever and have recently been sped  up a lot further by getting rid of slow animations and http calls to the server etc.

This is failing because for some reason QUnit unexpectedly dies at which point PhantomJS never gets the 'end' event callback and thus times out. It does not time out because the tests are too long or anything.
*** Bug 63647 has been marked as a duplicate of this bug. ***
Warning: PhantomJS timed out, possibly due to a missing QUnit start() call.\x07 Use --force to continue

On https://gerrit.wikimedia.org/r/#/c/124366/ and some more of my changes from last days

Possible regression from gerrit 117153

Please have a look into this tests. Thanks.
Again: https://gerrit.wikimedia.org/r/#/c/124302/
Another example from today: https://gerrit.wikimedia.org/r/#/c/123804/
Screenshot

Steps to reproduce:


1.Open a page with VE
2.Insert a media
3.Open the media Settings for the image

Observed Result:
The caption field is missing in the media settings dialog box .Also in the console the following error appears:

Uncaught TypeError: Object #<OoUiButtonSelectWidget> has no method 'initializeSelection'

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
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63544

**Attached**: {F13747}
Verified the fix in production
Verified the fix on mw.org
This issue got fixed with this commit:
https://gerrit.wikimedia.org/r/124381

Verified the fix in Betalabs
Reported by users and repro'd in beta labs

Log in and edit any page with VE at http://en.wikipedia.beta.wmflabs.org/

From the hamburger list select "Switch to source editing"

Nothing happens.  In the javascript console find the error 


Uncaught Error: OO.ui.Tool.onSelect not implemented in this subclass:function VeUiMWEditModeSourceTool(toolGroup,config){ve.ui.MWEditModeTool.call(this,toolGroup,config);}

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production:
https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/sandbox
Verified the fix in mw.org
Change 123825 merged by jenkins-bot:
Revert edit mode tool's onSelect method

https://gerrit.wikimedia.org/r/123825
Verified the fix on Betalabs: http://en.wikipedia.beta.wmflabs.org/wiki/Regression3rdaprilchrome
Change 123825 had a related patch set uploaded by Jforrester:
Revert edit mode tool's onSelect method

https://gerrit.wikimedia.org/r/123825
Change 123806 merged by jenkins-bot:
Revert edit mode tool's onSelect method

https://gerrit.wikimedia.org/r/123806
Change 123806 had a related patch set uploaded by Alex Monk:
Revert edit mode tool's onSelect method

https://gerrit.wikimedia.org/r/123806
Change 123806 had a related patch set uploaded by Alex Monk:
Revert edit mode tool's onSelect method

https://gerrit.wikimedia.org/r/123806
also repro'd on test2wiki
Video showing issue

Chrome Version 33.0.1750.152

1. Access spelling suggestion from right click menu
2. characters begin to be deleted (video attached)
or
3. Page content becomes corrupted, strange character insertions, loss of formatting. (image attached)

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Mac OS X 10.9
**Platform**: Macintosh
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50822

**Attached**: {F13521}
Agreed, we've fixed this.
Could not reproduce the problem on https://cs.wikipedia.org/wiki/Wikipedista:Malyacko/Sandbox?veaction=edit with Chrome 40 on Fedora 21.
Could not reproduce either by randomly trying on https://en.wikipedia.org/w/index.php?title=Kintsugi&veaction=edit
Only one insertion/string replacement (as expected).

Is this still an issue nowadays?
Created attachment 15013
random character insertion and lack of formatting.

**Attached**: {F13522}
Screenshot

Steps to reproduce:

1.Select an image
2.Click on Cite> Website/Book/Newspaper/Journal 

Observed Result:
It throws an error: Uncaught TypeError: Object #<VeDmMWBlockImageNode> has no method 'getInternalItem' 

and VE gets stuck at this point, as you cannot close that dialog anymore

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: FF 25
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/Pageoffseterror?veaction=edit

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

**Attached**: {F13484}
Verified the fix on Betalabs:http://en.wikipedia.beta.wmflabs.org/wiki/Test63452?veaction=edit
Works for me now, both locally and on beta labs.
After the fix, now the Cite dialogs does not open at all after selecting any image or any other mentioned nodes.
Therefore reopening the bug and changing the title of the bug .
Change 123124 merged by jenkins-bot:
Correctly insert or update citations based on template option

https://gerrit.wikimedia.org/r/123124
Change 123124 had a related patch set uploaded by Catrope:
Correctly insert or update citations based on template option

https://gerrit.wikimedia.org/r/123124
Should be resolved by I34a5a2da576247f4046da45f742bccc3cec22c5a

Specifically, the error is caused by calling getInternalItem on the node without checking if it's a ve.dm.MWReferenceNode. This patchset introduces an instanceof check.
It happens if you select a gallery/Math formula/template/reflist and then try to open any of the cite options
Intention:
Correct the spelling of a word

Steps to Reproduce:
1. Open a page in Chrome.

2. Pick a word that Chrome believes is misspelled.

3. Right-click to correct the spelling.

4. Save the page and check the diff.

Actual Results:  
Trying to change "Minories" to "Minorities" resulted in the missing "ti" being added at the very top of the page, rather than in the proper place.  (See http://en.wikipedia.org/w/index.php?title=User:Edgepedia/sandbox1&diff=next&oldid=602158018)



Reproducible: Didn't try

This may be related to Bug 50822 or Bug 59748.  

Reported in Chrome Version 33.0.1750.154 m on Windows 7 using Vector.  Cannot be reproduced in Safari 6 (although there are other spelling problems in Safari.)

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50822
In that case, marking as FIXED in that release. Unsatisfying, but…
According to a post on frwiki VE feedback page:

If you look at abuse filter 216, problem stopped to happen on June 19th, just after 1.24wmf9 being deployed, so probably a bug fixed in this release (in UTC+2 for Paris):
14h38 - 128.179.139.136
15h08 - 91.183.82.40
16h26 - 92.94.142.126 (not save)
19h00 - 195.101.137.28
19h22 - 195.101.137.28
20h35 - 87.90.125.24
20h35 - 90.32.27.10
21h12 - 41.189.42.250
23h07 - 1.24wmf9 on WP:fr [2]

[1] https://fr.wikipedia.org/w/index.php?title=Spécial:Journal_du_filtre_antiabus&wpSearchFilter=216
[2] https://wikitech.wikimedia.org/wiki/Server_admin_log
This was happening in new versions of chrome as recently as a month ago, I can no longer reproduce.
Might this be caused by ancient versions of Firefox/Chrome caused in part by some config of frwiki, or a bug in their dictionary app, or something?
Can't reproduce in FF or Chrome...
It's still happening, several times a day on frwiki. If you need examples, there's an abuse filter set in place in frwiki that catches some of the problems

https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:Journal_du_filtre_antiabus&wpSearchFilter=216
Just a note that this is still happening: https://www.mediawiki.org/w/index.php?diff=prev&oldid=997038
This is also an active bug for Firefox users, tested on FF 28.  Same steps to reproduce as above, same result (the corrected characters are added to both the word highlighted by the spellchecker, and the top of the document)

Note: the unwanted text can be removed with the "Undo" button. However, you can't "Undo" your spelling correction, undo goes grey after the first action)
*** Bug 63652 has been marked as a duplicate of this bug. ***
Screenshot

Steps to reproduce:

1.Open a page with VE

2.Insert a link

3.Now add a space and then a text next to it

4.Now delete the space and concatenate the text with the exiting link

5.Select the previous link and the text together

6.Re-apply the link 


Observed Result:
The new link does not get applied and "Save Page" button remains disabled 



See the screenshot attached


Test Environment: https://test2.wikipedia.org/
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5 
Page:https://test2.wikipedia.org/wiki/1staprilChrome?veaction=edit

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

**Attached**: {F13327}
Change 125019 merged by jenkins-bot:
Fix covering annotations logic

https://gerrit.wikimedia.org/r/125019
Change 125019 had a related patch set uploaded by Esanders:
Fix covering annotations logic

https://gerrit.wikimedia.org/r/125019
The fix is not working for the following cases:

Case 1:

Steps to reproduce:

1.Open a page with VE

2.Insert a link where the target is an existing page

3.Now add a space and then a text next to it

4.Save the page

5.Reopen the page

6.Now delete the space

7.Select the previous link and the text together

8.Re-apply the link where the link target is a new page


Case 2:

Steps to reproduce:

1.Open a page with VE

2.Insert a link where the link target is a new page

3.Now add a space and then a text next to it

4.Save the page

5.Reopen the page

6.Now delete the space

7.Select the previous link and the text together

8.Re-apply the link where the link target is a different new page

Case 3:

1.Open a page with VE

2.Insert a link where the target is a new page

3.Now add a space and then a text next to it

4.Save the page

5.Reopen the page

6.Now delete the space

7.Select the previous link and the text together

8.Re-apply the link where the link target is an exiting page

In all the above three cases , the link does not get applied to the concatenated text
I can still reproduce it on Betalabs.So, reopening it.
Change 124006 merged by jenkins-bot:
Apply annotations to partially annotated selections

https://gerrit.wikimedia.org/r/124006
Change 124006 had a related patch set uploaded by Esanders:
Apply annotations to partially annotated selections

https://gerrit.wikimedia.org/r/124006
This happens even if you dont delete the space and just select both the link and the text and then re-apply a new link.
So the problem is:

If you select text that is partially linked and partially not linked (in this specific case, the first part is linked and the second part isn't), then open the link inspector, we inspect the existing link but don't extend the link. If you then close the inspector without changing the target, nothing happens, but if you close the inspector with a changed target, the link is extended.

So I guess that on opening the link inspector, we should aggressively extend the link?
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert a Cite Web or Cite Book
3.Click on Show options to get the advanced widget


Observed Result:
Parameter icons inside transclusion dialog are overlapping with the parameter name

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**: {F13392}
Verified the fix in betalabs and test2
Should now be fixed in production too.
Change 121417 merged by jenkins-bot:
Move padding rules for OutlineItemWidget from core to skins.

https://gerrit.wikimedia.org/r/121417
Change 121417 had a related patch set uploaded by Catrope:
Move padding rules for OutlineItemWidget from core to skins.

https://gerrit.wikimedia.org/r/121417
Screenshot

Steps to reproduce:

1.Create a page with VE
2.Add a bullet list
3.Add few items
4.Now change the list to numbered list
5.The cursor gets shifted to the start of the document
6.Now type something

Observed Result:
Everything starts to behave weirdly .It starts to add text everywhere at the beginning of the page.The list disappears.

See the screenshot attached.

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Page:https://test2.wikipedia.org/w/index.php?title=Checkcursorbullet&veaction=edit

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

**Attached**: {F13373}
Verified the fix in production
Verified the fix on mediawiki.org
Verified the fix on Betalabs
Change 123488 merged by jenkins-bot:
Restore selection after ListAction too

https://gerrit.wikimedia.org/r/123488
Change 123488 had a related patch set uploaded by Catrope:
Restore selection after ListAction too

https://gerrit.wikimedia.org/r/123488
Created attachment 14999
snowman!!

**Attached**: {F13374}
Also, got the following error one time and the snowman while typing after changing the bullet list to numbered list:
Uncaught Error: Invalid retain length, cannot retain backwards:-1
The errors that appears in the console are:
Uncaught Error: Unbalanced set of replace operations found
Uncaught Error: ve.dm.Document.getNodeFromOffset(): offset 26 is out of bounds
https://gerrit.wikimedia.org/r/#/c/83221/ added a parameter to newarticletext, but VE doesn't pass it, so now when you try to use VE on a nonexistent page with vanilla messages (enwiki's newarticletext message doesn't use $1) you see a raw $1 in the edit notice.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 121251 merged by jenkins-bot:
Update use of newarticletext for added parameter

https://gerrit.wikimedia.org/r/121251
Change 121251 had a related patch set uploaded by Alex Monk:
Update use of newarticletext for added parameter

https://gerrit.wikimedia.org/r/121251
screenshot

Steps to reproduce:


1.Open a page with VE
2.Open the math inspector
3.Keep it open
4.Insert an image
5.Select the image
6.Click on undo 
7.Click on the media settings icon that is still appearing at the right corner of the page

Observed Result:

The Media Settings dialog box appears with empty caption field .An error appears in the console: 
Uncaught TypeError: Object #<VeDmMWMathNode> has no method 'getCaptionNode'

Also, you will not be able to close the Media Settings dialog box and will get stuck at this step.


See the screenshot attached.

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/User:RYasmeen_%28WMF%29?veaction=edit

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

**Attached**: {F13323}
Yes, Checked in production,appears to be fixed.
I believe that this is now fixed – please confirm.
This seems to be because MediaEditDialog is launched for an MWMathNode, which shouldn't be possible. Assigned to Trevor as the fact that we even got here is a bug in the tools system.

MediaEditDialog also shouldn't crash in this case, but Moriel is already going to merge the insertion and edit dialogs, so that should take care of that issue.
The citation tool recongizes a citation template that starts like this:

<ref>{{cite web|url= 

It does not recognize one that starts like this:

<ref>{{cite web |url=

The only difference is the (very common) addition of a space before the parameter.  It should understand both of these.

--------------------------
**Version**: unspecified
**Severity**: minor
I fixed this in https://gerrit.wikimedia.org/r/#/c/132725/ without realizing it.
Intention:
Edit an existing reference

Steps to Reproduce:
1. Open any article containing an existing citation in Firefox.  (I can't reproduce this in Safari.)

2. Open an existing reference.

3. Look at the "Options" area.

Actual Results:  
The icon overlaps with the text.  See screenshot.


Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: trivial
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63433
https://bugzilla.wikimedia.org/show_bug.cgi?id=63432
*** Bug 63433 has been marked as a duplicate of this bug. ***
*** Bug 63432 has been marked as a duplicate of this bug. ***
Created attachment 14915
Screenshot showing misaligned icon and labels

**Attached**: {F13315}
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Click on  Insert> Formula
3.Insert a formula inside then delete it 

Observed Result:
An empty selection box appears

Test Environment: https://test2.wikipedia.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5

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

**Attached**: {F13248}
Verified the fix in production
As per Ed, the initial empty selection box appearing on opening Math inspector is not related with this issue.So creating a separate bug for it and closing this one.
This bug is partially fixed, the empty selection box is still appearing when you first open the Math Inspector.
Verified the fix on Betalabs and test2
Change 122602 merged by Physikerwelt:
Emit rerender on math node if Tex image is not present

https://gerrit.wikimedia.org/r/122602
Change 122602 had a related patch set uploaded by Esanders:
Emit rerender on math node if Tex image is not present

https://gerrit.wikimedia.org/r/122602
Steps to reproduce:

1.Open a page with VE
2.Insert a gallery or a Link inspector
3.Edit something and close the inspector, this will make the save page button disabled

4.Now again reopen that inspector and make further changes but do not close the inspectors .

5.Click on the already active "Save Page" button

Observed Result:
The modified content of step 4 also gets saved even though user did not close the inspector to save it.

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65
OS: MAC OS X 10. 8. 5 
Page:https://test2.wikipedia.org/wiki/24thmarchrome?veaction=edit

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 51439 ***
This is intended behavior but should be made clearer to the user. Perhaps clicking the save button should close the inspector? Or clicking anywhere in the surface+toolbar should close the inspector?
Screenshot

Steps to reproduce:

1.Open a new page with VE
2.On this empty page select any option under Cite 

Observed Result:

The dialog box for cite options are appearing as empty dialog box 
After a long time , the required parameters for Cite options appear

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Another24Marchrome&veaction=edit

--------------------------
**Version**: unspecified
**Severity**: enhancement

**Attached**: {F13128}
It shouldn't be very long (but that's a different issue), but we've now fixed this by adding a loading animation to dialogs
Without any required parameters

Steps to reproduce:


1,Open a page with VE
2.Insert a reference
3.Open the reference dialog box select any option under Cite (Website/Book/Newspaper/Journal)

Observe Result:
None of the required parameters are showing up , in all cases the dialog to add a transclusion comes up.


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 
Page:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Another24Marchrome&veaction=edit

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

**Attached**: {F13118}
Change 121266 merged by jenkins-bot:
Make cite transclusion tools actually work

https://gerrit.wikimedia.org/r/121266
Change 121266 had a related patch set uploaded by Catrope:
Make cite transclusion tools actually work

https://gerrit.wikimedia.org/r/121266
It is not related with Beta Labs being slow yesterday.I can still reproduce it.
This was caused by Beta Labs melting; now working again. Ish.
Created attachment 14898
how it appears on CE with the required parameters

**Attached**: {F13119}
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Add a reference

Observed Result:

Uncaught TypeError: Cannot read property 'keyedNodes' of undefined appears in the console and VE gets unresponsive

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 
Page: http://en.wikipedia.beta.wmflabs.org/wiki/24thMarchrome?veaction=edit

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

**Attached**: {F13105}
Verified the fix in Betalabs:http://en.wikipedia.beta.wmflabs.org/wiki/Another24Marchrome?venotify=created
Change 120613 merged by jenkins-bot:
Update reference's internal item after inserting reference

https://gerrit.wikimedia.org/r/120613
Change 120613 had a related patch set uploaded by Catrope:
Update reference's internal item after inserting reference

https://gerrit.wikimedia.org/r/120613
Screenshot

Steps to reproduce:

Just open the Keyboard shortcut page

Observed Result: See the screenshot attached

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

**Attached**: {F13057}
Change 357808 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/extensions/Popups@master] Handle Restbase HTML response

[[https://gerrit.wikimedia.org/r/357808]]
Verified the fix in Betalabs:http://en.wikipedia.beta.wmflabs.org/wiki/26thmarChrome?veaction=edit
Change 121264 merged by jenkins-bot:
Bring CommandHelpDialog CSS back

https://gerrit.wikimedia.org/r/121264
Change 121264 had a related patch set uploaded by Catrope:
Bring CommandHelpDialog CSS back

https://gerrit.wikimedia.org/r/121264
Some CSS paths changed, maybe that's what broke this.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Add a text
3.Try to Save the page


Observed Result:
An error appears : Uncaught TypeError: Cannot call method 'teardown' of undefined
The page seems to be in readmode but the cursor still appears on the page

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 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/Toc_issue

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

**Attached**: {F12876}
Verified the fix in betalabs
Change 120070 merged by jenkins-bot:
Fix a typo that causes crashes when using the wrong symbol for mwTocWidget

https://gerrit.wikimedia.org/r/120070
Change 120070 had a related patch set uploaded by Jforrester:
Fix a typo that causes crashes when using the wrong symbol for mwTocWidget

https://gerrit.wikimedia.org/r/120070
Oops... I meant:

if ( this.surface.mwTocWidget ) {
    this.surface.mwTocWidget.teardown();
}
This error has to do with code that looks like this:

if ( this.surface.mwTocWidget ) {
    this.mwTocWidget.teardown();
}

which needs to be rewritten to look like:


if ( this.surface.mwTocWidget ) {
    this.mwTocWidget.surface.teardown();
}
This will alert us to things going wrong quickly. Hopefully. (Yes, there's a risk of noise, but there should be 0 of these, anyway.)

--------------------------
**Version**: unspecified
**Severity**: enhancement
(In reply to Elitre from comment #7)
> The tag vepawns, i.e. :
> https://en.wikipedia.org/w/index.php?title=Special:
> RecentChanges&tagfilter=vepawns .

That's not done by VisualEditor; these must be a local AbuseFilter written by the community…
The tag vepawns, i.e. : https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&tagfilter=vepawns .
What filter?
@Alex, that filter doesn't seem to be catching anything, I have no idea if it's still functional or not, that's why I asked.
Went with approach #3, it's a python script run under the 'wm-ve-needcheck-reporter' service user in tool labs. Cron set up to run every day at 16:30 (UTC).

(In reply to Elitre from comment #3)
> Should vepawns edits be tracked as well?
Perhaps we should have a separate bug for this - it sounds like a good idea to mark edits which add new pawn characters to the page as needcheck
Should vepawns edits be tracked as well?
As I said in IRC, option 3 seems sanest to me, but that's not really my call as I'm not the one that'll write it. :-)
Intention:
Tab through the fields in a pre-existing infobox

Steps to Reproduce:
1. In Firefox 27, open a page that contains an infobox.

2. The cursor is (should be) in the first parameter, which should light up with a blue border.  Press the tab key. 

3. Where is the cursor now?

4. Repeat.


Bonus:  When you get nearly to the end of the template, use the mouse or arrow keys to click back in the first parameter.  Press tab.  The cursor should be in parameter #2, but sometimes it goes to the parameter after your pre-click location.

Actual Results:  
You sometimes have to tab twice to get from parameter #1 to parameter #2.  If you do, then select-all from the keyboard will select the TemplateData descriptions.


Reproducible: Sometimes

I was unable to reproduce this in Safari.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 125894 merged by jenkins-bot:
Only blur inputs within booklet pages when moving away

https://gerrit.wikimedia.org/r/125894
Change 125894 had a related patch set uploaded by Trevor Parscal:
Only blur inputs within booklet pages when moving away

https://gerrit.wikimedia.org/r/125894
This is probably Firefox not respecting tab-index: -1; or something. Eurgh.
From bug 50945#c3

| However my testing showed that this was not reliable and sometimes resulted
| in odd wikicode, e.g. [[Ecuador|<nowiki/>]][[Egypt|E]][[Egypt|gypt]] when
| changing "Ecudor" to "Egypt".
| 
| See https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox&diff=563097916&oldid=563090562

<p><a rel="mw:WikiLink" href="./Ecuador" ></a><a rel="mw:WikiLink" href="./Egypt">E</a><a rel="mw:WikiLink" href="./Egypt">gypt</a></p>

--------------------------
**Version**: unspecified
**Severity**: normal
We /believe/ that this may have been fixed this week; provisionally closing as such.
Introduce artificial delays in your API modules (sleep(2); at the top of ApiOpenSearch::execute() and ApiQueryInfo::execute(); alternatively, you can try this in production if you're quick enough), then perform the following steps quickly:

1. Inspect an existing link
2. Change its target
3. Before the API request completes, close the link inspector by clicking out or clicking the back arrow
4. Inspect the link again

Expected: new target shows in inspector
Actual: old target shows

With the keyboard it's even weirder:

1. Inspect an existing link
2. Type "foo". Wait for the API request to come back and display suggestions
3. Type "bar" at the end (so you now have "foobar"), then quickly (before the API call comes back) press Enter.
4. Expected: inspector closes. Actual: input value is reset to "foo"
(At least if you press Enter again, "foo" is actually saved.)

You can work around this and still reproduce the first bug:

1. Inspect an existing link
2. Type "foo"
3. If a suggestion box is displayed (perhaps because "f" was in cache, or because the previous value was in cache), press Esc to dismiss it
4. Press Enter, the inspector closes
5. Inspect the link again

Expected: "foo"
Actual: previous value

--------------------------
**Version**: unspecified
**Severity**: normal
This looks like it's now been fixed. I think.
In afterDocumentKeyPress, setResizableHandlesSizeAndPosition() is called and measures and repositions all ResizableNode resize handles, even though they're not even visible. This is wasteful.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Fixed in gerrit Ia6cf8de0da0.
This was fixed at some point. setResizableHandlesSizeAndPosition() is now attached to the 'position' event on focus and detached on blur.
The error

Steps to reproduce:


1.Open a page with VE which has slug in it
2.Place your cursor in the slug and open the math inspector
3.Now type something inside the math inspector


Observed Issue 1: 
It throws an error:
Cannot call method 'update' of null

And if you insert the math function and save the page and then go to edit source , you will see an empty math rag has also been added to the page

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:RYasmeen_(WMF)&action=edit

See the screenshots attached

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

**Attached**: {F13147}
*** This bug has been marked as a duplicate of bug 58286 ***
Confirming still occurring.
Created attachment 14851
The empty math tag

**Attached**: {F13148}
Steps to reproduce:

- go to http://en.wikipedia.beta.wmflabs.org/wiki/Snail
- edit the page with visual editor
- highlight text "animal"
- click Hyperlink tool
- paste http://en.wikipedia.beta.wmflabs.org/wiki/Animal into Hyperlink tool
- the link goes out of Hyperlink tool box (see attached screen shot)

--------------------------
**Version**: unspecified
**Severity**: normal
Oh, yeah, we fixed this in the inspector styling tweaks in April, I think.
Works for me. Did this get fixed at some point since this bug was filed?
Created attachment 14849
hyperlink tool

**Attached**: {F13143}
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Open the link inspector 
3.Now enter something invalid for link inspector , for example: File:Joo Chiat Place.jpg|Item 1

Observed Result:

An error message appears for invalid page title , the style of the error message should be much more apparent like red 

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

**Attached**: {F13049}
Nice!
All patches mentioned in this report were merged or abandoned - is there more work left to do here (if yes: please reset the bug report status to NEW or ASSIGNED), or can you close this ticket as RESOLVED FIXED?
Change 150297 merged by jenkins-bot:
MWLinkTargetInputWidget: Add styles for invalid link titles

https://gerrit.wikimedia.org/r/150297
Change 150297 had a related patch set uploaded by Palerdot:
Fixed Bug 62761, added invalid link title style.

https://gerrit.wikimedia.org/r/150297
Comment on attachment 16097
Screenshot of Fix for Bug 62761

The color in the screenshot is red. I have changed the color to #d45353 to match the other warning elements in the mediawiki page.
Screenshot of Fix for Bug 62761

This is the screenshot of the fix I have made for the bug 62761. The gerrit patch link is https://gerrit.wikimedia.org/r/#/c/150297/

**Attached**: {F13050}
I have made a fix to this bug. The gerrit patchset link is https://gerrit.wikimedia.org/r/#/c/150297/

Things done:
A new CSS File 
've.ui.MWLinkTargetInputWidget.css' is added to the path 'VisualEditor/modules/ve-mw/ui/styles/widgets'. Warning text style is added to the class '.ve-ui-mwLinkTargetInputWidget-warning' in this file. The CSS File is included in the style resources in the file 'VisualEditor.php'. Tested in latest stable firefox, chrome in Ubuntu 14.04.

Please review the changes. I'm new to open source contribution, So let me know if I have done the fix to the bug in the right way. Thanks.
Change 150297 had a related patch set uploaded by Palerdot:
Fixed Bug 62761, added invalid link title style.

https://gerrit.wikimedia.org/r/150297
I don't know how the user did that, but take a look at this edit:
https://pt.wikipedia.org/wiki/Esporte_Clube_Pelotas?diff=38422037

--------------------------
**Version**: unspecified
**Severity**: normal
I can't replicate; I've not seen any other reports like this; and we re-wrote this system last week. Provisionally I'm going to mark as WFM.
That's the relocatable node image marker, so it's a  drag & drop bug.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Transclusion
3.Insert a template that does not have any description.
4.For example: Country showdata for betalabs

Observed Result:
A message comes up :You are adding the "Country_showdata" template to this page. It doesn't yet have a description, but there might be some information on the template's page.

In this message , the template name used should be in more readable form that is with underscores: Country showdata

See the screenshot attached

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/User:RYasmeen_(WMF)?veaction=edit

--------------------------
**Version**: unspecified
**Severity**: trivial

**Attached**: {F12888}
This appears to have been fixed in Gerrit change 132723 by Bartosz
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Place the cursor in a slug
3.Press tab

Observed Result:
An error appears in the console:
Uncaught TypeError: Cannot call method 'getParent' of null
ve.Document.getCoveredSiblingGroups
ve.ui.IndentationAction.increase
ve.ui.Surface.execute
ve.ui.Command.execute
ve.ui.Surface.execute
ve.ce.Surface.onDocumentKeyDown
proxy load.php:10
ve.EventSequencer.onEvent
(anonymous function)
jQuery.event.dispatch load.php:45
elemData.handle.eventHandle

Test Environment: production
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5 
Page:https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/sandbox?veaction=edit

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

**Attached**: {F12844}
Verified the fix on test2:https://test2.wikipedia.org/wiki/Wmf19?veaction=edit
Verified the fix on Betalabs:http://en.wikipedia.beta.wmflabs.org/wiki/User:RYasmeen_(WMF)?veaction=edit
Change 119045 merged by jenkins-bot:
Don't try to return the document in getCoveredNodes

https://gerrit.wikimedia.org/r/119045
Change 119045 had a related patch set uploaded by Esanders:
Don't try to return the document in getCoveredNodes

https://gerrit.wikimedia.org/r/119045
When resizing the window with an inspector open, it continuously flickers and flashes blank, sometimes making a slow, fast or partial fade in/out, others when you let go of the resize handle it does a bunch of flashes in burst (as if they were queued up).

Screen capture: http://cl.ly/0g2F0q2D3p1D

Seems to relate to code that adds/removes the "oo-ui-popupWidget-transitioning" class.

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed a couple of weeks ago by Trevor.
(In reply to Krinkle from comment #0)
> Screen capture: http://cl.ly/0g2F0q2D3p1D

This also exposes bug 55789, though these flashes are not caused or related to (absence of) the logic to reposition the overlay elements themselves.
Seen often in browser tests run locally and on Cloudbees, this happens: 


* default status of Beta toggle is OFF
* click Beta toggle to ON
* click Save

* get error: "Error saving settings. Please make sure that you have cookies enabled"

* Beta toggle goes back to OFF
* test fails


I have not yet triggered this manually. (but I haven't tried that hard either)

--------------------------
**Version**: unspecified
**Severity**: normal
Change 126873 merged by jenkins-bot:
Use core token handling

https://gerrit.wikimedia.org/r/126873
Change 126873 had a related patch set uploaded by Jdlrobson:
Use core token handling

https://gerrit.wikimedia.org/r/126873
(In reply to Jon from comment #64)
> We deep dived this issue again and concluded we should remove getMobileToken
> in favour of user->getToken
> 
> Chris says that soon anonymous editors will get a unique token when that is
> called.

Out of curiosity, is there a timeline for this?

> In mean time there is a CSRF risk to anons using Special:MobileOptions but
> we decided since risk was low we can live with this.

This makes sense to me since this would only be an issue for anons. I'm ok with it so long as Chris S is OK with it.
We deep dived this issue again and concluded we should remove getMobileToken in favour of user->getToken

Chris says that soon anonymous editors will get a unique token when that is called.

In mean time there is a CSRF risk to anons using Special:MobileOptions but we decided since risk was low we can live with this.
The test for "Keep Going" registers a new account but also triggers the token-mismatch problem: https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox/493/testReport/(root)/Encourage%20new%20users%20to%20Keep%20Going/I_see_a_KeepGoing_message_after_completing_my_VisualEditor_edit/
For reference, history:  http://git.wikimedia.org/history/mediawiki%2Fextensions%2FMobileFrontend/f7180dc297b958a27920a88348db27104eaf10e5/includes%2FMobileContext.php;jsessionid=7rk483w9yc4w15fi1z5t8bd05

and change to MobileContext: 

http://git.wikimedia.org/blobdiff/mediawiki%2Fextensions%2FMobileFrontend/27e463c35c202607fe3023fc020c76ef41c13cd8/includes%2FMobileContext.php
There have been 8708 hits to this error in the last 30 days on our production wikis.
The problematic function seems to be MobileContext::getMobileToken
So this problem seems to only happen when the user is anonymous...
It seems that $this->getRequest()->getSessionData( 'wsMobileToken' ) is returning null which results in a new session getting setup on submitting the form which results in invalidation of the form.

Don't understand this code well enough to know if this is misbehaving and if it is why.
I set the editor_ve.feature test to log in with a different user anyway and generated the following errors in the second run of the test on my local host: 

2014-04-02 17:52:34 deployment-apache02 enwiki: SpecialMobileOptions::submitSettingsForm(): token mismatch, received 60fa1ffd7c4273c5c1e5ceeb7d44cfd2 - expected 361fda81efd0e50f37234db4384ee64e
2014-04-02 17:53:35 deployment-apache02 enwiki: SpecialMobileOptions::submitSettingsForm(): token mismatch, received 60cd4c3b308cac220e7a8629b0427056 - expected 34a28952e608764e4452a5b73b80175e
2014-04-02 17:53:50 deployment-apache02 enwiki: SpecialMobileOptions::submitSettingsForm(): token mismatch, received 60cd4c3b308cac220e7a8629b0427056 - expected 34a28952e608764e4452a5b73b80175e


Is it of interest that the last two errors have exactly the same mismatched tokens 15 seconds apart?
These tests manipulate the ON/OFF toggle settings before logging in, and each browser starts with a fresh profile on every run of every scenario.  Username should be immaterial.
Thanks Chris, that narrows down the problem significantly.

Can you rerun the tests with a different (or new) username, so we can rule out that this is a race condition with multiple tests using the same user account, or something is corrupted in the session cache?

I ran the tests from the office from my linux box, and the test (whenever they finally ran) passed without any errors. So it seems like there is either something about the user that you're using, or the network lag affecting a race condition.
From the log in beta labs on eqiad just now: 

-04-02 07:46:39 deployment-apache02 enwiki: SpecialMobileOptions::submitSettingsForm(): token mismatch, received cb9248cad0ffc2d5886f2322ac58c2f9 - expected ff97fcfc9650819e3788b20c26680d6b
2014-04-02 14:36:50 deployment-apache01 enwiki: SpecialMobileOptions::submitSettingsForm(): token mismatch, received b6752dcbd18953383d871c531d620f4c - expected a3e842905af2f624cb4511345978fdc4
https://gerrit.wikimedia.org/r/121879 added logging of token details to mobile.log
Thanks Chris. That confirms that this is different from what Jeremy posted, since his had a Location header come back from the POST request, whereas yours showed the form with the <div class="error">Error saving settings. Please make sure that you have cookies enabled.</div>.

The only codepath that sets wsMobileToken seems pretty safe, and since the Set-Cookie with enwikiSession is returned with the form, that seems pretty safe.

Could someone add a logging statement just after the token check to see what value MediaWiki thinks the mobile token is supposed to be?
Created attachment 14959
WireShark capture of error conversation


This should be the entire conversation containing the POST to MobileOptions that causes the token error. 

(I happen to have another Ubuntu laptop.  After 90 OS upgrades, installing RVM and installing Wireshark, I was able to capture the traffic on a repro of the error.)

**Attached**: {F13407}
chris steipp, it's however worth noting that we've been unable to replicate this with the above steps on OS X
(In reply to Jon from comment #46)
> This is now the main source of our failing test builds (the last 3 builds
> failed solely because of this issue)
> 
> Thanks for all the attention being given here.
> 
> I wonder if in the mean time we should alter Special:MobileOptions to use a
> preference for logged in users rather than a cookie - this would be a way of
> getting around the failures and would be a useful user facing feature - opt
> in once, get beta/alpha everywhere...

We would still have the same problem - at least in terms of setting the preference. In order to use that form, we need to set the CSRF token which requires the session/cookie. So when the form was submitted to set the preference, you would get stuck with the same behavior. I suppose though once the preference were set, the issue would be moot. It could be a stopgap measure... just as I think running the tests against FF/Chrome in OSX rather than linux/windows would be.
Is anyone able to reproduce this in the office yet? If so, I'm happy to work on this in person tomorrow. Or if someone can walk me through the steps to reproduce, I can attempt from a couple of installs I have.
This is now the main source of our failing test builds (the last 3 builds failed solely because of this issue)

Thanks for all the attention being given here.

I wonder if in the mean time we should alter Special:MobileOptions to use a preference for logged in users rather than a cookie - this would be a way of getting around the failures and would be a useful user facing feature - opt in once, get beta/alpha everywhere...
Chris, in the meantime, can we point the saucelabs test to not use Linux, perhaps to use FF/Chrome in OS X since we haven't been able to replicate the issue there?
CSteipp, Wireshark is killing my poor underspec'd laptop.  I spent a couple hours on this, but I cannot even get the test to complete or my wlan interface to stay functional with WireShark running.
Chris, can you do "follow TCP Stream" and screenshot the result? I'd like to confirm that you're NOT seeing a Location header returned in the result of that call.
The screen shot above I think shows the token-mismatch problem on the POST.  

However, the test itself behaves strangely on my local machine with WireShark running so I may have done this incorrectly
Created attachment 14943
token mismatch on POST shown in WireShark on Linux

**Attached**: {F13406}
(In reply to Jeremy L Grajales from comment #39)
> Created attachment 14914 [details]
> (Partial) Wireshark capture of editor_ve test
> 
> [attachments]
> I captured the test with Wireshark.
> The POST is obviously the first packet in the log.
> I find the same behavior as Chris does in Windows Firefox.

So in both Chris'es headers and Jeremy's pcap, there is a session cookie being sent. So that's good.

What I'm confused on is that Jeremy's pcap shows the POST to /wiki/Special:MobileOptions, and you see coming back a Location: http://en.m.wikipedia.beta.wmflabs.org/wiki/Main_Page header, which means that the inequality check in SpecialMobileOptions.php (line 208) was NOT true (i.e., the token parameter matched getMobileToken()), otherwise a form would have been returned.

Is the pcap not showing the issue? Or is this not a token issue?

**Attached**: {F13405}
**jeremygrajales** wrote:

(Partial) Wireshark capture of editor_ve test

[attachments]
I captured the test with Wireshark.
The POST is obviously the first packet in the log.
I find the same behavior as Chris does in Windows Firefox.

**Attached**: {F13405}
Requested by Chris Steipp, Request headers and stuff pulled from the Network tab in Firefox after incurring the token error (I also have the entire response that contains the error message if you need it): 

request header: 

Host: en.m.wikipedia.beta.wmflabs.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:MobileOptions?useformat=mobile
Cookie: centralnotice_bucket=1-4.2; mf_useformat=true; enwikiSession=ed4a7df6517c9aa79ce5231905291c84
Connection: keep-alive

request body: 

Content-Type: application/x-www-form-urlencoded
Content-Length: 87
enableImages=on&enableBeta=on&token=b9a06d2beb98ed9b35acded20a41e9fb&returnto=Main+Page

timings: 
Waiting 892 ms
Receiving 3 ms
**jeremygrajales** wrote:

(In reply to Arthur Richards from comment #36)
> Chris, any luck dumping those headers? I'm increasingly curious to see
> what's going on there.

What headers are you looking for at what point?
I'd like to see it on my end to see if the Windows reproduction diverges any further from the original bug.
(In reply to Chris McMahon from comment #27)
> I chatted with Chris Steipp about this a bit: 
> 
> (03:53:51 PM) csteipp: So yeah, either the user doesn't have a session,
> wsMobileToken in the session is getting overwritten, or the form isn't
> correctly sending the token
> 
> <Antoine restarts all the caches on beta labs>
> 
> (04:06:19 PM) csteipp: chrismcmahon: Yeah, times out for me. So the thing is
> to narrow down which of those 3 is happening. A header capture of a failure
> would help determine that.
> 
> I'll look into getting those headers with WireShark or something.

Chris, any luck dumping those headers? I'm increasingly curious to see what's going on there.
Change 120959 abandoned by Jdlrobson:
See if sleeping helps avoid token issues on Special:MobileOptions

Reason:
Thanks to Jeremy L Grajales we can confirm this doesn't have any effect. Back to drawing board.

https://gerrit.wikimedia.org/r/120959
**jeremygrajales** wrote:

(In reply to Gerrit Notification Bot from comment #32)
> Change 120959 had a related patch set uploaded by Jdlrobson:
> See if sleeping helps avoid token issues on Special:MobileOptions
> 
> https://gerrit.wikimedia.org/r/120959
I get the same behavior as before with the patch using Firefox on Windows.
**jeremygrajales** wrote:

(In reply to Gerrit Notification Bot from comment #32)
> Change 120959 had a related patch set uploaded by Jdlrobson:
> See if sleeping helps avoid token issues on Special:MobileOptions
> 
> https://gerrit.wikimedia.org/r/120959
I get the same behavior as before with the patch using Firefox on Windows.
Change 120959 had a related patch set uploaded by Jdlrobson:
See if sleeping helps avoid token issues on Special:MobileOptions

https://gerrit.wikimedia.org/r/120959
**jeremygrajales** wrote:

(In reply to Jon from comment #30)
> If the opt into alpha happens after login does this resolve the issue? I
> wonder if it's something particularly strange with opting in whilst
> anonymous...

Don't you mean the opt into beta?
And this is something I thought of before.
I tried this manually, and anon or logged-in works fine.

Not sure about running an automated test. But I do not have enough experience editing tests to attempt this fix you suggest. If someone could show me how to do it, I'd love to try it out. But someone else would probably have the chance to do it before I got the chance to learn how to.
If the opt into alpha happens after login does this resolve the issue? I wonder if it's something particularly strange with opting in whilst anonymous...
**jeremygrajales** wrote:

(In reply to Jon from comment #9)
> If someone can help me get Chrome driver setup maybe I can find a way around
> this... does delaying the opt in event with a wait help at all Chris?

I also added a "sleep 5" below line 79 in common_steps.rb to see if that would resolve anything. Not sure if that is what you were suggesting to do. 

But
(In reply to Jeremy L Grajales from comment #28)
adding that delay didn't change any of the previous results on Firefox (Windows).

(In reply to Chris McMahon from comment #27)
> (03:53:51 PM) csteipp: So yeah, either the user doesn't have a session,
> wsMobileToken in the session is getting overwritten, or the form isn't
> correctly sending the token

I think this is heading in the right direction. My only objection to this is that when I attempt to reproduce this manually, everything works fine. This seems like a test handling error and not a session issue. Wouldn't a session issue affect all tests manual/automated?
**jeremygrajales** wrote:

I tested this on Firefox (Windows).
http://pastebin.com/yi9FGPVU

Seems to reproduce the  same issue.
Although, I'm not sure.

Visually:
The browser gets to the settings page. 
Toggles beta switch ON.
Saves settings.
And when the page refreshes, the beta button is toggled to OFF.


No obvious HTML errors are displayed as reported previously (ie. red text in the browser warning of disabled cookies).
I chatted with Chris Steipp about this a bit: 

(03:53:51 PM) csteipp: So yeah, either the user doesn't have a session, wsMobileToken in the session is getting overwritten, or the form isn't correctly sending the token

<Antoine restarts all the caches on beta labs>

(04:06:19 PM) csteipp: chrismcmahon: Yeah, times out for me. So the thing is to narrow down which of those 3 is happening. A header capture of a failure would help determine that.

I'll look into getting those headers with WireShark or something.
(In reply to Arthur Richards from comment #23)
> I agree with Max, in this case a race condition doesn't make sense due to
> the nature of PHP. However, it is conceivable that there are occasional
> hiccups/something going wrong with session storage on the cluster. If that
> were the case though, I would expect we would hear about more things like
> this happening - that said, it is probably worth checking into since this
> has been persistent and we have not been able to adequately explain it
> otherwise.


After chatting a bit with Chris today, I wonder if the problem is related to the platform and/or platform/browser combo. The jobs on sauce labs run in FF/Chrome on Linux - and when Chris tests locally he does so with a Linux box. AFAIK everyone else who has not been able to replicate this problem has been testing from a Mac.
Jeremy if you (In reply to Jeremy L Grajales from comment #24)
> Is there anything I could do to attempt to replicate this on my end?

Thanks Jeremy - if you don't have it set up already, the first thing to do would be to get MediaWiki and MobileFrontend setup and working. You would also need to install a few other extensions - ConfirmEdit (enable FancyCaptcha), GeoData, Echo, PageImages, VisualEditor (and get parsoid installed/running as well).

Then, you'd need to get your browser testing environment set up (https://www.mediawiki.org/wiki/Quality_Assurance/Browser_testing/Running_tests), and be sure to follow MobileFrontend-specific instructions in MobileFrontend/tests/browser/README.mediawiki

If you run into any problems, let us know and we can probably help you out. If you join #wikimedia-mobile on IRC (Freenode), you can usually get support faster than via Bugzilla.
**jeremygrajales** wrote:

Is there anything I could do to attempt to replicate this on my end?
I agree with Max, in this case a race condition doesn't make sense due to the nature of PHP. However, it is conceivable that there are occasional hiccups/something going wrong with session storage on the cluster. If that were the case though, I would expect we would hear about more things like this happening - that said, it is probably worth checking into since this has been persistent and we have not been able to adequately explain it otherwise.
I think the fact that this is passing anywhere is an environment issue.  

Same error happened twice in Firefox in the build just hours ago: https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox/438/
As stated before, I really thing this is an environment issue. Chris what else might be different in your setup to us?
Chris, these are synchronous operations, it's really hard to do stufff in parallel in PHP:) So no race condition.
Seems like a race condition in lines 204-208 of SpecialMobileOptions.php in submitSettingsForm. 

As I read this: 

* submitSettingsForm calls out to do "$context = MobileContext::singleton();" and also "$request = $this->getRequest();"

** both of these must take time

* then the code immediately compares tokens with "if ( $request->getVal( 'token' ) != $context->getMobileToken() )"  

It seems to me like submitSettingForm should wait for both $request and $context to complete before comparing values obtained from those operations.
Yep but still unable to replicate this bug in any way either locally or on beta labs...
(In reply to Jon from comment #9)
> If someone can help me get Chrome driver setup maybe I can find a way around
> this... does delaying the opt in event with a wait help at all Chris?

Jon, did you manage to get chromedriver working on your machine?
and here is the same problem in Firefox, so it is not only Chrome:  https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox/430/testReport/(root)/VisualEditor/Toolbar_VisualEditor/
ChromeDriver (v2.9.248304)

but that has nothing to do with the problem.
I understand - I can see this in the browser test screencast but I'm not seeing this so your environment must be setup slightly different to mine?

What version of Chrome Driver are you using?
Created attachment 14852
error saving settings

**Attached**: {F13404}
I understand but I ran exactly the same test 6 times and can't replicate this. This always passes for me.

What version of Chrome Driver are you using?
I got the problem the first time I ran, on the second scenario: 

$ bundle exec cucumber features/editor_ve.feature 
@en.m.wikipedia.beta.wmflabs.org @login @test2.m.wikipedia.org
Feature: VisualEditor

  Scenario: Toolbar VisualEditor                      # features/editor_ve.feature:4
    Given I am in alpha mode                          # features/step_definitions/common_steps.rb:77
    And I am logged into the mobile website           # features/step_definitions/common_steps.rb:10
    And I am on the "Selenium Edit Test" page         # features/step_definitions/common_steps.rb:88
    When I click the edit button                      # features/step_definitions/editor_steps.rb:7
    Then I see the VisualEditor overlay               # features/step_definitions/editor_ve_steps.rb:9
    And I see a toolbar in the overlay header         # features/step_definitions/editor_ve_steps.rb:17
    And The VisualEditor toolbar has a bold button    # features/step_definitions/editor_ve_steps.rb:21
    And The VisualEditor toolbar has an italic button # features/step_definitions/editor_ve_steps.rb:25

  Scenario: I can edit a page using VisualEditor # features/editor_ve.feature:14
    Given I am in alpha mode                     # features/step_definitions/common_steps.rb:77
      timed out after 5 seconds, waiting for {:class=>"mw-mf-settings-off", :tag_name=>"span"} to become present (Watir::Wait::TimeoutError)
      ./features/step_definitions/common_steps.rb:82:in `block (3 levels) in <top (required)>'
      ./features/step_definitions/common_steps.rb:81:in `block (2 levels) in <top (required)>'
      ./features/step_definitions/common_steps.rb:78:in `/^I am in alpha mode$/'
      features/editor_ve.feature:15:in `Given I am in alpha mode'

<snip>

$ date
Tue Mar 18 11:35:44 MST 2014


And in the browser I can clearly see the red error message "Error saving settings. Please make sure that you have cookies enabled"
I have run this 6 times locally against beta labs with the latest ChromeDriver (v2.9.248307) and all passed.

I'm still not sure what's going on here.
If someone can help me get Chrome driver setup maybe I can find a way around this... does delaying the opt in event with a wait help at all Chris?
To the extent that it is an issue with Selenium, the speed of the test between clicking the "ON" toggle and the "Save" button is probably triggering a race condition that is difficult to trigger manually.

But if I run "editor_ve.feature" with the "Given I am in alpha mode" step 3 times on my local environment pointed to beta labs, I'll get the error 1 or 2 times.
I wonder if it's possibly an issue with Selenium? This is not something I've been able to repro either and certainly not something I've experienced locally or in production.
Max, for me when I run the browser test "editor_ve.feature" (or any test with the step "Given I am in alpha mode") against beta labs,  I see the "Error saving settings. Please make sure that you have cookies enabled" pretty often, but not always.
Chris, how do I repro this problem locally?
I've not been able to replicate this issue myself. However if there is a bug it's going to be in getMobileToken - the only time when this error should happen is if the token in the settings form differs from the result of getMobileToken

Max any ideas to why this might happen?
As I said originally, this is pretty easy to repro locally, it is not just Cloudbees builds.
This looks like an issue on Cloudbees. The error shows only when cookies are disabled. Are we able to say with 100% certainty Cloudbees is not doing something funky?
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1770
After moving the image

Steps to reproduce:

1.Open a page with VE
2.Insert a thumbnail image
3.Move the image from Right to left
4.Again move the image from right to left

Observed Result:
Moving the image from Left to Right or Right to Left changes the size of the image in the VE mode


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
Page:http://en.wikipedia.beta.wmflabs.org/wiki/Test_62581?veaction=edit

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

**Attached**: {F13293}
Verified the fix in production:https://en.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/sandbox&veaction=edit
Change 118601 merged by jenkins-bot:
Fix regression bug 'default size' change on alignment

https://gerrit.wikimedia.org/r/118601
Change 118427 merged by jenkins-bot:
Fix regression bug 'default size' change on alignment

https://gerrit.wikimedia.org/r/118427
Change 118601 had a related patch set uploaded by Catrope:
Fix regression bug 'default size' change on alignment

https://gerrit.wikimedia.org/r/118601
Change 118427 had a related patch set uploaded by Mooeypoo:
Fix regression bug 'default size' change on alignment

https://gerrit.wikimedia.org/r/118427
Created attachment 14797
Before moving the image

**Attached**: {F13294}
1. Edit a document containing a block image
2. Click on the block image
3. Press delete
4. The selection looks odd

Inspection of the DM selection shows that it now covers [/paragraph, paragraph].

--------------------------
**Version**: unspecified
**Severity**: minor
This looks OK now… assuming that Ed fixed it. Go Ed.
Intention:
Edit https://www.mediawiki.org/wiki/Sandbox

Steps to Reproduce:
1. Click on https://www.mediawiki.org/wiki/Sandbox?veaction=edit

2. Press down arrow key.  Nothing happens.

3. Press up arrow key.  Nothing happens.

4.  Huh, how do I get off this template?

Actual Results:  
Left and right arrow keys take me to the slugs on either side, so why don't up and down arrow keys do the same?

In my brief testing, this doesn't happen if there is an infobox and text on the page.  https://www.mediawiki.org/wiki/Sandbox is the only page that I'm sure it always happens on.


Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://www.mediawiki.org/wiki/Sandbox?veaction=edit
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57477
**oliver.buchtala** wrote:

It happened that I ran over that issue while debugging. Here some details that may help:

The problem is, that after focussing 've.ce.Surface.onModelSelect()' runs into a case which seems to be dedicated to pasting situations:

  ...
  if ( next ) {
    rangySel = rangy.getSelection( this.getElementDocument() );
    if ( !ve.contains( this.$pasteTarget[0], rangySel.anchorNode, true ) ) {
      ...
    }
  ...

After that the window selection is on the paste element which will make the next up/down do nothing, but leaving the navigation to the CE.

HTH,

Oliver
Use the VisualEditor to edit an article on mediawiki.org, enter the word "bugzilla" and turn it into a link (highlight, Ctrl-K). The link input widget proposes a list of link targets, starting with "bugzilla" (checked), "Bugzilla/Notes/4198" and "Bugzilla". Click on the third one ("Bugzilla"). With quick eyes, you will notice that "Bugzilla/Notes/4198" is checked instead, but the list disappears immediately and the target box contains the string "Bugzilla". It appears as if the desired "Bugzilla" had been accepted as link target. Close the link input widget and preview your changes: "Bugzilla/Notes/4198" is used as link target.

Another instance:

Go to https://en.wikipedia.org/wiki/War?veaction=edit and turn the word "integral" in the second paragraph into a link. The link input widget proposes a list of link targets, starting with "integral" (checked), "Integral domain" and "Integral". Click on the third one ("Integral"). With quick eyes, you will notice that "Integral domain" is checked instead, but the list disappears immediately. It then appears as if the desired "Integral" had been accepted as link target. Close the link input widget and preview your changes: "Integral domain" is used as link target.

It's likely that these cases won't be reproducible for long since the suggested target list is highly dependent on the respective wiki's current set of articles.

--------------------------
**Version**: unspecified
**Severity**: major
Fixed as part of the general link inspector work this week.
https://he.wikipedia.org/wiki/%D7%9E%D7%93%D7%99%D7%94_%D7%95%D7%99%D7%A7Sandbox?veaction=edit as an anon yields to edit notices which together are way taller than the screen, which produces really weird behavior where you can't scroll to reach the bottom part of the edit notices.

Either the edit notices widget should be a ClippableElement, or it should have a max height and scroll beyond that (or both).

--------------------------
**Version**: unspecified
**Severity**: minor
*** This bug has been marked as a duplicate of bug 50885 ***
See also https://fr.wikipedia.org/wiki/Utilisateur:Elitre_(WMF)/Prove5?veaction=edit or https://it.wikipedia.org/wiki/Utente:Elitre_(WMF)/Sandbox_VE8?veaction=edit for more examples. (And bug 63631 for a related bug.)
This bug doesn't really address the root issues here, which are that:
* In some instances the edit notice box just needs to be wider if there's that much content to display.
* We don't provide a way of proving VE-specific edit notices. Most notices are wrapped in coloured-margined-padded boxes which is unnecessary with our UI.
I prefer both.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Reference
3.Click on "Apply Changes" without inserting any content for the reference

Observed Result:
The empty reference gets added in the page and after saving it shows the error message:Cite error: Invalid <ref> tag; refs with no content must have a name; see the help page ().

Expected Result:

The "Apply Changes" button should remain disabled unless user enters any content for the reference 

See the screenshot attached.


Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
http://en.wikipedia.beta.wmflabs.org/wiki/7thmarchrome

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

**Attached**: {F12857}
*** This bug has been marked as a duplicate of bug 52182 ***
Intention:
Delete an image.

Steps to Reproduce:
1. Click on http://en.wikipedia.beta.wmflabs.org/w/index.php?oldid=82527&veaction=edit

2. Place cursor inside the ==Referenced text== section heading.

3. Press the forward arrow key a few times.  At the end of the line, you'll select the entire image-and-image-containing-caption block.  Forward-arrow once more, and you'll end up in the first paragraph.  (This is all expected behavior.) 

4. If necessary, place your cursor in the first sentence after the ==Referenced text== section heading.

5.  Press the back arrow key a few times.  This selects only the image that is inside the caption, not the entire two-image block.  You can remove the second image or change the caption for the first image (only) while your cursor is there.  If you keep back-arrowing, you'll eventually select the whole block, and then end up in the ==Referenced text== section heading. 


Expected Results:  
I expected forward- and backward- arrows to produce the same results.

I like the "backward" result better.  Why not make it possible to edit captions simply by placing the cursor in the caption (either by clicking the caption [instead of the image] or with the keyboard)?

Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: major
This was fixed a while ago by Ed's selection/node work.
We deliberately don't show a CTA if they're already editing.  However, this is broken if they're editing with VE.

--------------------------
**Version**: master
**Severity**: normal
Change 131315 merged by jenkins-bot:
Don't show CTA on signup if user is editing with VE

https://gerrit.wikimedia.org/r/131315
Change 131315 had a related patch set uploaded by Mattflaschen:
Don't show CTA on signup if user is editing with VE

https://gerrit.wikimedia.org/r/131315
This blocks the signup CTA experiment (https://trello.com/c/MaqpJE5f/405-create-pre-edit-anonymous-editor-signup-invitation-guided-tour), since it creates a very bad experience for people who click 'signup and edit' (the GettingStarted CTA stays open even when VE is fully loaded).
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Add an image which has an full size less than the default size for example: http://en.wikipedia.beta.wmflabs.org/wiki/File:FS_barnstar.png
It has a full size of 111x107 px which is less than the default size 220x212 px

3.Now if you switch to set to custom size , it will show Size values are invalid as it is larger than the full size.

Page:http://en.wikipedia.beta.wmflabs.org/wiki/Betachrome5th?veaction=edit

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

**Attached**: {F13258}
Verified the fix in production
verified the fix in test2
Yes, I checked it with those images on Betalabs and looks like it got fixed with https://gerrit.wikimedia.org/r/#/c/120808/
Provisionally marking as FIXED, then. :-)
Just tested this again with the new MWImageModel, and it seems this bug is fixed.

I tested on both Ló_heraldika.png and FS_barnstar.png with quick changes to the size (as before). Works properly for me in labs.
This is still happening:

Getting the error message "Size values are invalid" when I switch to custom from default tab.Also, also the default size is appearing as 220x245 px where as the full size of the image is 71x79 px (smaller than the default size)
I can't replicate on master with the same image [[File:Ló_heraldika.png|thumb]]

It appears in the proper size, which is much smaller than the default.
This bug is happening again now in Betalabs and test2 for the image File:Ló_heraldika.png
Verified the fix in production: https://en.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/sandbox?veaction=edit
Verified the fix on test2:https://test2.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/sandbox&veaction=edit
Verified the fix on :http://en.wikipedia.beta.wmflabs.org/w/index.php?title=12thmarchchrome&veaction=edit
Change 118231 merged by jenkins-bot:
Deal with images whose size is smalled than default

https://gerrit.wikimedia.org/r/118231
Change 118231 had a related patch set uploaded by Mooeypoo:
Deal with images whose size is smalled than default

https://gerrit.wikimedia.org/r/118231
I can still reproduce this bug for the same image on that page when I switch from "Set to default size" to "Set Custom Size"
Change 117161 merged by jenkins-bot:
Enforce width-only default size only on larger images

https://gerrit.wikimedia.org/r/117161
Change 117161 had a related patch set uploaded by Mooeypoo:
Enforce width-only default size only on larger images

https://gerrit.wikimedia.org/r/117161
VisualEditor screenshot, showing number of image resizing handles in frameless vs thumb

May be related to bug 62139.

1.  Open a right-aligned image in VisualEditor.  Set to "thumb".  Count image resizing handlers (answer:  1).

2.  Change image to "frameless".  Count image resizing handlers (answer:  4).

I believe this also happens in "frame" and "basic", but it's a little hard to tell because of another bug (that sets them to full size).

It would make more sense to only have one handle for this situation.  Two (on the two lower corners) might make sense for centered images.  Probably nothing should have a handle on the top corners.

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F13223}
*** This bug has been marked as a duplicate of bug 61968 ***
So, this seems to still happen in beta labs, but it's seems to be fixed in master.
Wikitext code:  [[File:Hedrick (1921) - Bartlett.jpg|thumb|Caption]]

Original image dimensions:  920 × 1,216 pixels.

VisualEditor says:  166.32302405498282 × 220 pixels.


Please round to whole numbers of pixels.

--------------------------
**Version**: unspecified
**Severity**: minor
Change 117161 merged by jenkins-bot:
Enforce width-only default size only on larger images

https://gerrit.wikimedia.org/r/117161
Change 117161 had a related patch set uploaded by Mooeypoo:
Enforce width-only default size only on larger images

https://gerrit.wikimedia.org/r/117161
Apologies, I mean this fix: https://gerrit.wikimedia.org/r/#/c/117161/

(Added Math.round() in the default size conversion in the dm)
I still can't manage to replicate the bug on master or on betalabs, but in any case, height calculations are rounded in this patch: https://gerrit.wikimedia.org/r/#/c/117144/

This should fix instances of this bug.
I can't manage to replicate this, not even in betalabs.

http://en.wikipedia.beta.wmflabs.org/wiki/User:Mooeypoo/Test?veaction=edit

I get 166x220 in the media size widget...
Created attachment 14746
Screen shot of VisualEditor's image dialog, under advanced settings

**Attached**: {F13209}
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Now select the image and delete it
4.Go to the next line by pressing enter

Observed Result:


The following error appears in the console:


Uncaught TypeError: Cannot call method 'getChildren' of null 
Uncaught TypeError: Cannot call method 'getChildren' of null load.php:269
ve.ce.Surface.handleEnter load.php:269
ve.ce.Surface.onDocumentKeyDown load.php:247
proxy load.php:10
ve.EventSequencer.onEvent load.php:21
(anonymous function) load.php:20
jQuery.event.dispatch load.php:45
elemData.handle.eventHandle

See the screenshot attached

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

**Attached**: {F13081}
Verified the fix in production:https://en.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/sandbox?veaction=edit
Verified the fix in test2:https://test2.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/sandbox&veaction=edit
Verified the fix in betalabs:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=12thmarchchrome&veaction=edit
Change 118340 merged by jenkins-bot:
Fix JS error when pressing Enter with selection across multiple paragraphs

https://gerrit.wikimedia.org/r/118340
Change 118340 had a related patch set uploaded by Catrope:
Fix JS error when pressing Enter with selection across multiple paragrahps

https://gerrit.wikimedia.org/r/118340
Edit a page with wikitext [[User:Trevor_Parscal|Trevor Parscal]] ([[User talk:Trevor_Parscal|talk]]). Inspect the second link ("talk"), wait for the suggestions to load, then click out of the inspector. The save button activates. Click the save button and review the diff, and you'll see that the underscore in the link target went away.

Looking at the DM transaction history, the link was replaced with a newly generated annotation that doesn't have htmlAttributes and doesn't have origTitle or any of the orig* attributes.

For whatever reason, this bug doesn't happen for the first link. Maybe it's because only the second link has a namespace prefix that contains a space?

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/User:Catrope/Bug_62229
AFAICT this is now fixed, thanks be to Parsoid.
Is there anything for VE to do here or will it Just Work™ once Parsoid updates the production service?
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Now type something and open a link inspector over it

Observed Result:

The "New Page" and "Matching Pages" messages are not greyed out inside Link Inspector rather appearing in a more apparent style

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

**Attached**: {F13045}
Verified the fix on :https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/sandbox?veaction=edit
verified the fix on test2
Verified the fix in Betalabs
Change 117132 merged by jenkins-bot:
Rename OO.ui.MenuSectonItemWidget.less to the right name

https://gerrit.wikimedia.org/r/117132
Change 117132 had a related patch set uploaded by Catrope:
Rename OO.ui.MenuSectonItemWidget.less to the right name

https://gerrit.wikimedia.org/r/117132
For the serialization of new transclusions we'd like to have information about the preferred formatting from TemplateData:

* all parameters on a single line vs. one parameter per line
* (possibly) preferred order of parameters by key

--------------------------
**Version**: unspecified
**Severity**: enhancement
Is this a dupe of T64147 ?
BTW  -Question about the "real-world" use: I think that block  (non-inline) templates are infobox and (almost) only infobox?  if so, we can use this as heuristic for creating a bot to fill the format field in all existing templates quite easily.
Change 243138 had a related patch set uploaded (by Eranroz):
Introducing template format

[[https://gerrit.wikimedia.org/r/243138]]
Though admittedly this is really minor issue, it has a huge impact on whether VisualEditor is accepted by power users or not. Because of this issue it is actually frowned upon to create biographies with VE in de.wikipedia, users have been told already to use the normal source code editor instead.
>>! In T64217#1188824, @Schnark wrote:
> Proper formatting actually requires more information than just single line vs. one parameter per line

Yes, and we are not going to implement that. We aren't going to give the community tools to enact their epic, pointless wikitext style edit wars with each other through config settings.
Proper formatting actually requires more information than just single line vs. one parameter per line:

* Whitespace before pipe: For templates that should have one parameter per line this will be `"\n"`, for single line templates it can be the empty string or just a space.
* Whitespace after pipe: In most cases either an empty string or just a space.
* Whitespace before equal sign: This may vary widely: Empty string, one space, many spaces (depending on the length of the parameter name, to align the equal signs).
* Whitespace after equal sign: In most cases either an empty string or just a space. But this may depend on whether the parameter has a value or not, i.e. it should be possible to have a space after the equal sign iff the value isn't empty.

One important example is [[https://de.wikipedia.org/wiki/Vorlage:Personendaten|Vorlage:Personendaten (de.wikipedia)]], which provides meta-data about persons (it predates Wikidata but still fits our needs much better and thus is still actively used): To make parsing these data as easy as possible the whitespace used in the template transclusion should follow exactly the documentation. This means: When somebody uses VE to insert this template, another user //will// make [[https://de.wikipedia.org/w/index.php?title=Nazira_Abdula&curid=8786932&diff=140583554&oldid=140583398|an edit]] just to remove the spaces. So it should be possible to tell VE just not to insert them in the beginning.
*** Bug 63813 has been marked as a duplicate of this bug. ***
(In reply to Gabriel Wicke from comment #0)
> For the serialization of new transclusions we'd like to have information
> about the preferred formatting from TemplateData:
> 
> * all parameters on a single line vs. one parameter per line

Sounds sensible.

> * (possibly) preferred order of parameters by key

This is already done for display purposes; I imagine we should just re-use the same order?
Screenshot

Steps to reproduce:

Yet Unknown.I am getting it by following no specific steps.

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

**Attached**: {F12939}
Verified the fix in production:https://en.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/sandbox
Change 117445 merged by jenkins-bot:
Work around DOM corruption for default-sized images

https://gerrit.wikimedia.org/r/117445
Change 117445 had a related patch set uploaded by Catrope:
Work around DOM corruption for default-sized images

https://gerrit.wikimedia.org/r/117445
verified the fix on test2
Verified the fix on betalabs  on this page: http://en.wikipedia.beta.wmflabs.org/wiki/Editcorrupted
Change 117144 merged by jenkins-bot:
Work around DOM corruption for default-sized images

https://gerrit.wikimedia.org/r/117144
Change 117144 had a related patch set uploaded by Catrope:
Work around DOM corruption for default-sized images

https://gerrit.wikimedia.org/r/117144
This is not because of galleries of formulas, but because of Moriel's fixes for default images sizes in the DM. So it manifests only for images with default size.

The corruption occurs because the default image size fixes overwrite Parsoid's width/height (which is reasonable) but then also send the overwritten values back to Parsoid (which is not reasonable). We should store the original values and send those back in the HTML unless the user changed something.

Additionally, the default size fixes are causing us to incorrectly size images whose original size is less than 220px. An 16x16px icon, for instance, is 16x16 even though the default bounding box is 220, because default sizing never grows an image above its original size. In this case Parsoid's width/height are actually correct, but we overwrite that with the default size, and so 16x16px icons end up rendering as 220x220px in VE and look horribly pixelated.
Confirmed on http://en.wikipedia.beta.wmflabs.org/wiki/Editcorrupted?veaction=edit with not actual corruption, but can't reproduce locally.
Steps to reproduce:  (found later )

1.Open a page with VE
2.Add a formula or a gallery
3.Save the page

Observed Result:
 "Your edit may have been corrupted – please review before saving" appears on the save dialog box
#1 Go to https://office.wikimedia.org/wiki/HR_Corner/Massage_Signups#Standby_list
#2 Click edit

Notice how you get a 'Error loading data from server: parsoidserver-http-curl-error: Couldn't resolve host 'HR_Corner%2FMassage_Signups'

--------------------------
**Version**: unspecified
**Severity**: major
Change 116792 merged by jenkins-bot:
Really actually fix VE on private wikis

https://gerrit.wikimedia.org/r/116792
Change 116792 had a related patch set uploaded by Catrope:
Really actually fix VE on private wikis

https://gerrit.wikimedia.org/r/116792
Change 116662 merged by jenkins-bot:
Fix VisualEditor/Parsoid on private wikis

https://gerrit.wikimedia.org/r/116662
Change 116662 had a related patch set uploaded by Catrope:
Fix VisualEditor/Parsoid on private wikis

https://gerrit.wikimedia.org/r/116662
Screenshot

Steps to reproduce:


1.Open a page with VE
2.Go to Options>Categories
3.Try to add a category to the page

Observed Result:
Cannot place the cursor in the Add a category text box and cannot add a category

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
Page: http://en.wikipedia.beta.wmflabs.org/wiki/Newpage3rdfeb?veaction=edit

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

**Attached**: {F12924}
Verified the fix in test2
Verified the fix in Betalabs
Fixed in OOjs UI; will be pulled into master for MW-core later today.
Change 116664 merged by jenkins-bot:
Allow focusing of inputs in booklet layouts without continuous pages

https://gerrit.wikimedia.org/r/116664
Change 116664 had a related patch set uploaded by Trevor Parscal:
Allow focusing of inputs in booklet layouts without continuous pages

https://gerrit.wikimedia.org/r/116664
(In reply to James Forrester from comment #2)
> Roan suggests that it may be caused by Ed's blur of surface on dialog open.
I was wrong, it was the autofocusing of pages feature in oojs-ui, which didn't properly respect the config setting that disables it (plus had other issues). Fix inbound from Trevor.
Roan suggests that it may be caused by Ed's blur of surface on dialog open.
This seems to repeat for all input boxes inside Dialogs. It happens also for alternate text in Media Edit dialog and in the MediaSizeWidget in the same dialog.

The values change properly through the automatic changes (by selecting different options) but the textboxes do not get focused and seem to be non responsive.
1. "frame" thinks you can set a size other than original size, you can't
2. changing from "thumbnail" to "frame" doesn't hide the zoom icon
3. changing from "thumbnail" or "frame" to border doesn't collapse the border
4. "border" images come up as inline so can't be edited, even though you can convert to border from a block image

I'm concerned we're merging features before they're ready. We should consider rolling back features that don't fully work yet at is looks like there's a lot still to do.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 117928 merged by jenkins-bot:
Show/hide the magnify button on type change

https://gerrit.wikimedia.org/r/117928
Change 117928 had a related patch set uploaded by Mooeypoo:
Show/hide the magnify button on type change

https://gerrit.wikimedia.org/r/117928
(In reply to Ed Sanders from comment #0)
> 1. "frame" thinks you can set a size other than original size, you can't

Fixed.


> 2. changing from "thumbnail" to "frame" doesn't hide the zoom icon

Not fixed.

> 3. changing from "thumbnail" or "frame" to border doesn't collapse the border

Fixed.

> 4. "border" images come up as inline so can't be edited, even though you can
> convert to border from a block image

Fixed.

(In reply to Ed Sanders from comment #1)
> 5. Opening the media dialog editor on a frameless centred image
> ([[File:Example.jpg|200px|center]]) throws an exception (Cannot call method
> 'getData' of null ve.ui.MWMediaEditDialog.js:329)

Fixed.

=> Re-titling.
I believe at least some of these are done in gerrit 115939.
5. Opening the media dialog editor on a frameless centred image ([[File:Example.jpg|200px|center]]) throws an exception (Cannot call method 'getData' of null ve.ui.MWMediaEditDialog.js:329)
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Create a heading
3.Undo creating the heading and type something in that line instead
4.Press enter

Observed Result:
Uncaught Error: Inserted data is trying to close the root node (at index 0) is appearing in the console.

See the screenshot attached

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Test62015&veaction=edit

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

**Attached**: {F13363}
Verified the fix in production: https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/sandbox?veaction=edit
Verified the fix in test2 environment
Verified the fix in Betalabs
Change 116754 merged by jenkins-bot:
Store previous range in breakpoint for undo

https://gerrit.wikimedia.org/r/116754
Change 116754 had a related patch set uploaded by Esanders:
Use previous breakpoint's range when undoing

https://gerrit.wikimedia.org/r/116754
In standalone demo empty.html

1. Turn on 'get range on change', observe [1,1]
2. Create heading, observe [1,1]
3. Undo, observe [2,2]

Expected: Range is still [1,1] after undo
Steps to Reproduce:
1. Open the page:  http://en.wikipedia.beta.wmflabs.org/w/index.php?oldid=81526&veaction=edit

2. Scroll down to the image of an apple.

3. Why is it barely visible?



Reproducible: Always

This happens in both Safari and Firefox, but only at beta.wmflabs.

--------------------------
**Version**: unspecified
**Severity**: major
**URL**: http://en.wikipedia.beta.wmflabs.org/w/index.php?oldid=81526&veaction=edit
Verified the fix on : https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/sandbox?veaction=edit
Verified the fix in test2:https://test2.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/sandbox&veaction=edit
Change 117123 merged by jenkins-bot:
Force thumb and frameless images to default size in DM

https://gerrit.wikimedia.org/r/117123
Change 117123 had a related patch set uploaded by Catrope:
Force thumb and frameless images to default size in DM

https://gerrit.wikimedia.org/r/117123
Change 117106 merged by jenkins-bot:
Force thumb and frameless images to default size in DM

https://gerrit.wikimedia.org/r/117106
Change 117106 had a related patch set uploaded by Catrope:
Force thumb and frameless images to default size in DM

https://gerrit.wikimedia.org/r/117106
Verified the fix in betalabs
Change 115939 merged by jenkins-bot:
Deal with 'none'/'border' and default size in media edit

https://gerrit.wikimedia.org/r/115939
Change 115939 had a related patch set uploaded by Jforrester:
Add type 'none' to the media edit dialog

https://gerrit.wikimedia.org/r/115939
Created attachment 14705
Image display bug

**Attached**: {F13189}
**Author:** `robert.labrie`

**Description:**
Intention:
Add media with visual editor

Steps to Reproduce:
LocalSettings.php and wiresharks are attached. The MW search does work. I can do a partial name search for an image in the File namespace and it works. The gallery in mediawiki does not.

Actual Results:  
No images

Expected Results:  
Images

Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: major
This appears to be a core MW issue with unsupported hosting paths. Closing as INVALID.
If you access the MediaWiki core api.php entry point directly in your browser, what do you get back?

It should look like this: https://www.mediawiki.org/w/api.php

If it doesn't then there is nothing VisualEditor can do as it means your server is not configured correctly to expose MediaWiki's entry points (perhaps you only whitelisted index.php?).

This likely means other features are broken as well (the autocompleting of page names in the search box, the "Watch this page" button etc.).

Serving the MediaWiki application directory from your document root is highly discouraged.  If you don't like exposing a /wiki/ path in URLs you can keep the application in /w/ but let Apache rewrite your urls from /Page_name to /w/index.php. That way you have both nice urls in the root, but still keep your application's internal files tucked away safely in /w. See https://www.mediawiki.org/wiki/Manual:Short_URL and related pages.
(In reply to James Forrester from comment #6)
> Moriel – was this what Gerrit change #112491 fixed?

That change fixed another related bug, but apparently there are other remaining issues after that fix that I'm trying to understand. 

I think it has to do with the fact the wiki is installed in the root directory. The media search seems to skip looking for files in the local repository.
Moriel – was this what gerrit 112491 fixed?
**robert.labrie** wrote:

Hi James,

I'm not sure. What I do know is that VE never sends a search to the API. It does a filerepoinfo and that's the end of it. Whatever I type in the searchbox, nothing gets sent to the API.

If you give me a sample querystring I'll change the srsearch param to match something that should be found and test it.
Is this related to the issue we found (fixed?) in MediaWiki core recently about certain configurations of document root and the file search API?
**robert.labrie** wrote:

My local settings file

**Attached**: {F13178}
**robert.labrie** wrote:

search pcap

This is just proving that the search does work. Something is broken in the way VisualEditor calls the API, or in the results the API returns.

**Attached**: {F13177}
**robert.labrie** wrote:

visual editor pcap

This shows the whole experience from clicking edit to clicking add media. You can see the call to API.php where it asks for repos, it gets nothing back.

**Attached**: {F13176}
Right now you can re-position an inline transclusion in the same way as images, with a click-drag feature. Unfortunately this isn't set for block transclusions.

This is particularly irritating for suers because when you initially insert a transclusion we assume it's inline, so let them move it, but then when they re-open the page it's now magically un-moveable.

--------------------------
**Version**: unspecified
**Severity**: minor
I'm declaring that it was.
Was this fixed by the changes to GCNs?
The problem here is not block templates, but that the CE HTML is <div wrapper><table float:right/></div>, and the relocatable marker takes it's dimensions from the <div> (which has no height).

In ProtectedNode we solve this by drawing boxes around _every_ descendent. Ideally we'll come up with a better solution before we start add drag handlers to them.
Abandoned that, the test case I was using appears to be an edge case, it actually works ok.
Disable on block images for now: https://gerrit.wikimedia.org/r/#/c/116118/
Relocatable doesn't work on block elements atm. We have it enabled for block images, but it breaks.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert an image 
3.Make it frameless
4.Keep on resizing down the image going beyond 1x1 px.
5.Click anywhere on the page

Observed Result:

The image becomes a dot size . and user can no more select or find Media Settings icon for it.

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 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/24thfebchrome?veaction=edit

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

**Attached**: {F13101}
Sorry on:https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/sandbox?veaction=edit
Verified the fix in production:http://en.wikipedia.beta.wmflabs.org/wiki/Slug?veaction=edit
Verified the fix in test2 environment.
Verified the fix in Betalabs
Invalid input

Steps to reproduce:

1.Open a page with VE which has multiple references
2.Go to Insert>Reference>Use an existing reference
3.Now input something in the search box which will have no search result
4.Now cross out the dialog box
5.Again go to Insert>Reference

Observed Result:
The "Use an existing reference" button is disabled and it does not become enabled for the rest of the session unless user cancels the edit and reopen the page again with VE

Test Environment: https://test2.wikipedia.org/
Browser: Chrome Version 26.0.1410.65
OS: MAC OS X 10. 8. 5 
Page:https://test2.wikipedia.org/wiki/User:RYasmeen_(WMF)/sandbox?veaction=edit

See the screenshots attached

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F13055}
Verified the fix in test2 :https://test2.wikipedia.org/wiki/Wmf19?veaction=edit
Change 119702 merged by jenkins-bot:
Don't use search widget emptiness as a proxy for "no reusable references"

https://gerrit.wikimedia.org/r/119702
Change 119702 had a related patch set uploaded by Catrope:
Don't use search widget emptiness as a proxy for "no reusable references"

https://gerrit.wikimedia.org/r/119702
Created attachment 14692
Disabled "Use an existing reference" button

**Attached**: {F13056}
VisualEditor breaking words on diacritics

A user was trying to remove the duplicated header which is on section "Propriedades Algébricas" of
https://pt.wikipedia.org/wiki/Logaritmo?oldid=38172637&veaction=edit

After deleting the duplicated cells, Visual Editor also removes part of a word from the previous paragraph.

--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://pt.wikipedia.org/w/index.php?title=Logaritmo&diff=38264880&oldid=38264877

**Attached**: {F13042}
I suspect this had nothing to do with diacritics, but was because there was unbalanced wikitext. It looks like Parsoid outputs that particular wikitext differently now anyway. Suggest WONTFIX.
Move EventLogging component from MediaWiki extensions product to Analytics product, as requested via email.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
I'm still trying to adjust to VisualEditor being a product instead of a component under "MediaWiki extensions." Now I'll have to add a mental exception for EventLogging as well. Blergh.
Done.
enwiki has been seeing a bunch of slow ApiQueryLogEvents queries:

SELECT /* ApiQueryLogEvents::execute */ /*! STRAIGHT_JOIN */ log_type, log_action, log_timestamp, log_deleted, log_id, page_id, log_user, log_user_text, user_name, log_namespace, log_title, log_comment, log_params FROM `logging` LEFT JOIN `user` ON ((user_id=log_user)) LEFT JOIN `page` ON ((log_namespace=page_namespace) AND (log_title=page_title)) INNER JOIN `change_tag` ON ((log_id=ct_log_id)) WHERE (log_type != 'suppress') AND ct_tag = 'Possible self promotion in userspace' ORDER BY log_timestamp DESC LIMIT 11

SELECT /* ApiQueryLogEvents::execute */ /*! STRAIGHT_JOIN */ log_type, log_action, log_timestamp, log_deleted, log_namespace, log_title, ts_tags FROM `logging` LEFT JOIN `user` ON ((user_id=log_user)) LEFT JOIN `page` ON ((log_namespace=page_namespace) AND (log_title=page_title)) LEFT JOIN `tag_summary` ON ((log_id=ts_log_id)) INNER JOIN `change_tag` ON ((log_id=ct_log_id)) WHERE (log_type != 'suppress') AND ct_tag = 'VisualEditor' ORDER BY log_timestamp DESC LIMIT 11

... and several other similar forms.

In all cases the STRAIGHT_JOIN forces an index scan on logging.times index, or more rarely a range access on logging.type_time index. Both query plans hit tens of millions of rows and take many minutes.

Removing the STRAIGHT_JOIN allows the MariaDB query optimizer to choose a plan that takes seconds. Often it includes a filesort step, but more importantly it allows "index condition pushdown" which makes the filesort cheap.

--------------------------
**Version**: 1.23.0
**Severity**: major
Change 115381 merged by Springle:
Remove STRAIGHT_JOIN from ApiQueryLogEvents

https://gerrit.wikimedia.org/r/115381
Change 115381 had a related patch set uploaded by Anomie:
Remove STRAIGHT_JOIN from ApiQueryLogEvents

https://gerrit.wikimedia.org/r/115381
Screenshot

Steps to reproduce:

1.Open a page with VE which contains an image
2.Select the image
3.Go to Insert>References List

Observed Result:
The Save page button becomes active though there is no new reflist got added.If you click on "Review Your Changes" on the Save Dialog box, it will say 
"Could not start the review because your revision matches the latest version of this page"


See the screenshot attached.

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Page: http://en.wikipedia.beta.wmflabs.org/wiki/24thfebchrome?veaction=edit

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

**Attached**: {F12904}
Verified the fix in production:https://en.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/sandbox&veaction=edit
Verified the fix in test2
Verified the fix on Betalabs
Change 125799 merged by jenkins-bot:
Fix inserting references list while selecting another kind of node

https://gerrit.wikimedia.org/r/125799
Change 125799 had a related patch set uploaded by Trevor Parscal:
(Bug 61885) Inserting ref list while selecting another kind of node

https://gerrit.wikimedia.org/r/125799
Steps to reproduce:
1.  Start with a blank page.

2.  Go to Page settings.

3.  Tick both redirect-related boxes, but don't provide a page name.

4.  Apply changes.


Results:
It sets __STATICREDIRECT__, which is not pointful on an otherwise blank page.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61864
Change 115239 merged by jenkins-bot:
Don't let the user set a static redirect flag on a non-redirect

https://gerrit.wikimedia.org/r/115239
Change 115239 had a related patch set uploaded by Jforrester:
Don't let the user set a static redirect flag on a non-redirect

https://gerrit.wikimedia.org/r/115239
Hmm. This shouldn't be possible – I think this is the same issue as bug 61864.
In the "Page settings" dialog, it says "Redirect this page to" and a blank field for the target name.  If you put a name in there, then it sets a redirect, even if you don't tick the checkbox.  

VisualEditor should automatically tick the checkbox there if it's going to set a redirect (e.g., as soon as you start typing).  Otherwise, it looks like it's not going to redirect the page when you exit the dialog box.

(Reproducing this has only been consistent if there is no redirect on the page at the start of the editing session.)

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61865
verified the fix in betalabs:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Imageghau
Change 115237 merged by jenkins-bot:
Disable redirect field unless the checkbox is set in setup

https://gerrit.wikimedia.org/r/115237
Change 115237 had a related patch set uploaded by Jforrester:
Disable redirect field unless the checkbox is set in setup

https://gerrit.wikimedia.org/r/115237
*** Bug 61866 has been marked as a duplicate of this bug. ***
The logic for this box is meant to work the other way around - that is, you can't set a redirect unless you check the box first - but a simple forgotten line made this not work in one (very frequent) case: when the page isn't a redirect and you're making it one. Whoops. :-(
Intention:
Add one ref

Steps to Reproduce:
1. Opened an existing ref, copied the contents, and cancelled out of the dialog.

2. Opened a new ref, pasted what I'd just copied, changed the contents slightly, and applied changes.


Actual Results:  
All the <ref name = whatever> tags on the page were "corrected".

Expected Results:  
Nothing would change in paragraphs that I didn't touch.

Reproducible: Didn't try

This is presumably a regression, but search couldn't find any bugs containing the word "name".

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/w/index.php?title=User:Whatamidoing_(WMF)/Sandbox&diff=912199&oldid=840682
I, too, can't reproduce – possibly a Parsoid deployment cache artefact? Closing as WFM.
I can't reproduce this today in Safari (which is what I was using at the time), either.  Perhaps it has been fixed already?  Perhaps there's something unfortunately subtle about it (e.g., must click eleven times first, only on the night before the last quarter of the Moon)?
Can't reproduce using that specific revision of the page, and the same edit, either in FF or Chrome.
(In reply to WhatamIdoing from comment #2)
> https://www.mediawiki.org/w/index.php?title=User:Whatamidoing_(WMF)/
> Sandbox&diff=912199&oldid=840682

Very odd. Seems to be something on that page triggering the behaviour?
https://www.mediawiki.org/w/index.php?title=User:Whatamidoing_(WMF)/Sandbox&diff=912199&oldid=840682
I tried this on MediaWiki.org, following your steps with this edit: https://www.mediawiki.org/w/index.php?title=VisualEditor:TestReferenceContents&diff=912228&oldid=768024

As you can see, I couldn't reproduce. Can you give a link to a page where this happens?
Screenshot

Do no Show empty summary preview: () when there is no summary in Review Changes dialog box

See the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F13076}
Verified the fix in betalabs
Change 114737 merged by jenkins-bot:
Don't show edit summary preview if it's blank

https://gerrit.wikimedia.org/r/114737
Change 114737 had a related patch set uploaded by Alex Monk:
Don't show edit summary preview if it's blank

https://gerrit.wikimedia.org/r/114737
Reported on fr.wp:
<<Here is how I did : on the page https://fr.wikipedia.org/wiki/Utilisateur:NemesisIII/Ch%C3%A2teau_Rothschild_(Boulogne-Billancourt) opened with VE, "Historique" section, copy from "Joseph Fleuriau d'Armenonville" to "évoqua brièvement le lieu." Then paste it somewhere on the page https://fr.wikipedia.org/wiki/Utilisateur:NemesisIII/Brouillon [it's a sandbox, it's ok to test there], and everything will be deleted. 
I also noticed that a few times nothing was deleted but nothing was pasted too. [...]
I have the same bug with FF 29 with both W7 and W8.1, and also Chrome 32 with W7. Nemesis III (me contacter), le 19 février 2014 à 19:16 (CET). >>

I reproduced this as well.
In addition, the first time it didn't blank the destination page, and the same happened on one of my sandboxes. Then one time it blanked the page, allowed me to save, I got the confirmation message but nothing was recorded (the history doesn't have signs of this).

--------------------------
**Version**: unspecified
**Severity**: normal
Can't reproduce.
This is happening elsewhere as well.
I was testing if you can copy/paste a reference from a VE instance on one wiki to another (from sv.wp to it.wp).
Sometimes it takes a lot for the save dialog to appear; in other cases the action just leads to page blanking.
VEdit https://fr.wikipedia.org/wiki/Utilisateur:Elitre_(WMF)/Prove2?veaction=edit in Firefox.

Place your cursor right below the initial template, press Shift and the Up arrow to select it, type something = pawn.

NicoV, who found this, says you can also start from the line above the template, Shift + Down arrow in that case.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=58675
https://bugzilla.wikimedia.org/show_bug.cgi?id=54917
This is fixed now.
Simple test case:
{{Simple table include}}
Foo

Place the cursor before 'Foo', press up (shift not requred) and type.

Interestingly if the block template is float right it works fine.
Screenshot

Steps to reproduce:


1.Open a page with VE
2.Add a text with reference
3.Add a reflist
4.Go to the next line of the text with reference and add an image
5.Go to the Media settings of the image and set the alignment to left(This should move the image between reference and reflist , instead it distorts the reflist position and it appears just beside the image instead of appearing below it)
6.Save the page
7.Reopen the page
8.Try to the position of reflist it by pressing enter 

Observed Result:
No newline gets entered , an error appears in the console:
Uncaught TypeError: Cannot call method 'getModel' of null 

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 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/Anotherdeep?veaction=edit

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

**Attached**: {F13298}
This issue got resolved with  bug 59911
The pressing-enter-in-the-slug bug is I think bug 59911, so merging with that.

*** This bug has been marked as a duplicate of bug 59911 ***
I don't see anything wrong with the rendering, it looks pretty similar to the PHP parser output. The pressing-enter-in-the-slug bug is a problem though.
(In reply to ryasmeen from comment #1)
> This is also happening when the first element of a page is image and you try
> to press enter to go to the next line

Correction: When the first element of a page is a left aligned image
This is also happening when the first element of a page is image and you try to press enter to go to the next line
pawn before the link

Steps to reproduce:

1.Open a page with VE
2.Create a link
3.Type something just before the link
4.Type something just after the link
4.Click on "Undo" several times

Observed Result:

A pawn appears right before and after the link 


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 
Page:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=18thfebchrome

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

**Attached**: {F13288}
No pawns now.
I'm not taking this bug either, but I can reproduce it -if I make the link in the block slug-. Which I wasn't doing when I tested this before.
Created attachment 17150
video capture of the bug

See the video capture attached

**Attached**: {F13290}
I just reproduced this on Chrome in Betalabs
Tried again, seems fixed.
Cannot reproduce.
I might be reopening the wrong bug, but this doesn't seem to be fixed.

1) VEdit any article on the French Wikipedia.
2) Type some words exactly before a wikilinked single word. (Based on my tests, it doesn't really matter if we add one word or several ones.)
3) Undo your edit with the related keyboard shortcut or the Undo button: a pawn will appear. Undo again, the pawn might disappear, undo one more time, it appears again, etc.
I was able to reproduce with Vector and Safari.
I think this is now fixed.
Created attachment 14622
Pawn after the link

**Attached**: {F13289}
1. Go to template dialog
2. Insert two templates (or a template and a content item, or whatever)
3. Click the bottom one and click the up arrow to move it up; this works
4. Click the top one and click the down arrow; nothing happens

--------------------------
**Version**: unspecified
**Severity**: normal
This is related to bug 38129.

The alt text box in the media dialog is only about two-thirds the width of the screen, with no possibility of wrapping/scrolling down.  Maybe eight words fit in it (two-thirds of the example given in the lead of https://en.wikipedia.org/wiki/WP:ALT).  

It should be at least the normal width of the dialog.

--------------------------
**Version**: unspecified
**Severity**: minor
Verified the fix in test2
Change 114022 merged by jenkins-bot:
Make alternate text input stretch to full width

https://gerrit.wikimedia.org/r/114022
Change 114022 had a related patch set uploaded by Mooeypoo:
Make alternate text input stretch to full width

https://gerrit.wikimedia.org/r/114022
This is related to bug 51293, bug 61323, and the general bug 38129:

The alignment options in the media dialog's advanced settings are:

Left
Center
Right
None

It is the convention to not specify the alignment when choosing the default, mostly to avoid needless clutter in the wikitext.  If the default is right (or left), and the user chooses that default, then VisualEditor should not add "right" but instead should leave the alignment setting empty.

--------------------------
**Version**: unspecified
**Severity**: minor
*** Bug 61565 has been marked as a duplicate of this bug. ***
Done last week (I think).
This is related to bug 51293 and the general bug 38129:

The alignment options in the media dialog's advanced settings are:

Left
Center
Right
None

These are the four explicit settings provided in MediaWiki.

Most users, even if they click on a few buttons to consider other options, are going to want the image at the default (i.e., on the right for left-to-right languages).  It is the convention to not specify the default, mostly to avoid needless clutter in the wikitext.

Most users have no idea what "None" does because they've never encountered it before.  They're going to think that it means "unspecified default", rather than left-and-clear.  

It would be good to offer a "default" button, even though this duplicates the function of one of the existing buttons.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Verified the fix in betalabs.
*** Bug 56609 has been marked as a duplicate of this bug. ***
Done in gerrit 114420.
Actual Results:  
You can only see about 1.5 lines of text.  It should be tall enough to display two lines of text, even if people are using slightly larger fonts.


Reproducible: Always

Multiple complaints with screenshots:

https://en.wikipedia.org/wiki/File:Euromaidan_VisualEditor_infobox.PNG

https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_13#Multiple_issues_-_minimal_space

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60541
Cool, please keep no limit for the size, some template have a lot of content :
https://fr.wikipedia.org/w/index.php?title=Espèces_du_genre_Carex&oldid=96878307&veaction=edit
*** Bug 61859 has been marked as a duplicate of this bug. ***
Other suggestions from en.wp:
 
* At least three lines tall.

* Scrollbars as needed.

* Ability to resize the window vertically.

* Replace the grey area between parameters by a line (less space wasted, as readable as before), don't use large padding inside the fields, reduce white space between parameter name and value.
We may want to re-visit this when these boxes are rich content, but whilst as wikitext they're likely to be expansive more often than not.
Screenshot

Steps to reproduce:

1.Open this page with VE:http://en.wikipedia.beta.wmflabs.org/wiki/12thfebchrome?veaction=edit

2.Go to the Media Settings for the image:[[File:Dau ho thoi Ho.png]]

3.Set the Width size of the image to 8000 and Apply changes (Works fine)

4.Set the Width of the image to 8000000 and apply changes (Still work fine)


5.Set the Width of the image to 80000000 and Apply changes 

Observed Result:
The image shrinks to a dot size in the VE mode


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**: {F13328}
This looks like it's now fixed, I think.
Created attachment 14785
Reproduced on windows8-chrome

**Attached**: {F13330}
I can't replicate here; I set the image even up to "800000000000000000000" width and still it resized as "expected".
Created attachment 14761
This is how it appears in the review changes in the save dialog

**Attached**: {F13329}
I see this image as a huge one. There is a bug here that the context menu is hidden outside the page (should be reported separately) but I don't see this as a dot-size.

Checked under Windows on Chrome version 33.0.1750.146 m and Firefox 27.0.1

In both cases, I see this image as humongous, which is exactly as it appears in the "view" mode. 

I can't manage to replicate the "dot-image" effect.
Another page and image where I encountered this issue: http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Hateres&veaction=edit
I can still reproduce this issue for the image :[[File:Dau ho thoi Ho.png]] with Frame and Basic Image type
Change 115939 merged by jenkins-bot:
Deal with 'none'/'border' and default size in media edit

https://gerrit.wikimedia.org/r/115939
Change 115939 had a related patch set uploaded by Mooeypoo:
[wip] Deal with 'none'/'border' and default size in media edit

https://gerrit.wikimedia.org/r/115939
I can still reproduce this issue.
Change 115307 merged by jenkins-bot:
Limit thumbnail dimensions in media edit dialog

https://gerrit.wikimedia.org/r/115307
Change 115307 had a related patch set uploaded by Mooeypoo:
[wip] Limit thumbnail dimensions in media edit dialog

https://gerrit.wikimedia.org/r/115307
I can't replicate the exact phenomenon, but it does seem to show an issue with maximum dimensions.

When I increase the size (even to the 80000000 width) I just get a humongous version of the stretched image. 

I'm looking into the conditions of limiting image scale size.
Intention:
edit Polish Wikipedia using VisualEditor

Steps to Reproduce:
1. difflink 1: https://pl.wikipedia.org/w/index.php?title=Amalowie&diff=38322555&oldid=38322515
2. difflink 2: https://pl.wikipedia.org/w/index.php?title=Amalowie&diff=prev&oldid=38322515
3. discussion link: https://pl.wikipedia.org/wiki/Wikipedia:VisualEditor/Opinie#Edytor_wizualny_psuje_przypisy

Actual Results:  
snowmen appear (see difflink 1) and text disappears or "gets eaten"

Expected Results:  
no snowmen and text is inserted where it is wanted

Reproducible: Didn't try

please see bug:54712 and bug:54976 re: snowmen

please see bug:51624 and bug:50286 re: backspace

--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://pl.wikipedia.org/wiki/Wikipedia:VisualEditor/Opinie#Edytor_wizualny_psuje_przypisy
I played around a bit with Chrome, Firefox and Opera and couldn't reproduce. Closing as WORKSFORME, but that feels bad…
I /think/ the editor replied that that problem didn't occur again since, and that he doesn't want to test further. If you want you can play with my sandbox at https://pl.wikipedia.org/wiki/Wikipedysta:Elitre_(WMF)/sandbox or just close this provisionally. Thanks.
I asked for details at pl.wp.
Difficult to do anything without steps to reproduce...
Misaligned Undo/Re-do buttons at Beta Labs

The Undo/re-do buttons aren't lined up properly in the toolbar at Beta Labs.

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F13192}
Change 112946 abandoned by Jforrester:
Fix margins after they were broken in 9d988924

Reason:
Whoops, this is wmf13 only.

https://gerrit.wikimedia.org/r/112946
Change 112814 merged by jenkins-bot:
Fix margins after they were broken in 9d988924

https://gerrit.wikimedia.org/r/112814
Change 112947 had a related patch set uploaded by Jforrester:
Fix margins after they were broken in 9d988924

https://gerrit.wikimedia.org/r/112947
Change 112946 had a related patch set uploaded by Jforrester:
Fix margins after they were broken in 9d988924

https://gerrit.wikimedia.org/r/112946
Change 112814 had a related patch set uploaded by Jforrester:
Fix margins after they were broken in 9d988924

https://gerrit.wikimedia.org/r/112814
Resolved in Ie6b47f5d1929533669118ba51202c1fccda4a0d6

Basically, Liangent made a change to the padding of the content div Vector and didn't make a corresponding change to the toolbar in the VisualEditor extension.
Take text. Make link to page ("Foo"). Observe wikitext. Good.

Take text. Make link to page with section ("Foo#Bar"). Observe wikitext. Bad.

--------------------------
**Version**: unspecified
**Severity**: major
Fixed in gerrit 112898.
Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Go to Media Settings>Advanced Settings for that image
4.Select the option Border under Image Type

Observed Result:
There is no value/Change appears for this image type
The resulting wikitext is:
[[File:Wheat (flo).JPG|200x200px||left]]

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/w/index.php?title=10thFeb&action=edit

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production:https://en.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/sandbox&veaction=edit
Verified the fix in test2
Verified the fix in Betalabs
Change 115939 merged by jenkins-bot:
Deal with 'none'/'border' and default size in media edit

https://gerrit.wikimedia.org/r/115939
Change 115939 had a related patch set uploaded by Mooeypoo:
[wip] Deal with 'none'/'border' and default size in media edit

https://gerrit.wikimedia.org/r/115939
Created attachment 14708
Screenshot

**Attached**: {F13029}
Still not working for me.I could still reproduce it in page:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=27thfebff&action=edit

See the screenshot attached
Change 112041 merged by jenkins-bot:
Revamp media edit dialog's position widget

https://gerrit.wikimedia.org/r/112041
Change 112041 had a related patch set uploaded by Jforrester:
Revamp media edit dialog's position widget

https://gerrit.wikimedia.org/r/112041
Found the bug, the wikitext doesn't have |border even though the CE is updated.

This commit seems to fix it: https://gerrit.wikimedia.org/r/#/c/112041/
Cannot replicate in master in both Chrome 32 and Firefox 27 under Ubuntu.
In French, the option to switch to wikitext is called "Basculer vers la modification du code". In Italian, it's "Passa alla modifica sorgente".
In both languages the text is so long you need to slide to the right to see all of it. Is there a better way to display it?

--------------------------
**Version**: unspecified
**Severity**: minor
Merging into bug 57366.

*** This bug has been marked as a duplicate of bug 57366 ***
I spent a while looking into this. I gave up but here is what I found anyway

First of all I tried to make it expand outwards instead of squashing against the side, and couldn't get that to work.

Then I tried making the text wrap instead, found I could set the white-space CSS property on the tool title which kind of did the job, but it was not working well enough (last word of a wrapped line would overflow). I found word-break: break-word; but that only made things look worse.
I asked on fr.wp. On the Italian one, this is still the case with Monobook, but Vector displays the message just fine...
Could we improve the translations to be briefer?
In mobile various JavaScript and CSS modules are loaded that are not needed including OO JS UI.css (see https://gerrit.wikimedia.org/r/#/c/109940/)

After talking to Trevor and Timo we agreed that it would be a good idea to refactor and break out many of VisualEditor's modules to support a much slimmer mobile version.

--------------------------
**Version**: unspecified
**Severity**: normal
Done.
Change 113488 merged by jenkins-bot:
Split up ext.visualEditor.mwcore into smaller parts

https://gerrit.wikimedia.org/r/113488
Change 113487 merged by jenkins-bot:
Split VE-MW's ve.ce.Node.css file into per-node files

https://gerrit.wikimedia.org/r/113487
Change 113488 had a related patch set uploaded by Jforrester:
Split up ext.visualEditor.mwcore into smaller parts

https://gerrit.wikimedia.org/r/113488
Change 113487 had a related patch set uploaded by Jforrester:
Split VE-MW's ve.ce.Node.css file into per-node files

https://gerrit.wikimedia.org/r/113487
"visualeditor-linkinspector-suggest-matching-page": "Matching page",
"visualeditor-linkinspector-suggest-disambig-page": "Disambiguation page",
"visualeditor-linkinspector-suggest-redirect-page": "Redirect page"

These messages should be something like {{PLURAL:$1|Matching page|Matching pages}} instead, and be passed the number of pages in the section.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 112164 merged by jenkins-bot:
Pluralise visualeditor-linkinspector-suggest-(matching|redirect|disambig)-page

https://gerrit.wikimedia.org/r/112164
Change 112164 had a related patch set uploaded by Alex Monk:
Pluralise visualeditor-linkinspector-suggest-(matching|redirect|disambig)-page

https://gerrit.wikimedia.org/r/112164
Steps to reproduce:

1.Open a page with VE
2.Add an image
3.Open the media settings for that image
4.Go to Advanced Settings tab
5.Change the image size to something different than what it is right now
6.Click on "Apply Changes"
7.Reopen the Media Settings again and go to Advanced Settings panel

Observed Results:
The Size values are still reflecting the previous value unless user saves the whole page and open the panel again it stays like this.


Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/7thfeb?veaction=edit#cite_ref-2

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix on test2
Change 112950 merged by jenkins-bot:
Quick fix: image size property update

https://gerrit.wikimedia.org/r/112950
Change 113014 had a related patch set uploaded by Catrope:
Quick fix: image size property update

https://gerrit.wikimedia.org/r/113014
Change 112950 had a related patch set uploaded by Mooeypoo:
Fix image size property update

https://gerrit.wikimedia.org/r/112950
Screenshot

Steps to reproduce:


1.Open a page with VE which contains a image at the right

2.Select the image 

3.Go to the Media Settings> Advanced Settings

4.Move the position of the image to center

5.Select some other element or just click outside the image anywhere on the page


Observed result:
Cannot select any other object in the page 
An error appears in the console:
Uncaught Error: Offset could not be translated to a DOM element and offset: 227

See the screenshot attached.
Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
Page:http://en.wikipedia.beta.wmflabs.org/wiki/Ehat?veaction=edit

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

**Attached**: {F13303}
verified the fix in test2
Change 113258 merged by jenkins-bot:
Prevent clicks on top-most shield for centered image nodes

https://gerrit.wikimedia.org/r/113258
I believe that gerrit 113256 fixed part of this issue.
Change 113258 had a related patch set uploaded by Jforrester:
Prevent clicks on top-most shield for centered image nodes

https://gerrit.wikimedia.org/r/113258
It happens while moving an image from Left to Right too
1. Select a block image with caption
2. Press the list button

Expected:
Either nothing, or a list is created above/below the image

Observed:
The caption is wrapped in a list

Clearly we need to ignore nodes which are inside handlesOwnChildren nodes when applying such actions.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60804
Change 111822 merged by jenkins-bot:
Don't descend into handlesOwnChildren nodes in selectNodes

https://gerrit.wikimedia.org/r/111822
I'm assuming that bug 60804 the same issue.
Change 111822 had a related patch set uploaded by Esanders:
Don't descend into handlesOwnChildren nodes in selectNodes

https://gerrit.wikimedia.org/r/111822
See 
https://it.wikipedia.org/w/index.php?title=Utente%3AElitre_%28WMF%29%2FSandbox_VE3&diff=63988076&oldid=63988055 ,
or https://it.wikipedia.org/w/index.php?title=Oreste_Tommasini&diff=63836558&oldid=61161898, or https://it.wikipedia.org/w/index.php?title=Frederic_William_Maitland&diff=63692381&oldid=59785358 .

Reproduced with Chrome, FF, Opera (unlogged), tested with both skins.

You only need to add the Template:Interprogetto to an existing page or a new one.
Useless code like <span data-ve-ignore="true" about="g0.8632714317645878"></span> is added.
James, bug 59653, IMHO, had a similar problem.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60375
Change 111518 merged by jenkins-bot:
Only generate transclusion contents for clipboard

https://gerrit.wikimedia.org/r/111518
Change 111518 had a related patch set uploaded by Esanders:
Only generate transclusion contents for clipboard

https://gerrit.wikimedia.org/r/111518
(In reply to comment #5)
> Is Bug 60375 related?

Looks like it.
Moving it back to VE.
Is Bug 60375 related?
This is scenario #3 from https://www.mediawiki.org/wiki/Parsoid/DOM_notes#Efficient_re-rendering_on_edits
So this is caused by new templates always being inline templates, as we don't know if they are block templates until they render. As a result the above HTML is invalid (<ul> inside a <p>) which after Parsoid fixes, means the about-grouped items are no longer siblings.
This extra HTML is correctly added here for the sake of putting something meaningful into the external clipboard. data-ve-ignore tells the converter to ignore it if it's pasted into another VE instances, and about="g[random]" tells Parsoid to ignore it. However the about grouping appears not to be working at Parsoids end:

HTML:
<p><span about="g1" typeof="mw:Transclusion" data-mw="{&quot;parts&quot;:[{&quot;template&quot;:{&quot;target&quot;:{&quot;href&quot;:&quot;Template:Interprogetto&quot;,&quot;wt&quot;:&quot;Interprogetto&quot;},&quot;params&quot;:{&quot;commons&quot;:{&quot;wt&quot;:&quot;cats&quot;}}}}]}" data-ve-no-generated-contents="true"></span><span data-ve-ignore="true" about="g1"></span><ul data-ve-ignore="true" about="g1">
<li>Foo</li>
</ul>
<span data-ve-ignore="true" about="g1">

</span></p>

Wikitext:
{{Interprogetto|commons = cats}}
* Foo

<span data-ve-ignore="true" about="g1"></span>

The first about-grouped sibling is discarded, but the subsequent ul and span are not.
There was a related issue beforehand – but this isn't getting copied, so I can't work out out data-ve-ignore is getting added to the HTML?
link text appearing for the second time

Steps to reproduce:

1.Select a math function/image/gallery/hiero
2.Now open the link inspector
3.Insert a link (this link gets placed just before the selected element)
4.Again select the element
5.Open the link inserter
6.Observe that the link title of the previous link is appearing now in the link inspector
7.Close the link inspector.

Observed Result:
The link text title of the previous link is getting inserted just before the selected element.

See the screenshot attached.

Test Environment: https://test2.wikipedia.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Page:https://test2.wikipedia.org/wiki/Image_then_gallery?veaction=edit

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

**Attached**: {F12936}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
I can't reproduce. Probably fixed by Ed's recent cleanup of the link inspector.
Never mind, I'm an idiot. It's still broken if you try to inspect the same reference with the link inspector twice in a row.
Confirmed fixed in master but not in wmf18.
I think this is fixed now? I can't reproduce it any more...
Roan says the fix is to fix the pre-population of the link inspector in create mode. I think.
Selection's not being re-set to the actual link (of the pre-annotation stack or something odd)?
This is not yet fixed.The link text is still getting added next to the previously added link
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
Created attachment 14487
link text getting added before math function

**Attached**: {F12937}
Any time I try to use the mobile VisualEditor on a page that includes an image, it is not editable due to having a protectedNode-shield covering most of the page. You can see an example at:
https://en.m.wikipedia.org/wiki/Rice_flour#editor/0

The protectedNode-shield has a width of 100% and a height of 100% and it appears that each image creates a new one.

--------------------------
**Version**: unspecified
**Severity**: major
**jgonera** wrote:

Fix in https://gerrit.wikimedia.org/r/#/c/113475/
*** Bug 60103 has been marked as a duplicate of this bug. ***
Intention:
Add a gallery

Steps to Reproduce:
1. Open a page in Safari.

2. Go to Insert > Gallery

3. Type in the name of an image and a caption.  *Don't click or type anywhere else after this.*

4. Click on the save button.

5. Realize that the gallery dialog is still open, so cancel the save box.  The dialog will close and the gallery will display.

6. Click on the save button again.

Actual Results:  
The gallery displays on screen, but is not present in Review Changes or when the page is saved.

If you click outside the gallery dialog after typing the name, or if you click the mysterious < button, then it works as expected.

Expected Results:  
A button at the bottom of the gallery inserter that says "Insert this gallery now".

Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=67049
Change 112893 merged by jenkins-bot:
Give the document focus on save dialog open to resolve inspectors

https://gerrit.wikimedia.org/r/112893
(In reply to comment #6)
> 2. OOUI defers the close event of the dialog by 250ms for animation purposes,
> after which we set up a one-time listener to surface-transact to clear the
> serialization cache, but the transaction has already happened.
> 
Is there an event / method in OOUI (closing as opposed to close, maybe?) that fires before the animation? Then we could listen to that and immediately attach the event listener.
1. The document is given focus, triggering events which result in the inspectors being closed, and a transaction being created which inserts the extension node.
2. OOUI defers the close event of the dialog by 250ms for animation purposes, after which we set up a one-time listener to surface-transact to clear the serialization cache, but the transaction has already happened.

Fix:
Give the document focus before opening the save dialog to make sure it's in a more stable state.
Change 112893 had a related patch set uploaded by Esanders:
Give the document focus on save dialog open to resolve inspectors

https://gerrit.wikimedia.org/r/112893
Actually the CE and DM aren't out of sync, but the new document isn't being passed to Parsoid.
Yuck.

Clicking out of an inspector *into the surface* causes the inspector to close, applying changes.

Clicking out of an inspector *outside the surface* (such as the save dialog launcher) causes the inspector to not close; when the save dialog is closed, this also closes the inspector and "insert" the content into CE but NOT DM, causing them to get out of sync. Not good.
More Observation: This issue happens for all other inspector for example: Math,Hiero, Link inspector.
Created attachment 14483
Screenshot displaying a visible gallery, and displaying the absence of the gallery in the wikitext code

**Attached**: {F12922}
Steps to reproduce:

1.Open a page with VE
2.Insert a image
3.Open the media settings for the image
4.Insert a link as a caption
5.Save the page
6.Reopen the page and select the image
7.Open the link inspector and type in a different a link inside it
8.Save the page
9.Reopen the page and the Media Settings for the image

Observed Result:
The link inside the caption got changed by the link inserter in step 7

Test Environment: https://test2.wikipedia.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Page:https://test2.wikipedia.org/w/index.php?title=3rdfebFF&veaction=edit

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60969
https://bugzilla.wikimedia.org/show_bug.cgi?id=58045
Verified the fix in production
Verified the fix in mediawiki.org
Change 123429 merged by jenkins-bot:
Skip over handlesOwnChildren nodes in newFromAnnotation

https://gerrit.wikimedia.org/r/123429
Change 123429 had a related patch set uploaded by Esanders:
Skip over handlesOwnChildren nodes in newFromAnnotation

https://gerrit.wikimedia.org/r/123429
If there are multiple links inside the media caption then the link applied outside the image gets applied to all other links .
Created attachment 14472
Screenshot of the error

**Attached**: {F12832}
Intention:
Replicate a mess seen at https://pt.wikipedia.org/w/index.php?title=Esporte_Clube_Pelotas&curid=68824&diff=38075497&oldid=38075466

Steps to Reproduce:
1. Start creating a new reference.
2. Open nytimes.com and select both some text and one small image. 
3. Copy the selection and paste it into the ref dialog box.

Actual Results:  
In Safari, nothing pastes.  In Firefox, both text and image rich-paste into the ref dialog box, but I can't save the page.

Expected Results:  
That the image would be discarded, since it's not uploaded to the wiki.

Reproducible: Sometimes

--------------------------
**Version**: unspecified
**Severity**: normal
Verified in betalabs.
AFAICT this is now completely fixed; however, in testing this I uncovered bug 72385 which is sigh-inducing.
**As an editor I can get paste a link or DOI into a simple form to get an auto-filled citation.**

A user has their cursor in a place they would like to add a citation. 
They click the Cite button on the toolbar. 
An inspector opens in context, showing the title "Cite" a URL field, and a "Lookup" button.

Click-through prototype http://invis.io/HR2DK2FXM

**Workflow**
{F55330}

**Detail of citation inspector**
Include line below field with link that opens the manual citation dialogue.
{F45790}

**Manual Citation Dialogue**
First step now includes all items in the former Cite menu
{F43867}

**Errors**
DOI error - if incorrect amount of characters entered
{F43776}

URL error - if page not found
{F45749}

Generic error
{F45752}

--------------------------
**Version**: unspecified
**Severity**: enhancement
>>! In T62768#1138925, @Mvolz wrote:
> FYI citoid does not support ISBNs yet so I edited that bit out- very surprised to find out we supported ISBNs when I read the tech bulletin on my RSS reader this morning, and it was probably because it was in the description here. 

Thank you for the heads-up. I wasn't sure we'd be announcing this in Tech News, because I was confused about the status of this feature, due to last week's rushed deployment. This is why this task was marked as "Not ready to announce" (which does apply to Tech News). On Friday, James added the item to the newsletter, and I edited it to use simpler language; I also added the ISBN bit, based on this task's title.

> @gpaumier Also, I noticed this is tagged "not ready to announce" yet - does that not apply to tech bulletin? If so there's still technically time to remove it because even though it ended up in my RSS reader, because publication is not technically until tomorrow. 

Yes, however we can't make last-minute edits to the newsletter because that only changes the English version; translators need more time to echo the changes.

Considering that:
* the current text is inaccurate and could cause confusion if sent,
* the current text only concerns two wikis that have already been notified of the feature,
* and there is no urgency in sending this information,
I've removed the Citoid item from this week's issue entirely, and added it to the list of items to announce in next week's newsletter.
Elitre, I agree. It hasn't been re-triggered for translation yet so there
is still time to remove that link.
(I find the link to the [[ https://www.mediawiki.org/wiki/VisualEditor/Design/Reference_Dialog | design page ]] confusing. Some parts of the interface are different in production - and the last 2 screenshots on the page would show the regular Cite flow - which is not so "connected" to Citoid.)
FYI citoid does not support ISBNs yet so I edited that bit out- very surprised to find out we supported ISBNs when I read the tech bulletin on my RSS reader this morning, and it was probably because it was in the description here. 

@gpaumier Also, I noticed this is tagged "not ready to announce" yet - does that not apply to tech bulletin? If so there's still technically time to remove it because even though it ended up in my RSS reader, because publication is not technically until tomorrow.
FYI citoid does not support ISBNs yet so I edited that bit out- very surprised to find out we supported ISBNs when I read the tech bulletin on my RSS reader this morning, and it was probably because it was in the description here. Also, I noticed this is tagged "not ready to announce" yet - does that not apply to tech bulletin? If so there's still technically time to remove it because even though it ended up in my RSS reader, because publication is not technically until tomorrow.
Change 198261 abandoned by Mooeypoo:
Add general citations dialog

Reason:
Not needed.

[[https://gerrit.wikimedia.org/r/198261]]
Change 198261 had a related patch set uploaded (by Mooeypoo):
Add general citations dialog

[[https://gerrit.wikimedia.org/r/198261]]
Change 197925 merged by jenkins-bot:
Enable Citoid extension on all VisualEditor wikis

[[https://gerrit.wikimedia.org/r/197925]]
Change 197925 had a related patch set uploaded (by Alex Monk):
Enable Citoid extension on all VisualEditor wikis

[[https://gerrit.wikimedia.org/r/197925]]
Change 197074 merged by jenkins-bot:
Enable Citoid extension on all VisualEditor wikis

[[https://gerrit.wikimedia.org/r/197074]]
Change 195802 merged by jenkins-bot:
Redesign the citation widget in the citoid inspector

[[https://gerrit.wikimedia.org/r/195802]]
Change 196645 merged by jenkins-bot:
Add general citations dialog

[[https://gerrit.wikimedia.org/r/196645]]
Change 197074 had a related patch set uploaded (by Jforrester):
Enable Citoid extension on all VisualEditor wikis

[[https://gerrit.wikimedia.org/r/197074]]
Change 196645 had a related patch set uploaded (by Mooeypoo):
[wip] Add general citations dialog

[[https://gerrit.wikimedia.org/r/196645]]
Change 195802 had a related patch set uploaded (by Mooeypoo):
Redesign the citation widget in the citoid inspector

[[https://gerrit.wikimedia.org/r/195802]]
>>! In T62768#1094741, @Eloquence wrote:
> Can we project a "week of" deployment ETA?

No. Everything is backed up on {T89656} which has an unknown schedule.
Can we project a "week of" deployment ETA?
Hi Marielle,
I think we should leave the user on the same screen, in case they messed up the number and want to try again. 
We should show an error message that says something like "We couldn't find that book" and maybe give a hint like "An ISBN is usually 10 or 13 digits."
And the user still has the option at the bottom to go to the screen to enter the citation manually.
{F20069}
Hi Kaity,

What should the user see if there are no results?

For most urls I think it should just be the linked url, and then they can edit that, but for some identifiers (like issn, isbn) it's definitely possible there won't be anything to display at all. And we may or may not know what kind of ID it is (although we could guess?) I'm assuming it should go to this page https://www.mediawiki.org/wiki/VisualEditor/Design/Reference_Dialog#mediaviewer/File:Magic_cite4-02.png automatically but should there be some sort of error message or something....

Also it's possible that if the scraping is bad- i.e. it's just the text of the url as the title- these automatically are set as web citations, but it's possible the user will want to change the citation type from web to journal, for instance. Any thoughts on that?
(In reply to WhatamIdoing from comment #0)
> It would be convenient if the reference tool would autofill {{cite book}}
> from a URL to books.google.com  This is done in several existing gadgets on
> the English Wikipedia and is especially helpful for books that do not have
> ISBNs.

Czech Wikipedia could be filled from national book database. I think their API might be available to us as we were already negotiating with them. Basically every time I fill reference template and also ISBN variable I wonder, why this cant be done automaticaly as in many countries such data are available and readable for scripts.

But what Ive been talking about in https://bugzilla.wikimedia.org/show_bug.cgi?id=60863

was just to load some basic options and than the user should file them by values. But this proposal is even better.
*** Bug 60863 has been marked as a duplicate of this bug. ***
This is part of bug 50768's re-written merged form; am re-splitting and using this one for the second half.
http://en.m.wikipedia.beta.wmflabs.org/wiki/Forty-seven_Ronin?mobileaction=alpha#editor/0

Error: Container must be attached to the DOM Error {stack: (...), message: "Container must be attached to the DOM"}

--------------------------
**Version**: unspecified
**Severity**: normal
Change 110498 merged by jenkins-bot:
Fix VE error with latest VE master

https://gerrit.wikimedia.org/r/110498
Change 110498 had a related patch set uploaded by JGonera:
Fix VE error with latest VE master

https://gerrit.wikimedia.org/r/110498
@Juliusz: Looks like the .surface element selector here is either not finding anything at all or it is referring to something that is still detached at that point:

https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/c4264d76bc817df71c6b3631afb19be737246c52/javascripts/modules/editor/VisualEditorOverlay.js#L16

It doesn't have to be fully initialised, but the target container element should however be somewhere in the document.
This is exposing a pre-existing bug in mobile VE or MobileFrontend's VE integration or something in this ecosystem: you cannot initialize targets into a container that isn't already attached to the DOM. Previously, you could do this and various things regarding measurements would just break and render wrong, but now we throw an exception.
Steps to reproduce:


1.Open a page with VE
2.Now select an image or a reference note in the Page
3.Now Open the Gallery from Insert>Gallery

Observed Result:

It deletes the image and the reference note.

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
This was fixed a while ago by Ed.
And then close the Math inspector.
Sorry the third step should be "Insert>Formula"
The CSS file modules/ve-mw/ce/styles/ve.ce.Node.css implements styling of page content. This styling should be handled by the skin, not by VisualEditor. It looks like someone already figured this out, as most of the styles include TODO notes about merging them into core styles.

As the mobile team is now implementing VE with a mobile-specific skin, now would be the best time to make these fixes. Otherwise, lots of !important overrides will be necessary.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 112618 merged by jenkins-bot:
Move some skin styling from ve.ce.Node.css to a shared skin css file

https://gerrit.wikimedia.org/r/112618
Change 112618 had a related patch set uploaded by Kaldari:
Move some skin styling from ve.ce.Node.css to the skin styles

https://gerrit.wikimedia.org/r/112618
Talked to Roan. He definitely favors solution 2 and gave me some advice on implementing it. Apparently VE already has some skin styling in it (modules/ve-mw/init/styles/), so most of these styles should just be moved there.
There are two possible solutions:

1. Make VE's page DOM more similar to the normal rendered page DOM. That way VE won't have to worry about styling them as they'll be styled by existing skin styles. (This seemed to be a solution favored by Trevor.)

2. Add support for some VE-specific elements to the skins, for example, figure elements. (This seemed to be a solution favored by Roan.)

Probably the best solution is a combination of both. I would be happy to help with solution 2, although it would be nice to get some guidance from the VE team on what approach (or approaches) they would prefer to see (and possibly help implement).
What's the solution to this issue, though? Re-write MW's skins to work with nodes? 'Cos right now they don't…

"Fix MW's skin system" is a bit of a large tangential bug.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Select a text for example: "link with wikitext"
3.Press command+k to apply link on it
4.Without adding anything just close the inspector.
5.Save the page.
6.Reopen the page in VE

Observed Result:
The wikitext for the link is appearing in Read mode and in VE

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/23rd_january

See the screenshot attached

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

**Attached**: {F13098}
Verified the fix on test2 and mw.org
Verified the fix on Betalabs:http://en.wikipedia.beta.wmflabs.org/wiki/Jan_27th?veaction=edit
Change 109738 merged by jenkins-bot:
Followup 7994eae8c2: fix MWLinkInspector breakage

https://gerrit.wikimedia.org/r/109738
Change 109738 had a related patch set uploaded by Catrope:
Followup 7994eae8c2: fix MWLinkInspector breakage

https://gerrit.wikimedia.org/r/109738
Intention:
Add a template and remove a non-breaking space (&nbsp;) in the same line/paragraph

Steps to Reproduce:
(Order matters!)

1.  Begin with a page that contains the HTML code for a non-breaking space.  Open in VisualEditor.

2.  On the line that contains the nbsp, add a template (e.g., {{fact}}).  The template should be added to the same 'word' that contains the nbsp.

3.  Then remove the nbsp (replace with a plain space, or just delete the whole 'word').

Actual Results:  
VisualEditor added span text like <span about="g0.42287685585435686" data-ve-ignore="true"></span> when the nbsp was removed.

Adding a fact template to the end of:

1&nbsp;mg 2&nbsp;mg 3&nbsp;mg 4&nbsp;mg

turns into:

1&nbsp;mg 2&nbsp;mg 3&nbsp;mg 4 mg{{Fact}}<span data-ve-ignore="true" about="g0.5170239245053381"></span>

However, adding the template to "3 mg" and deleting the nbsp from "2 mg" works correctly:

1&nbsp;mg 2 mg 3&nbsp;mg{{Fact}} 4&nbsp;mg




Reproducible: Always

See https://en.wikipedia.org/w/index.php?title=Wikipedia%3AVisualEditor%2FFeedback&diff=591972176&oldid=591955710 and testing at https://en.wikipedia.org/w/index.php?title=User:Jay8g/sandbox&action=history on 23 January 2014 for many more details.

Found in Firefox 26 on Windows 7 with Monobook, confirmed in Safari 6 on Mac OS 10.8.5 with Vector.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60897
From following WhatAmIDoing's instructions, I can replicate in enwiki and it's fixed in Beta Labs; marking as FIXED.
Probably a duplicate of bug 60897

See if the fix there resolves this.
This also appears if you add any template after a {{convert}} template, and then remove the {{convert}} template.

If there are multiple nbsp's on the same line, them it is only the removal of the nbsp that is immediately before the template that appears to trigger it.
Reproducible: Didn't try

Two editors report that VisualEditor's "Edit beta" tab occcasionally does not appear on their screens.  Both were using Firefox on Windows 7.  The button reappeared upon refreshing the screen, or spontaneously reappeared the next day.

--------------------------
**Version**: unspecified
**Severity**: minor
I'm presuming that this is a duplicate of bug 54706.

*** This bug has been marked as a duplicate of bug 54706 ***
It happened to one of them again.
Possibly a JS transmission error; without detailed information we'll never have any idea what caused it, but let's keep this open in case there are further reports.
reedy@tin:/tmp/uploads$ sudo -u apache mwscript importImages.php --wiki=commonswiki --user="Jdforrester_(WMF)" /tmp/uploads
Import Images

Importing linux.conf.au 2014 - VisualEditor presentation.ogv...PHP Warning:  fopen(/tmp/uploads/linux.conf.au 2014 - VisualEditor presentation.ogv): failed to open stream: Permission denied in /a/common/php-1.23wmf10/includes/filebackend/SwiftFileBackend.php on line 278

Warning: fopen(/tmp/uploads/linux.conf.au 2014 - VisualEditor presentation.ogv): failed to open stream: Permission denied in /a/common/php-1.23wmf10/includes/filebackend/SwiftFileBackend.php on line 278
done.

Found: 1
Added: 1
reedy@tin:/tmp/uploads$


The added is a lie. The upload didn't complete, it's a 404

https://upload.wikimedia.org/wikipedia/commons/e/ea/Linux.conf.au_2014_-_VisualEditor_presentation.ogv

404 Not Found

The resource could not be found.

File not found: /v1/AUTH_mw/wikipedia-commons-local-public.ea/e/ea/Linux.conf.au_2014_-_VisualEditor_presentation.ogv

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60777
Change 111116 merged by Aaron Schulz:
Fixes and cleanups to FileOpBatch

https://gerrit.wikimedia.org/r/111116
Change 111115 merged by jenkins-bot:
Use "rb" instead of "rb+" for Swift store operation handles

https://gerrit.wikimedia.org/r/111115
Change 110993 merged by jenkins-bot:
Use "rb" instead of "rb+" for Swift store operation handles

https://gerrit.wikimedia.org/r/110993
Change 111116 had a related patch set uploaded by Aaron Schulz:
Fixes and cleanups to FileOpBatch

https://gerrit.wikimedia.org/r/111116
Change 111115 had a related patch set uploaded by Aaron Schulz:
Use "rb" instead of "rb+" for Swift store operation handles

https://gerrit.wikimedia.org/r/111115
Change 111111 merged by jenkins-bot:
Fixes and cleanups to FileOpBatch

https://gerrit.wikimedia.org/r/111111
Change 111111 had a related patch set uploaded by Aaron Schulz:
Fixes and cleanups to FileOpBatch

https://gerrit.wikimedia.org/r/111111
Change 110993 had a related patch set uploaded by Aaron Schulz:
Use "rb" instead of "rb+" for Swift store operation handles

https://gerrit.wikimedia.org/r/110993
I don't see any way around getting errors when trying to upload files as a user that can't see them. What exactly is this about?
If I chmod 777 it, I can upload it :/
**Author:** `llamaal_wikis`

**Description:**
Intention:
After the conclusion of https://es.wikipedia.org/wiki/Wikipedia:Votaciones/2014/Sobre_el_Editor_Visual on the Spanish Wikipedia, some changes to the status of VE in that project have to be implemented:

1. VE should now be opt-in
2. The "edit" tab should return to wikitext
3. VE should be presented as part of Beta Features
4. The tab for VE, if users activate it, should be "Editor VisualBETA"

Regards,

LlamaAl




Reproducible: Didn't try

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
This is now done.
**albertojuansebastian** wrote:

Thank you very much, James. If you have any doubt, ask us here or there: https://es.wikipedia.org/wiki/Wikipedia:Caf%C3%A9/Archivo/Noticias/Actual#Acuse_de_recibo. 

Regards.
_________________________________________________________________________
And thanks, Nemo. Maybe I could convince some of my 'tech collegues' on esWikipedia to take part in the discussion there.

Greetings.
_________________________________________________________________________
Thank you all. Albertojuanse.
(In reply to comment #11)
> Finally, even if they had nothing to do with the VisualEditor, several users
> have meant to note that more economics and human resources should be focuses
> on
> fixing existing problems such us the FastButtons —it was disabled weeks ago
> because a security breach—, the cellular phone and portable devices editing
> softwares, etc.

Indeed beyond the scope of a bug: I've copied this to https://www.mediawiki.org/?diff=902629&oldid=892609 . It would be useful if those users (or other users who understand Spanish and read their comments) could elaborate/continue the discussion there, I think.
Understood. Thank you for the responses. I have adjusted the configuration change to correct for these issues as much as we can.

I will now ask my colleagues to find a time that we can make these changes.
**albertojuansebastian** wrote:

(In reply to comment #9)

Indeed. We are already discussing the answers in our Café (Village pump). In fact, in a few days (2 or 3)  we will be able to give you the answers, since it seems that we are reaching consensus. Greetings.
Shouldn't these "big questions" be brought up with the entire eswiki community, rather than on Bugzilla where only the single community member who filed the bug will see?
Some questions and points (sorry for being slow; I've been on leave, returning next week):

1. When you say "VE should now be opt-in", what should happen to the accounts that have been using VE? Should they be opted-in, or just left stranded without VisualEditor? Should the default for new accounts be to have to find VisualEditor to switch it on?

2. You want the labels to be "Edit" for wikitext and "Editor Visual" for VisualEditor? Which way around should they go? (Right now eswiki has VE as the primary/first tab, but we could change it to secondary/second tab if you think it would be a good change. However, that would be a bit odd to do as well as the opt-in, and is more an alternative.

3. Also on the labels of the tabs, in general, we're not happy with the "beta" superscript note and we were planning to get rid of it in the next few weeks. I don't think it makes sense for an opt-in system with two warnings about the software being beta to have a third, and it doesn't work very well in Firefox and some other platforms due to browser bugs.

4. What is the plan to inform users who have been using VisualEditor as to the disruption? Particularly, what is the plan for anonymous editors (who can't opt-in)? About 20% of edits by anonymous users have been through VisualEditor to date, and this is likely to confuse them.

5. What is the plan for returning to use VisualEditor as the primary editor? What changes or fixes would you like to see?
Change 109639 had a related patch set uploaded by TTO:
Move VisualEditor to secondary status on eswiki

https://gerrit.wikimedia.org/r/109639
Just to explain:

This request is easy, except for the desire to have the VisualEditor tab labelled "Editor Visual <sup>BETA</sup>". It is not currently possible to label the VisualEditor tab differently from the regular "Edit" tab (other than the appending of a BETA suffix), this would appear to require an alteration to the VisualEditor software itself.

The remaining three points of the request can be fulfilled easily, I think.
**llamaal_wikis** wrote:

I want to clarify something: the "BETA" part in the name of the Visual Editor tab should appear in small and superscript text, as shown in this diff [1].

[1] https://es.wikipedia.org/w/index.php?title=Wikipedia%3AZona_de_pruebas%2F5&diff=72006555&oldid=71969129
**llamaal_wikis** wrote:

(In reply to comment #3)
> (In reply to comment #1)
> > 4. The tab for VE, if users activate it, should be "Editor VisualBETA"
> Note that this is different from the enwiki config (the rest of the request
> is
> the same). On enwiki:
> * users who have VE disabled only see one tab, labeled "Edit", that points to
> the source editor
> * for users who have VE enabled, this tab is labeled "Edit source" instead
> * additionally, they have a VE tab labeled "EditBETA"
> * the VE tab appears after (to the right of) the source editor tab
> 
> For eswiki, #4 in the request asks us to implement the third bullet point
> differently, by labeling the VE tab "Editor VisualBETA" rather than
> "EditarBETA".
> 
> So what should happen to the source editor tab for users who have VE enabled?
> Should it be labeled "Editar código" (as it is now, and would be with an
> enwiki-like configuration), or as "Editar", or ... ? Should it appear before
> or
> after the source editor tab (right now it's before, with an enwiki-like
> configuration it would be after).

In the case a user enables VE, the source editor tab should remain as "Editar", and a new tab labeled "Editor VisualBETA" should appear after it.
(In reply to comment #1)
> 4. The tab for VE, if users activate it, should be "Editor VisualBETA"
Note that this is different from the enwiki config (the rest of the request is the same). On enwiki:
* users who have VE disabled only see one tab, labeled "Edit", that points to the source editor
* for users who have VE enabled, this tab is labeled "Edit source" instead
* additionally, they have a VE tab labeled "EditBETA"
* the VE tab appears after (to the right of) the source editor tab

For eswiki, #4 in the request asks us to implement the third bullet point differently, by labeling the VE tab "Editor VisualBETA" rather than "EditarBETA".

So what should happen to the source editor tab for users who have VE enabled? Should it be labeled "Editar código" (as it is now, and would be with an enwiki-like configuration), or as "Editar", or ... ? Should it appear before or after the source editor tab (right now it's before, with an enwiki-like configuration it would be after).
*** Bug 60189 has been marked as a duplicate of this bug. ***
**llamaal_wikis** wrote:

After the conclusion of
https://es.wikipedia.org/wiki/Wikipedia:Votaciones/2014/Sobre_el_Editor_Visual
on the Spanish Wikipedia, some changes to the status of VE in that project have
to be implemented:

1. VE should now be opt-in
2. The "edit" tab should return to wikitext
3. VE should be presented as part of Beta Features
4. The tab for VE, if users activate it, should be "Editor VisualBETA"

Regards,
Screenshot of the bug

See attached screenshot.

This is because the standalone demo initializes the target into a detached DOM element, then attaches it once it's done. But you can't do that, because it causes ve.ui.Toolbar.prototype.initialize to be run before the toolbar is attached to the DOM (and generally causes initialize to be run on unattached things, which is not allowed), which means its measurements will be wrong, and so the toolbar gets right: 1840px; (width of screen) rather than width: 63px; or whatever.

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

**Attached**: {F13274}
*** This bug has been marked as a duplicate of bug 59720 ***
Broken inspector

Steps to reproduce:

1.Open the VisualEditor
2.Go to Insert menu and Settings menu

Observed Result:
<visualeditor-mwgalleryinspector-title> and <visualeditor-dialog-commands>  is appearing in the Insert menu and Settings menu respectively.
Also selecting <visualeditor-mwgalleryinspector-title> opens up a broken gallery inspector.

See the screenshot attached.

Test Environment: https://test2.wikipedia.org/,wmf11
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F13165}
Verified the fix in test2 using Chrome and FF
Now fixed.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Add a math function from Insert>Formula for example \pi
3.While the added math formula is still selected go to Insert>Hiero
4.Observe that the math function previously added is now appearing in hiero inspector.
5.Close the inspector for hiero
6.Save the page

Observed Result:
A hiero tag got added  in the wikitext as  <hiero>\pi</hiero>

See the screenshot attached

Test Environment: https://test2.wikipedia.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Page:https://test2.wikipedia.org/w/index.php?title=Wmf11&veaction=edit

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

**Attached**: {F13157}
Can not reproduce from my end as well.Closing the bug.
Can't reproduce, might have been fixed by https://gerrit.wikimedia.org/r/#/c/111178/ ? Please test again.
When you "switch" inspectors the content of the first inspector is inserted, but a new inspector isn't created (so the content of the first is also available for the new one).
Selecting a line of text and turning it into a header (ctrl+1) removes the selection highlighting but keeps the text selected. Additionally turning text into a header also moves the position marker to the wrong place (visually).

As a result e.g. the action of creating a header then pressing enter replaces the header by an empty line.

Se screencast below for procedure and illustration.
https://www.youtube.com/watch?v=7OtpP5iS2uw

Reproducible in Chrome and Firefox

--------------------------
**Version**: unspecified
**Severity**: minor
*** This bug has been marked as a duplicate of bug 57552 ***
Oh nos!

When trying to edit San Francisco with VE in mobile alpha mode all hell breaks lose.

See for yourself at this URL:
https://en.m.wikipedia.org/wiki/San_Francisco?mobileaction=alpha#editor/0

and see screen for the sort of things that happen.

I can't focus the textarea or make any changes. This makes me sad.

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F13080}
This appears to have been fixed by the changes that Juliusz and Jon made last month.
https://jv.wikipedia.org/w/index.php?title=Kraton_Ngayogyakarta_Hadiningrat&curid=87083&diff=879162&oldid=845799

This begins with a =Level 1 heading= (perhaps the article title was copied?).  Some paragraphs are broken onto separate lines. The [[links]] are improperly converted to [[http://jv.wikipedia.org/wiki/Links]].

--------------------------
**Version**: unspecified
**Severity**: normal
Whenever we fixed this, it's certainly not a problem now.
The H1 is just external copy of the read HTML (and isn't a bug, just bad user behaviour).

The links getting badly converted are bug 58136.

However, the paragraphs getting split is a new regression in Firefox pasting behaviour. :-(
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Transclusion 
3.Add some content and click on "Apply changes"
4.Click on "Save Page"

Observed Result:

The "Save Page" button does not worl.In the console the following error appears:
TypeError: currentDom[i].setAttribute is not a function

See the screenshot attached.

Test Environment: https://test2.wikipedia.org/
Browser:  FF 25
OS: MAC OS X 10. 8. 5 
Page:https://test2.wikipedia.org/wiki/Jan_13th?veaction=edit

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

**Attached**: {F12850}
Verified the fix  in test2
This should have been fixed by https://gerrit.wikimedia.org/r/#/c/107511/
Screenshot

Steps to reproduce:

1.Open a page with VE which has some content
2.Add any image from Insert>Media after going to a newline.
3.Save the page
4.Reopen the page
5.Place the cursor in a new line and hit return

Observed Result:
Newline cannot be added , in the console an error appears:
TypeError: outermostNode is null
	

...documentModel,selection.from,'\n');}else{node.traverseUpstream(function(node){if...

load.p...1826Z&* (line 261)

Test Environment: mw.org
Browser: FF 25
OS: MAC OS X 10. 8. 5

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/w/index.php?title=User:Jdforrester_(WMF)/Sandbox_345&oldid=885285?veaction=edit

**Attached**: {F12613}
Verified the fix in production:https://en.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/sandbox&veaction=edit
Verified the fix in test2.
Verified the fix in betalabs
Change 109693 merged by jenkins-bot:
Fix handleEnter in nodes that don't split

https://gerrit.wikimedia.org/r/109693
*** Bug 62015 has been marked as a duplicate of this bug. ***
*** Bug 61525 has been marked as a duplicate of this bug. ***
*** Bug 61932 has been marked as a duplicate of this bug. ***
Change 109693 had a related patch set uploaded by Divec:
WIP:Fix handleEnter when not in a splittable node

https://gerrit.wikimedia.org/r/109693
Seems to be failing to handle enter when in a block slug for some reason… but only on the page re-load.

Line 1675 of ve.ce.Surface.js (in handleEnter) is throwing "TypeError: Cannot call method 'getModel' of null" because  "outermostNode" is null.

ncaught TypeError: Cannot call method 'getModel' of null ve.ce.Surface.js:1675
Steps to reproduce:

- go to page (for example [1]) that has only this as contents: {{done}}
- edit the page with visual editor
- copy/paste the template
- I was expecting the page now to contain only this text: {{done}}{{done}}
- instead, the page text is: {{done}}{{done}}<span data-ve-ignore="true"> </span>'''Done.'''
- that causes "Done." to be displayed three times (instead of two), see screenshot[2]
- two minute video recording reproducing the bug is available at [3]
- Sauce Labs is pretty slow to respond, so the actions looks really really slow, the best way to view the video is to download it from [4] and play it with VLC on maximum speed (4x)

1: https://test2.wikipedia.org/wiki/Done
2: https://saucelabs.com/jobs/9dd0291def28413bb7f9ca3a9fd7e891/0001screenshot.png
3: https://saucelabs.com/tests/9dd0291def28413bb7f9ca3a9fd7e891
4: https://saucelabs.com/jobs/9dd0291def28413bb7f9ca3a9fd7e891/video_9dd0291def28413bb7f9ca3a9fd7e891.flv

--------------------------
**Version**: unspecified
**Severity**: major
*** This bug has been marked as a duplicate of bug 59653 ***
Despite the fact that you can have the appearance of the document being blurred and having no active selections, we will always keep the last valid range as the current selection. This is a case of the model not matching the view.

The other solution (as used by Google Docs) is to always render a selection even when the document is unfocused, but as we are using native selections this may not be possible.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=62410
Change 124359 merged by jenkins-bot:
Detect document focus properly and allow null selection in model

https://gerrit.wikimedia.org/r/124359
Change 124359 had a related patch set uploaded by Esanders:
Detect document focus properly and allow null selection in model

https://gerrit.wikimedia.org/r/124359
Was reverted in https://gerrit.wikimedia.org/r/123464
Change 121534 merged by jenkins-bot:
Detect document focus properly and allow null selection in model

https://gerrit.wikimedia.org/r/121534
Change 121534 had a related patch set uploaded by Esanders:
Detect document focus properly and allow null selection in model

https://gerrit.wikimedia.org/r/121534
What's the status of this? Did your work on cursor selections last week relate?
Intention:
Test a bug.

Steps to Reproduce:
1. Selecting the appendices on the page https://en.wikipedia.org/w/index.php?oldid=588539903&veaction=edit

2. Cut them out (Control-x), and 

3. Paste them right back where they were.  


Actual Results:  
The indentation level for all the bulleted lists was increased.


Reproducible: Didn't try

**URL**: https://en.wikipedia.org/w/index.php?title=User%3AEdgepedia%2FVE%2FS%26D&diff=588777573&oldid=588539903
I've tested this out and it seems to work correctly now. Feel free to reopen if I've missed something.
I'm convinced that most editors don't know this.  I only learned this a couple of years ago, when talking to someone with WikiProject Accessibility.

https://en.wikipedia.org/wiki/Template:Glossary is only used 101 times, which is almost nothing for the English Wikipedia.  I don't believe that I've ever seen a list using it.  The normal way to make a definition list is:

;Term
:Definition

or, alternatively:

;Term: Definition

See [[Disease]] for one of several examples I could name off the top of my head.  Both formats produce the same end result.

VisualEditor does not support definition lists at all at this time.  Support is planned (see bug 37938), but it may be a while.  Whenever that happens, this problem should (hopefully) be resolved.
> TLDR:  The colon does *not* actually mean "indent".

Ok, the colon does not mean indent.  However, I have had an account on English Wikipedia for seven years, have made 50,000 edits in that time (which must include tens of thousands of colons) but this is the first I have heard of it.  We have a page (WP:INDENT) explaining how to use colons for indenting, MOS:MATH requires it for display formulae, and WP:TALK suggests that it may be disruptive to deliberately not use colons.  On none of those pages is it explained that, actually, colon does not really mean indent.

I am almost certain that the vast majority of editors do not know this.  There are probably hundreds of thousands of articles that use colons.  It is simply not going to be acceptable for VE to chew up articles because it does not "like" the markup used by editors and established for many years.  A less disruptive way forward would be to make the colon actually mean indent.  Definition lists are usually achieved with templates.  The few that are not are going to be a much smaller number of pages that need fixing and can easily be found by extracting a list of pages from the database with semicolons in lines beginning with colons.  A semi-automated bot could then go through them.
I don't understand why editors aren't allowed free use of indenting, either.  But "free use of indenting" is bug 4521 from eight years ago.  "Free use of indenting" is not "using the second half of the markup from a definition list to sort of fake indenting, so that it looks okay on my desktop system but also so that reading the page is irritating to people using screen readers".

The colon is part of semantic markup.  Screen readers don't skip over semantic markup.  They don't just read the contents of a list.  They stop reading content and announce that there is a list, and how long the list is.  If you use a colon, then some screen readers (correctly) interpret this as being marked as a long list of definitions, so that your markup:

:where,
: ''D'' = 1/''C'' is elastance
: ''C'' is capacitance
: ''S'' is stiffness

is read as something like "Term with four definitions:  where, d = 1/C is elastance, c is capacitance, s is stiffness".  Unless you really want the words "Term with four definitions" to be stuck in the middle of that sentence, then you should not define those four lines as being in a definition list (aka association list).

If you just want visual-only indentation, then you have to set span or div tags to provide visual-only changes to the text arrangement.  As I said above, I don't know why MediaWiki doesn't have a much simpler method for letting editors provide visual intendations properly, and instead gives them a choice between screwing up accessibility or having to hand-type complicated HTML codes.  Using indentation freely been requested for at least eight years.  We have a legitimate need for this, but I don't know if we'll ever get it.


TLDR:  The colon does *not* actually mean "indent".
(In reply to WhatamIdoing from comment #2)

> However, what's being used there as "indentation" isn't indentation,
> strictly speaking; that text has been marked as the second half of a
> term-definition pair in a definition list, which is not semantically
> meaningful.  

It wasn't so marked by me and I don't see any markup in the edit window so you would appear to mean that VE has generated markup.  Generating semantically incorrect markup and then blaming the user for the error is plainly ridiculous.  Or perhaps you mean that the colon in wiki markup does not really mean indentation?  Well, yes it does, it is used extensively all over Wikipedia (ahem, talk pages) with just that intention so by practice and precedent that is what it means.  VE needs to live with that, not garble it because it doesn't like the semantics, otherwise VE will never be ready for prime time.

> where,
> * ''D'' = 1/''C'' is elastance
> * ''C'' is capacitance
> * ''S'' is stiffness

No, that is not a good solution.  Display maths lines are pretty universally indented for aesthetic reasons.  The definitions list following a maths display line are commonly indented as well.  Thus not indenting the "where" and using bullets are both not acceptable.  Bear in mind that a formula, even a display formula, can be inserted in the middle of a sentence so bullets would break the grammatical punctuation.  I can't understand this desire not to allow editors free use of indenting.  It is an editorial decision and there is no reason for VE to interfere or impose something different.  It is for the style guidelines to thrash out, not for VE to impose.
The mess created here is definitely a problem.

However, what's being used there as "indentation" isn't indentation, strictly speaking; that text has been marked as the second half of a term-definition pair in a definition list, which is not semantically meaningful.  

I don't know whether VisualEditor is expected to support the presence of only half of a paired list:  maybe, because it's (mis)used a lot, but maybe not, because it shouldn't be used that way?  (That decision is someone else's problem.)  

However, what's represented there like this:

:where,
: ''D'' = 1/''C'' is elastance
: ''C'' is capacitance
: ''S'' is stiffness


probably ought to be (for proper semantic meaning) a standard (non-definition/non-association) list like this:

where,
* ''D'' = 1/''C'' is elastance
* ''C'' is capacitance
* ''S'' is stiffness

(or in a similar format, but without bullet points, which is possible but not as trivial to create in wikitext).

It would be nice if MediaWiki actually supported plain old indentation, similar to pressing the tab key on a typewriter, perhaps along the lines of the request in bug 4521 (from 2006), but so far that request has not been granted.
I don't know if this is related, or whether it should be a new bug.  In this edit:

https://en.wikipedia.org/w/index.php?title=User:Spinningspark/Work_in_progress/Mobility_analogy&diff=626824709&oldid=626823704

VE adds a number of spurious indents.  The intended edit was to swap over the order of two blocks of text containing math markup.  Very frustrating that the problem could not even be fixed from within VE since indenting does not function in general.
1. Open up the standalone demo /empty.html and type some text
2. Select text from right to left, mouse up outside the surface (or even outside the window)
3. Although the text is selected in CE pressing dump range gives a collapsed range. Formatting actions will fail too.

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 159919 merged by jenkins-bot:
Trigger selection update on selectionchange or mousemove events

https://gerrit.wikimedia.org/r/159919
Change 159919 had a related patch set uploaded by Esanders:
Trigger selection update on selectionchange or mousemove events

https://gerrit.wikimedia.org/r/159919
Change 159807 merged by jenkins-bot:
Bind ve.ce.Surface#onDocumentMouseUp to the entire document on mousedown

https://gerrit.wikimedia.org/r/159807
Change 159807 had a related patch set uploaded by Esanders:
Bound onDocumentMouseUp to the entire document on mousedown

https://gerrit.wikimedia.org/r/159807
Or just stop the surface observer from being disabled. We currently have a bug whereby if you create a selection on a blurred document the SO isn't disabled so you can see the range being periodically updated as you change the selection.
Perhaps we should be using document.onselectionchange to update the model selection (polyfill: https://github.com/2is10/selectionchange-polyfill)
--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in test2 and mw.org
Verified the fix in Betalabs
I believe that this is now fixed in master (but not in Beta Labs yet). Can reproduce in wmf11 but not in master, so closing as fixed by Roan's change in gerrit 108082.
Observed Result:
1.The page *focus* automatically scrolls up
2.If you scroll up or down a bit you will see the link inspector is broken as shown in the screenshot
Created attachment 14246
Link inspector UI is broken

**Attached**: {F12306}
Steps to reproduce:

1.Open a page with VE which contains two or more paragraphs
2.At the end of the page select a text
3.Press command+K and apply a link

Observed Result:
The page fous automatically scrolls up and if you scroll down a bit you will see the link inspector is broken as shown in the screenshot.

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/Jan7th?veaction=edit
Intention:
Correct the spelling of a word.

Steps to Reproduce:
1. Add some text, including a spelling error, to an article.
2. Use Safari's built-in spellcheck to correct the spelling. 


Actual Results:  
The correct spelling displays on the screen.  However, if you "review changes", only the old, incorrect spelling is present.  Also, the correct spelling stops being displayed on the screen if you hit return to start a new paragraph or list item.

Screenshot shows the display and the review changes.  Confirmed in both lists and plain paragraphs.


Reproducible: Always

Confirmed in Safari 6 on Mac OS 10.8.5 using Vector.  It's not present in Firefox 26.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50822
>>! In T61748#836003, @Whatamidoing-WMF wrote:
> I think we're making some progress on this.  Today, the automatic spelling correction is visible in "Review changes".  If the spelling change has the net effect of removing one character, then it even appears to be handled correctly.  However, if it adds a character, then the change is not made, but an equivalent number of extra letters are repeated at the end.
> 
> Examples:
> 
> * Typing "teh" and auto-correcting it to "the" displays correctly and saves correctly.
> * Typing "cantalop" and auto-correcting it to "cantaloup" (adding one character) is saved as "cantalopp" (last letter repeated; added 'u' missing).
> * Typing "proftabilty" and auto-correcting it to "profitability"(adding two characters) is saved as "proftabiltyty" (last two letters repeated; added two letters missing).

This also appears to now be fixed. Adding and removing characters works perfectly, in all three use cases here and others I tested.
I think we're making some progress on this.  Today, the automatic spelling correction is visible in "Review changes".  If the spelling change has the net effect of removing one character, then it even appears to be handled correctly.  However, if it adds a character, then the change is not made, but an equivalent number of extra letters are repeated at the end.

Examples:

* Typing "teh" and auto-correcting it to "the" displays correctly and saves correctly.
* Typing "cantalop" and auto-correcting it to "cantaloup" (adding one character) is saved as "cantalopp" (last letter repeated; added 'u' missing).
* Typing "proftabilty" and auto-correcting it to "profitability"(adding two characters) is saved as "proftabiltyty" (last two letters repeated; added two letters missing).
Confirmed with Safari 7 on 10.9
Created attachment 14242
VisualEditor screenshot, showing "Review changes" not matching the displayed text

**Attached**: {F12267}
Per Gabriel's report via email, when VE POSTs HTML to api.php , it should ensure that gzip compression is used for the POST body.

TODO: Figure out how to actually tell the browser to do this

--------------------------
**Version**: unspecified
**Severity**: enhancement
*** This bug has been marked as a duplicate of bug 66914 ***
This doesn't seem to be supported natively in browsers. Even the XHR2 standard doesn't include support for this. Presumably this is because POST bodies large enough that compression is desired are rare, and because clients don't know in advance whether the server will support compression.

We may be able to do this using a client-side gzip implementation; I'll have to see whether that makes sense. Alternatively, it might be that the savings from fixing bug 59660 and dropping data-parsoid will suffice.
Intention:
Add a caption to an image without having to type out the name by hand.

Steps to Reproduce:
1. Add an image in VisualEditor (e.g., an image of a person).  Open the caption dialog.
2. Go to another window (e.g., an article about the person) and copy a =Name= from the article title.
3. Paste the rich text into the caption.

Actual Results:  
The pasted text retained rich formatting.  It is not possible to remove the =Heading= formatting.  Only '''text''' <s>formatting</s> can be added or removed in that dialog.  So if you copy the article title from [[George Washington]] and paste it into the caption box, then it produces this wikitext:

= <span dir="auto">George Washington</span> =

and there is no way to remove the formatting.

Expected Results:  
That either you could remove the formatting, or ideally, that the caption box would strip the unwanted formatting automagically.  There's no obvious reason why someone would need or want a ==Heading== of any level in a caption.

Reproducible: Didn't try

Confirmed in Safari 6 and Firefox 26

--------------------------
**Version**: unspecified
**Severity**: normal
Closing for now, though we may make further changes about removing or allowing certain kinds of formatting in future.
We mean discouraged. At the moment there's a Parsoid bug that breaks list rendering, but we can revisit that decision if users really want it. And yes, the patch will convert lists to paragraphs.
What does "disallowed" mean?  People do put lists into refs.  See https://en.wikipedia.org/wiki/Wikipedia:Verifiability#cite_note-9 for an example.

It is important that people be able to paste something that was in a list format, even if it was converted into a paragraph upon pasting.
Disallowed inside references: references, reference lists, lists, definition lists, tables. Headings can be pasted but are converted to paragraphs.

Disallowed inside image captions: lists, definition lists, tables. Headings can be pasted but are converted to paragraphs.
Change 110960 merged by jenkins-bot:
Implement surface paste rules for media/ref dialogs

https://gerrit.wikimedia.org/r/110960
Change 110960 had a related patch set uploaded by Esanders:
Implement surface paste rules for media/ref dialogs

https://gerrit.wikimedia.org/r/110960
SurfaceWidgets currently aren't even implementing the main surface's paste rules.
I see now, that there is a dialog box for reference group, while in most cases, where refs are being used as citation, we dont need to fill that group. I propose than to give a tip below that dialox box saing: "For reference list leave empty".

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 114382 merged by jenkins-bot:
Add placeholder to 'group' field in reference dialog too

https://gerrit.wikimedia.org/r/114382
(In reply to Alex Monk from comment #3)
> Is there anything else to do here?

Beyond also adding it to references' dialogs too (now done :-)), there's the TODO from that file:

// TODO: Use a drop-down or something, and populate with existing groups instead of free-text

But will split that off into a new bug (and it will require a new kind of OOjs UI widget anyway).
Change 114382 had a related patch set uploaded by Jforrester:
Add placeholder to 'group' field in reference dialog too

https://gerrit.wikimedia.org/r/114382
Is there anything else to do here?
Change 113684 merged by jenkins-bot:
Show placeholder text in group input box on reference list dialog

https://gerrit.wikimedia.org/r/113684
Change 113684 had a related patch set uploaded by Alex Monk:
Show "General references" as placeholder text in group input box on reference list insert dialog

https://gerrit.wikimedia.org/r/113684
Screenshot

Steps to reproduce:

1.Open a page with VE in FireFox which contains a reference and reference list
For example:
reference<ref>reference</ref>
<references />
2.Copy the reference and the reference list
3.Open another page with VE in FireFox
4.Paste the reference and the reference list
5.Save the page

Observed Result:
The wikitext resulting from after copy-paste is:

reference<span class="reference" id="cite_ref-1-0" rel="dc:references"><sup href="http://en.wikipedia.beta.wmflabs.org/wiki/30th_december?veaction=edit#cite_note-1">[1]</sup></span>
#<span class="" rel="mw:referencedBy">[http://en.wikipedia.beta.wmflabs.org/wiki/30th_december?veaction=edit#cite_ref-1-0 ↑]</span> reference

And it redirects to the source page (in this case: http://en.wikipedia.beta.wmflabs.org/wiki/30th_december?veaction=edit#cite_ref-1-0) 


See the screenshot attached.

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser:  FF 25
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/Newrefff

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

**Attached**: {F12746}
Verified the fix in test2
verified the fix in Betalabs:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Jan24th_ff&action=edit
betalabs doesn't have this code deployed yet
Still getting this issue on Betalabs:

The resulting wikitext after copying a reference and reference list from FireFox to FireFox is:

reference<span class="reference" id="cite_ref-1-0" rel="dc:references"><sup href="http://en.wikipedia.beta.wmflabs.org/wiki/23rd_january?veaction=edit#cite_note-1">[1]</sup></span>
#<span class="" rel="mw:referencedBy"><a href="http://en.wikipedia.beta.wmflabs.org/wiki/23rd_january#cite_ref-1-0">↑</a></span> reference
Change 108680 merged by jenkins-bot:
Protect RDFa attributes from obliteration

https://gerrit.wikimedia.org/r/108680
Change 108680 had a related patch set uploaded by Esanders:
Protect RDFa attributes from obliteration

https://gerrit.wikimedia.org/r/108680
Screenshot of the error

Steps to reproduce:

1.Open a page with VE in Chrome Browser which has references list in it 
2.Copy the references list with the reference.For example copy the following:
reference<ref>reference</ref>
<references />
3.Open another page in FireFox with VE
4.Paste the copied reference and reference list
5.Save the page

Observed Result:
The reference list got copied as bullet list rather than as <references/>

The resulting wikitext is as follows:
reference<sup>[1]</sup>
# reference

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Chrome Page:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=31st_december&veaction=edit
FF Page:http://en.wikipedia.beta.wmflabs.org/wiki/Newrefff

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

**Attached**: {F12743}
Verified the fix in test2
Verified the fix in Betalabs.
betalabs doesn't have this code deployed yet
Still getting this issue on betalabs.

Copied Reference list from this page:http://en.wikipedia.beta.wmflabs.org/wiki/23rd_january?veaction=edit



Pasted on the page:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Paste_reference&action=edit

The resulting wikitext is:
reference<sup>[1]</sup>
# reference
Change 108680 merged by jenkins-bot:
Protect RDFa attributes from obliteration

https://gerrit.wikimedia.org/r/108680
Change 108680 had a related patch set uploaded by Esanders:
Protect RDFa attributes from obliteration

https://gerrit.wikimedia.org/r/108680
Screenshot

Steps to reproduce:

1.Open a page in Chrome Browser with VE which has a template in it
2.Copy the template
3.Open another page in FirFox browser with VE
4.Paste the copied template

Observed result:
The template does not get copied and in the console an error appears:
TypeError: item is undefined

See the screenshot attached.

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/31st_decemberff?veaction=edit

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

**Attached**: {F12738}
Verified the fix in test2
betalabs doesn't have this code deployed yet
I can still reproduce this issue on Betalabs.
Change 108680 merged by jenkins-bot:
Protect RDFa attributes from obliteration

https://gerrit.wikimedia.org/r/108680
Change 108680 had a related patch set uploaded by Esanders:
Protect RDFa attributes from obliteration

https://gerrit.wikimedia.org/r/108680
Steps to reproduce:

1.Open a page with VE which has reference added to a text
2.Copy the text with the reference 
3.Open another page with VE in FireFox
4.Paste the copied reference

Observed Result:
Instead of getting copied as text <ref> reference </ref>, it is getting copied as text<sup> [1] </sup>


Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: FF 25
OS: MAC OS X 10. 8. 5 
http://en.wikipedia.beta.wmflabs.org/w/index.php?title=30th_december_ff&veaction=edit

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in test2
Verified the fix in Betalabs:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Jan24th_ff&action=edit
betalabs doesn't have this code deployed yet
Still getting this issue on betalabs.

Copied Reference list from this
page:http://en.wikipedia.beta.wmflabs.org/wiki/23rd_january?veaction=edit



Pasted on the
page:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Paste_reference&action=edit

The resulting wikitext is:
reference<sup>[1]</sup>
# reference
Change 108680 merged by jenkins-bot:
Protect RDFa attributes from obliteration

https://gerrit.wikimedia.org/r/108680
Change 108680 had a related patch set uploaded by Esanders:
Protect RDFa attributes from obliteration

https://gerrit.wikimedia.org/r/108680
Screenshot

Steps to reproduce:

1.Open the VE in Chrome browser for a page which contains image
2.Copy the image
3.Open another VE in FireFox browser
4.Paste the copied image

Observed Result:
Image does not get copied.An error appears in the console:
TypeError: item is undefined
	

...nction(){return this.getData(this.balancedRange);};ve.dm.LinearData=function VeD...

load.p...2128Z&* (line 122)

See the screenshot attached.


Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
http://en.wikipedia.beta.wmflabs.org/wiki/30th_december_ff?veaction=edit

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

**Attached**: {F12694}
Verified the fix in test2
Verified the fix in Betalabs:http://en.wikipedia.beta.wmflabs.org/wiki/Jan_24th?veaction=edit
betalabs doesn't have this code deployed yet
I can still reproduce it on Betalabs
Change 108680 merged by jenkins-bot:
Protect RDFa attributes from obliteration

https://gerrit.wikimedia.org/r/108680
Change 108680 had a related patch set uploaded by Esanders:
Protect RDFa attributes from obliteration

https://gerrit.wikimedia.org/r/108680
Warning in the save dialog box

Steps to reproduce:

1.Open a page with VE
2.Add the template Cite Web from Insert>Transclusion
3.Save the page
4.Reopen the page with VE
5.Do some more edit in that page
5.Click on "Save Page"

Observed Result:
A warning appears in the save dialog box "You edit may have been corrupted-Please review your changes"

This error appears everytime I add this Cite Web template even though there is no apparent reason for being my edit corrupted.

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**: {F12545}
Change 115510 abandoned by Jforrester:
[Browser test] WIP Additional Scenario for bug 59091 regression.

Reason:
Not currently being worked on AFAICT.

https://gerrit.wikimedia.org/r/115510
Change 115510 had a related patch set uploaded by Jhall:
[Browser test] WIP Addtional Scenario for bug 59091 regression.

https://gerrit.wikimedia.org/r/115510
Got fixed with the fix of https://bugzilla.wikimedia.org/show_bug.cgi?id=59002
**spektre1** wrote:

Tested on my private install. Any transclusion at all seems to throw it this error in the save dialog.
Attempting to edit any page in betalabs is giving following error:
Error loading data from server: internal_api_error_MWException: Exception Caught: Tag hook for namespace is not callable.

In the console,I see the following error
Uncaught TypeError: Cannot read property '$actions' of null

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=27th_december

--------------------------
**Version**: unspecified
**Severity**: major
This issue is not happening anymore in betalabs now.I can now open any page to edit.
Screenshot of the error

Steps to reproduce:

1.Open the editor for page
2.Go to Insert>Template
3.Search for template Cite Web
4.Add a a value for source title field but keep the URL field empty
5.Add the template
6.Click the button "Save Page"

Observed Result: 
The "Save Page" button does not work .In the console it is showing an error:
Uncaught TypeError: Object [object Text] has no method 'setAttribute'


See the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: critical
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55985

**Attached**: {F12409}
Works for mw.org in Chrome now.Might be a caching issue.
(In reply to comment #21)
> This issue is verified for test2.But in mw.org I still cannot save after
> adding
> a template in Chrome 26.0.1410.65, however it does not show any error in the
> console as such Uncaught TypeError: Object [object Text] has no method
> 'setAttribute'
> 
> In FireFox, it works for both test 2 and mw.org.
> 
> Hence reopening it.If it is a separate issue please Close this one , I will
> file a separate issue for mw.org

Maybe if you refresh it will go away? Sounds most likely like a cacheing issue…
Can't reproduce on mw.org. Which template did you use?
This issue is verified for test2.But in mw.org I still cannot save after adding a template in Chrome 26.0.1410.65, however it does not show any error in the console as such Uncaught TypeError: Object [object Text] has no method 'setAttribute'

In FireFox, it works for both test 2 and mw.org.

Hence reopening it.If it is a separate issue please Close this one , I will file a separate issue for mw.org
Now fixed and back-ported to production.
Change 107638 merged by Catrope:
About-group extra DOM data in toDomElements

https://gerrit.wikimedia.org/r/107638
Change 107530 merged by Catrope:
Wrap text nodes in spans if trying to mark as data-ve-ignore

https://gerrit.wikimedia.org/r/107530
Change 107640 merged by Catrope:
About-group extra DOM data in toDomElements

https://gerrit.wikimedia.org/r/107640
Change 107531 merged by Catrope:
Wrap text nodes in spans if trying to mark as data-ve-ignore

https://gerrit.wikimedia.org/r/107531
Change 107640 had a related patch set uploaded by Catrope:
About-group extra DOM data in toDomElements

https://gerrit.wikimedia.org/r/107640
Change 107638 had a related patch set uploaded by Catrope:
About-group extra DOM data in toDomElements

https://gerrit.wikimedia.org/r/107638
Change 107559 merged by jenkins-bot:
About-group extra DOM data in toDomElements

https://gerrit.wikimedia.org/r/107559
Change 107559 had a related patch set uploaded by Esanders:
About-group extra DOM data in toDomElements

https://gerrit.wikimedia.org/r/107559
data-ve-ignore showing up in converter in some cases still. Working on a fix.
Fix has been merged, backported and will be deployed during tomorrow's lightning deploy window (Thu Jan 16 00:00 - 00:30 UTC; Wed Jan 15 16:00 - 16:30 PST)
Change 107511 merged by jenkins-bot:
Wrap text nodes in spans if trying to mark as data-ve-ignore

https://gerrit.wikimedia.org/r/107511
Change 107531 had a related patch set uploaded by Catrope:
Wrap text nodes in spans if trying to mark as data-ve-ignore

https://gerrit.wikimedia.org/r/107531
Change 107530 had a related patch set uploaded by Catrope:
Wrap text nodes in spans if trying to mark as data-ve-ignore

https://gerrit.wikimedia.org/r/107530
Change 107511 had a related patch set uploaded by Esanders:
Wrap text nodes in spans if trying to mark as data-ve-ignore

https://gerrit.wikimedia.org/r/107511
*This is happening for adding all templates on test2*
This s\is happening for adding all templates on test2.
Adding to my previous comment: when i try to switch to wiki markup mode i get the same error. No way to save my stuff :(

Here's a stack trace:

Uncaught TypeError: Object [object Text] has no method 'setAttribute' 
ve.dm.MWTransclusionNode.static.toDomElements 
ve.dm.Converter.getDomElementsFromDataElement 
ve.dm.Converter.getDomSubtreeFromData 
ve.dm.MWReferenceNode.static.toDomElements 
ve.dm.Converter.getDomElementsFromDataElement 
ve.dm.Converter.getDomSubtreeFromData 
ve.dm.Converter.getDomSubtreeFromModel 
ve.dm.Converter.getDomFromModel 
ve.init.mw.ViewPageTarget.editSource 
ve.ui.MWEditModeSourceTool.onSelect 
OO.ui.ToolGroup.onMouseUp 
OO.ui.PopupToolGroup.onMouseUp 
proxy 
jQuery.event.dispatch 
elemData.handle.eventHandle
I can reproduce this problem as well. A pity, because not being able to save makes the Visual Editor, well, pretty much useless. I've changed priority to 'High' for that reason.
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/w/index.php?title=27th_december&veaction=edit
With FireFox (compulsory) on Windows
insert a new line then enter : Alt A (or Alt + any key)
=> a pawn is inserted

--------------------------
**Version**: unspecified
**Severity**: normal
**Platform**: PC
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61538
Have re-tested; no issue any more.
Looks like alt+a doesn't fire a KeyPress event in Chrome whereas it does in FF. As slugs are always pawned, and there is no inserted content from alt+a we have a problem.
VisualEditor supports the 'apex' skin, however that isn't installed on WMF projects, so users using a non-supported skin will see "&lt;skinname-apex&gt;".

--------------------------
**Version**: unspecified
**Severity**: normal
Sorry, page error. This comment is for bug 70814.
The current state on the Wikimedia project is without the names of the required skins. In the case it is wanted to keep the current state (for Wikimedia and/or for the master branch of BetaFeatures), this feature can be hidden with CSS, similarly to the browser requirements, by editing BetaFeatures/resources/betafeatures.less.
Change 102383 merged by jenkins-bot:
Don't show skin names if the user can't enable them

https://gerrit.wikimedia.org/r/102383
*** Bug 63151 has been marked as a duplicate of this bug. ***
Change 102383 had a related patch set uploaded by Legoktm:
Don't show skin names if the user can't enable them

https://gerrit.wikimedia.org/r/102383
screenshot of the error

Steps to reproduce:

1.Go to this page:

https://en.wikipedia.org/w/index.php?title=User:RYasmeen_(WMF)/12th_december&veaction=edit

2.Copy the reference and the reference list at the end of this page
3.Paste in into another VE
4.Save it

Observed Result:

The wiki text for the text copied is: 

reference<ref>http://cnn.com</ref>
<references />

The wiki text on the page where it is copied to:
reference<ref />
<references />

In Edit mode it says:
The reference is defined in a template or other generated block and for now can
only be edited in source mode.

and the reference cannot be edited using VE


In read mode it shows:

Cite error: The opening <ref> tag is malformed
or has a bad name (see the help page).

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F12112}
verified the fix in test2 with  MediaWiki 1.23wmf8 on page:
https://test2.wikipedia.org/wiki/Another_page20th
Verified the fix in betalabs:http://en.wikipedia.beta.wmflabs.org/wiki/December_16th
This appears to be fixed in master. Please re-open if you can reproduce on beta labs.
**Author:** `jhall`

**Description:**
Seen in beta labs with these repro steps:

1)  Open Visual Editor.
2)  Select "Transclusion" from the "Insert" menu.
3)  Type some characters in the "New Template" text box.

In previous releases of VE, the user would get a list of template suggestions.  That list of suggestions doesn't seem to be displaying anymore :(

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53231
Now the template suggestions are appearing.
This is again happening on betalabs.I dont see any template suggestion appearing. 

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/26th_december?veaction=edit
**jhall** wrote:

(In reply to comment #1)
> This seems to work for me? Which browser is this in? (Tested in Mac/Chrome 31
> and Mac/Firefox 25.)

Hmmm… this does now seem to be working in beta labs with Chrome, Firefox, and Safari on Mac OS.  I successfully get transclusion template suggestions for the letters C, N, T, and W.  My favorite suggestion so far is "Noble Pipe".  Not sure what that is, but it's a great name for a transclusion template.

I'll update the automated browser test to search by one of the letters indicated above (rather than by "S", which doesn't currently return any suggestions).
This seems to work for me? Which browser is this in? (Tested in Mac/Chrome 31 and Mac/Firefox 25.)
Screenshot inside reference

We have changed the toolbar design to have all the formatting under one button A (underlined) and all other options to add elements under Insert option.

But if you open up the Media Settings or a Reference the toolbar that appears there does not conform with the new design.
It will better to have a consistent design everywhere the toolbar is used.

See the screemshots attached.

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F12060}
verified the fix in test2:https://test2.wikipedia.org/w/index.php?title=User:RYasmeen_(WMF)&veaction=edit
Now being deployed on wmf7.
Change 101047 merged by Catrope:
Use the same new toolbar for media and reference dialogs

https://gerrit.wikimedia.org/r/101047
Change 101039 merged by jenkins-bot:
Use the same new toolbar for media and reference dialogs

https://gerrit.wikimedia.org/r/101039
Change 101047 had a related patch set uploaded by Jforrester:
Use the same new toolbar for media and reference dialogs

https://gerrit.wikimedia.org/r/101047
Change 101039 had a related patch set uploaded by Jforrester:
Use the same new toolbar for media and reference dialogs

https://gerrit.wikimedia.org/r/101039
Created attachment 14073
toolbar inside media settings

**Attached**: {F12061}
A could sometimes suddenly appears. As well as 'left over sections' it seems.

https://www.mediawiki.org/w/index.php?title=User:TheDJ/sandbox&oldid=841359

I think this was due to "select all" cmd-A, then cmd-v paste over the old content.

--------------------------
**Version**: unspecified
**Severity**: major
I believe we fixed this bug with the CE select-all change that Ed worked on two months ago.
Steps to reproduce:


1.Open the editor for a page which contains link

2.Copy it.

3.Paste it into a new line 

4.Save it

Observed Result:
The link is getting merged on to the end of the previous line

--------------------------
**Version**: unspecified
**Severity**: normal
*The fix for the original issue has been verified in test 2 with mediawiki 1.23wmf8*
The original issue of this bug has been verified in test 2 with MediaWiki 1.23wmf8 
on page:https://test2.wikipedia.org/wiki/19th_december
This is a new bug and something to do with Parsoid and Selser. Filed as bug 58695.
After these steps if you try copying a math function or a link on the third line of Page B , it will also get merged with the two merged links
Sorry, here are the detailed steps: 

1.Create a page "A" with three links in three consecutive lines.
2.Create another page "B" where you will copy these links to.
3.Copy the first and second link to "B"
4.Save it.
5.Reopen the editor.
6.Now copy the third link and paste it to the third line of "B"
7.Save it.

Observed Result:
The second and the third link in page B is getting merged.

Example Pages:

A:http://en.wikipedia.beta.wmflabs.org/wiki/19th_december_source?veaction=edit
B:http://en.wikipedia.beta.wmflabs.org/wiki/19th_destination
Works for me in Chrome and Firefox. Please provide detailed instructions if you can reproduce.
I am still getting the issue of two links getting merged in one line after pressing enter after pasting the first link:
http://en.wikipedia.beta.wmflabs.org/wiki/December_17th
Change 101905 merged by jenkins-bot:
Strip trailing linebreaks on paste due to Chrome bug

https://gerrit.wikimedia.org/r/101905
Change 101905 had a related patch set uploaded by Esanders:
Strip trailing linebreaks on paste due to Chrome bug

https://gerrit.wikimedia.org/r/101905
This latest version of the bug is known issue with CE in Chrome when pasting into a newline.
Modification in steps to reproduce:

1.Open the editor 
2.Copy a link or a text
3.Paste it into another VE
4.Observed that the cursor is automatically to the next line though you have not pressed Enter/return
5.Now paste the link or the text again in that position without pressing enter
6.Save the page

Observed Result:
The texts or the links are getting merged in the same line
The issue of link getting merged is still reproducible in betalabs:http://en.wikipedia.beta.wmflabs.org/wiki/December_16th
Another issue which I think might be related with this, if not I will file separate bug:

Steps to reproduce:


1.Open the editor for a page 

2.Copy a text

3.Paste it into another page

4.Copy an image and paste it onto the next line

Observed Result:
The image does not gets pasted in the other VE.
Modification in steps to reproduce:

step 3 :paste it into a newline on another page or VE
Created attachment 14062
Screenshot

**Attached**: {F12812}
Test Environment: betalabs
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5 
Example Page:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=11th_december
Steps to reproduce:

1.Open the Editor.
2.Place the cursor inside a word or text but do not select anything
3.Press command+c
4.Now go to another page and do command+v (Nothing is getting copied, which is okay as per the fix given in https://bugzilla.wikimedia.org/show_bug.cgi?id=58138)
5.But now select anything from the source page by selecting it
6.Press command+c
7.Press command+V onto the other page where you were pasting.

Observed Result:
Nothing gets copied

--------------------------
**Version**: unspecified
**Severity**: normal
Pushed to wmf6.
Change 100915 merged by jenkins-bot:
Move resetting of paste state variables to after afterPaste

https://gerrit.wikimedia.org/r/100915
Change 100915 had a related patch set uploaded by Jforrester:
Move resetting of paste state variables to after afterPaste

https://gerrit.wikimedia.org/r/100915
Verified on betalabs
Change 100827 merged by jenkins-bot:
Move resetting of paste state variables to after afterPaste

https://gerrit.wikimedia.org/r/100827
Change 100827 had a related patch set uploaded by Esanders:
Move resetting of paste state variables to after afterPaste

https://gerrit.wikimedia.org/r/100827
Test Environment:betalabs
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5
Maybe some new config has to be added for it to consider REL1_22 as a valid branch to download?

--------------------------
**Version**: unspecified
**Severity**: normal
Change 100799 merged by jenkins-bot:
Add REL1_22 to ExtensionDistributor branches

https://gerrit.wikimedia.org/r/100799
Change 100799 had a related patch set uploaded by Reedy:
Add REL1_22 to ExtensionDistributor branches

https://gerrit.wikimedia.org/r/100799
Safari 7

Copy on https://www.mediawiki.org/wiki/VisualEditor?veaction=edit

From and including the header Timeline, up to the paragraph before "Notes" headline (including the table).

Past in an empty surface:

[Error] TypeError: 'undefined' is not an object (evaluating 'source.clone')
	copy (undefined, line 3)
	getClonedElement
	fixupInsertion
	fixupInsertion
	newFromDocumentInsertion
	afterPaste
	proxy (load.php, line 10)

--------------------------
**Version**: unspecified
**Severity**: normal
Pushed to wmf6.
Change 100916 merged by jenkins-bot:
Allow tables to contain captions!

https://gerrit.wikimedia.org/r/100916
Change 100916 had a related patch set uploaded by Jforrester:
Allow tables to contain captions!

https://gerrit.wikimedia.org/r/100916
Change 100792 merged by jenkins-bot:
Allow tables to contain captions!

https://gerrit.wikimedia.org/r/100792
Change 100792 had a related patch set uploaded by Esanders:
Allow tables to contain captions!

https://gerrit.wikimedia.org/r/100792
Part of this appears to be caused by table captions. Investigating.
More detail: the problem is caused by ContentEditable (surprise). When you paste a table into an empty paragraph, the paragraph is *completely* deleted, which the paste context comparer can't currently deal with.
The problem here is that fixUpInsertion is deciding you can't put a table in a paragraph but not resolving properly.
This came from the Hebrew Wikipedia feedback page, I could not replicate it in the English Wikipedia

It seems to happen only in Firefox.


To reproduce -

1. Go to this sample page: https://he.wikipedia.org/w/index.php?title=%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:Nurick/%D7%91%D7%93%D7%99%D7%A7%D7%95%D7%AA_-_%D7%A2%D7%95%D7%A8%D7%9A_%D7%97%D7%96%D7%95%D7%AA%D7%99&oldid=14834614&veaction=edit

2. Put the cursor a couple of character to the left of the word "יפן" (third paragraph, the word with the reference attached)

3. Move the cursor so it is between the word and the reference.

4. Add a period.

Watch a pawn appear.

* Firefox 25.0.1 on Windows and on Ubuntu

--------------------------
**Version**: unspecified
**Severity**: major
This appears to be now fixed. I think.
*** Bug 67620 has been marked as a duplicate of this bug. ***
This is an interesting feedback comment that came from the Hebrew Wikipedia and I managed to also replicate in the English Wikipedia. 

Steps to replicate:

1. Go to a Sandbox page under a username. For example, this page https://en.wikipedia.org/w/index.php?title=User:Mooeypoo/Sandbox&veaction=edit

2. Mark one of the words and add an existing page to link to it. For instance, I marked 'some' and chose the link to "Somerset".

3. Inspect the link while still in VisualEditor - the link is under the user namespace, so in my example, the link is now "https://en.wikipedia.org/wiki/User:Mooeypoo/Somerset"

4. Save the page.

5. After save, the link seems fine (points to https://en.wikipedia.org/wiki/Somerset as it should).

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=59196
Change 119914 merged by jenkins-bot:
Hack around Parsoid's href prefixing in rendering new links

https://gerrit.wikimedia.org/r/119914
*** Bug 59196 has been marked as a duplicate of this bug. ***
Change 119914 had a related patch set uploaded by Jforrester:
Hack around Parsoid's href prefixing in rendering new links

https://gerrit.wikimedia.org/r/119914
*** Bug 59196 has been marked as a duplicate of this bug. ***
*** Bug 62877 has been marked as a duplicate of this bug. ***
Broken UI

Steps to reproduce:


1.Open the editor 
2.create a link
3.Save the page
4.Re-open the editor.
5.Select the link to modify it

Observed Result:

Link inspector is not opening.Coming back from some other window opens it but the UI is totally broken

See the screenshot attached

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

**Attached**: {F12763}
verified on test2:https://test2.wikipedia.org/w/index.php?title=13th_december&veaction=edit
verified in betalabs.
Change 100828 merged by jenkins-bot:
Followup 5d7673eb: still adjust width/height when positioning fails

https://gerrit.wikimedia.org/r/100828
Change 100828 had a related patch set uploaded by Catrope:
Followup 5d7673eb: still adjust width/height when positioning fails

https://gerrit.wikimedia.org/r/100828
yes, i can still reproduce it .
Can you still reproduce this? It works for me.
Test Environment:betalabs
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5 
Example:http://en.wikipedia.beta.wmflabs.org/wiki/Latex?veaction=edit
Created attachment 14053
No link inspector opening up

**Attached**: {F12764}
screenshot of the error and empty Latex window

Steps to reproduce:

1.Add a bullet list
2.Add a template as a bulleted item
3.Save the page and reopen the editor
4.Go to the next line of the bulleted list (get rid of bullets by pressing return twice)

5.Click on More>Latex

Observed Result:

The latex window is opening up at the right end, where the template is placed.

6.Then if you change the focus by clicking somewhere on the page outside the latex window

Observed Result:

A blank Latex windows is opening up and a uncaught type error appears Uncaught TypeError: Cannot call method 'getOuterRange' of null 

If you save the page and go to edit source , you will see empty <math> tag is getting placed

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

**Attached**: {F12725}
Verified the fix in production
Verified the fix in test2
Change 129622 merged by jenkins-bot:
Create MWLiveExtensionInspector base class

https://gerrit.wikimedia.org/r/129622
Change 129622 had a related patch set uploaded by Jforrester:
Create MWLiveExtensionInspector base class

https://gerrit.wikimedia.org/r/129622
Verified the fix on Betalabs
Change 126900 merged by jenkins-bot:
Create MWLiveExtensionInspector base class

https://gerrit.wikimedia.org/r/126900
Change 126900 had a related patch set uploaded by Esanders:
Create MWLiveExtensionInspector base class

https://gerrit.wikimedia.org/r/126900
This code as of gerrit 126900 is moving back into VE's repo where it needs to be fixed.
*** Bug 62797 has been marked as a duplicate of this bug. ***
This happens because ve.ui.MWMathInspector.prototype.setup assumes that after calling insertContent() to insert a math node, the selection will cover the math node exactly. But in a block slug, that's not true, because fixupInsertion will have amended the insertion to wrap the math node in a paragraph. Then when the selection does not precisely cover a FocusableNode, focusedNode will be null.
Modification in steps to reproduce:

4.There is an empty bullet place cursor there and then go to More>Latex

It can also be reproduced by adding image in step 2.
Created attachment 14050
emtpy <math> tags

**Attached**: {F12726}
E.g. copying the disclaimer from my staff page https://www.mediawiki.org/wiki/User:Jdforrester_%28WMF%29 takes:

<p><b>Disclaimer:</b> Although I work for the Wikimedia Foundation, contributions under this account do not necessarily represent the actions or views of the Foundation unless expressly stated otherwise. For example, edits to articles or uploads of other media are done in my individual, personal capacity unless otherwise stated.</p>

… and turns it into the wikitext:

'''Disclaimer:'''
<nowiki> </nowiki>Although I work for the Wikimedia Foundation, contributions under this
account do not necessarily represent the actions or views of the
Foundation unless expressly stated otherwise. For example, edits to
articles or uploads of other media are done in my individual, personal
capacity unless otherwise stated.

… (with the newlines showing before saving; not a Parsoid bug).

No new lines added when doing a plain paste.
Change 100614 merged by Catrope:
Fix paste sequence in Firefox

https://gerrit.wikimedia.org/r/100614
Change 100613 merged by jenkins-bot:
Fix paste sequence in Firefox

https://gerrit.wikimedia.org/r/100613
Change 100614 had a related patch set uploaded by Jforrester:
Fix paste sequence in Firefox

https://gerrit.wikimedia.org/r/100614
Change 100613 had a related patch set uploaded by Esanders:
Fix paste sequence in Firefox

https://gerrit.wikimedia.org/r/100613
Failed to read file: exception 'Exception' with message 'Expected open tag, whitespace, or variable., got T_STRING ('array_map')' in /a/common/php-1.23wmf6/extensions/LocalisationUpdate/QuickArrayReader.php:135
Stack trace:
#0 /a/common/php-1.23wmf6/extensions/LocalisationUpdate/QuickArrayReader.php(119): QuickArrayReader->except(Array, 'open tag, white...')
#1 /a/common/php-1.23wmf6/extensions/LocalisationUpdate/LocalisationUpdate.class.php(528): QuickArrayReader->__construct('<?php $messages...')
#2 /a/common/php-1.23wmf6/extensions/LocalisationUpdate/LocalisationUpdate.class.php(313): LocalisationUpdate::parsePHP('$messages = arr...', 'messages')
#3 /a/common/php-1.23wmf6/extensions/LocalisationUpdate/LocalisationUpdate.class.php(435): LocalisationUpdate::loadFilesToCompare('VisualEditor', '/var/lib/l10nup...', '/a/common/php-1...', false, false)
#4 /a/common/php-1.23wmf6/extensions/LocalisationUpdate/LocalisationUpdate.class.php(153): LocalisationUpdate::compareExtensionFiles('VisualEditor', '/var/lib/l10nup...', '/a/common/php-1...', false)
#5 /a/common/php-1.23wmf6/extensions/LocalisationUpdate/LocalisationUpdate.class.php(113): LocalisationUpdate::updateExtensionMessages('/a/common/php-1...', 'VisualEditor', false, '/var/lib/l10nup...')
#6 /a/common/php-1.23wmf6/extensions/LocalisationUpdate/update.php(34): LocalisationUpdate::updateMessages(Array)
#7 /a/common/multiversion/MWScript.php(97): require_once('/a/common/php-1...')
#8 {main}
Failed to parse /var/lib/l10nupdate/mediawiki/extensions/VisualEditor/VisualEditor.i18n.php

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to Amir E. Aharoni from comment #6)
> Is this fixed now?

I believe it will be fixed by gerrit 119944 when that is merged and deployed.
Is this fixed now?
Please see https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions/LocalisationUpdate+branch:json-rewrite,n,z
This issue is tracked in mingle at https://wikimedia.mingle.thoughtworks.com/projects/language_engineering/cards/3897
(In reply to comment #2)
> Change 100527 merged by jenkins-bot:
> Revert "Shim for VisualEditor.i18n.php that reads JSON blobs"
> 
> https://gerrit.wikimedia.org/r/100527
This has been reintroduced, because despite the scary-looking exception, it didn't actually break LU for anything other than VE.
Change 100527 merged by jenkins-bot:
Revert "Shim for VisualEditor.i18n.php that reads JSON blobs"

https://gerrit.wikimedia.org/r/100527
Change 100527 had a related patch set uploaded by Jforrester:
Revert "Shim for VisualEditor.i18n.php that reads JSON blobs"

https://gerrit.wikimedia.org/r/100527
Ed,

Think you were working on this before? Would be lovely to finally get this fixed…

J.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57477
Verified the fix on test2
Change 106707 merged by jenkins-bot:
Move initial selection to first content offset

https://gerrit.wikimedia.org/r/106707
Change 106707 had a related patch set uploaded by Esanders:
Move initial selection to first content offset

https://gerrit.wikimedia.org/r/106707
Any update on this? It's a significant UX issue.
The Errors

Steps to reproduce:

1.Open an editor which has a text with reference and the reflist
For example:

text with reference[1]
↑ ref

2.Try to paste it into a different page

Observed Result:
Uncaught TypeError: Cannot read property 'length' of undefined appears and nothing gets pasted.

However the "Save Page" button is active and clicking on that gives the error:
Uncaught TypeError: Cannot call method 'getRange' of undefined

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F12622}
Yes please. Give steps with wikitext to reproduce.
Checked the fix in production.The issue specified in this bug is fixed.Reference is getting pasted with reference list and the subsequent elements are getting copy-pasted properly.But still there is a problem with pasting reference :(

The reference is getting copied as an empty <ref/> tags and on edit mode it says 
The reference is defined in a template or other generated block and for now can only be edited in source mode.

In read mode: There is an error:Cite error: The opening <ref> tag is malformed or has a bad name (see the help page).

Should I create a different issue ticket for that?
Now being deployed on wmf6 and wmf7.
Change 101133 merged by Catrope:
Check InternalList node exists when rendering MWReferenceList

https://gerrit.wikimedia.org/r/101133
Change 101134 merged by Catrope:
Check InternalList node exists when rendering MWReferenceList

https://gerrit.wikimedia.org/r/101134
Change 101134 had a related patch set uploaded by Catrope:
Check InternalList node exists when rendering MWReferenceList

https://gerrit.wikimedia.org/r/101134
Change 101131 merged by jenkins-bot:
Check InternalList node exists when rendering MWReferenceList

https://gerrit.wikimedia.org/r/101131
Change 101133 had a related patch set uploaded by Catrope:
Check InternalList node exists when rendering MWReferenceList

https://gerrit.wikimedia.org/r/101133
Change 101131 had a related patch set uploaded by Esanders:
Check InternalList node exists when rendering MWReferenceList

https://gerrit.wikimedia.org/r/101131
In production, go to this page :https://en.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/12th_december&veaction=edit

Copy the last reference along with reference list and try to paste it into another page.
And after that nothing can be copied into the other VE
I am escalating this issue, because it is now reproducible in production:https://en.wikipedia.org/wiki/ and after this action copy-paste does not work from one VE to another.
Test Environment: betalabs
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5 
Example Page with reference and reflist: :http://en.wikipedia.beta.wmflabs.org/wiki/Bold?veaction=edit
Table format in destination page

Steps to reproduce:

1.Open the editor.
2.Copy a template with a parameter which has a value and paste it into a different page
3.Copy a template which does not have any parameter  and paste it into a different page
4.Copy a template with a parameter which does not have any value.


Observed Result:


1.All the template copied are getting pasted as a table
2.If you switch to the edit source you will see :

the template copied in step 2 has a table format
the template copied in step 3 is getting pasted in an empty template wikitext format:{|
!
|}

the template copied in step 4 is getting pasted in a template wikitext format with the page name inside it:{|
!Copy
|}

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

**Attached**: {F12618}
verified in production:https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/13th_december
(And back-ported to wmf6.)
Change 100943 merged by Catrope:
Fix issues with copy-pasting MWTransclusionNodes

https://gerrit.wikimedia.org/r/100943
Change 100943 had a related patch set uploaded by Catrope:
Fix issues with copy-pasting MWTransclusionNodes

https://gerrit.wikimedia.org/r/100943
Change 100775 merged by jenkins-bot:
Fix issues with copy-pasting MWTransclusionNodes

https://gerrit.wikimedia.org/r/100775
Change 100775 had a related patch set uploaded by Esanders:
Fix issues with copy-pasting MWTransclusionNodes

https://gerrit.wikimedia.org/r/100775
For an example
if you go to this page :http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Paste

I have copied three templates from http://en.wikipedia.beta.wmflabs.org/wiki/Copy
and they are having these issues.
Can you give a more specific example. The templates I'm testing on copy and paste okay.
Created attachment 14043
tooltip and yellow bordered box

**Attached**: {F12620}
After pasting a template, which has parameter with no value, it does not let user to edit that template on the edit mode.
and shows a tooltip "Sorry this element can be edited in source mode now" with yellow bordered box.

See the screenshot attached
Created attachment 14042
The edit source section for the destination page

**Attached**: {F12619}
screenshot

Steps to reproduce:

1.Open the editor for a page
2.Place a link to a page
3.Rename the link text to something different than the destination page name
4.Save the page
5.Now copy this link and paste it to another page
6.Save the second page

Observed Result:
In the read mode of the second page the wikitext for the link is showing up


See the screenshot attached

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

**Attached**: {F12566}
OK, will mark as FIXED.
I cannot reproduce it either now.But, this was a different issue than bug 58136
I can't reproduce now - is this the same as bug 58136?
Test Environment: betalabs
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5 
Example Page:http://en.wikipedia.beta.wmflabs.org/wiki/Linker
See: https://www.mediawiki.org/w/index.php?title=User:Eloquence/CP_tests&oldid=838815

Copied from:
https://www.mediawiki.org/w/index.php?title=VisualEditor:Welcome&oldid=799120

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed in Ed's series of fixes to rich copy and paste in (I think) the same week this was filed; sorry for the very slow triage.
screenshot of the icon

Steps to reproduce:

1.Open the editor for an article
2.Place your cursor any position of a link and press command+c.
3.Open another page and press command+v

Observed:
 An icon ☁ appears on the second page.

See the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=58136

**Attached**: {F12394}
verified the fix on test2:https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/13th_december?veaction=edit
Verified in Betalabs
Change 100605 merged by Catrope:
Check the selection has collapsed after pasting

https://gerrit.wikimedia.org/r/100605
Change 100605 had a related patch set uploaded by Jforrester:
Check the selection has collapsed after pasting

https://gerrit.wikimedia.org/r/100605
Change 100578 merged by jenkins-bot:
Check the selection has collapsed after pasting

https://gerrit.wikimedia.org/r/100578
Change 100578 had a related patch set uploaded by Esanders:
Check the selection has collapsed after pasting

https://gerrit.wikimedia.org/r/100578
Ignore that, only works if the cursor is placed on a blank line.
Can't reproduce in Chrome 30 on OSX.
Test Environment: production
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/Linker?veaction=edit
**Author:** `Wikifram`

**Description:**
Version 2013-12-05 (MW 1.23wmf6), implemented at MediaWiki, now for the first time tested apparently (by me)... When you add a reference, the cursor is again positioned at the top of the article, no matter where you insert the reference. The focus (the part you actually see) of the page is where you added the reference, but when you start typing, you are actually adding text to the top of the page. This is confusing as hell. 

The same applies when adding a template, but not with media.

--------------------------
**Version**: unspecified
**Severity**: critical
*** Bug 57034 has been marked as a duplicate of this bug. ***
Verified on betalabs
*** Bug 57438 has been marked as a duplicate of this bug. ***
A fix for this for wmf6 is going out in about 4 minutes' time; fixing it for wmf5 would involve back-porting half of wmf6, and is too risky. Sorry for the disruption.
Change 100496 merged by jenkins-bot:
Don't move the cursor to the top of the page after closing a dialog

https://gerrit.wikimedia.org/r/100496
Change 100490 merged by jenkins-bot:
Don't move the cursor to the top of the page after closing a dialog

https://gerrit.wikimedia.org/r/100490
Change 100496 had a related patch set uploaded by Jforrester:
Don't move the cursor to the top of the page after closing a dialog

https://gerrit.wikimedia.org/r/100496
Change 100490 had a related patch set uploaded by Catrope:
Don't move the cursor to the top of the page when closing a dialog

https://gerrit.wikimedia.org/r/100490
This is actually present in 1.23wmf5 as well.
*** Bug 58194 has been marked as a duplicate of this bug. ***
**Author:** `Wikifram`

**Description:**
Have you ''really'' implemented a new version at MediaWiki that scrolls to the ''bottom'' of the page when opened in VE? Was this intentional or (if I'm allowed to say this) just something that should have been obvious with the most basic test, but somehow wasn't noticed? FF25, W7, nothing fancy or unusual. And no, this didn't happen in earlier versions, and doesn't happen when I use VE on enwiki...

--------------------------
**Version**: unspecified
**Severity**: major
A fix for this is going out in about 4 minutes' time. Sorry for the disruption.
Change 99785 merged by jenkins-bot:
mw.Target: Fix document focus scroll bug

https://gerrit.wikimedia.org/r/99785
Change 99785 had a related patch set uploaded by Jforrester:
mw.Target: Fix document focus scroll bug

https://gerrit.wikimedia.org/r/99785
Change 99718 merged by jenkins-bot:
mw.Target: Fix document focus scroll bug

https://gerrit.wikimedia.org/r/99718
Change 99718 had a related patch set uploaded by Krinkle:
mw.Target: Fix document focus scroll bug

https://gerrit.wikimedia.org/r/99718
Confirming with Firefox 25 on Fedora 20 on mediawiki.org.
**Wikifram** wrote:

Note that the ''cursor'' is at the top, but the part of the page you view (if the page is longer than the screen) is the bottom, so your cursor isn't even visible when you start typing... If it had been intentional, I suppose that the cursor would have been at the bottom as well (still useless, but at least consistent).
Steps to reproduce:

1.Open any article on VE
2.Add a bullet list
3.Try to add an image as a bulleted item of that list ( the image goes to the right side but keep it like that)
4.Save the page
5.Reopen the editor
6.Now go to position where empty bullet list is.
7.Now try to remove it by clicking ob bullet list icon from the toolbar

Observed Result:
The Editor become completely unresponsive

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in Betalabs
Cannot verify this issue for:https://bugzilla.wikimedia.org/show_bug.cgi?id=62022
Change 115402 merged by jenkins-bot:
Add special case to de-indentation for slugs in listItems

https://gerrit.wikimedia.org/r/115402
Change 115385 merged by jenkins-bot:
Check indentation was successful before trying again

https://gerrit.wikimedia.org/r/115385
Change 115402 had a related patch set uploaded by Esanders:
Add special case to de-indentation for slugs in listItems

https://gerrit.wikimedia.org/r/115402
Above patch prevents infinite loop. Need to investigate why indentation is failing.
Change 115385 had a related patch set uploaded by Esanders:
Check indentation was successful before trying again

https://gerrit.wikimedia.org/r/115385
Also occurs (same STR) with the wikitext

* {{infobox}}

on testwiki.
Created attachment 13998
Screenshot

**Attached**: {F12233}
Infact it makes the browser page unresponsive.I could not close the browser window even until it showed an error to kill page in Chrome and stop script in FF.

See the screenshot attached.

Test Environment: production
Browser: Chrome Version 26.0.1410.65 &       FF 25
OS: MAC OS X 10. 8. 5 

Example Page:https://en.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/unresponsive?veaction=edit

In this page, Go to the last bullet and click on Bullet icon from toolbar to reproduce.
Infact it makes the browser page unresponsive.I could not close the browser window even until it showed an error to kill page in Chrome and stop script in FF.

See the screenshot attached.

Test Environment: production
Browser: Chrome Version 26.0.1410.65 &       FF 25
OS: MAC OS X 10. 8. 5 

Example Page:https://en.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/unresponsive?veaction=edit

In this page, Go to the last bullet and click on Bullet icon from toolbar to reproduce.
Screenshot

Button UI is missing in production for Link/Undo/Redo/Cancel formatting 

See the screenshot attached.

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F12207}
Verified in Production
Deployment issue fixed by touching the OOjs UI file in wmf5:

https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=91382&oldid=91381
I am not seeing any UI of the following buttons in production:
Link/Undo/Redo/Cancel formatting/Paragraph drop down/More options/computer code/Media/Help/Settings
Created attachment 13997
Screenshot of the UI missing in More option

**Attached**: {F12208}
Test Environment: production
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5 
Page:https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/windows8?veaction=edit
Steps to reproduce:

There are several issues in this bug.I tried to document all of them chronologically in one issue for convenience.


1.click on the Edit button
2.click on the bullet list icon.
3.Click on tab to add indentation to the list for several times.
4.Now press Enter/Return
5.It deletes the bullets, where as pressing delete does not do that.
6.After deleting all the bullets by pressing return it goes to the next line 
7.Again add bulleted list with indentation on the first line
8.Now this time if you press Enter it goes to the next line but does not add next bullet.
9.Now go to the end of the first line and press enter, this time the next bullet gets added.
10.Now try adding indentation to the second item , it does not work
11.Delete the bullet and repeat the action again,this time it will add indentation.
12.Now if you save the page , you will see there is no bullets in the read mode
13.If you try to delete all the content by selecting with mouse pad, it gives the error:
"Uncaught Error:Invalid start offset:-1"


Test Environment: production
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Example Page where in the read mode there is no bullets but in the edit mode they appear:

http://en.wikipedia.beta.wmflabs.org/wiki/New_bullet

--------------------------
**Version**: unspecified
**Severity**: normal
Looks like this was done as part of the "handle enter" re-write.
Giving steps to reproduce again:

1.Open a completely new page with VE
2.Add a text
3.Click on Bullet list icon from the toolbar
4.Add indentation to that line
5.Go to the next line (Adds a second bullet)
6.Add indentation to this second bullet line too
7.Go back to the first bullet point and delete the text
8.Go back to end of the second empty bullet point
9.Press Delete(this will bring all the bullet points in one line)

After this step you will get the error:Uncaught TypeError: Cannot call method 'getOffset' of null 

If you press Delete again it will show error Uncaught Error: Invalid start offset: -1
I can't reproduce this problem as written (Chrome here too), but there is some funkiness related to being able to split some mutli-depth bullet list items oddly.
Created attachment 14234
Reproduced on 6th Jan

**Attached**: {F12102}
Yes , I can still reproduce it.Attaching the screenshot.
Are you getting the error:Uncaught TypeError: Cannot call method 'getOffset' of null ?
I've reproduced the steps in the video but I don't get an exception. Can you try again with the latest code.
Created attachment 14088
video capture of the bug

**Attached**: {F12101}
Steps 1-7 are as expected. I don't understand step 8, as after 7 there is only one double-indented bullet item.
Another way to reproduce the error "Uncaught Error:Invalid start offset:-1"

1.Open the editor
2.Add a text 
3.Go the next line add a bullet list with a text
4.Add indentation to that item
5.Press enter go to the next line then add indentation to the second empty bullet item
6.Press enter to go to the next line
7.It actually takes the cursor to the end of first bulleted item
8.Press delete until all the bullets comes in the same line.
9.The cursor then moves to the end of the first line of step 2
10.Delete that text
11.Now place your cursor at the end of series bullets press delete to delete it

A. you will get the error:Uncaught TypeError: Cannot call method 'getOffset' of null

B. If you again press delete , you will get "Uncaught Error:Invalid start offset:-1"

C. if you press undo then redo, you will get "Uncaught Error: Unbalanced input passed to document"

D. if you attempt to save the page, you will get "Uncaught TypeError: Cannot set property 'lastOuterPost' of null"
Screenshot of the error

Steps to reproduce:

Still Unknown.Will update once I get it.

Mostly it occurred to me when I reload an open editor after an idle time or switch from Edit Source to VE it does not the editor and shows the following error:


TypeError:Cannot read property 'Element' of undefined >TypeError

See the screenshot attached

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

**Attached**: {F12080}
verified the fix in production.
Verified the fix on betalabs:http://en.wikipedia.beta.wmflabs.org/
One way it is always reproducible is: while creating a new page switch to Create-Beta.
Somehow OO.ui becomes undefined. I have no idea why.
Created attachment 13984
Screenshot of the error

**Attached**: {F12082}
From VE, switched to Edit source then again switching back to VE gave this error this time and VE did not load

Uncaught TypeError: Cannot read property 'Element' of undefined
VeUiSurface
(anonymous function)
Created attachment 13983
Screenshot of the error

**Attached**: {F12081}
The environment in my previous comment will be betalabs.

The error occured again while creating a new page on Betalabs.

ypeError: Cannot read property 'Element' of undefined TypeError {} load.php:145
log load.php:145
runScript load.php:154
checkCssHandles load.php:155
(anonymous function) load.php:155
fire load.php:12
self.fireWith load.php:14
self.fire load.php:14
addEmbeddedCSS load.php:149
(anonymous function) load.php:149
Test Environment: production
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5 
Example Page:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:RYasmeen_(WMF)&veaction=edit
First impressions count! You can make the initial experience of loading VE substantially faster by prefetching the modules on a standard article page if the DOM isn't busy.

What I have in mind is something like this:

    $( window ).load( function () {
        if ( !mw.loader.store.enabled ) {
            return;
        }

        setTimeout( function () {
            var modules = [
                'ext.visualEditor.base',
                'ext.visualEditor.core'
                'ext.visualEditor.data',
                'ext.visualEditor.icons-vector',
                'ext.visualEditor.mediawiki',
                'ext.visualEditor.viewPageTarget',
                'ext.visualEditor.viewPageTarget.icons-vector',
            ]

            mw.loader.using( modules.filter( function ( module ) {
                var key = mw.loader.store.getModuleKey( module );
                return key in mw.loader.store.items;
            } ) );

        }, 0 );
    } );


You'd need to ensure that the modules don't execute automatically somehow.

--------------------------
**Version**: unspecified
**Severity**: enhancement
I'll challenge my own contention from 2013:
> You can make the initial experience of loading VE substantially faster 

Probably not. For all but the slowest of connections, VE load time is dominated by the cost of fetching the Parsoid DOM, building the linear model, and then building the ContentEditable DOM from the linear model. The cost of retrieving the JavaScript and CSS is negligible in comparison.

This may or may not be worth doing, but in the absence of good data, there is no strong case for doing this work, so I'm closing this for now.
Roan says there should be some infrastructure in RL to do this.
It's fine for them to execute automatically, nothing happens until .activate() is invoked.
Wiktext:
[[File:Image.jpg|thumb|Foo]]
Bar

Place the cursor the the left of 'B' and press backspace

Expected: Image is focused
Result: 'Bar' is moved into the image caption

--------------------------
**Version**: unspecified
**Severity**: normal
verified in betalabs
Change 99419 merged by jenkins-bot:
Prevent content selections ending up inside handlesOwnChildren nodes

https://gerrit.wikimedia.org/r/99419
Change 99419 had a related patch set uploaded by Esanders:
Prevent content selections ending up inside handlesOwnChildren nodes

https://gerrit.wikimedia.org/r/99419
1. Open VE on a page
2. Make a change
3. Go into save dialog, review diff
4. Close save dialog without saving
5. Click Read tab, click through warning that you'll lose your changes
6. Click Edit tab to open VE again
7. Make a change that's very different from #2
8. Go into save dialog, review diff
9. Observe that the diff displayed is for #2, not #7

--------------------------
**Version**: unspecified
**Severity**: major
Change 98752 merged by jenkins-bot:
Clear cache key when deactivating target

https://gerrit.wikimedia.org/r/98752
Change 98752 had a related patch set uploaded by Catrope:
Clear cache key when deactivating target

https://gerrit.wikimedia.org/r/98752
On fr.wp at least a couple of edits were noticed that generated snowmen:

https://fr.wikipedia.org/w/index.php?title=D%C3%A9sir_mim%C3%A9tique&diff=98365348&oldid=96841726
and https://fr.wikipedia.org/w/index.php?title=Andromaque&diff=98765089&oldid=97860409 (a vandalism).

The snowman appears in the word "français(e)" (so it's possibly related to the ç character?).

No other details available - the first editor didn't provide them, and the other was a vandal.

--------------------------
**Version**: unspecified
**Severity**: major
I believe that we fixed the last of the snowmen issues (ha!) with the re-write last week; I've not been able to reproduce these edits at all now. Provisionally marking as FIXED.
*** Bug 67591 has been marked as a duplicate of this bug. ***
Here's another odd set of snowmen, this time at the Javanese Wikipedia.  

https://jv.wikipedia.org/w/index.php?title=Igor_Stravinsky&curid=73209&diff=881366&oldid=830233

The edit was inappropriate (poor English replacing Javanese) and was reverted.
About the first case, where an external link was added and a <br> tag can also be observed, User:Drongou notes that it is "utterly incomprehensible. It's impossible to add a <br> vith VE, and VE itself does not seem to generate it. It must have come from copy/paste (snowmen are typical of failed copy/paste). Really strange, (one would rather expect a <br />): all the inclusions of <br> should be checked."

I roughly translated his words. I didn't notice that before - he's right that adding <br> by hand in VE would produce nowiki tags, which are not there.
For action=flow:
* The "flowaction" parameter lacks a description.
* The "page" parameter lacks a description.
* The "flowaction" parameter does not list available actions.
* The "params" parameter is poorly documented. Passing a json blob of "params" is rather awful. I might rather see a setup where "flowaction" selects a submodule, along the lines of how action=query works, so these parameters could actually be documented in api.php.
* getExamples() should be properly implemented.
* getHelpUrls() should be implemented.
* I'm assuming at least some of the possible flowactions are write actions. isWriteMode() should therefore return true.
* I note that ApiBase is already a ContextSource, so there is no need for $this->getContext()->getUser() instead of just $this->getUser().
* I see you're setting "_element" directly. Use ApiResult's method to handle that instead, please. The same goes if you're setting "*" directly anywhere.
* I see that sometimes the "result" element in the result will be an associative array and sometimes it will be the string "error". I'd rather see a "status" element of some sort that is always a string and have "result" always be an associative array when it is present.
* I see you have a "doRenderer" protected method that is never actually called.

For list=flow:
* The link returned by getHelpUrls() does not actually document this API module.
* The "flowaction" parameter does not list available actions.
* Same criticisms of the "params" blob as above.
* You are setting "_element" directly instead of using ApiResult's methods.
* You should be checking the return from ApiResult's addValue method and properly handling failure.

--------------------------
**Version**: master
**Severity**: normal
Marking as fixed, the issues in comment 0 were fixed, and it supports autogenerated documentation.

What's still missing is the on-wiki documentation, that's bug 58361.
(In reply to Brad Jorsch from comment #0)

> For list=flow:
> * The link returned by getHelpUrls() does not actually document this API
> module.

I had removed this earlier, but I'll make sure to add it in once the parameters are finalized.

> * The "flowaction" parameter does not list available actions.

Removed in I73347cb3b0a8cf35881691f50e70be10d10571b8 because it's pointless.

> * Same criticisms of the "params" blob as above.

After looking through all the JS that call this, they're either options to control the result format, like "contentFormat": "wikitext", or they're a post-id. I'll turn this into 2-3 more parameters to the API module directly.

> * You are setting "_element" directly instead of using ApiResult's methods.

Note to self that this needs to be fixed in all implementations of Block::renderAPI as well.

> * You should be checking the return from ApiResult's addValue method and
> properly handling failure.

From the documentation, addValue will return false if the data is too big. We'll need some kind of continuation parameter...I'm not exactly sure how Flow handles that internally.

https://gerrit.wikimedia.org/r/#/q/project:mediawiki/extensions/Flow+topic:flow-api,n,z
action=flow looks much better!

list=flow still needs work though, so reopening.
Change 107411 merged by jenkins-bot:
API: Revamp action=flow

https://gerrit.wikimedia.org/r/107411
This bug is marked as "PATCH_TO_REVIEW", but the patch in question is marked as work in progress ("[WIP]").  For clarity, I'm moving this back out to "assigned", since I understand that Kunal is working on it.
> (In reply to comment #21)
Alex Z., what do you and others want from a Flow API?  How can we best collaborate on it?  A Flow board makes API requests for all in-page updates, so Flow heavily exercises its API while we implement Brad Jorsch's feedback, but I'm concerned about what we overlook. I filed bug 60808 and bug 60809, but I'm just guessing.

Erik Bernhardson posted https://en.wikipedia.org/wiki/Wikipedia:Bot_owners%27_noticeboard#New_extension:_Flow , so that's another venue. I mentioned these bugs there.

I've created https://www.mediawiki.org/wiki/Flow/Architecture/API with links to these, and empty sections awaiting use cases. I'll try to keep it updated.

Thanks everyone.
(In reply to comment #21)
> So, to expand: I fully believe that the community should be factored into the
> decision-making process, directly and indirectly - but factored in is very
> different from being a trump card. If the argument is "there will be people
> who
> look at the API and think it's Us Doing The VisualEditor All Over Again",

I'm looking at this and thinking, "Oh, no, it's them doing WikiEditor all over again," where a product is deployed to wikis before the API is properly documented or becomes stable, and bot/script developers practically have to reverse engineer it in order to update all of their code in time.

I mean, you're at the point of field testing it in production, but there apparently isn't even a specification for how the real API will work, let alone a place where the people who will be using it might actually be able to make some input.
(In reply to comment #24)
> (In reply to comment #23)
> > Easily. Just include the necessary text in the string returned from the
> > module's getDescription() method.
> 
> Sorry, more meant "Can the team please do this soon, or say why not?" :)

https://gerrit.wikimedia.org/r/#/c/110967/ should address that.
(In reply to comment #23)
> Easily. Just include the necessary text in the string returned from the
> module's getDescription() method.

Sorry, more meant "Can the team please do this soon, or say why not?" :)
(In reply to comment #22)
> So, back on topic...
> 
> From Brian on bug 60178 comment 28:
> "I would think the appropriate thing to do (If we must do this) is to
> include a
> note in the auto-generated api documentation."
> 
> Can this be done

Easily. Just include the necessary text in the string returned from the module's getDescription() method.
So, back on topic...

From Brian on bug 60178 comment 28:
"I would think the appropriate thing to do (If we must do this) is to include a note in the auto-generated api documentation."

Can this be done, or explain why not? I still think a note to BAG or similar is good in addition, personally.
(In reply to comment #19)
> (In reply to comment #9)
> 
> > Possibly. There are some community members who would find a way to take
> > offence to "how is your day going?". I don't particularly think we should base
> > our decisions around pandering to them.
> 
> This is unacceptable attitude, Oliver. You in particular should know better
> than that.

Sorry, I should be clearer; the 'them' is 'the sort of people who would find a way to take offence...'

So, to expand: I fully believe that the community should be factored into the decision-making process, directly and indirectly - but factored in is very different from being a trump card. If the argument is "there will be people who look at the API and think it's Us Doing The VisualEditor All Over Again", that's a bad argument, and the sort of people who would jump from 'the minimum viable product is not perfect' to 'everything is going to be terrible forever' are not people I am particularly interested in basing our decisions on, because anyone who _makes_ that cognitive leap is clearly not approaching things rationally, and so it becomes very hard to actually compromise with them - if compromising with them is actually worthwhile in the first place.
(In reply to comment #13)
> Personally I find impersonal communication methods like bugzilla a passive
> aggressive way to air issues without actually talking to anyone directly.

I'm severely confused. After reading comment 0 out of the blue, I expected comment 1 to start like this: "Great Brad, thanks for your thorough review of our API module! It's very useful when someone helps us learn more about/do better with some specialised areas of the code rather than let us alone hitting against a wall". And then a conversation to clarify the various actionable items and to log them properly in atomic bugs or cards.
(In reply to comment #9)

> Possibly. There are some community members who would find a way to take
> offence to "how is your day going?". I don't particularly think we should base
> our decisions around pandering to them.

This is unacceptable attitude, Oliver. You in particular should know better than that.
(Off-topic, like the rest of the last 6 or so comments, but, I wanted to publicly say: Sorry for my tone. We'll work together on addressing this bug.)
(In reply to comment #15)
> (In reply to comment #14)
> > Bugzilla is how one files bugs against a product--sorry you don't like it.
> > The
> > nice thing is it's asynchronous so if someone is in a different timezone they
> > can easily report issues without waiting for you to be around :)
> 
> Bugzilla is an excellent way to track bugs, but for solving problems nothing
> beats communicating with a human being in real time.  The foundation uses
> real
> time communication within teams extensively to organize and ensure the work
> they want to get done happens.  Embrace the most effective forms of
> communication you can.
> 
> Lucky for those in other timezones, we have team members in 2 american
> timezones, europe and australia.

The point is simply: there was a bug report by a respected member of the platform team (whether or not you knew he was the point person for the API); please respond to bug reports. People are busy and reviewing a lot of people's code and can't be on point to track everyone down all the time (seriously, if Platform had to do that, we'd never get anything else done).

Please take some initiative and review your bugzilla tickets and ask for clarification where needed.
(In reply to comment #15)
> (In reply to comment #14)
> > Bugzilla is how one files bugs against a product--sorry you don't like it.
> > The
> > nice thing is it's asynchronous so if someone is in a different timezone they
> > can easily report issues without waiting for you to be around :)
> 
> Bugzilla is an excellent way to track bugs, but for solving problems nothing
> beats communicating with a human being in real time.

Indeed. But it's also good to file bugs because people are imperfect and can forget conversations they have :)

> The foundation uses
> real
> time communication within teams extensively to organize and ensure the work
> they want to get done happens.  Embrace the most effective forms of
> communication you can.
> 

I know how the Foundation works...I work here too ;-)

Is real time communication awesome? Sure. Is finding someone on IRC to chat about your problem sometimes faster than a bug? Absolutely.

But you said:

(In reply to comment #13)
> Personally I find impersonal communication methods like bugzilla a passive
> aggressive way to air issues without actually talking to anyone directly.  If
> you had come into our irc room months ago and xommunicated in real time I
> guarantee this bug would be in a different state.

Regardless of your personal opinions about Bugzilla, it's where we file bugs about
our software--all of it. It's completely reasonable to expect people to file bugs here, and they should be treated with just as much interest and care as things tracked in Mingle, Trello, or reported to the IRC ether.
(In reply to comment #14)
> Bugzilla is how one files bugs against a product--sorry you don't like it.
> The
> nice thing is it's asynchronous so if someone is in a different timezone they
> can easily report issues without waiting for you to be around :)

Bugzilla is an excellent way to track bugs, but for solving problems nothing beats communicating with a human being in real time.  The foundation uses real time communication within teams extensively to organize and ensure the work they want to get done happens.  Embrace the most effective forms of communication you can.

Lucky for those in other timezones, we have team members in 2 american timezones, europe and australia.
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #10)
> > > (In reply to comment #7)
> > > > In the future, let's not rely on passive Bugzilla communication
> > > > around things you feel are serious blockers; let's just talk to each other
> > > > directly
> > > 
> > > In that case please document outcome as a comment in Bugzilla, so community
> > > members can also be aware and provide input if they were not physically
> > > around
> > > in your office.
> > 
> > Personally, I find bugzilla works as well as email and IRC doesn't seem like
> > it
> > would have been that much of an improvement here.
> > 
> > No one besides me is around my office. ;)
> 
> Personally I find impersonal communication methods like bugzilla a passive
> aggressive way to air issues without actually talking to anyone directly.  If
> you had come into our irc room months ago and xommunicated in real time I
> guarantee this bug would be in a different state.

Bugzilla is how one files bugs against a product--sorry you don't like it. The nice thing is it's asynchronous so if someone is in a different timezone they can easily report issues without waiting for you to be around :)
(In reply to comment #12)
> (In reply to comment #10)
> > (In reply to comment #7)
> > > In the future, let's not rely on passive Bugzilla communication
> > > around things you feel are serious blockers; let's just talk to each other
> > > directly
> > 
> > In that case please document outcome as a comment in Bugzilla, so community
> > members can also be aware and provide input if they were not physically
> > around
> > in your office.
> 
> Personally, I find bugzilla works as well as email and IRC doesn't seem like
> it
> would have been that much of an improvement here.
> 
> No one besides me is around my office. ;)

Personally I find impersonal communication methods like bugzilla a passive aggressive way to air issues without actually talking to anyone directly.  If you had come into our irc room months ago and xommunicated in real time I guarantee this bug would be in a different state.
(In reply to comment #10)
> (In reply to comment #7)
> > In the future, let's not rely on passive Bugzilla communication
> > around things you feel are serious blockers; let's just talk to each other
> > directly
> 
> In that case please document outcome as a comment in Bugzilla, so community
> members can also be aware and provide input if they were not physically
> around
> in your office.

Personally, I find bugzilla works as well as email and IRC doesn't seem like it would have been that much of an improvement here.

No one besides me is around my office. ;)
(In reply to comment #10)
> (In reply to comment #7)
> > In the future, let's not rely on passive Bugzilla communication
> > around things you feel are serious blockers; let's just talk to each other
> > directly
> 
> In that case please document outcome as a comment in Bugzilla, so community
> members can also be aware and provide input if they were not physically
> around
> in your office.

I think that's what Maryana just said she'd do. Indeed, it's what she just did :).
(In reply to comment #7)
> In the future, let's not rely on passive Bugzilla communication
> around things you feel are serious blockers; let's just talk to each other
> directly

In that case please document outcome as a comment in Bugzilla, so community members can also be aware and provide input if they were not physically around in your office.
(In reply to comment #8)
> (In reply to comment #7)
> > Putting Flow out there on a couple of real discussion spaces
> > is
> > the only way we're going to be able to get actionable feedback on the design
> > and UI side. The sooner we start receiving this kind of feedback, the sooner
> > we
> > can prioritize our work on all the outstanding bugs, enhancements and feature
> > requests, so we get the right features to the right users at the right time.
> 
> That sounds like the same reasoning they used when deploying VE to enwiki
> with
> known bugs unfixed. I think we all know how well *that* went.
> 
> I realize the proposed deployment of Flow to enwiki is somewhat different
> since
> it's a deployment to two rather out-of-the-way talk pages rather than being
> enabled by default for everyone. But on the other hand, it's also that much
> less likely to give you the sort of feedback you're hoping for. And certain
> vocal community members will be on the defensive given the recent VE
> situation,
> ready to blast "the WMF" for doing the "same" thing again.
> 
Possibly. There are some community members who would find a way to take offence to "how is your day going?". I don't particularly think we should base our decisions around pandering to them.
> 
> (In reply to comment #7)
> > I understand that your priorities as a platform engineer fall toward making
> > sure our API is robust and well-documented.
> 
> I also want to avoid causing our volunteer community members to develop
> towards
> an API with known major flaws by pushing it on a production site before it's
> ready. The test wikis and mediawiki.org, while in production, are still test
> sites.
(In reply to comment #7)
> Putting Flow out there on a couple of real discussion spaces
> is
> the only way we're going to be able to get actionable feedback on the design
> and UI side. The sooner we start receiving this kind of feedback, the sooner
> we
> can prioritize our work on all the outstanding bugs, enhancements and feature
> requests, so we get the right features to the right users at the right time.

That sounds like the same reasoning they used when deploying VE to enwiki with known bugs unfixed. I think we all know how well *that* went.

I realize the proposed deployment of Flow to enwiki is somewhat different since it's a deployment to two rather out-of-the-way talk pages rather than being enabled by default for everyone. But on the other hand, it's also that much less likely to give you the sort of feedback you're hoping for. And certain vocal community members will be on the defensive given the recent VE situation, ready to blast "the WMF" for doing the "same" thing again.


(In reply to comment #7)
> I understand that your priorities as a platform engineer fall toward making
> sure our API is robust and well-documented.

I also want to avoid causing our volunteer community members to develop towards an API with known major flaws by pushing it on a production site before it's ready. The test wikis and mediawiki.org, while in production, are still test sites.
Change 107411 had a related patch set uploaded by Legoktm:
[WIP] Revamp API

https://gerrit.wikimedia.org/r/107411
Flow team: This was reported in November with pretty clear concerns. Brad is the current point of reason/arbitration for the API. Can you give a response to this as well? (On BZ not Mingle ;) ).
(In reply to comment #3)
> (In reply to comment #0)
> > * The link returned by getHelpUrls() does not actually document this API
> > module.
> 
> Removed in https://gerrit.wikimedia.org/r/#/c/102030/

Good to get rid of the bad link. But list=flow does need a valid implementation of getHelpUrls(). I expect you already are aware of this, but the obvious bears stating.
(In reply to comment #0)
> * I note that ApiBase is already a ContextSource, so there is no need for
> $this->getContext()->getUser() instead of just $this->getUser().

https://gerrit.wikimedia.org/r/#/c/102046/

> * The link returned by getHelpUrls() does not actually document this API
> module.

Removed in https://gerrit.wikimedia.org/r/#/c/102030/
Marking as high priority, it gets much harder to change the API once something is deployed...
**bingle-admin** wrote:

The WMF core features team tracks this bug on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/532, but people from the community are welcome to contribute here and in Gerrit.
Steps to reproduce:
* Click on an image before a text node. The image will be marked as selected.
* Press rightarrow to cursor next to the text.
* Start typing. The text will be inserted backwards.

Cause:
After cursoring off the image, the selection is in the text node (and the cursor is flashing), but the focus is not.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54917
Change 97750 merged by jenkins-bot:
Fix moving over an image with the arrow keys in Firefox

https://gerrit.wikimedia.org/r/97750
Change 97750 had a related patch set uploaded by Catrope:
Fix moving over an image with the arrow keys in Firefox

https://gerrit.wikimedia.org/r/97750
*** Bug 57347 has been marked as a duplicate of this bug. ***
Change 97750 had a related patch set uploaded by Divec:
Fix post-image selection bug

https://gerrit.wikimedia.org/r/97750
Other modules (and gadgets) should be able to hide their interfaces when VisualEditor is opened - for example the Nearby pages BetaFeature (https://www.mediawiki.org/wiki/Beta_Features/Nearby_Pages) creates a blue button in the top right.

Ideally this feature should be able to know when it is in edit mode and hide itself.

Maybe abusing the action-edit / action-view classes would be useful here?

--------------------------
**Version**: unspecified
**Severity**: normal
Change 97702 merged by jenkins-bot:
mw.ViewPageTarget: Use ve-activated class on the html element

https://gerrit.wikimedia.org/r/97702
Change 97702 had a related patch set uploaded by Robmoen:
Toggle veaction-edit class on the body of the view page

https://gerrit.wikimedia.org/r/97702
Screenshot

Steps to reproduce:

1.Click on the Edit button in a page
2.Select a text by dragging with mouse control.
3.Change the heading format of the text to any format for example:heading/paragraph etc.

Observed Result:
The cursor moves to a position which is the middle of the first and second line of the page

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

**Attached**: {F12046}
*** Bug 60139 has been marked as a duplicate of this bug. ***
Verified the fix in betalabs:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=27thfebchrome&veaction=edit
Change 115759 merged by jenkins-bot:
Restore focus after node-destroying actions

https://gerrit.wikimedia.org/r/115759
Change 115759 had a related patch set uploaded by Esanders:
Restore focus after node-destroying actions

https://gerrit.wikimedia.org/r/115759
This issue is still happening however I am changing the steps and observed result as follows:

Steps to reproduce:

1.Open a page with VE
2.Select any text with keyboard/mouse control/double click
3.Change the heading format of the section to any format, for example:Preformatted/Sub-heading 1 etc.

Observed Result:
The cursor jumps to the beginning of the page.Now Type something on the first line or apply a format on the first line say "Page title", it actually adds the text in the text position of step 2 replacing replacing its previous content and style.
Test Environment: production
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5 
Example Page:https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/ref_not_editable?veaction=edit
https://gerrit.wikimedia.org/r/#/c/96984/ adds a workaround for the fact that getting the directionality from the FocusedNode doesn't work if there is no node focused (i.e. in creation mode), but it doesn't add any alternative logic for getting the directionality. We should look at the context in the CE tree somehow and figure out what directionality to use. Right now it just defaults to the UI directionality.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 101125 merged by jenkins-bot:
Add a getDirectionFromRange Method to ve.ce.Document

https://gerrit.wikimedia.org/r/101125
Change 101125 had a related patch set uploaded by Mooeypoo:
Add a getDirectionFromRange Method to ve.ce.Document

https://gerrit.wikimedia.org/r/101125
At the end of the first paragraph there is reference #1.
If you scroll to the reference list, it will look empty.

Actually, the reference, which can be edited, contains an unnamed link. 
The markup guide for en.wp says these links are "Only used within article body
for footnotes", so it makes sense that VE should display them correctly.

--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://en.wikipedia.org/w/index.php?title=User:Elitre_%28WMF%29/sandbox&veaction=edit
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57419
Change 97037 merged by jenkins-bot:
Also apply autonumbering CSS to links in generated content

https://gerrit.wikimedia.org/r/97037
*** Bug 57209 has been marked as a duplicate of this bug. ***
This happened because the numbered link was generated by a template (indirectly in this case: it was in the references list which was in turn generated by {{reflist}}), and the CSS we use to do the numbering didn't account for numbered links in templates.
Change 97037 had a related patch set uploaded by Catrope:
Also apply autonumbering CSS to links in generated content

https://gerrit.wikimedia.org/r/97037
**Author:** `swalling`

**Description:**
Screenshot from mediawiki.org

The box that appears on hover around dropdown menu items overlaps with the text for the "Switch to source editor" option. (See attachment)

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F12471}
Verified the fix in Production
*** Bug 69707 has been marked as a duplicate of this bug. ***
Verified the fix in Betalabs and test2
This bug got fixed with this change commit:https://gerrit.wikimedia.org/r/#/c/157295/
*** Bug 70316 has been marked as a duplicate of this bug. ***
Created attachment 16280
Screenshot of problem on master.

It's worse now that the "Cancel" button is gone. The menu is even narrower now and more items are cut off. And the "Switch to source text" item is now actually cropped instead of just partially hanging outside the container.

**Attached**: {F12472}
*** Bug 69808 has been marked as a duplicate of this bug. ***
I believe this blocks bug 67340 (or at least, this being fixed would be useful there).
@Krinkle: Ping. Any progress on this?
Bumping priority now that the loss of the Cancel button makes this more acute.
*** Bug 68483 has been marked as a duplicate of this bug. ***
*** Bug 61149 has been marked as a duplicate of this bug. ***
Merging in bug 61149 to this.
**Author:** `Wikifram`

**Description:**
There are a number of bugs about pawns and/or reverse typing, many of them "resolved fixed". But it is clear that in many circumstances, on different wikiversions, pawn characters and reverse typing still occur. 

See [[en:Wikipedia:VisualEditor/Feedback#Line with template, pawn]] (and the linked sections on fr-wiki as well) for an explanation of some scenarios when this occurs. This has, in various guises, been reported since the first deployment of VE, and none of the fixes seem to have been permanent or fundamental. Can this please be tackled?

--------------------------
**Version**: unspecified
**Severity**: major
Re-merged with bug 57600, as slightly distinct from bug 54917.

*** This bug has been marked as a duplicate of bug 57600 ***
Merging into bug 54917 which is the same, yes.

*** This bug has been marked as a duplicate of bug 54917 ***
Possibly a dupe of https://bugzilla.wikimedia.org/show_bug.cgi?id=54917?
The above was related to templates (that is, a weird behavior when templates are selected and then deselected via keyboard arrows). The opposite happens when dealing with references.

1. https://en.wikipedia.org/wiki/Selan_%28Dungeons_%26_Dragons%29?veaction=edit
2. Put your cursor right after the first reference number ([1]).
3. Arrow left.
4. Arrow left.
5. Start typing.

You are typing backwards.

Also:

1. and 2. as above.
3. Arrow left.
4. Arrow right.
5. Start typing.

A pawn appears.
In short (and partially reusing Fram's words).
This happens in FF, in both MB and Vector.

1. VEdit https://en.wikipedia.org/wiki/Selan_(Dungeons_%26_Dragons) .
2. Put your cursor at the start of the text (i.e. before "In the...").
3. Arrow left.
4. Arrow left.
5. Start typing.

A pawn appears. 

Also:

1. and 2. as above.
3. Arrow left.
4. Arrow right (nothing happens; a bug in its own right?)
5. Arrow right.
6. Start typing.

You are typing backwards.
The current event reaction order means that many IMEs including jQuery.IME and a number of Windows built-in input methods don't work in VE; we should change it to something that does – needs investigation as to what order is right.

--------------------------
**Version**: unspecified
**Severity**: major
IME support has improved markedly due to incrementally revamped event logic. Significant milestones included:

https://gerrit.wikimedia.org/r/86688 - Selection change debounce
https://gerrit.wikimedia.org/r/91786 - Fixup selection after rerender
https://gerrit.wikimedia.org/r/105231 - Reduce refreshes
https://gerrit.wikimedia.org/r/125937 - Unicorns
https://gerrit.wikimedia.org/r/166188 - Poll refactor
https://gerrit.wikimedia.org/r/179530 - Stable selections
https://gerrit.wikimedia.org/r/177946 - Native left/rightarrow

The basic way VE handles events is probably right now, given all the constraints of the browser environment and all the features of unicode/individual scripts that must be supported. Any unresolved dependent bugs can now be given a more specific diagnosis :-)
Regression of bug 52427.

--------------------------
**Version**: unspecified
**Severity**: normal
Looks like this got fixed at some point because it works for me.
Intention:
Copyedit a page

Steps to Reproduce:
1. Open a page with pre-existing content.
2. Type or change some of the text (I was adding a new first line).
3. Select and cut (⌘ Command+x) some pre-existing text (I cut mine from the end of the third line).
4. Notice that what you typed on the first line has been undone.
5. Paste what you cut (in my case, at the end of the first line).
6. Notice that what you typed on the first line has been redone.



Expected Results:  
That text would not magically disappear and reappear.

Reproducible: Always

I experienced this on office.wikipedia.org using Safari 6 on Mac OS 10.7.5.  It was confirmed at en.wikipedia.org using Vector/Chrome 30/Windows 7, with the additional discoveries that:

If you type your new first line all in one go (so that 'undo' would remove the whole first line), the first character of the new line remains present.

The undone text only reappears if you paste your cut text onto the line with the now-missing text.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=58724
Fixed at the same time as bug 58724.
My computer is brand new, no custom shortcuts. Maybe VE is using a keyboard shortcut hack to make undo possible.
Whether it's impossible or not, it happens every time I use Command-X in Safari after closing a tab.  It only happens if "Undo closed tab" is listed in Safari's Edit menu as the action for undo/Command-Z.  It's bug 58724.
(In reply to Mc128k from comment #1)
> I have a similar issue that makes Safari reopen a closed tab, same with
> cmd-x.
> It doesn't happen immediately and in all cases though.

I'm pretty sure it's impossible for VisualEditor to cause a browser to re-open a tab; you probably have a keyboard mapping clash or something similar?
I have a similar issue that makes Safari reopen a closed tab, same with cmd-x.
It doesn't happen immediately and in all cases though.
With Vector in FF.
Try to add a caption to an image:
the words will be splitted on multiple lines, with the first letter being automatically placed on the second line, the other letters on the first one, and no ability to fix this.

I understand that https://bugzilla.wikimedia.org/show_bug.cgi?id=38129 is coming but I thought I'd file this anyway.

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed last week as part of our fix-up of how windows works, happily (or, at least, I think so – I can replicate on enwiki but not on MediaWiki.org).
It is.
This is probably specific to Firefox.  I'm able to replicate this in Firefox 25 on a Mac, but not Safari 6.
On desktop, as soon as the visual editor is loaded, the cursor is activated at the beginning of the page content. This doesn't happen in the mobile version.

Clicking on the page content after the editor has loaded then has inconsistent behavior between browsers. In Firefox, clicking anywhere in the page content inserts the cursor at the beginning of the content. In Webkit browsers, it inserts the cursor at the click location.

I believe that fixing the first problem will also fix the second problem in for free.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=67389
https://bugzilla.wikimedia.org/show_bug.cgi?id=67390
https://bugzilla.wikimedia.org/show_bug.cgi?id=67399
According to Juliusz this is on purpose as tablets require an actual tap to activate the virtual keyboard.
This is caused by code in MF, line 152 of VisualEditorOverlay.js:

// for some reason the first time contenteditables are focused, focus
// event doesn't fire if we don't blur them first
this.$( '[contenteditable]' ).blur();

The code was added to fix bug 61240.
(In reply to Ryan Kaldari from comment #2)
> We would like to have this fixed before we push mobile VE to stable if
> possible. Any update on it?

… no? Bugs in VE/Mobile have been awaiting triage and action by the Mobile since this was agreed in 2012. We can have a look at it now, though.
We would like to have this fixed before we push mobile VE to stable if possible. Any update on it?
This is in reference to Rob's prototype mobile visual editor. https://gerrit.wikimedia.org/r/#/c/93916/
>>! In T59153#1822120, @Etonkovidova wrote:
> 4)
>>Watchlist --
>> For the post/reply/edit, the link should render as the title (no brackets), and should link to the Topic:UUID, not to the page.
>> For editing the topic summary, the link should render as the title, not linked.
> 
> {F2993084}

That looks like a bug: those brackets should not appear. I've filed {T120329} for this, so we can close this bug.
(This will be announced in Tech News the week after next, as there's no MediaWiki deployment next week.)
Filed as a separate issue {T119537}

- Have a title with a link in it
- scroll up - the link exposes html code: 
{F2993105}
Not sure if it's big enough to be in a separate issue: 

- Have a title with a link in it
- scroll up - the link exposes html code: 
{F2993105}
Checked in betalabs according to specs. Please check below
Talk:ET19 - the link in the title and in the Summary - [[Talk:ET1|ET1]] 
1)
> Topic heading -- this should be a working link
 
{F2992994}

2) The links to the topic ET1 are rendered as for the Recent changes - see below
> Contributions -
> For the post/reply/edit, the link should render as the title (no brackets), and should link to the Topic:UUID, not to the page.
> For editing the topic summary, the link should render as the title, not linked.

{F2993008}

3) 
>Recent changes --
>For the post/reply/edit, the link should render as the title (no brackets), and should link to the Topic:UUID, not to the page.
>For editing the topic summary, the link should render as the title, not linked.

{F2993045}

4)
>Watchlist --
> For the post/reply/edit, the link should render as the title (no brackets), and should link to the Topic:UUID, not to the page.
> For editing the topic summary, the link should render as the title, not linked.

{F2993084}

5)  Links are in the right place - checked.
>Board and Topic history --
> For both post/reply/edit and editing the topic summary, the link should render as the title, not linked.

{F2993093}
Change 243066 merged by jenkins-bot:
Add support for edit summary formatting in topic titles

[[https://gerrit.wikimedia.org/r/243066]]
See {T115910}.
Change 243066 had a related patch set uploaded (by Mattflaschen):
WIP: Add support for edit summary formatting in topic titles

[[https://gerrit.wikimedia.org/r/243066]]
>>! In T59153#1439920, @Mattflaschen wrote:
> We discussed the possibility of using the same subset the edit summary parser allows.

That would be the least. You've already broken many topic titles:
https://www.mediawiki.org/wiki/Talk:MediaWiki_Stakeholders%27_Group
We discussed the possibility of using the same subset the edit summary parser allows.
@DannyH https://trello.com/c/bj3IZSE5/190-limited-wikitext-formatting-in-topic-titles
> We shouldn't do wikitext in topic titles -- titles will be used in log pages like contributions, watchlist, etc.
Many wikis use titles with wikitext "==[[PageInTitle]]=="  and special log pages showing simply "PageInTitle" and links [[ SomePage#PageInTitle ]] work fine. Why this can not further work so?
Well it's very cool that at least one users and also users of languages who don't use formatting at all would survive. But as there are still lots of users who are not covered by that array I'd rather have wikimarkup allowed in there. We are not to force people to change their talk page editing style or even make them drop some features their language allows...
Mmmm... Page titles don't have wikitext formatting either and we survive. I never missed '''', [[]] or {{}} in page titles, although I wish I could write something <span lang="en" dir="ltr">(What's the Story?) Morning Glory</span> and <span lang="en" dir="ltr">C++</span> in a title of the respective Hebrew Wikipedia articles. But still, I survive (with {{DISPLAYTITLE}}).

MediaWiki section headings can have links, and people do use them, but I have no idea why, because it is ugly, unnecessary, and untappable on mobile. This could probably be fixed in MobileFrontend, but I'd just disallow them. Italics could be useful in section headings, for book titles and such, but I could live with that, too. (DYK: It's specific to English and some other languages written in the Latin alphabet. Some languages don't actually use italics. And guess what, they survive.)

And I could certainly survive without wiki syntax in Flow topic titles.
Previous comments are from 2013. This task should be higher priority now.
Links in headers are definitely needed in final product! Links are often used on "specialty pages" like image workshops or administrators noticeboards to quickly give a link to the file/user in question (which/whom the whole topic is about).
(In reply to comment #7)

Thanks for the clarifications. :-)
(In reply to comment #5)
> With wikitext, it's sort of all or nothing; it would be a huge pain to
> disallow all wikitext except, say, italics. Of course, if anybody out there
> thinks it's easy, patches welcome ;)

This bug tracker keeps bugs open if patches are welcome. We'll just adjust the importance/priority to lowest/enhancement, I suppose.

For what it's worth, we implement partial parsers in weird places. Consider edit summaries, which auto-link internal links, but don't auto-link external links and magic links and don't allow formatting such as bold or italics. Not that we really should continue this practice of creating new partial parsers... but it's certainly not unprecedented.

> Since this is just the MVP, I think it makes sense to keep things simple for
> now and just keep titles in plaintext.

The most valuable player? Sorry, I don't know what "MVP" means.

> If there's a demonstrable need to have wikitext in titles that outweighs all
> the cons, it's something we can easily change.

Having watched the train wreck that was VisualEditor's deployment, I can that it's often small 'features' like this that can potentially be a very big deal to a wiki and its workflows. If you look at a process such as [[WP:RFPP]], you can see a half-dozen links in many headers, each of which correspond to discrete units of work. I think attempting to de-wikify the topic title may result in a lot of annoyed users.
With wikitext, it's sort of all or nothing; it would be a huge pain to disallow all wikitext except, say, italics. Of course, if anybody out there thinks it's easy, patches welcome ;)

Since this is just the MVP, I think it makes sense to keep things simple for now and just keep titles in plaintext. If there's a demonstrable need to have wikitext in titles that outweighs all the cons, it's something we can easily change.
The WMF core features team tracks this bug on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/471, but people from the community are welcome to contribute here and in Gerrit.
(In reply to comment #1)
> Wikitext is purposefully Plain text only. 

s/Wikitext is/Topic-titles are/
Sorry.

(In reply to comment #2)
> (In reply to comment #1)
> > *Other?
> > ** Is there any other wikitext that topic titles might need?
> 
> Magic words, covered by a separate bug. External links. Bold. Probably a
> million other pieces of formatting.

Bold is never (?) needed in topic titles. Unless there are foreign language projects that require it?

External links will presumably follow whatever decision we arrive at with internal wikilinks.

I'll ask the team to give more details, and potentially reconsider certain aspects (particularly italics).
(In reply to comment #1)
> ** Links generally shouldn't be in headers, because the bolded text makes it
> harder for some people to see that the link is there.

When I look at [[WP:AN]] and [[WP:AN/I]], I see many headers that contain links. When I look at [[User talk:Quiddity]] ([[Special:Permalink/581983546]]), I see headers containing italics and links. What are you talking about?
 
> ** Plus it's generally counter to the (Enwiki) styleguides [[WP:LINKSTYLE]]
> and [[WP:Header]].

I'm not sure what you're talking about here. The style guidelines you're linking to obviously apply only to content, not to discussions. Flow is specifically focused on discussions (non-content). Your links seem completely irrelevant.

> *Other?
> ** Is there any other wikitext that topic titles might need?

Magic words, covered by a separate bug. External links. Bold. Probably a million other pieces of formatting.
Wikitext is purposefully Plain text only. IIRC, these are the reasons why:

*Links: 
** Links generally shouldn't be in headers, because the bolded text makes it harder for some people to see that the link is there.
** Plus it's generally counter to the (Enwiki) styleguides [[WP:LINKSTYLE]] and [[WP:Header]]. (Although, do any other projects make a standard practice of including links in section headers?)
** Also "editors who have their preferences set to edit sections by clicking on the header will not be able to click these links" - [[Help:Section#Section_linking]]   (Although this might not apply to Flow)
** Flow currently uses most of the topic-title as a clickable area to trigger the topic-collapse. This would conflict with wikilinks.

*Italics:
** I agree that this should be allowed. We need italics for proper formatting of things like media titles, court cases, etc, in Enwiki. ([[WP:ITALICS]])

*Other?
** Is there any other wikitext that topic titles might need?
This isn't a VE bug but ...
With google translate and chrome when you choose "always translate" and then hide the translate bar, the look and feel is really WP:en or WP:yourlanguage

When you choose to contribute with VisualEditor, everything is translated : text, button, message but the little "search" in the research box.

Then contributions in different language appear on WP:fr ex : https://fr.wikipedia.org/w/index.php?title=Acrosport&diff=prev&oldid=98352033

A little change in text saves the all translated bloc.

Maybe, the VE edit button should be block with a warning message or the text display for edition should block google translate (I don't know if it's possible) like textarea does.

--------------------------
**Version**: unspecified
**Severity**: normal
**Whiteboard**: aklapper-moreinfo
Change 200746 merged by jenkins-bot:
Add class="notranslate" to prevent Chrome from translating the CE DOM

[[https://gerrit.wikimedia.org/r/200746]]
Change 200746 had a related patch set uploaded (by Catrope):
Add class="notranslate" to prevent Chrome from translating the CE DOM

[[https://gerrit.wikimedia.org/r/200746]]
Roan's found a way to get Google Translate to be suppressed, which is awesome.
BTW, I send feedback to Google Translate, requesting they ignore contenteditable areas. Probably not gonna make a difference, but you never know.
I've nominated this task to Q3 blockers as it keeps damaging articles on frwiki, and I highly doubt that the snowmen are really added by google translate.

https://fr.wikipedia.org/w/index.php?title=Ben_Bocquelet&diff=113382413&oldid=113108176
https://fr.wikipedia.org/w/index.php?title=Jake_le_chien&diff=113382267&oldid=113253474
https://fr.wikipedia.org/w/index.php?title=Miss_Rainicorne&diff=prev&oldid=113234436
According to Drongou, this "google problem" would also explain that in the following edit, snowmen were added by VE to the text.
I doubt that google translate adds snowmen to its translation, and its a recurrent problem with VE.

https://fr.wikipedia.org/w/index.php?title=Touche_pas_%C3%A0_mon_pote&curid=5972689&diff=111575789&oldid=110714100
Unfortunately the only way to fix this is to add:

  <meta name="google" content="notranslate" />

to the <head> of every Wikipedia page, which is undesirable (not least because it would disable translate.google.com requests of the page, too). - See https://support.google.com/webmasters/answer/79812?hl=en

I think the duty lies with Google to fix Chrome to not translate contentEditable elements. There doesn't appear to be anything we can do at Wikimedia to fix this.

Marking as INVALID.
With Chrome

Go on a wiki with a language different of the language choosen in Chrome parameter

For example, if Chrome language is english go on WP:fr

For a registred account change the language in wiki preference to the language of the wiki (here français) because the button in english will block the chrome translate banner or do it on IP.

Go on a WP:fr page
The chrome translate banner appears; choose always translate and close the banner (not compulsory but better for the look and feel) 

Go on VE (modifier button)

Select the first word (just one word) of any paragraph. Do copy/paste. (copy the word on himself) Then save

Then you get a paragraph in english in a french article.

Because it's difficult to change a Chrome for french to a Chrome for english (Chrome doesn't want to forget he's in a french environment), I've done it on WP:en (in reverse, it will be difficult for you to do it on WP:en) https://en.wikipedia.org/w/index.php?title=User%3ADrongou%2FBug57124&diff=582266868&oldid=582266664
Hi Drongou, 
thanks for taking the time to report this!

Please describe the actual problem, the expected outcome, and the exact steps to reproduce so somebody else could follow these steps. Also see https://www.mediawiki.org/wiki/How_to_report_a_bug . Thanks in advance!
1. Edit an existing reference or insert a new one
2. When the dialog is closed, the reference is selected and a callout is displayed
3. 200ms later the selection moves to the start of the document

Somehow, for some reason, SurfaceObserver is "fixing" the selection here.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 58090 ***
Happens on Chromium 25 but not on Firefox 24 (on my Ubuntu system).

When the reference is inserted, the CE cursor gets reset to the start (as always happens with a ContentEditable when you change the content). But then the CE cursor updates the DM cursor, whereas it should happen the other way round.

Evidence: Make SurfaceObserver.pollOnceInternal into a no-op, then right-cursor to a word and click Reference, Insert Reference. Then the CE cursor gets reset to the start of the document, whereas the DM cursor is still in the place where the reference appears.
reference icon after the selected text

Steps to reproduce:

1.Click on the edit button for a blank page
2.Type a text on the first line
3.Now type another text on the second line
4.Add a template
5.Select the second text in a way that it also selects the template
6.Click on More>Reference 
7.Add a reference


[Note] This might not be the exact steps to reproduce , I am trying to figure out the correct steps.I will update the steps once I am sure.Still filing it to keep track.

Observed Result:
The reference note gets added in the middle of the template and the second line in a blank line.After that the editor gets unresponsive

Also sometimes the reference icon gets added at the beginning of the first line

See the screenshot attached.

Browser:Chrome 26
Environment:test 2
OS: MAC OS X 10.8.5

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

**Attached**: {F12555}
I cannot reproduce this bug anymore This got fixed couple of weeks ago.
Created attachment 13790
case where reference gets added at the beginning of the text

**Attached**: {F12557}
Confirming the steps to reproduce.
Also, attaching the screenshots where a reference gets added at the beginning of the text
Created attachment 13781
Reference icon being added at the beginning of the text

**Attached**: {F12556}
I thought it was Opera's fault,
but tested this again today and it's not related to the browser you're using.
It appears that when you edit as an unregistered user (on wikis which allow you to...) you'll always get an Edit conflict page when you try to save after you switched to wikitext.
Tested on multiple wikis on both ns0 and ns2.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56767
I think this is fixed now. If you notice any issues with it (easiest way to test right now is on beta) please reopen
Change 123795 merged by jenkins-bot:
Fix order of start and base timestamps when switching to the wikitext editor

https://gerrit.wikimedia.org/r/123795
Change 123795 had a related patch set uploaded by Alex Monk:
Fix order of start and base timestamps when switching to the wikitext editor

https://gerrit.wikimedia.org/r/123795
Some of my confusion on this bug was caused by some extra ways MediaWiki can resolve edit conflicts which I hadn't properly taken into account when testing. It looks like swapping those values fixes this bug. Assigning this to me and bumping the milestone forward.
So I think that:
* A conflict is always detected when having switched from VE
* Said conflict is suppressed when Revision::userWasLastToEdit is run for a logged in user, but if they're anonymous then it's not suppressed.
I suspect this might have something to do with this code in ve.init.mw.Target.js:

>'wpStarttime': this.baseTimeStamp,
>'wpEdittime': this.startTimeStamp,

Which seems a bit backwards to me...
Reported again on it.wp, I verified it on my sandbox there (http://it.wikipedia.org/wiki/Utente:Elitre_(WMF)/Sandbox_VE?veaction=edit); I got the warning, then tried to save anyway, I apparently managed to but nothing appears in the history.
Change 95730 merged by jenkins-bot:
Share code between conflict resolution and the edit source switch

https://gerrit.wikimedia.org/r/95730
Change 95730 had a related patch set uploaded by Catrope:
Share code between conflict resolution and the edit source switch

https://gerrit.wikimedia.org/r/95730
(I wonder if https://bugzilla.wikimedia.org/show_bug.cgi?id=56849 is related?)
Right now, CSSJanus flips toolbar icons by their definitions, so an icon indent-ltr would automatically turn to indent-rtl when user GUI is set to RTL.

However, the indent and list-related buttons don't depend on user GUI language but rather on the content language. If editing English content, the icon for "increase indent" should point from left to the right regardless of user GUI language, and the icon for "decrease indent" should point the other way.

For a quick demo, see:
https://www.mediawiki.org/wiki/User:Mooeypoo/IndentDemo?veaction=edit&setlang=he
(Wiki language is English/LTR and GUI is Hebrew/RTL)

--------------------------
**Version**: unspecified
**Severity**: normal
This is fixed with this patch https://gerrit.wikimedia.org/r/#/c/95560/
We would like to revert the fix for bug 39617.  That bug should have been fixed via the 'whitespace' CSS property.

The 'fix' to bug 39617 caused Parsoid to begin creating dirty diffs (and failing its test suite) -- see https://gerrit.wikimedia.org/r/92978

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=39617
This has since been fixed in core.
Change 94443 abandoned by Cscott:
Revert "Have list items occupy their own line".

Reason:
Abandoned in favor of Ib7aa9449bbd994cb23b83b3f23cff944b1cddadf

https://gerrit.wikimedia.org/r/94443
Change 134380 merged by jenkins-bot:
Update list item newline handling to follow Parsoid's model

https://gerrit.wikimedia.org/r/134380
(In reply to Bartosz Dziewoński from comment #26)
> (In reply to Gabriel Wicke from comment #25)
> > PHP + tidy inserts newlines in the first case too, which is broken.
> 
> I'm pretty sure that this is the case only if Tidy is enabled, and that kind
> of behavior is one of the many reasons why I want to kill it. (I really do
> not know why no one from the Parsoid team shares my sentiment about this.)

Believe me, we want to kill it just as much as you do. And we have been working hard on it for 2+ years now.
Change 134380 had a related patch set uploaded by GWicke:
Update list item newline handling to follow Parsoid's model

https://gerrit.wikimedia.org/r/134380
(In reply to Gabriel Wicke from comment #25)
> PHP + tidy inserts newlines in the first case too, which is broken.

I'm pretty sure that this is the case only if Tidy is enabled, and that kind of behavior is one of the many reasons why I want to kill it. (I really do not know why no one from the Parsoid team shares my sentiment about this.)
Parsoid does not insert newlines where there are none:

<ul><li>foo</li><li>bar</li></ul>

in wikitext becomes 

<ul><li>foo</li><li>bar</li></ul>

It does preserve newlines from wikitext though:

* foo 
* bar
* baz

in wikitext becomes

<ul><li> foo</li>
<li> bar</li>
<li> baz</li></ul>

PHP + tidy inserts newlines in the first case too, which is broken.
Sorry, but it isn't. The *old* PHP parser output is:

<ul><li>a
</li><li>b
</li><li>c
</li></ul>

No linebreak *between* list items. Parsoid goes (if I understand above correctly):

<ul><li>a</li>
<li>b</li>
<li>c</li></ul>

I want the PHP parser to behave the smae.
(In reply to Erwin Dokter from comment #22)
> Ah, so it is only the *tests* that are affected. I think I understand now.

Not just tests. See part (2) in Comment 16.

> Still my question remains: can I make the parser make a clean break *only*
> between </li> and <li> (as that is the core issue affecting nowrap), without
> any linebreak before or after <ul> and </ul>?

That is already the case since wikitext has newlines between list items. See below for Parsoid's output.

[subbu@earth tests] echo "*a\n*b\n*c" | node parse
<body data-parsoid='{"dsr":[0,9,0,0]}'><ul data-parsoid='{"dsr":[0,8,0,0]}'><li data-parsoid='{"dsr":[0,2,1,0]}'>a</li>
<li data-parsoid='{"dsr":[3,5,1,0]}'>b</li>
<li data-parsoid='{"dsr":[6,8,1,0]}'>c</li></ul>
</body>
Ah, so it is only the *tests* that are affected. I think I understand now.

Still my question remains: can I make the parser make a clean break *only* between </li> and <li> (as that is the core issue affecting nowrap), without any linebreak before or after <ul> and </ul>?
(In reply to Erwin Dokter from comment #20)
> OK, this discussion is not going to end in the next couple of hundred years,
> partly because I will never understand what is really going on. 

Do you want to pop onto IRC (#mediawiki-parsoid) sometime and chat with us about this? We can then post the summary here after that. It might be simpler to figure this out in a more interactive discussion than is possible via bugzilla comments. I am going to be signing off for the day shortly, but the IRC channel is usually active between 9 am PST - 4 pm PST when most of us are around.

> I still
> don't know where parsoid is getting its HTML from. Can't be from the browser
> DOM; that has gone through Tidy. 

No, Parsoid generates the HTML as I indicated in Comment 16. In the case of Visual Editor use, VE then sends that HTML (alongwith any user edits) to Parsoid to convert back to wikitext.

Since Parsoid HTML will replace PHP parser HTML at some point in the foreseeable future (this year possibly), if anything requires these newlines to be present for functionality, Parsoid will also have to add them and that is what we are complaining about so far.
OK, this discussion is not going to end in the next couple of hundred years, partly because I will never understand what is really going on. I still don't know where parsoid is getting its HTML from. Can't be from the browser DOM; that has gone through Tidy. 

Revert the patch.

I just want the parser (as long as it lasts) to emit some sanely formatted lists, just as it outputs sanely formatted tables. Is that too much to ask?

If I can make the parser to make a clean break *only* between </li> and <li>, without any linebreak before or after <ul> and </ul>, would that make parsoid happy?
(In reply to Erwin Dokter from comment #18)
> * block level elements (including list itema) must be terminated with e
> newline
> * all other (inline) elements should not
> 
> Would that ease the situation?

This would in fact complicate the situation. We don't insert newlines in HTML where there were none in the original wikitext. This preserves the semantics independent of the CSS whitespace styling (remember that 'pre' is a possible value) and helps us to round-trip wikitext correctly without introducing spurious newlines.

As discussed in bug 39617, the newlines don't seem to be necessary any more now that the nowrap requirement is gone. Taking into account the cost they have for Parsoid development, I'd recommend removing the code that inserts them from the PHP parser.
Re: "a\n\n*b"

I don't understand where the extra newline comes from, as the parser outputs only one. Regardless... perhaps we need to go about this another way.

There should be a simple set of rules that govern how parser and parsoid interact, for example:

* block level elements (including list itema) must be terminated with e newline
* all other (inline) elements should not

Would that ease the situation?
(In reply to Erwin Dokter from comment #15)

> I can't help but feel that this issue is a major blocker for any parser
> improvement in the future, so I want to understand exactly where the problem
> exists and come up with a solution that will prevent such issues in the
> future.

This is not a general blocker. Parser changes can be done and have been done, but changes have to be considered carefully since there are a lot of dependent users, and that is what you are seeing here in this bug report discussion.
Parsoid converts wikitext to HTML and back. Tidy does not enter the picture at all in the Parsoid pipeline.

There are two separate issues:

1. Parsoid uses the same set of PHP parser tests to make sure that Parsoid generates HTML that doesn't break existing wikitext. It uses PHP HTML to serialize back to wikitext. The extra newline that PHP parser emits introduces extra newlines in wikitext. "a\n\n*b" instead of "a\n*b". So, the extra newline is a "dirty diff". This now obscures our regular testing because we blacklist these failing tests and then try to compare changes in HTML output. So, not entirely unworkable, but requires greater diligence to monitor regressions during development. Ideally, we wouldn't have these failures. Alternatively, we have to fix Parsoid's HTML to wikitext conversion to ignore the extra newlines when they come from the parser's insertion rather than from source -- that means extra bookkeeping.

2. If you want Parsoid HTML to have the same CSS semantics like PHP HTML, Parsoid would also have to start adding these newlines after <ul> and before </ul>. These extra newline characters would now have to be accounted for in the DSR calculations (DSR maps a range to wikitext source to a DOM subtree, ex: wikitext substring [3,9] generate <p>foobar</p> HTML) which is also additional bookkeeping. DSR calculations has been carefully tweaked to account for every single character of wikitext so that Parsoid can faithfully output original wikitext on unedited portions of the HTML. So, Parsoid would have to ignore the extra inserted newlines in its calculations. Without accounting for them, Parsoid will generate different wikitext on conversion which manifests as "dirty diffs". Again, all of this extra bookkeeping can be done.

But, if we can avoid the extra newlines, the extra work can be avoided.
I also have a problem understanding 'dirty diffs'. Where does parsoid get its HTML from? I thought it converted wikitext to HTML and then back. So how does the parser even come into play? Is Tidy also involved? Sorry to ask al this, but I simply need a basic understanding of parsoid.

FYI, the nowrap has been completely removed from hlist, so there are no CSS hacks to deal with. But any locally applied nowrap may cause errors, so the linebreaks must remain.

I can't help but feel that this issue is a major blocker for any parser improvement in the future, so I want to understand exactly where the problem exists and come up with a solution that will prevent such issues in the future.
That is a scoping problem; Tidy should simply not touch anything that comes out of GeSHi (pre & code). This is simply two external extentions clashing.
Just to guide the discussion, let's try to keep this bug concentrated on the parsertest regressions in Parsoid and other extensions, and possible fixes for that.  Discussion of the hlist issue and the CSS fix (or lack thereof) goes over on bug 39617.

Since most of the discussion has already happened on bug 39617, I'd say that, if in doubt, let's continue the discussion there.  I'm just trying to prevent the discussion from being scattered across gerrit and a bunch of different bugzilla items, and people's good points being lost in the shuffle. (In particular, I'm going to copy comment 10 over to bug 39617.)
(In reply to comment #11)
> (In reply to bug 39617 comment #27)
> > The Tidy bug is what caused hlists to work in the first place, according to
> > what you're saying :)
> 
> Why is that even considered a bug? list items are block level elements, and
> as such, should be on their own line per unwritten code style conventions.

Tidy's overzealous newline insertion has caused problems in the past already, see bug 260 (which is still open only because of the same Tidy issue) and bug 38800 (which is basically what Gabriel reported).
(In reply to comment bug:39617#27)
> The Tidy bug is what caused hlists to work in the first place, according to
> what you're saying :)

Why is that even considered a bug? list items are block level elements, and as such, should be on their own line per unwritten code style conventions.
https://test.wikipedia.org/wiki/MediaWiki:Common.css contain current CSS for hlist.
https://test.wikipedia.org/wiki/User:Edokter/sandbox contains the test cases.

Any suggested changes will break one or more testcases.
(In reply to comment #8)
> Unless you come up with a working CSS solution (which I doubt you will), I
> insist my patch be reinstated and Parsoid be fixed instead.

(Just a note that the patch was not reverted, but a revert has been submitted for review / consideration.)

Is there a demo of hlist set up somewhere? Or a list of things it does, and a list of cases it supports? Any of these things would be very useful here.
Oh for crying...! Please provide a COMPLETE working set of CSS for horizontal lists that supposedly fixes all the bugs I have spent TWO YEARS trying to fix! I have tested EVERY scenario, including inline-block, which breaks nested lists in *ALL* browsers.

Unless you come up with a working CSS solution (which I doubt you will), I insist my patch be reinstated and Parsoid be fixed instead.
(In reply to comment #5)
> I've already seen the patch and sadly it is not telling me anything. What
> does
> a "dirty diff" mean here? A dirty diff during after editing a page with
> VisualEditor? Because that's the only significant definition I know.

Parsoid is failing the parser tests in html2wt and html2html mode since the same parser tests are used by core and Parsoid. I blacklisted the failures for now. But this blacklisting is not ideal since we have to be a bit more careful about failures in the future when inspecting changes.

That aside, if VE and Parsoid emits the same HTML that the core parser does for lists (emitting newlines around <ul> tags), then we have to deal with it.
Also, see https://gerrit.wikimedia.org/r/#/c/93626/ where I started messing with Parsoid to prevent these dirty diffs, but it seems a lot more pain than worth it currently -- it is mostly a distraction from other critical issues that I just left it in WIP stage. This wont be an issue in production necessarily right now, but if the CSS fix is not employed, then Parsoid will also have to emit the same kind of HTML that the core php parser emits and then this could be an issue in production with occasional dirty diffs without this WIP patch being worked out to completion. So, seems like a lot of pain for unclear benefit.
I've already seen the patch and sadly it is not telling me anything. What does a "dirty diff" mean here? A dirty diff during after editing a page with VisualEditor? Because that's the only significant definition I know.
Matma(In reply to comment #3)
> Why does this cause dirty diffs? Can I get a link to such diff?

See the gerrit patch cscott linked to in the bug description (https://bugzilla.wikimedia.org/show_bug.cgi?id=56809#c0)
Why does this cause dirty diffs? Can I get a link to such diff?
https://bugzilla.wikimedia.org/show_bug.cgi?id=39617#c18 demonstrates a css fix. Related comment is https://bugzilla.wikimedia.org/show_bug.cgi?id=39617#c17
Change 94443 had a related patch set uploaded by Cscott:
Revert "Have list items occupy their own line"

https://gerrit.wikimedia.org/r/94443
Misplaced

Steps to reproduce

1. Click on the Edit button for an article or click on the media icon on a image
2. Type something
3. Go to some other window of your browser
4.Come back to the editor after few minutes (approx. 5-10 minutes)
5.Now select the text and click on the link icon 

Observed Result:
The link inspector appears broken or misplaced 



Browser:Chrome
Environment:test2
Page:Any
Reproducible: Mostly  

See the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F12157}
This appears to now be fixed FWICS; closing as such.
Other inspectors (e.g. MWExtensionInspector) are affected as well.
Created attachment 14014
reproduced on 6th december

**Attached**: {F12162}
Reproduced it again on Betalabs:
http://en.wikipedia.beta.wmflabs.org/w/index.php?title=6th_december&veaction=edit

See the screenshot attached
This issue is fixed now and verified on betalabs
should this have blocked deployment?
Yes, the issue reported here is now appearing in production/Live environment for any page.

(In reply to comment #5)
> (In reply to comment #4)
> > Now it is live.
> 
> ????  You mean the problem in this bug report is deployed to production
> servers
> now, or how to interpret that comment?
(In reply to comment #4)
> Now it is live.

????  You mean the problem in this bug report is deployed to production servers now, or how to interpret that comment?
Now it is live.
Created attachment 13742
Broken UI 2

**Attached**: {F12161}
Created attachment 13741
Broken UI

**Attached**: {F12160}
Created attachment 13740
Broken

**Attached**: {F12159}
Currently, if I go to https://www.mediawiki.org/wiki/User:Amire80/ve-poem and edit it using VE, I can edit the content of the <poem> tag. If my UI language is Hebrew, then the <textarea> for editing the poem is RTL. I would expect it to be LTR.

Ideally the default direction for the <textarea> that this feature should be the direction of the surrounding text. If it's hard to get, then the direction of the page's content will probably suffice. (Currently it will be the same as the content language of the wiki, but it may change some day when we finally introduce page language.)

There can also be some tags for which the default direction must be different, such as <source>, but that's an issue for a separate bug.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 94375 merged by jenkins-bot:
MWExtensionInspector input direction based on content

https://gerrit.wikimedia.org/r/94375
Change 94375 had a related patch set uploaded by Mooeypoo:
MWExtensionInspector input direction based on content

https://gerrit.wikimedia.org/r/94375
Related: Bug 56780.
From IRC:

<mooeypoo>	what do you mean "must correspond to surrounding content direction?
<mooeypoo>	of the <poem> ?
<mooeypoo>	so, it should be content direction rather than GUI direction?
<aharoni>	mooeypoo: It definitely shouldn't be the GUI direction. It has nothing to do with it.
<mooeypoo>	nods
<aharoni>	The direction of the inspector's GUI should be the GUI direction,
<aharoni>	but the textarea needs the direction of the content.
<mooeypoo>	yeah
<mooeypoo>	makes sense, just wanted to make sure
<aharoni>	Ideally, if the wiki is in English, but it's a <poem> tag inside <div lang="fa" dir="rtl">, then the textarea should be rtl.
There are 2 users at least (Fram and myself)
reporting that the new option does not seem to work when using FF (in our case, version 25).
I tried to VEdit my sandboxes in several languages.
You can use https://it.wikipedia.org/wiki/Utente:Elitre/Sandbox?veaction=edit if you need to.
After you click on the Switch button, and click OK on the warning message, the surfaces is "grayed out", and just stays that way without actually switching.
Please notice you can still VEdit at this time, and even save.
The chosen skin instead does not seem to matter (it didn't work for me with any of them).

In Fram's words:
<< I get the "you are about to change" message, but then the VE page gets "bleached" out, as if an opaque glass is put in front of it, and nothing further happens. I can still use the toolbox at this time, and can edit the article in VE, but it doesn't have the normal look.>>

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56835
Change 94595 abandoned by Jforrester:
Fix edit source switch in Firefox

Reason:
Not done.

https://gerrit.wikimedia.org/r/94595
Change 94594 abandoned by Jforrester:
Fix edit source switch in Firefox

Reason:
Not done.

https://gerrit.wikimedia.org/r/94594
Change 94595 had a related patch set uploaded by Jforrester:
Fix edit source switch in Firefox

https://gerrit.wikimedia.org/r/94595
Change 94594 had a related patch set uploaded by Jforrester:
Fix edit source switch in Firefox

https://gerrit.wikimedia.org/r/94594
Change 94498 merged by jenkins-bot:
Fix edit source switch in Firefox

https://gerrit.wikimedia.org/r/94498
Change 94498 had a related patch set uploaded by Esanders:
Fix edit source switch in Firefox

https://gerrit.wikimedia.org/r/94498
(Your wish is my command.
See 56835 now, turns out it had nothing to do with Opera after all.)
Dropping the Opera issue, as that appears unrelated. Open as a different bug?
FYI, I tried to VEdit a few sandboxes while unlogged with Opera.
After switching to wikitext, when I try to save changes I always get an "edit conflict" notice. It will save if I re-add my text, but clearly this is not optimal :)
beta commons localStorage nearly full

seen on beta labs while logged in as Selenium_user
seen in Chrome/Chromium, not checked in Firefox (yet)

consistent behavior seen:  
initial load of VisualEditor in beta enwiki sets localStorage to 3.5MB
initial load of UploadWizard in beta commons sets localStorage to 2.5MB

routine navigation to pages like 
* wikitext editor
* Flow e.g. http://en.wikipedia.beta.wmflabs.org/wiki/Talk:Flow_QA
* Special:NewPagesFeed
* etc

continues to fill localStorage until it maxes out.

inconsistent behavior: 

I do not have a consistent repro to max out localStorage.  at first I thought that repeatedly hitting shift-reload/cancel on a ?veaction=edit page did it, but on my second attempt I was unable to max out localStorage that way

--------------------------
**Version**: 1.23.0
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56778

**Attached**: {F12036}
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > My suspicion is that the mtimes of modules is being continuously changed
> > > because of the way [beta] is set up.
> > 
> > Doesn't appear to be the case. I hacked up a quick script to check:
> > <https://gist.github.com/atdt/7359920>. No changes were merged to master
> > while
> > I tested, though; still interested to know what happens then.
> 
> And BTW, if you do find config differences between beta enwiki and prod,
> please
> let me know.  I have other intermittent/unreproduceable performance problems
> with Chrome (not Firefox) there that are becoming quite frustrating, seen in
> particular in VE and UploadWizard.  I worry that these problems exist in
> production but are so flaky that they are not reported.

modules are updating pretty frequently on beta. 20 mins' worth here: <https://gist.github.com/atdt/7359920#file-rl-mon-log>. I'm running it again now *with* timestamps.
(In reply to comment #8)
> (In reply to comment #7)
> > My suspicion is that the mtimes of modules is being continuously changed
> > because of the way [beta] is set up.
> 
> Doesn't appear to be the case. I hacked up a quick script to check:
> <https://gist.github.com/atdt/7359920>. No changes were merged to master
> while
> I tested, though; still interested to know what happens then.

And BTW, if you do find config differences between beta enwiki and prod, please let me know.  I have other intermittent/unreproduceable performance problems with Chrome (not Firefox) there that are becoming quite frustrating, seen in particular in VE and UploadWizard.  I worry that these problems exist in production but are so flaky that they are not reported.
(In reply to comment #7)
> My suspicion is that the mtimes of modules is being continuously changed
> because of the way [beta] is set up.

Doesn't appear to be the case. I hacked up a quick script to check: <https://gist.github.com/atdt/7359920>. No changes were merged to master while I tested, though; still interested to know what happens then.
Several points:
- Can you isolate the size of the module storage? You can check it by running mw.loader.inspect('store') in a JavaScript console. (See 'totalSize' column).
- Pruning old modules from the cache is deferred until the page / DOM is quiescent. What happens if you just let the page load and hang out for 5-10 seconds?
- Is this reproducible outside the beta cluster? My suspicion is that the mtimes of modules is being continuously changed because of the way it is set up. Haven't investigated yet, but the way to check would be to load the startup module and compare module versions across reloads.
Well, the limit can be worked around… 

"Introducing the HTML5 Hard Disk Filler™ API" http://feross.org/fill-disk/

:P
So apparently the only way to find the limit is to keep adding data until you fill it up. Awesome.

http://dev-test.nemikor.com/web-storage/support-test/

^ looks like a frequent limit is 5MB, which in some browsers means 2.5M *UTF-16 code points*. That's going to be pretty tight for the amount of code we want to store. :(
(In reply to comment #3)
> Can we determine the limits of available localStorage in some consistent way?

I believe it is per-browser.  Empirically I found that my Chromium allows 5MB while my Chrome allows 10MB. 

See http://arty.name/localstorage.html (warning: fills up your local storage upon loading the page and gives you a status message when done)
Can we determine the limits of available localStorage in some consistent way?
Comment on attachment 13721
beta commons localStorage nearly full

I meant beta enwiki for this attachment
Created attachment 13722
beta commons localStorage after loading UploadWizard

**Attached**: {F12037}
For some reason, the 'keydown' event is being unbound when the suggestions popup appears, so the function is never firing. However, it seems like they shouldn't be listening to keydown anyway because they only care about when the enter key is pressed and that event is already available on the input as the 'enter' event (from OO.ui.TextInputWidget).

With love from the Wikia development team.

--------------------------
**Version**: unspecified
**Severity**: minor
(In reply to Krinkle from comment #4)
> There is still a tech debt here though, we should use OOjs UI's "enter" event 
> (instead of manually binding keypress

Done in Ia47bc8976f22dfe7e3a6fb6068dc4b6e03a3357b.
Nevermind. They all work fine now. There is still a tech debt here though, we should use OOjs UI's "enter" event (instead of manually binding keypress and looking for keyCode=13), but it works fine.
The handler from MWCategoryWidget is working fine. However, here is the code I used for comment #2

In ve/ui/MWCategoryWidget.js:

	this.input.$input.on( 'keypress', function () {
		console.log( ['MWCategoryWidget', 'MWCategoryInputWidget', '$input', 'keypress'] );
	} );
	this.input.on( 'enter', function () {
		console.log( ['MWCategoryWidget', 'MWCategoryInputWidget', 'enter'] );
	} );

And the 'enter' event never fired. Because there is still a mystery here. The event bound by OO.ui.TextInputWidget on $input for 'keypress' (which fires 'enter') disappears somehow.

Putting the same logger in there makes it never fire.
Created attachment 16743
Screenshot of bug not happening.

I can't reproduce this. When typing in the input, I see all keydowns happening as they should. From the key codes in the screenshot:
* [shift]
* E
* x
* a
* m
* p
* l
* e
* [enter]

**Attached**: {F12000}
<Krenair> Krinkle, http://imgur.com/a39IuMk - that's handlers, handlers.length, handleObj
<Krenair> Immediately after handlers.push( handleObj ); in jquery.event.add

handlers.push( handleObj );
if ( types.indexOf( 'keydown' ) !== -1 ) {
	console.log( handlers );
	console.log( handlers.length );
	console.log( handleObj );
}
this may be more appropriate to assign to VisualEditor than Flow:

in a fresh instance of the Chrome browser, log in and go to page http://en.wikipedia.beta.wmflabs.org/wiki/Talk:Flow_QA 

* click Start a new topic
* watch the spinner as VisualEditor loads up
* when the spinner stops and the editor controls are visible, attempt to type in the ContentEditable surface

* only some seconds after the spinner stops and the controls appear is it possible to place the cursor in the CE surface and begin typing.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #3)
> (In reply to comment #2)
> > Flow no longer supports VE
> 
> Eep!

Clarification; the model as deployed on production intentionally does not support VE until we have some breathing room for it ;p
(In reply to comment #2)
> Flow no longer supports VE

Eep!
Flow no longer supports VE
The WMF core features team tracks this bug on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/409, but people from the community are welcome to contribute here and in Gerrit.
Link inspector and Math inspector together

Steps to reproduce:

1.Click on the Edit beta
2.Add a media such as image
3.Now open the Math inspector from More>Latex

Observed Result:
The Math inspector does not open,Now if you click on link both the inspectors open together.

See the screenshot attached.

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

**Attached**: {F12805}
Verified the fix on production
Verified the fix on test2
Verified the fix on Betalabs
Fixed in gerrit 125933.
Created attachment 15126
Errors and blank inspector

**Attached**: {F12806}
It also throws the following errors and the math inspector gets completely blank.:
Uncaught TypeError: Cannot call method 'getAttribute' of null VM977:417
Uncaught TypeError: Cannot call method 'getOuterRange' of null
Both issues caused by the math inspector not checking that what it's inspecting is really a math node, changing summary.
(In reply to comment #1)
> I couldn't reproduce the double inspector offhand.
I can now:
1. Insert an image
2. Unselect and reselect the image so just the image is selected
3. Open the math inspector. It attempts to inspect the image and crashes
4. Post-crash, you get the double inspector thing
At least one issue here is that MWExtensionInspector and MWMathInspector don't check that this.focusedNode is actually of the right type before doing things, so the math inspector will happily inspect references etc.

I couldn't reproduce the double inspector offhand.
Currently OOjs is mastered in github(!) and OOjs-UI within VisualEditor; instead, they should be in their own repos so that other projects can re-use them.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This is now done.
Change 94264 merged by jenkins-bot:
Move files from modules/oojs-ui to the repository root

https://gerrit.wikimedia.org/r/94264
Change 94264 had a related patch set uploaded by Jforrester:
Move files from modules/oojs-ui to the repository root

https://gerrit.wikimedia.org/r/94264
If a template is made translatable, {{template}} no longer works as expected. While this is hard to fix, Translate extension should provide out of the box the functionality of https://www.mediawiki.org/wiki/Template:Translatable_template.
Of course I should have checked whether such tasks exists before doing changes...
I am going to repuspose this task. This might change when support for VisualEditor is added. In the mean time the recommended way is to use templates such as https://www.mediawiki.org/wiki/Template:Translatable_template

Translate extension should provide such facility out of the box, or at least make it easier than copying that template (which requires Lua).
This has never been supported. Bug 48891 might change that, but I'm desperately needing help from people being able to hack the parser.
I meant

2. Transclude page A in Page B. Sorry.
This is related to bug #48924 and came up while working on VE's new media dialog.

Symptoms :
1. Parsoid seems to ignore adding an alt attribute to an image that had no alt attribute previously -- the image still has no alt attribute post-save, even though the DM/CE in VisualEditor were both updated properly.

2. When the alt string in 'alt=something' is changed, the resulting wikitext post-save is produced without the 'alt='

So, an original wikitext:

[[File:Someimage.png|thumb|265x265px|some caption|right|alt=some alternate text]]

After editing the alt property in VE, the wikitext post-save becomes:

[[File:Someimage.png|thumb|265x265px|some caption|right|some alternate edited text]]

--------------------------
**Version**: unspecified
**Severity**: normal
Change 103082 merged by jenkins-bot:
Edited image attributes should override data-parsoid value.

https://gerrit.wikimedia.org/r/103082
Change 103082 had a related patch set uploaded by Cscott:
Edited image attributes should override data-parsoid value.

https://gerrit.wikimedia.org/r/103082
Document:

 h2> Foo
 p> Lorem ipsum.
 h2> Bar
 p> Bla bla bla.

Steps:

* Put cursor in the first heading between "F" and "oo".
* Change text style to paragraph (via menu or or use ctrl-0).
* Observe cursor going wild (disappears in Firefox, appears outside the document in the margin in Chrome, bug 50442)
* Type 3 characters ("a", "b", "c")

Firefox result:

3 new paragraph appear.

 p> o [new]
 p> o [new]
 p> a [new]
 p> Foo
 p> Lorem ipsum.

And more on every subsequent keystroke. It seems to have copied this "o" from "Foo" somehow. And "b" and "c" never appear.

--------------------------
**Version**: unspecified
**Severity**: major
I believe that this was fixed by Ed's Firefox CE re-write.
*** Bug 56338 has been marked as a duplicate of this bug. ***
Screenshot of problem.

1. Put cursor in a heading.
2. Change text style to paragraph (or use ctrl-0).
3. Observe the cursor is now outside the content area in the document margin.

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F12115}
*** This bug has been marked as a duplicate of bug 56340 ***
The text style menu has major issues. For all intends and purposes I declare it completely broken. Tracking them here in case they're related.

--------------------------
**Version**: unspecified
**Severity**: normal
Not needed for one bug.
page after typing one character

seen in Firefox not Chrome in master as of Oct 28

Edit any page on http://en.wikipedia.beta.wmflabs.org

When VE manifests, type any character

Existing text of page jumps down one line, as if VE has inserted a RETURN command upon typing in the page. 

Seen only in Firefox, not Chrome.

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

**Attached**: {F12001}
Unsetting "VERIFIED"; we don't generally use that, and setting it will hide it from people's saved searches.
Verified for on https://test2.wikipedia.org/ with FireFox 25 on MAC OS X 10.8.5
Example test page:https://test2.wikipedia.org/wiki/Verify_56274
Verified in for any page on http://en.wikipedia.beta.wmflabs.org
Looks like this issue got fixed.Verified in betalabs with FF 25.
Reproduced this bug FireFox.Also observed that , in FireFox upon clicking on the Edit-beta the value of the heading pull down menu is blank instead of the format the existing text have as soon as a character is entered and the existing line goes to the next line, the "Paragraph" value appears in the heading drop down.

However, the case is different for chrome , the value of the heading drop down for the existing line appears as soon as user clicks on Edit-beta and this bug does not occur there.
note that this action also seems to incorporate a BACKSPACE action as well, since the cursor ends on the same vertical axis as it begins
**Author:** `Wikifram`

**Description:**
This test edit[https://www.mediawiki.org/w/index.php?title=User%3AFram%2FSandbox&diff=809490&oldid=795427]: all I did was add [[Test]] at the end of the sentence (to check basic nowiki functionality in the new release 23). However, VE started moving the nowikis around, and now the ref, which was in the old diff a nice "1", is now a strange string, "UNIQ74171d8572aa65a1-nowiki-00000018-QINU1UNIQ74171d8572aa65a1-nowiki-00000019-QINU". This will probably be a rare occurrence, so not urgent in that regard, but it may be indicative of other problems.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 96238 merged by jenkins-bot:
Prevent link-annotating MWReferences

https://gerrit.wikimedia.org/r/96238
Change 96238 had a related patch set uploaded by Esanders:
Prevent link-annotating MWReferences

https://gerrit.wikimedia.org/r/96238
Otherwise, output is ill-defined (UNIQ bug) and not good for users.

(Thought there was an existing bug, but couldn't find it.)
*** Bug 56751 has been marked as a duplicate of this bug. ***
**Wikifram** wrote:

Note that when you open the page in VE mode, it again displays the ref correctly. Strange... 

Note also that a much simpler version, a link with a ref in the link, has the same behaviour, so the "nowikis" are probably only a distraction and this may more serious than I first thought...[https://www.mediawiki.org/w/index.php?title=User%3AFram%2FSandbox&diff=809494&oldid=809493]
As far as I can tell these were solved when we switched up/down behaviour with regard to browser-native selections. There are some issues in this area, but this ticket doesn't capture them.
1) I can reproduce the odd two-step up-arrow selection bug in Firefox, but not in Chrome. I couldnt quickly see that bug raised.

2) Likewise the down-arrow selection problem is also Firefox only, and appears to be bug 51957

3) The arrow-page-scroll-down bug is also Firefox only. I couldnt find a bug for it, but it is similar to bug 53420
Perceived performance could be substantially improved by having VisualEditor optimistically request serialization of the DOM as soon as the user hits "Save page". If the user ends up canceling the save, the serialized DOM would be discarded.

Users that take a few seconds to write the edit summary before confirming the save would experience near-instant saves this way.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55979
Change 93934 merged by jenkins-bot:
Use serialization cache in MW integration

https://gerrit.wikimedia.org/r/93934
Change 93109 merged by jenkins-bot:
Implement serialization cache in VisualEditor API

https://gerrit.wikimedia.org/r/93109
Change 93934 had a related patch set uploaded by Catrope:
[WIP] Use serialization cache in MW integration

https://gerrit.wikimedia.org/r/93934
Change 93109 had a related patch set uploaded by Catrope:
Implement serialization cache in VisualEditor API

https://gerrit.wikimedia.org/r/93109
Previewing a page and then saving it without further modifications should result in one serialization request being made to Parsoid, not two. The serialized DOM generated in course of responding to the preview request should be re-used when saving whenever VisualEditor can determine that no modifications intervene these two operations.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56011
Change 93934 merged by jenkins-bot:
Use serialization cache in MW integration

https://gerrit.wikimedia.org/r/93934
Change 93109 merged by jenkins-bot:
Implement serialization cache in VisualEditor API

https://gerrit.wikimedia.org/r/93109
Change 93934 had a related patch set uploaded by Catrope:
[WIP] Use serialization cache in MW integration

https://gerrit.wikimedia.org/r/93934
Change 93109 had a related patch set uploaded by Catrope:
Implement serialization cache in VisualEditor API

https://gerrit.wikimedia.org/r/93109
An empty edit notice is now appearing on any page.

Tested on Firefox and Safari

https://en.wikipedia.org/wiki/LibreOffice?veaction=edit
https://en.wikipedia.org/wiki/Maxi_single?veaction=edit
https://en.wikipedia.org/wiki/Northeim?veaction=edit

--------------------------
**Version**: unspecified
**Severity**: minor
Only a problem for sysops – a regression in bug 43013's fix.

*** This bug has been marked as a duplicate of bug 43013 ***
On pages that do have a notice displayed (e.g. those that are semi-protected) the empty page notice is noted as a second message, but one that it is impossible to view. 

Firefox 24.0/Monobook/Linux observed at [[Tycho Brahe]]
Also confirmed on Chrome.
Intention:  Add a parameter to a template.


Expectation:  That the cursor would automatically be present in the "Add parameter" text field (where it says "Parameter name"), so we could just start typing without having to reach for the mouse.


Steps to reproduce and results:

1)  Add or open any template.

2)  Start typing the name of a parameter.

3)  Discover that you are no longer able to just start typing the name, but must first reach for the mouse or trackpad, and then click to put the cursor inside the only possible place where you might be typing on that screen.


This was reported as a new and undesirable behavior with MediaWiki version 1.22wmf21, by a user who normally uses Firefox 24, Windows 8 and Vector skin and confirmed in Safari 6 on a Mac.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Works for me!  Thanks.
Change 148233 merged by jenkins-bot:
Auto-open "Add parameter" part of template dialog when tabbed to or opening with no required/suggested params

https://gerrit.wikimedia.org/r/148233
Should be done now. WhatamIdoing, feel free to reopen this if you disagree
Change 148233 had a related patch set uploaded by Alex Monk:
Auto-open "Add parameter" part of template dialog when tabbed to or opening with no required/suggested params

https://gerrit.wikimedia.org/r/148233
Changing this bug slightly to fit the current situation with tab indexes.
This bug came about from a misspelled parameter in a template on hewiki. The template returned a completely empty result when the required parameter was invalid, and there was no place to hover above the template and access the transclusion icon to change or remove it.

To replicate:
* Go to 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
* Click on transclusion, and add the template "ערך מורחב"
* Add parameter with the name "1"
* Add value to the parameter (invalid value) - "[[blah]]"
* Apply and click anywhere else on the document to clear the selection - the template vanished. However, it was added to the wikitext and is in the page after save, but there's no way to access it from VisualEditor and remove it (or edit it)

I have an idea on how to solve that, but I am not sure if the issue isn't deeper.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 90210 merged by jenkins-bot:
Add a placeholder into an empty transclusion

https://gerrit.wikimedia.org/r/90210
Change 90210 had a related patch set uploaded by Catrope:
Adding a placeholder into an empty transclusion

https://gerrit.wikimedia.org/r/90210
If you have a right-floating image, select it by clicking on it, then make the window wider on the right-hand size, the image moves to the right but the highlight doesn't. Same goes for resize handles etc.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55787
At least the first part of this is done.
Change 134363 merged by jenkins-bot:
[BREAKING CHANGE] Merge ProtectedNode into FocusableNode

https://gerrit.wikimedia.org/r/134363
Change 134363 had a related patch set uploaded by Esanders:
[BREAKING CHANGE] Merge protected node into focusable node

https://gerrit.wikimedia.org/r/134363
The video capture for bug 62632 shows this effect:
 http://cl.ly/0g2F0q2D3p1D
*** Bug 60701 has been marked as a duplicate of this bug. ***
Uncaught TypeError: Object #<VeInitMwViewPageTarget> has no method 'clearMessage'

Appears to be thrown by line 792 of modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.js: 'this.clearMessage( 'captcha' );'.

Seen on MediaWiki.org after trying to solve a Captcha, in the process of saving an edit to <https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Quarterly_review%2C_October_2013>.

--------------------------
**Version**: unspecified
**Severity**: normal
Now cherry-picked to live.
Change 89794 merged by jenkins-bot:
'clearMessage' is a method of MWSaveDialog, not ViewPageTarget

https://gerrit.wikimedia.org/r/89794
Change 89794 had a related patch set uploaded by Catrope:
'clearMessage' is a method of MWSaveDialog, not ViewPageTarget

https://gerrit.wikimedia.org/r/89794
Change 89773 merged by jenkins-bot:
'clearMessage' is a method of MWSaveDialog, not ViewPageTarget

https://gerrit.wikimedia.org/r/89773
Change 89773 had a related patch set uploaded by Krinkle:
'clearMessage' is a method of MWSaveDialog, not ViewPageTarget

https://gerrit.wikimedia.org/r/89773
Cause an exception from something with call_user_func in its stack.

For example, if you use wfUseMW( '2000.0' ); inside VisualEditor::onSetup (wgExtensionFunctions), you get:



Notice: Undefined index: file in /includes/Exception.php on line 725
Notice: Undefined index: line in /includes/Exception.php on line 725
Notice: Undefined index: file in /includes/Exception.php on line 725
Notice: Undefined index: line in /includes/Exception.php on line 725

MediaWiki 2000.0 required--this is only 1.22alpha

Backtrace:

#0 /extensions/VisualEditor/VisualEditor.hooks.php(23): wfUseMW('1.229wmf11')
#1 (): VisualEditorHooks::onSetup()
#2 /includes/Setup.php(592): call_user_func('VisualEditorHooks::onSetup')
#3 /includes/WebStart.php(153): require_once('/includes/Setup.php')
#4 /index.php(46): require('/includes/WebStart.php')
#5 {main}

--------------------------
**Version**: 1.22.0
**Severity**: normal
Change 90067 abandoned by Dereckson:
Fixes stacktrace output when an internal function is called.

Reason:
As the information isn't pertinent to the exception position.

https://gerrit.wikimedia.org/r/90067
*** Bug 55479 has been marked as a duplicate of this bug. ***
Change 90067 had a related patch set uploaded by Dereckson:
Fixes stacktrace output when an internal function is called.

https://gerrit.wikimedia.org/r/90067
*** Bug 55479 has been marked as a duplicate of this bug. ***
Change 89243 merged by jenkins-bot:
exception: Account for $call['file'] and $call['line'] being unset

https://gerrit.wikimedia.org/r/89243
(In reply to comment #0)
> Notice: Undefined index: file in /includes/Exception.php on line 725
> Notice: Undefined index: line in /includes/Exception.php on line 725
> Notice: Undefined index: file in /includes/Exception.php on line 725
> Notice: Undefined index: line in /includes/Exception.php on line 725
> 
> MediaWiki 2000.0 required--this is only 1.22alpha
> 
> Backtrace:
> 
> #0 /extensions/VisualEditor/VisualEditor.hooks.php(23): wfUseMW('1.229wmf11')
> #1 (): VisualEditorHooks::onSetup()
> #2 /includes/Setup.php(592): call_user_func('VisualEditorHooks::onSetup')
> #3 /includes/WebStart.php(153): require_once('/includes/Setup.php')
> #4 /index.php(46): require('/includes/WebStart.php')
> #5 {main}


New output after the patch:

#0 /extensions/VisualEditor/VisualEditor.hooks.php(23): wfUseMW('1.229wmf11')
#1 {internal}: VisualEditorHooks::onSetup()
#2 /includes/Setup.php(592): call_user_func('VisualEditorHooks::onSetup')
#3 /includes/WebStart.php(153): require_once('/includes/Setup.php')
#4 /index.php(46): require('/includes/WebStart.php')
#5 {main}
Change 89243 had a related patch set uploaded by Krinkle:
exception: Account for $call['file'] and $call['line'] being unset

https://gerrit.wikimedia.org/r/89243
Upstream bug:

https://bugs.php.net/bug.php?id=64987
Problems:
* The dm.Surface constructor initializes the selection at (1,1) because (0,0) is not a selection we can render in most documents
* ui.Surface.initialize has the following code:
// By re-asserting the current selection and forcing a poll we force selection to be something
// reasonable - otherwise in Firefox, the initial selection is (0,0), causing bug 42277
this.model.getFragment().select();
this.view.surfaceObserver.pollOnce();
* However, when VE loses focus then regains focus, we don't restore the selection

Issues caused:
* Selections of (1,1) don't play nice with documents that start with a FocusableNode
* The fact that ui.Surface.initialize reasserts the selection means that VisualEditor focuses itself on initialization, which Flow is now having to work around
* When ULS blurs then refocuses VE during its initialization, the selection jumps back to the top

What we should really be doing:
* Initialize the selection at the first content offset (this is 1 for most documents, but will be different for documents that start with a FocusableNode)
* Get rid of the model->view->model circular synchronization in ui.Surface.initialize and fix whatever problems it fixed differently
* Restore selection on focus

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to Roan Kattouw from comment #4)
> (In reply to Ed Sanders from comment #3)
> > I certainly addressed point 1 of Roan's list of actions, he may want to
> > follow up on 2 & 3.
> I did 3 a while ago. As for 2, I don't know how current that is, let me take
> a look.
Nope, 2 seems to be gone. So this bug is fixed completely then.
(In reply to Ed Sanders from comment #3)
> I certainly addressed point 1 of Roan's list of actions, he may want to
> follow up on 2 & 3.
I did 3 a while ago. As for 2, I don't know how current that is, let me take a look.
I certainly addressed point 1 of Roan's list of actions, he may want to follow up on 2 & 3.
This was fixed some time ago by Ed.
Is this the bug that causes templates to be pre-selected upon loading the editor?

Is this the bug that is resolved when the editor just places the cursor ("collapsed" selection) at the visual start of the document (e.g. not selecting the first template or character, but before it, blinking on the top left).
Right now we emit both 'live' and 'setup'/'teardown' , and some classes listen to 'live' while others use 'setup'/'teardown'. We should converge on using setup/teardown and remove live.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 144634 merged by jenkins-bot:
Deprecate 'live' event in favor of 'setup' and 'teardown' in MW

https://gerrit.wikimedia.org/r/144634
Change 144586 merged by jenkins-bot:
Deprecate 'live' event in favor of 'setup' and 'teardown'

https://gerrit.wikimedia.org/r/144586
Change 144634 had a related patch set uploaded by Mooeypoo:
Deprecate 'live' event in favor of 'setup' and 'teardown' in MW

https://gerrit.wikimedia.org/r/144634
Change 144586 had a related patch set uploaded by Mooeypoo:
Deprecate 'live' event in favor of 'setup' and 'teardown'

https://gerrit.wikimedia.org/r/144586
Tested on both the Italian and the English Wikipedia a few days ago;
Reach the bottom of any page: the link inspector does not present the
list of options.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55343
I believe that this is now fixed, at least as far as I can tell.
Yup, I can reproduce this now. It looks like in some cases, the selection dropdown isn't shown properly, it retains display:none; and height:0; (but the suggestions are there, I can see them in the DOM inspector). I think this may have to do with the unreliable behavior of nested .show() calls in jQuery in Firefox: I've observed that sometimes, calling .show() on a container doesn't immediately cause its children to evaluate as visible, which means that calling .show() on those children is a no-op because .show() refuses to touch things whose parent is hidden. The height:0 is likely due to trying to measure a hidden element.

CC Trevor.
Roan: right now in that page, if I click on "California", I get a "page found" text and two arrows which allow me to scroll a list of alternatives (which do not look handy since they only allow to preview one line at a time).
A few lines below, if I click on "architettura moderna", I don't get alternatives.
If I write somewhere, say, "USA" and try to make it a link, that will work, but I still don't get to decide which page the link should point at.
In FF, it doesn't work with Vector. It's both browser and skin specific, for me.
I can confirm this bug on en.wp, but not on nn.wp or mediawiki.org
I tried reproducing this on http://it.wikipedia.org/wiki/San_Francisco in both Firefox and Chrome, but both editing existing links and adding new links works for me.
(Please scratch the bottom of the page part, it doesn't work anywhere).
Filing this since subbu wanted to take a closer look ("Yes, VE/Parsoid shouldn't be making dirty diffs -- and these kind of dirty diffs is an exception rather than the rule. This is a bug."):

<<VE seems to make unnecessary changes. I wouldn't mind so much if it always helped to maintain the layout of invisible elements, but normally it just screws them (like infoboxes, or position of templates), without any effect on the rendered page but with a less easily readable wikitext editing window.
What I notice now though are totally unnecessary and hard to explain changes to ref names. For some reason, VE decides that all ref names need to be in quotes, which is not true at all and doesn't help one bit. It also decides that between the final quote and the forward slash, there needs to be a space. All this has no effect on the rendered page, and doesn't make the wikitext page any easier (or harder) to read, so why does VE bother doing this, which only helps to make diffs a lot longer.
Take a look at e.g. [10]: can you easily see if any significant change has been made, and what that may be?
First difference; <ref name="globsec-arjun"/> becomes 
<ref name="globsec-arjun" /> Further: <ref name=nomorearjuns> becomes <ref name="nomorearjuns">
and so on. I have not found the actual significant difference between the old and new version. What is the purpose and benefit of this? If VE would always make the "invisible" layout clearer and better, fine, but VE doesn't care one bit about wikitext layout, so I don't get this useless editing. Fram (talk) 09:27, 7 October 2013 (UTC)>>

https://en.wikipedia.org/w/index.php?title=Arjun_%28tank%29&curid=7648336&diff=576092971&oldid=575064244

--------------------------
**Version**: unspecified
**Severity**: normal
Closing this task since there is nothing much more to be done here since we cannot protect against varnish cache failures -- these should be a fairly rare occurrence. Once we move to RESTbase, this should not happen anymore.
This is still happening regularly.  Another example is at  https://en.wikipedia.org/w/index.php?diff=629369061
Another one, found while looking at diffs after the deploy of d51e64097:
https://fr.wikipedia.org/w/index.php?title=Cendrillon_(Disney)&curid=3040885&diff=105440424&oldid=104520814
Here's another diff that is probably the same bug:

https://en.wikipedia.org/w/index.php?title=Rights&curid=51490&diff=603988349&oldid=601154438

In this one, an oddly named-but-unnamed ref tag (<ref name="">) has its whitespace normalized.
This is just a note that Bug 64197, merged here, is about {{sfn}} templates, which sort of are and sort of aren't ref tags.  See https://en.wikipedia.org/w/index.php?title=Jack_Parsons_%28rocket_engineer%29&diff=604788783&oldid=604787564
*** Bug 64162 has been marked as a duplicate of this bug. ***
*** Bug 64197 has been marked as a duplicate of this bug. ***
**Wikifram** wrote:

I've reopened this, since it appears that this still happens: [https://en.wikipedia.org/w/index.php?title=Triceratops&curid=54410&diff=584366006&oldid=584365568]
I believe this was fixed by 67fca5bdc7 and 923c79102a.

These test cases from comments above now round-trip fine:

* comment #1: https://en.wikipedia.org/wiki/User:Gwicke/Test/Arjun_%28tank%29
* comment #4: https://en.wikipedia.org/wiki/User:Gwicke/Test/Wrestler
* comment #8: https://en.wikipedia.org/wiki/User:Gwicke/Test/Gray_wolf

Please reopen if this problem still exists.
The diff in comment #10 might have been caused by an unrelated issue with one of the Varnish caches in production.
This last diff seems to have happened in the context of some error the editor encountered. Recording here for further debugging.

https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=581952520#Error:Unknown_error
**Wikifram** wrote:

Still happened on the 16th: [https://en.wikipedia.org/w/index.php?title=KLM&diff=581951122&oldid=581950935]
Yes, those were probably from cache misses. We deployed newer code y'day that should eliminate these unrelated normalizations in most cases (barring bugs). 

Note however that if a <ref> is edited, Parsoid will still normalize the quotes and whitespace in the attributes of the edited ref.

Let us wait for a week to see if we still see unrelaed normalizations and if not, close this as resolved.
**Wikifram** wrote:

Not just the quotes, also the additional spaces: [https://en.wikipedia.org/w/index.php?title=Gray_wolf&curid=33702&diff=581450926&oldid=581450732] I can't judge whether this is fixed on most pages or not, but it certainly seems to happen quite reguilarly still.
**Wikifram** wrote:

...still happens apparently: [https://en.wikipedia.org/w/index.php?title=New_%28album%29&diff=581113730&oldid=581109664] (noted by another editor on [[en:WP:VEF]])
New code has been deployed with a bunch of fixes related to cache misses that would cause Parsoid to run the regular serializer on the entire dom. This should fix this issue on most pages. 

We'll also make some fixes to minimize dirty diffs even when there is a cache miss -- we've identified some improvements we could make to the DOM diff algorithm.
The new code I mentioned in #c3 hasn't been deployed to production yet. Will update this ticket when that happens.
**Wikifram** wrote:

It seems that quotes are still being added to ref tags as of today: [https://en.wikipedia.org/w/index.php?title=Sting_%28wrestler%29&curid=655575&diff=580574777&oldid=580516764]
Gabriel and I now think this happened when Parsoid incurred a cache miss for the HTML (rare) and also suffered a timeout on reparsing (possible on large pages since we had a timeout of 16 sec). But, a couple commits today should address this and further reduce the likelihood of selser not getting triggered on the edit.

The relevant commits are:

1. https://gerrit.wikimedia.org/r/#/c/93896/ (increases cache timeout to 60 sec)
2. https://gerrit.wikimedia.org/r/#/c/93902/ (improves parse time when selser suffers a cache miss fetching original HTML).
This seems to be related to bugs in selser (Parsoid) when a cache URL is set. I've set a cache URL locally and will investigate.
Yup, that's a bug. VE should not be normalizing <ref name="globsec-arjun"/> to <ref name="globsec-arjun" /> nor should it be normalizing <ref name=nomorearjuns> to <ref name="nomorearjuns">.

Since the revision wasn't tagged with the visualeditor-check tag, VE didn't detect any corruption on its end, which makes me suspect that this is a Parsoid bug.
1. Trigger a notification
2. Click on the notification to dismiss it
3. The notification area (<div id="mw-notification-area">) is now empty, but still obscures a narrow strip in the top right corner:

> $('#mw-notification-area').outerHeight()
12
> $('#mw-notification-area').outerWidth()
269
> $('#mw-notification-area').position()
Object {top: 89.59375, left: 1251.203125}
> $('#mw-notification-area').css('z-index')
"10000"

This is a problem because the div steals events and mouse interaction from the UI elements below it. For instance, in VisualEditor:
1. Open a page in VE
2. Type '[['. The wikitext warning appears
3. Click the warning to dismiss it
4. Reveal #mw-notification-area in the inspector and observe how it's on top of part of the save button
5. Very carefully move the mouse over the save button, and you'll notice a small (12px tall) area where mouse pointer is a normal pointer instead of a hand. Clicking in this area does not press the save button.

--------------------------
**Version**: unspecified
**Severity**: normal
Wrong bug, sorry

*** This bug has been marked as a duplicate of bug 52659 ***
Change 158659 had a related patch set uploaded by Catrope:
Followup 6c5b246: also hide #mw-notification-area upon creation

https://gerrit.wikimedia.org/r/158659
All you VE guys really should start looking through bugs that are already reported instead of adding more copies.

*** This bug has been marked as a duplicate of bug 52659 ***
1. Edit a page with VisualEditor.
2. Copy a line of text.

Sometimes it just copies the line to the clipboard without generating any move of the content (expected behavior). But sometimes just by typing ctrl-C with text selected you will see a jump of the page.

I haven't found the pattern, but it looks like doing this close to the end of long pages makes it easier to reproduce.

--------------------------
**Version**: unspecified
**Severity**: normal
Can't reproduce any of the issues described in this bug.
Using *any* means of copying text is making the ctrl/cmd key cause a page to jump up, not just ctrl-c/cmd-c, in Firefox. Right-click and select "Copy" and the same thing happens to the ctrl/cmd key. I cannot replicate this in Chrome.

Using Firefox 30:
1. Open any article of reasonable length to edit in VisualEditor, let's say 
https://en.wikipedia.org/wiki/Cat?veaction=edit
2. Scroll down to the middle of the article, select any portion of text, and copy it by either ctrl-c/cmd-c *or* right-clicking on the section with the mouse and selecting copy, without using a keyboard shortcut at all.
3. Now press your control or command key while the selected text is still highlighted. It now functions as an "up" button.
4. Deselect the text that you have copied and function returns to the control/command.
Well, the problem also encountered on this page: 
https://cs.wikipedia.org/wiki/Seznam_lid%C3%AD%2C_kte%C5%99%C3%AD_byli_zabiti_b%C4%9Bhem_Euromajdanu

E.g. when copy&pasting "." between rows it also jumps. Problem confirmed in:
*FF 27 safe mode
*FF 27.0.1
*FF 27.0.1 logged of

In Google Chrome 33.0.1750.117 m it jumps and paste sometimes and just once. In IE 7 VE doesnt work at all.
OK I tried FF 27 and safe mode and I have discovered that problem comes when there are empty list items in undordered list. E.g. If I have:


*M. auricantha R.T. Craig
*M. auritricha R.T. Craig
*
*
*M. canelensis R.T. Craig
*M. hertrichiana R.T. Craig
*M. lindsayi R.T. Craig

And I select whatever string on that page and type CTRL+C it "jumps"

Note: to produce empty li is just place cursor on the end of second item and hit several times enter (in this case 2 times).
Can't reproduce in FF 26. What exact text did you select? Can someone else confirm?
I am reopening this bug as I am obscuring such behaviour again in FF 26.0 at this page:
https://cs.wikipedia.org/wiki/Mammillaria_standleyi

Way to reproduce:
*Select an item in the unsorted list
*hit CTRL+C

You will see a jump up and down of the page, which is pretty unconfortable during editing.
Yes, fixed in gerrit 106185 (made avaiable in MW-VE in gerrit change 106731). Marking as such.
I think Roan put in a fix this a while back, can he confirm?
Fram reports:
<<Having looked a bit more at categories, I encountered another strange phenomenon. On Opel Laubfrosch https://en.wikipedia.org/wiki/Opel_Laubfrosch, which has a lot of categories, the order of the cats on the page settings tab changes. Initially I get 8 categories, from "Opel vehicles" to "compact cars". But when I e.g. click on the drop down button next to 1920s automobiles, and then click again in the "categories" window (to close the drop down without any changes), I get 10 cats instead of 8, and in a different order. "Vehicles introduced in 1924" and "Sedans" are doubled (explaining the increase from 8 to 10), and the 3rd one is now no longer "1920s automobiles" but "1930s automobiles"... This can go on for quite a while, with the occasional disappearance of a cat as well apparently (normally the last one). Things start to break down, with the page settings then no longer working, or it being no longer possible to add a cat, and so on.>>

I can confirm what he says, and this bug does not look browser or skin specific.
VE will let you save in a situation where you have these cats duplicated, and a "saved edit" message will also pop-up, but there will be no trace of the edit in the history. Plain removal of all the categories works fine instead: https://en.wikipedia.org/w/index.php?title=User%3AElitre_%28WMF%29%2Fsandbox&diff=576123603&oldid=576122965 .

--------------------------
**Version**: unspecified
**Severity**: normal
Yeah, I think so.
Didn't we fix a bug like this recently? Is this still valid?
Erik Moeller: "
I agree with previous commenters that this is likely to be at the cause of a
lot of the accidental infobox deletions and such. I understand it's a tricky
issue, but the current behavior is extremely confusing from the user's point of
view, so we need to look at some viable solutions. 

Recapping the simple case: User is on what they perceive to be an unnecessary
newline, presses delete to make the visual layout match the expected layout. A
separate object (in the case of the infobox, right-aligned on the other side of
the screen) suddenly disappears. This is very surprising and counter-intuitive
behavior.

Why don't we just suppress the delete key when pressing it would delete the
object the slug is associated with? In some alternative editors like Google
Docs, it is actually not possible to nuke the entire document by just pressing
down the delete key at the top of the page -- it will stop before certain
objects. I've never had any problems as a result.

That seems like the simplest solution to me and does not require a redesign of
the slugs.
"

--------------------------
**Version**: unspecified
**Severity**: major
On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on "white lines" as a blocking issue for turning VE on as default. 
On top of pages like:
* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
as well as on other places on the page "white lines" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 

Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.

This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.

(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)

How can I help to resolve this 'bug'? I will also copy to bug 55336.
I'm confirming on http://en.wikipedia.beta.wmflabs.org/wiki/Greg_and_Karen_DeSanto as a test case that this is working as intended. I would encourage others who care about this issue to try as well (note you'll need to login and enable VE, just as you do on en.wp, since Beta has the same config).

One small UX issue I'm noticing is that you can't consistently cursor away from the focusable nodes, which is somewhat exacerbated now that they're more frequently selected as you delete/backspace through content. I suggest tracking that as a separate bug, if it isn't one already.
Change 87666 merged by jenkins-bot:
Prevent deletion of FocusableNodes from a collapsed selection

https://gerrit.wikimedia.org/r/87666
Yes, anything you can select with a single click (focusable). We could restrict it to non-inline elements but I think it's useful for inline too.
Will this also cause citations and similar inline nodes to be first selected, rather than deleted, when you press backspace or delete next to them? I'm not saying that would necessarily be wrong behavior (I think it could actually be helpful), but just wanted to clarify.
Change 87666 had a related patch set uploaded by Esanders:
Prevent deletion of FocusableNodes from a collapsed selection

https://gerrit.wikimedia.org/r/87666
I agree, although I would say instead of suppressing the delete/backspace key, it should cause the adjacent FocusableNode (e.g. Infobox) to become focused, so that a second keypress actually deletes it. This shouldn't be too difficult to achieve.
https://en.wikipedia.org/wiki/Konami_code?veaction=edit , in Firefox.
Locate the sequence of references [5][6][7][8].
Delete one of them (not the first one), hit Space, a pawn appears. 
Easter egg *in* Konami Code!

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54712
This too is fixed now.
James, if it's a dupe, it's still not working.
This is actually the same (really terrible) bug as bug 54712, which is thankfully now fixed; merging.

Thanks for reporting it!

*** This bug has been marked as a duplicate of bug 54712 ***
Because we don't store the inner whitespace of the document, we can't validate the outer whitespace its first/last children.

1. Create document with wikitext:
==Heading==
Foo
2. Delete 'Heading' and the empty line
3. You now have:
[{'type':'paragraph', 'internal': {'whitepsace': ['\n']}}, 'F' ....
in the DM
4. This serialises to
\n
Foo

--------------------------
**Version**: unspecified
**Severity**: normal
Change 92885 merged by jenkins-bot:
Store inner whitespace of the body and compare it on conversion

https://gerrit.wikimedia.org/r/92885
Change 92885 had a related patch set uploaded by Esanders:
Store inner whitespace of the body and compare it on conversion

https://gerrit.wikimedia.org/r/92885
**Wikifram** wrote:

Translation for those looking to file a similar bug but no so well-versed in code-speak :-): 

When you have a blank line at the start of an article, before the text of the lead, it is impossible in VE to remove this line or lines. See e.g. [https://en.wikipedia.org/w/index.php?title=User%3AFram%2Fsandbox&diff=575706125&oldid=575706080]
See test case below. For some reason the <pre> inside the <blockquote> and the p-tag before the blockquote (all of those conditions are necessary to reproduce the bug) is causing the content after the blockquote to not be wrapped in p-tags. See output below. Probably some edge case in the paragraph-wrapping code. 

Based on bug report here:
https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=575631753#VE_removing_paragraph_gaps

[subbu@earth lib] cat /tmp/x
a

<blockquote><pre>
b
</pre></blockquote>

c

d
[subbu@earth lib] node parse < /tmp/x
<body data-parsoid='{"dsr":[0,49,0,0]}'><p data-parsoid='{"dsr":[0,1,0,0]}'>a</p>

<blockquote data-parsoid='{"stx":"html","dsr":[3,42,12,13]}'><pre data-parsoid='{"stx":"html","autoInsertedEnd":true,"strippedNL":"\n","dsr":[15,29,5,0]}'>

b
&lt;/pre&gt;</pre></blockquote>

c

d
</body>

--------------------------
**Version**: unspecified
**Severity**: normal
Change 87632 abandoned by Subramanya Sastry:
(Bug 54946) Fixed unhandled <pre> tokenizing scenarios

Reason:
Old and rusty and I am not going to look at this as I originally thought.

https://gerrit.wikimedia.org/r/87632
Change 92469 merged by jenkins-bot:
Bug 54946: Alternative solution for <pre> tokenization

https://gerrit.wikimedia.org/r/92469
Change 92469 had a related patch set uploaded by GWicke:
WIP Bug 54946: Alternative solution for <pre> tokenization

https://gerrit.wikimedia.org/r/92469
Change 87632 had a related patch set uploaded by Subramanya Sastry:
(Bug 54946) Fix unhandle <pre> tokenizing scenarios

https://gerrit.wikimedia.org/r/87632
This is actually a tokenizer bug. The closing </pre> is not being recognized as an end-tag when a HTML <pre> follows another literal HTML tag on the same line.

Relevent snippet of output for: "a\n\n<span><pre>\nb\n</pre></span>"
...
<span data-parsoid='{"stx":"html","dsr":[3,28,5,6]}'><pre data-parsoid='{"stx":"html","autoInsertedEnd":true,"strippedNL":"\n","dsr":[8,22,5,0]}'>

b
&lt;/pre&gt;</pre></span>
...
Changing that to "<blockquote><pre> b </pre></blockquote>" does not trigger the bug. So, p-tags before blockquote and HTML-pre in blockquote with content on new line puts the p-wrapper in a state where p-tags are not added.
De.WP's ref templates interact unhelpfully with VE/Parsoid, resulting in unwanted insertion of "<ref name=":0">"; examples:

https://de.wikipedia.org/w/index.php?title=Titl%C3%A1&diff=prev&oldid=122939538

template: https://de.wikipedia.org/wiki/Vorlage:Internetquelle

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

template: https://de.wikipedia.org/wiki/Vorlage:Der_Spiegel

It also results in having the display of the ref being moved into another ref. This is different from the other issue debated in 53777

--------------------------
**Version**: unspecified
**Severity**: major
Closing unless and until this is shown to still be a problem.
Can you provide steps to reproduce?
(In reply to comment #1)
> I'm not sure I understand what the issue is here? Re-used references are
> getting a name automatically added (":0") so that they can be re-used…
> 
> Or are they not edits that are intentionally re-using a reference?

First case: The "Südtiroler Wochenmagazin" ref eats the newly inserted ref "ServusTV", causing a fix:

https://de.wikipedia.org/w/index.php?title=Titl%C3%A1&diff=123114172&oldid=122939538

Second case: The Der Spiegel ref in the second diff doesn't appear in the ref section at the end of the article but gets eaten up by the Die Zeit ref; causing this edit:

https://de.wikipedia.org/w/index.php?title=Die_letzte_Vorstellung&diff=next&oldid=123020177
I'm not sure I understand what the issue is here? Re-used references are getting a name automatically added (":0") so that they can be re-used…

Or are they not edits that are intentionally re-using a reference?
(Second browser-specific - Firefox - bug I file today after 54322).
It was reported by Fram at en.wp, quickest way to duplicate:
<<cursor in front of ref, use the "back arrow" on your keyboard once (so the ref number gets "blue"), and type.>>

https://en.wikipedia.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandbox&diff=575562298&oldid=575557792 (with a snowman as well).

More ways:
<<Type some text, add a ref, remove the ref using backspace, then change your mind and use the "undo" arrow of VE. No, change your mind again and use the "undo" arrow once more, again removing the ref. Now type. Notice anything strange? Yep, I'm typing backwards. https://en.wikipedia.org/w/index.php?title=User:Fram/sandbox&oldid=575553019
[...]
Other tests produced the snowmen, or the insertion of huge chunks of text by VE. https://en.wikipedia.org/wiki/In_My_Dreams_%28Emmylou_Harris_song%29?veaction=edit
[...]
Easy way to check the "backwards typing": go to https://en.wikipedia.org/wiki/In_My_Dreams_%28Emmylou_Harris_song%29?veaction=edit , put the cursor after ref 1, backspace, undo arrow, type.>>

TeamGale adds:
<<I tried to reproduce it because I was curious and it's a really weird bug! Although when I put my cursor at the end of the "backwards typing" and clicked space, I could type straight again! TeamGale 10:03, 3 October 2013 (UTC)>>

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57600
https://bugzilla.wikimedia.org/show_bug.cgi?id=61538
Now fixed again, hopefully for good.
*** Bug 57347 has been marked as a duplicate of this bug. ***
Still being reported: yesterday, on fr.wp.
Can now replicate; yes, this is very worrying.
/me shouts :D
Still happening with Firefox.
**Wikifram** wrote:

Not a duplicate and/or not resolved. Please just test whatever has been described before closing bugs, there are too many that need to be reopened. [https://en.wikipedia.org/w/index.php?title=In_My_Dreams_%28Emmylou_Harris_song%29&diff=575692625&oldid=565930941]
I /think/ this is the same as bug 54712 which we're working on right now and will rush out a live patch - merging the bugs. If it proves otherwise, please shout

*** This bug has been marked as a duplicate of bug 54712 ***
To reproduce, go to the URL ([[User:Amire80/ve-invalid-image-keyword]]). Notice that the save button doesn't appear in the toolbar. The JS console shows the following error:

[15:59:08.469] Error: Offset could not be translated to a DOM element and offset: 3

The reason for this is the invalid keyword "no_such_keyword" that I used on the image.

A better behavior would be to show the user some kind of a warning about the wrong keyword, rather than throwing a JS error and crashing.

This bug was discovered by User:Nurick in the Hebrew Wikipedia.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/wiki/User:Amire80/ve-invalid-image-keyword?veaction=edit
This seems to have occurred because we tried to put the selection inside the image caption, which then caused an error. For whatever reason, this doesn't seem to be happening any more; opening your test page in VE doesn't reproduce the error now.
The Paragraph style tool in toolbar is not working in Firefox most of the time.

Steps to reproduce
1. https://www.mediawiki.org/wiki/special:random
2. Active VE (Click 'Edit')
3. Place cursor on normal text

Expected results:
The paragraph style selector should change to 'Paragraph'

Actual results (in Firefox 24/linux):
9 out of 10 times, nothing changes.  The tool does not work at all.  Changing style doesnt work.

This doesnt happen on enwp.

In debug=true mode, the paragraph selector nearly always changes to Paragraph, but sometimes it then doesnt change to Heading if the cursor is moved to a Heading and changing the style doesnt work.

There is nothing in the JS console to suggest what might be the problem.

--------------------------
**Version**: unspecified
**Severity**: major
Can't reproduce either; that's four devs (on various environments) unable to reproduce today, so I'm going to claim that this is fixed.
Just for good measure, also tested extended-support release which is Firefox 24.3; seems ok there too. Either specific conditions need to trigger this which we aren't hitting, or it's gotten fixed...
I'm no longer able to reproduce this in Firefox 27.0.1 or Firefox 30 nightly.
(In reply to comment #2)
> I believe that this is a regression of sorts:
> 
> Behavior 1: 2 click, works
> 
> 1. Click tool to open menu
> 2. Move mouse to item you want to select
> 3. Click to select item
>..
> Can you confirm that Behavior 1 works?

yes, that works.
 
> The only difference between browsers seems to be that on Chrome clicking and
> dragging doesn't highlight items as you drag over them, but in Firefox it
> does,
> which is probably why you were expecting the menu to select the item using
> click and drag on that browser.

My steps to reproduce dont include any clicking, let alone dragging.  You can reproduce this bug using the only they keyboard.
I believe that this is a regression of sorts:

Behavior 1: 2 click, works

1. Click tool to open menu
2. Move mouse to item you want to select
3. Click to select item

Behavior 2: Click and drag, broken since recent refactor of toolbar

1. Press mouse button down on tool to open menu
2. Move mouse to item you want to select
3. Release mouse button to select item

I can confirm that Behavior 2 is broken.

Can you confirm that Behavior 1 works?

The only difference between browsers seems to be that on Chrome clicking and dragging doesn't highlight items as you drag over them, but in Firefox it does, which is probably why you were expecting the menu to select the item using click and drag on that browser.
Confirmed in Firefox 24 on Mac OS X 10.8.5 -- I had it work once, then not work several times after reloading. Something funky!
When saving some page using VisualEditor, "characters left" (e.g. 255) is under the text which comes from the Pending changes extension.

I have a picture to explain more. It's taken from the Finnish Wikipedia where is the Pending changes extension.

https://commons.wikimedia.org/wiki/File:To_explain_a_bug_with_VisualEditor_and_Pending_changes.png

--------------------------
**Version**: unspecified
**Severity**: normal
Merging with bug 52175; this is happily already fixed in the re-written save dialog that will be coming shortly. Sorry for the disruption.

*** This bug has been marked as a duplicate of bug 52175 ***
Confirmed bug on de.wp.  Support for flagged revs was added on bug 49699.
From T56721 comment 2:

> When I copy a portion of content beginning with a header, then paste it
> elsewhere in the same document, everything is retained  /except/ the header.
> However, if I begin before the header (the paragraph before the header, for
> example) the header is retained.
>
> For example, copy everything from 'Start' to 'Finish' on this test page:
> https://www.mediawiki.org/wiki/VisualEditor:Test1234567
>
> Everything is retained except the H2 formatting on 'Start'. See this
> screenshot as an example too:
> http://images.wikia.com/trevortest/images/5/54/Header_is_lost.png
> {F16005520}

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 50126 ***
Currently on MediaWiki.org, categories cannot be removed from the 'Page Settings' modal. This is true of new categories added and existing categories.

https://www.mediawiki.org/wiki/VisualEditor:Test1234567?veaction=edit

Inez says he's working on a fix now.

--------------------------
**Version**: unspecified
**Severity**: major
Change 86674 merged by jenkins-bot:
removedItems[i] is already an item, no need to pass removedItems[i].item

https://gerrit.wikimedia.org/r/86674
Change 86673 merged by jenkins-bot:
removedItems[i] is already an item, no need to pass removedItems[i].item

https://gerrit.wikimedia.org/r/86673
Change 86674 had a related patch set uploaded by Jforrester:
removedItems[i] is already an item, no need to pass removedItems[i].item

https://gerrit.wikimedia.org/r/86674
Change 86673 had a related patch set uploaded by Jforrester:
removedItems[i] is already an item, no need to pass removedItems[i].item

https://gerrit.wikimedia.org/r/86673
Marking as "FIXED"; have removed "or change sort key" from title per discussion with Inez.
Change 86341 merged by jenkins-bot:
removedItems[i] is already an item, no need to pass removedItems[i].item

https://gerrit.wikimedia.org/r/86341
Change 86341 had a related patch set uploaded by Catrope:
(bug 54727) item itself is an item, there is no need to try to pass item of that item

https://gerrit.wikimedia.org/r/86341
Bugfix for removal is waiting for review. Sortkey still not fixed - Trevor: Can you split it into separated bug?
Change 86341 had a related patch set uploaded by Inez:
(bug 54727) item itself is an item, there is no need to try to pass item of that item

https://gerrit.wikimedia.org/r/86341
Also just checked editing a sort key — that functionality is no longer working as well. You can enter text into the field and close the inspector, but when it is reopened the text is not retained.
Comparison of content

I am on Mac OSX 10.8.5 on Firefox 24.0

Steps to reproduce:

1. Navigate to any article and open the VisualEditor (https://en.wikipedia.org/wiki/Kitten?veaction=edit)
2. Copy any selection of text that has formatting (bold, italics, link, header, references)
3. Paste the content elsewhere in the same VE document.
4. You will see that all formatting has been stripped. See the attached file.

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

**Attached**: {F12231}
Making this a new bug as it's actually present in all browsers and has been around for a while, unlike this one - bug 54728.
Oh, it is fixed!  But now I see a more minor issue:

When I copy a portion of content beginning with a header, then paste it elsewhere in the same document, everything is retained  /except/ the header. However, if I begin before the header (the paragraph before the header, for example) the header is retained.

For example, copy everything from 'Start' to 'Finish' on this test page: https://www.mediawiki.org/wiki/VisualEditor:Test1234567

Everything is retained except the H2 formatting on 'Start'. See this screenshot as an example too: http://images.wikia.com/trevortest/images/5/54/Header_is_lost.png

I can create a new ticket if you need me to, but I think this one may suffice with a name change.
Aha - yes, sorry, I *can* re-create this in wmf18 (en.wikipedia.org) but not wmf19 (mediawiki.org). I think we fixed this is in gerrit 85213, but closing as FIXED for now. If you can reproduce on MediaWiki.org (or master), please re-open.
Edit link for VE missing in automated test

Seen on mw.o and test2wiki, with examples from automated tests and manual operations, but I do not have a consistent repro. 

Seems to happen more frequently for Chrome than Firefox. 

The lack of an edit link causes automated tests to fail from time to time.  I had thought it might be an artifact of the automation, but one of our candidates for VE QA also encountered the issue and conveniently provided a screen shot.

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

**Attached**: {F12179}
No recent reports.
Have you seen this issue recently? If not, this could probably be closed...
*** Bug 60359 has been marked as a duplicate of this bug. ***
probably worth a look but this might be WORKSFORME, I don't think we've encountered this issue in at least a month
Created attachment 13393
Edit link for VE missing in manual operation

**Attached**: {F12180}
Change 90957 merged by jenkins-bot:
Defer selection-triggered updates in ve.ui.Context

https://gerrit.wikimedia.org/r/90957
Change 90957 had a related patch set uploaded by Catrope:
Defer selection-triggered updates in ve.ui.Context

https://gerrit.wikimedia.org/r/90957
From #mediawiki-visualeditor IRC with RoanKattouw:

* It seems wrong to implement click-out-to-close by detecting a selection change.
* Should we bind to document mousedown instead? We need to avoid tripping over other mouse handling of course.

Aside from this,

* In general DM selection changes should emit something less drastic than 'change', because we don't want them to get back to the CE layer (which has a somewhat different set of possible cursor positions).
* I (David) am currently working on a fairly big refactor of ve.ce.Surface will include this.
1. Create a page with <source lang="JavaScript">some content here</source>
2. Edit the page in VE. Note that the <source> tag renders correctly
3. Use the alien tag inspector to edit the contents of the <source> tag
4. The <source> tag rerenders as an empty block

This is because the HTML <source> tag is self-closing and cannot have any content. This leads to strange situations like:

>>> extensionNode[0]
<source lang=​"JavaScript">​whee​</source>​
>>> extensionNode[0].outerHTML
"<source lang="JavaScript"></source>"

To avoid the HTML behavior for this and possibly other tag names, we should create an XML node rather than an HTML node to build the wikitext string for the preview.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57429
Change 98392 merged by jenkins-bot:
Render MW extension node wikitext with XML

https://gerrit.wikimedia.org/r/98392
Change 98392 had a related patch set uploaded by Esanders:
Render MW extension node wikitext with XML

https://gerrit.wikimedia.org/r/98392
https://en.wikipedia.org/w/index.php?title=Daniel_Rowe_%28footballer%29&oldid=570278760&veaction=edit

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54341
Hey Roan :)
I might be wrong, but I think it's still about name corruption (I think the user is complaining that he added or reused a reference, but after he saved the number in brackets was not pointing to the one he chose).
Anyway, I'll contact the user to get more details, because it might also be not a bug at all. As I wrote elsewhere, I think it can be confusing that the name and the number of a reference do not match, although everything will still work as intended.
See
https://en.wikipedia.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandbox&diff=575128343&oldid=575128003
(the reference #2 gets a ref name:3).
(In reply to comment #7)
> Additional comments from Polish Wikipedia Kthaara:
> 
> "Bug seems did not recognize references or not recognize their numbers. Ex.:
> I
> wrote some text in section about add-ons and need to make a reference to page
> from Eve-community. I make one and VE, sure, did it, but aotomaticaly
> redirects
> to completely different reference, like: it make ref no. 50 and redirect it
> to
> no. 3 - which is different thing. After several tries I manage to get right
> reference but it change another. In this moment I gave up." 
> 
> And here is a diff:
> https://pl.wikipedia.org/w/index.
> php?title=Eve_Online&diff=37587971&oldid=37587957
This looks like a similar bug, but it's not the same bug (the original report was about name corruption, not content corruption). Could you file a new bug for this?

Additionally, an as detailed as possible explanation of what the user did to produce that diff (step-by-step instructions, if they remember) would be very helpful. It's theoretically possible for VE to produce that diff legitimately if the user did certain things, but I doubt that's what happened.
Additional comments from Polish Wikipedia Kthaara:

"Bug seems did not recognize references or not recognize their numbers. Ex.: I wrote some text in section about add-ons and need to make a reference to page from Eve-community. I make one and VE, sure, did it, but aotomaticaly redirects to completely different reference, like: it make ref no. 50 and redirect it to no. 3 - which is different thing. After several tries I manage to get right reference but it change another. In this moment I gave up." 

And here is a diff: https://pl.wikipedia.org/w/index.php?title=Eve_Online&diff=37587971&oldid=37587957
This problem was also reported happening on Polish Wikipedia (PL.WP) by User:Kthaara (using VE on Win 7, Mozilla Firefox (latest version)).

https://pl.wikipedia.org/wiki/Wikipedia:VisualEditor/Opinie#linki_i_przypisy 

>> This bug appears when I edited Eve Online page:
>> https://pl.wikipedia.org/wiki/Eve_Online
I believe that this is the same as bug 54341 which was fixed last week and is live.

*** This bug has been marked as a duplicate of bug 54341 ***
More from Red Fiona:
<<If the page already has references, it either doesn't add the reference at all, on this page (https://en.wikipedia.org/w/index.php?title=Vladimir_Gojkovi%C4%87&diff=575208071&oldid=551414203)
, or adds it as the second reference when it's not really the second reference (https://en.wikipedia.org/w/index.php?title=Nataliya_Pyhyda&diff=575209107&oldid=568886402) .>>
Worse, I just attempted to add an actual reference, and this bug just replaced the reference I tried to insert with a cross-reference to this new bogus :0 reference!

It was a good thing Visual Editor got disabled by default recently - quality control seems to be lacking!!
Created attachment 13346
Screenshot of dirty diff on "Turkey Hill (company)"

https://en.wikipedia.org/w/index.php?title=Turkey_Hill_(company)&oldid=568325662&veaction=edit

http://tools.wmflabs.org/visualeditor/dirtydiffs/2013-09-17_13-00/Turkey_Hill_-company-.png

**Attached**: {F11869}
Created attachment 13344
Screenshot of dirty diff on "Daniel Rowe (footballer)"

http://tools.wmflabs.org/visualeditor/dirtydiffs/2013-09-17_13-00/Daniel_Rowe_-footballer-.png

**Attached**: {F11868}
**Author:** `swalling`

**Description:**
Steps to reproduce:

1. Place your cursor in page text. 
2. Navigate through the text with left-right arrow keys, until you get to a reference
3. When the ref tool popup appears, you cannot move past it with arrow keys.

--------------------------
**Version**: unspecified
**Severity**: major
Change 86801 merged by Catrope:
Make cursoring over a FocusableNode work again

https://gerrit.wikimedia.org/r/86801
Change 86800 merged by Catrope:
Make cursoring over a FocusableNode work again

https://gerrit.wikimedia.org/r/86800
Merged into master; we'll back-port and deploy tomorrow.
Change 86801 had a related patch set uploaded by Jforrester:
Make cursoring over a FocusableNode work again

https://gerrit.wikimedia.org/r/86801
Change 86800 had a related patch set uploaded by Jforrester:
Make cursoring over a FocusableNode work again

https://gerrit.wikimedia.org/r/86800
Change 86788 merged by jenkins-bot:
Make cursoring over a FocusableNode work again

https://gerrit.wikimedia.org/r/86788
Change 86788 had a related patch set uploaded by Catrope:
Make cursoring over a FocusableNode work again

https://gerrit.wikimedia.org/r/86788
*** Bug 54722 has been marked as a duplicate of this bug. ***
The events from the pasteTarget (which has focus when a focusableNode is selected) are not getting through to the document listener.
Updating priority to normal. Inability to move the cursor using arrows is definitely a bug.
Copy/pasting a template that existed prior to the current session only pastes, as literal text, the unformatted text output of the template. Template boxes, etc are ignored. Images are ignored unless they have alt-text, in which case the alt-text is pasted in the position the image would be if shown.

Templates added in the current editing session can be copied and pasted as expected.

Possibly this is a result of the fix to bug 49396?

To reproduce:
1. Load any page with 1 or more templates or images, e.g. https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox4&oldid=573844495

2. select and copy a template or image
3. Paste the somewhere else in the page.

Expected behaviour: the full template or image is pasted
Actual behaviour (templates): Only text output of the template is pasted, unformatted and unlinked.
Actual behaviour (images): Only the image caption is pasted, unformatted and unlinked.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49396
This was fixed some time ago; sorry for the slow update.
Parsoid is flooding the global job queue.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**Whiteboard**: [see comment 9]
(In reply to James Forrester from comment #36)
> Can we close this bug now? I believe this has been fixed.

No feedback => Closing.
Can we close this bug now? I believe this has been fixed.
Change 86745 merged by Faidon Liambotis:
Bug 54406: Speed up Parsoid job processing

https://gerrit.wikimedia.org/r/86745
(In reply to comment #30)
> @MZMcBride: I think both the broader technical and the social issue have been
> discussed sufficiently now. From now on I am not going to discuss anything
> but the Parsoid job queue length in this bug.

I was repeatedly called out (by you and others) on this bug for causing the increased job queue length when there's no evidence this was the case.

(In reply to comment #32)
> (I'm removing myself from cc as we don't even manage to get a fact-based
> summary.)

I wish I could remove myself, but Bugzilla doesn't allow the reporter to be changed. :-(
Change 86745 had a related patch set uploaded by GWicke:
Bug 54406: Speed up Parsoid job processing

https://gerrit.wikimedia.org/r/86745
(I'm removing myself from cc as we don't even manage to get a fact-based summary.)
PS: There is no such thing as a global job queue. There are several independent queues which are stored on the same infrastructure and graphed as an aggregate.
@MZMcBride: I think both the broader technical and the social issue have been discussed sufficiently now. From now on I am not going to discuss anything but the Parsoid job queue length in this bug. Please discuss other aspects elsewhere.
(In reply to comment #3)
> The main issue seems to be MZMcBride's null editing at a rate way beyond even
> bot edit limits.

It's difficult to look at these claims as being anything other than spurious. Attachment 13412 shows a continued increase in the global job queue (now exceeding 3.78 million jobs).

I'm restoring the original bug summary, which was most accurate: Parsoid is flooding the global job queue. Nobody seems to be particularly concerned with this, however, so it may make sense to mark this bug as resolved/worksforme.
Created attachment 13412
Screenshot to accompany comment 3

**Attached**: {F11775}
(In reply to comment #23)
> Just curious - is there anything actionable that can possibly come out of
> this bug?

This bug was filed under the assumption that job queues shouldn't contain millions of jobs.

Gabriel seems to suggest throughout this bug report that the global job queue size is irrelevant (or rather, that he's apparently unconcerned with its size), so I'm not sure there is anything actionable here. This may be a wontfix.

(In reply to comment #21)
> For templates there is no way around the load this creates when they really
> need to be edited. I have a hard time seeing a similarly good reason for
> making 8 million null edits at a rate of ~4/second.

There are a lot of pages to edit. If we edited one page per minute and edited 31,000,000 pages, that would take approximately 58.9 years. Obviously we're going to have to go a bit faster than that.

Many pages have not been re-parsed or purged from cache in years (since 2005 for the oldest pages). This results in outdated or incorrect *links entries, stale HTML cache, etc., in addition to a number of lurking page text anomalies (incorrectly unsubstituted templates, incorrectly unexpanded user signatures, etc.). Null editing is built in to MediaWiki to address these issues on a per-page basis. You've yet to identify any issue with using this built-in feature.

Other than a global job queue that's already flooded, were there any issues from null editing that you (Gabriel) or anyone else has found? If so, I'd like to learn more so that I can understand and grow as a contributor.
@Yuvi: For the technical part, see comment #9. The social / DoS prevention issue is probably better discussed elsewhere.
(In reply to comment #24)
> Yes! I'm hoping for a definition of "what is the problem" to actually come
> out
> of it. It may take a hundred more comments though, given the current speed
> we're approaching it at.

May I suggest using something that's not bugzilla for that purpose? I understand the need for clarity, but honestly a bugzilla ticket is probably not the best way to do it. A mailing list post, perhaps?
(In reply to comment #23)
> Just curious - is there anything actionable that can possibly come out of
> this
> bug?

Yes! I'm hoping for a definition of "what is the problem" to actually come out of it. It may take a hundred more comments though, given the current speed we're approaching it at.
Just curious - is there anything actionable that can possibly come out of this bug?
(In reply to comment #21)
> Popular templates are protected for a reason, and editors don't edit them
> needlessly, as they know about the high load this causes. 
> 
> For templates there is no way around the load this creates when they really
> need to be edited. 

Ok, so people avoid things which cause overload but still in July we had about 2M additional job queue items. And it seems that's fine. What's not fine then, what is this bug about? Can we please identify the problem and the source of it? Otherwise I don't see how one can identify solutions.

> I have a hard time seeing a similarly good reason for
> making
> 8 million null edits at a rate of ~4/second. 

I'm having a hard time too. They are just speculations without answers to what above.

> Especially without talking to
> the
> people responsible for keeping the site running 

(This makes sense.)

> and in contravention of the
> bot
> policy.

Sigh. There isn't any contravention of the bot policy. The relevant local page is [[Wikipedia:Don't worry about performance]].
Hint: the policies or pseudo-policies you are looking for are on wikitech, e.g. [[wikitech:Robot policy]]. I don't remember which one precisely but there is one written by Tim which explicitly says "if you're causing problems/bringing the site down we'll block you", period.
In this case however, I still don't see what the problem is. Again, why is 2M not a problem but 3M yes?
(In reply to comment #20)
> Can you then explain why "the
> second million was too much", i.e. why reaching 2M job queue is in your
> opinion
> all fine and normal while 3 is something absolutely horrible and criminal?
> Thanks.

Popular templates are protected for a reason, and editors don't edit them needlessly, as they know about the high load this causes. 

For templates there is no way around the load this creates when they really need to be edited. I have a hard time seeing a similarly good reason for making 8 million null edits at a rate of ~4/second. Especially without talking to the people responsible for keeping the site running and in contravention of the bot policy.
I'm not sure how familiar you are with the actual writing and enacting of those social rules, but surely here nothing was done against them. The social rules in the various variations of the global [[m:Bot policy]] are not about performance; the speed limit is typically driven by users not wanting their Special:RecentChanges and Special:WatchList to be flooded, which in this case obviously didn't happen (so let's not even start debating what's an "edit").

Besides, I don't really have an answer yet to my question, though we're getting nearer; probably it would be faster if we avoided off-topic discussions on alleged abuse and similar stuff.

(In reply to comment #19)
> (In reply to comment #15)
> > I still see no answer about what the spike on July 29 was: are you saying it
> > wasn't about parsoid, but just a coincidence? Or that it was normal to queue
> > over a million jobs in a couple of days (initial caching of all pages or
> > something?) but the second million was too much?
> 
> Just editing a handful really popular templates (some are used in >7 million
> articles) can enqueue a lot of jobs (10 titles per job, so ~700k jobs). As
> can
> editing content at high rates. Core happens to cap the number of titles to
> re-render at 200k, while Parsoid re-renders all, albeit with a delay.

Thanks, so I guess the answer is the second. Can you then explain why "the second million was too much", i.e. why reaching 2M job queue is in your opinion all fine and normal while 3 is something absolutely horrible and criminal? Thanks.
(In reply to comment #15)
> I still see no answer about what the spike on July 29 was: are you saying it
> wasn't about parsoid, but just a coincidence? Or that it was normal to queue
> over a million jobs in a couple of days (initial caching of all pages or
> something?) but the second million was too much?

Just editing a handful really popular templates (some are used in >7 million articles) can enqueue a lot of jobs (10 titles per job, so ~700k jobs). As can editing content at high rates. Core happens to cap the number of titles to re-render at 200k, while Parsoid re-renders all, albeit with a delay.

Ideally we'd prioritize direct edits over template updates as only the former has any performance impact. Editing a page with slightly out-of-date template rendering will still yield correct results. Longer-term our goal is to reduce API requests further so that we can run the Parsoid cluster at capacity without taking out the API.

And yes, I was referring to very straightforward social rules that are designed to prevent our users from overloading the site with expensive operations. We currently provide powerful API access that can easily be abused. If the attitude that everything that is not technically blocked must surely be ok becomes more popular we'll have to neuter those APIs significantly. Maybe it is actually time to technically enforce social rules more strictly, for example by automatically blocking abusers.
No user in the "bot" user group was used to null edit. Just a standard and unprivileged (albeit autoconfirmed) account.

On Wikimedia wikis, 'edit' is rate-limited only for 'ip' and 'newbie', but not for 'user' or 'bot' or any other group, as far as I can tell.
(In reply to comment #16)
> (In reply to comment #14)
> > Bots are explicitly not rate-limited.
> 
> https://en.wikipedia.org/wiki/Wikipedia:Bot_policy#Bot_requirements states
> that
> "bots doing non-urgent tasks may edit approximately once every ten seconds". 
> Am I missing something?

That requirement is imposed by the community, it is not necessarily a technical limit. If you look at https://en.wikipedia.org/wiki/Special:ListGroupRights, the 'bot' group is deliberately exempted from rate limits with the 'noratelimit' userright.
(In reply to comment #14)
> Bots are explicitly not rate-limited.

https://en.wikipedia.org/wiki/Wikipedia:Bot_policy#Bot_requirements states that "bots doing non-urgent tasks may edit approximately once every ten seconds". 
Am I missing something?
I still see no answer about what the spike on July 29 was: are you saying it wasn't about parsoid, but just a coincidence? Or that it was normal to queue over a million jobs in a couple of days (initial caching of all pages or something?) but the second million was too much?

The new summary seems incorrect in two ways:
1) "fast enough" might be incorrect, you say that it's not important if it's slow,
2) "during heavy bot activity" is a possibly incorrect guess.
What's sure is that we no longer seem to have any meaningful job queue data.
(In reply to comment #13)
> Still, to avoid any misunderstandings: Null editing at rates way higher than
> those allowed for bots is at best a very bad idea.

Bots are explicitly not rate-limited.
Changed the subject to be more accurate. Some more clarification for those less familiar with the way Parsoid caching works:

* Timely Parsoid cache refreshes are not needed for correctness. Delayed updates can result in a higher percentage of cache misses than usual, but will not result in incorrect edits.

* Parsoid uses its own queue, so a backlog does not affect any other job queue.

So in the bigger picture this is annoying, but not critical.

Still, to avoid any misunderstandings: Null editing at rates way higher than those allowed for bots is at best a very bad idea.
(In reply to comment #10)
> (In reply to comment #9)
> > Since
> > that stopped yesterday, the enwiki Parsoid job queue has drained by 10% (200k
> > jobs).
> 
> Did the other jobs increase then? 

Jobs in other job queues (I see 26k refreshlinks2 jobs on enwiki for example), and/or Parsoid jobs on other wikis have likely slightly increased in number. Overall the queue size has slightly decreased since the null-editing was stopped.
(In reply to comment #9)
> It seems that the Parsoid dequeue rate was slightly lower than the average
> enqueue rate since the end of July, which allowed the job backlog to build
> up a bit.

A bit? Looking at https://ganglia.wikimedia.org/latest/graph_all_periods.php?c=Miscellaneous%20pmtpa&h=hume.wikimedia.org&v=823574&m=Global_JobQueue_length&r=hour&z=default&jr=&js=&st=1365625056&z=large it seems like the queue went from 355,850 to 1,590,000 in the span of about six days (from July 29 to August 3). It grew by... 346%? That's what you're calling "a bit"?
(In reply to comment #9)
> Since
> that stopped yesterday, the enwiki Parsoid job queue has drained by 10% (200k
> jobs).

Did the other jobs increase then? The total job queue was 3.01M and is now 2.94M (it generally goes down in European nights and so).
(In reply to comment #6)
> (In reply to comment #3)
> > We dequeue Parsoid jobs in a throttled manner to avoid overloading the API
> > during edit spikes. This means that abnormal edit rates especially to
> > templates can create a large backlog of jobs in the Parsoid queue.
> 
> Where does Parsoid fit in to the general MediaWiki ecosystem? Are Parsoid
> jobs
> generated on every edit? If so, why? 

After an edit, the Parsoid HTML for each affected article is generated / updated with jobs that perform HTTP requests to the Parsoid cluster. This ensures that requests from VisualEditor and other users are normally served straight from cache. We have been processing all edits from all Wikipedias since June. As expected, VE deployments have not made a noticeable difference to the load on the Parsoid cluster.

It seems that the Parsoid dequeue rate was slightly lower than the average enqueue rate since the end of July, which allowed the job backlog to build up a bit. During MZMcBride's null edit episode the backlog doubled in size. Since that stopped yesterday, the enwiki Parsoid job queue has drained by 10% (200k jobs).

So overall, the Parsoid job dequeue rate is slightly too low to absorb abnormal edit rates in a timely manner. It might be sufficient to slightly de-throttle the Parsoid dequeue rate while keeping an eye on the API cluster load (https://ganglia.wikimedia.org/latest/?r=hour&cs=&ce=&m=cpu_report&s=by+name&c=API+application+servers+eqiad&h=&host_regex=&max_graphs=0&tab=m&vn=&sh=1&z=small&hc=4).
(In reply to comment #7)
> Created attachment 13342 [details]
> Screenshot to accompany comment 2

The spike around July 29 is easy to see and most likely corresponds with the deployment mentioned in comment 2. There are also spikes around August 14 and September 8, neither of which have been accounted for yet.

**Attached**: {F11772}
Created attachment 13342
Screenshot to accompany comment 2

**Attached**: {F11772}
(In reply to comment #3)
> We dequeue Parsoid jobs in a throttled manner to avoid overloading the API
> during edit spikes. This means that abnormal edit rates especially to
> templates can create a large backlog of jobs in the Parsoid queue.

Where does Parsoid fit in to the general MediaWiki ecosystem? Are Parsoid jobs generated on every edit? If so, why? My understanding is that Parsoid is related to VisualEditor, so I have difficultly understanding how millions of Parsoid jobs would be queued unless they were all related to VisualEditor usage.

> The main issue seems to be MZMcBride's null editing at a rate way beyond even
> bot edit limits.

What's a bot edit limit?

> Do we have a product for DoS attack detection and -mitigation?

DoS attack? I think it makes sense for all of us to focus on why and how Parsoid is flooding the global job queue. Suggesting anyone was performing a denial-of-service attack is both inappropriate and unhelpful. There are a number of anti-abuse measures built in to MediaWiki, to answer your question generally.
(In reply to comment #2)
> For the record, my null editing respected maxlag. It also started August 28
> and
> ended September 20.

maxlag has actually little relevance as a metric on the task you were doing...
(In reply to comment #3)
> The main issue seems to be MZMcBride's null editing at a rate way beyond even
> bot edit limits.

Can you please clarify how, in your opinion, the null editing retroactively caused a spike a month before its beginning? Thanks.
We dequeue Parsoid jobs in a throttled manner to avoid overloading the API during edit spikes. This means that abnormal edit rates especially to templates can create a large backlog of jobs in the Parsoid queue. This is then slowly processed over time. Since this is a separate queue this won't hold up other job queues.

The main issue seems to be MZMcBride's null editing at a rate way beyond even bot edit limits. Do we have a product for DoS attack detection and -mitigation?
For the record, my null editing respected maxlag. It also started August 28 and ended September 20.

The graph goes wild around July 29, which seems to correspond tightly with "16:44 logmsgbot: catrope synchronized wmf-config/InitialiseSettings.php 'Enable VE for anons on es/fr/he/it/pl/ru/svwiki; set dewiki back to opt-in mode'".
https://ganglia.wikimedia.org/latest/graph_all_periods.php?c=Miscellaneous%20pmtpa&h=hume.wikimedia.org&v=823574&m=Global_JobQueue_length&r=hour&z=default&jr=&js=&st=1365625056&z=large

06.11 < TimStarling> mostly parsoid
06.11 < TimStarling> ParsoidCacheUpdateJob: 2413680 queued; 611 claimed (12 active, 599 abandoned)
When a page has an image on the first line and the image caption contains a <center> tag or a <div align="..."> tag (where ... is "left", "right" or "center">, the right half of the VE toolbar (Beta, Page settings, Cancel and Save) are not visible. Obviously this means you cannot save any edits.

Curiously, <p align="center"> does not exhibit this problem.

Example from an article: https://en.wikipedia.org/w/index.php?title=Little_Tich&oldid=573770305

Minimal test case: https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox4&oldid=573786703

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54642
This was fixed some time ago, I believe; sorry for the very slow triage.
Because firefox converts path attributes to absolute URLs, the hashes don't match up, so VE pastes the plain-text equivalent content (empty string).

--------------------------
**Version**: unspecified
**Severity**: normal
Change 85213 merged by jenkins-bot:
Ignore all node attributes in clipboard hash

https://gerrit.wikimedia.org/r/85213
Change 85213 had a related patch set uploaded by Esanders:
Clipboard hash should ignore all node attributes

https://gerrit.wikimedia.org/r/85213
This was fixed in gerrit 90957.
The same also happens with Link annotation on MediaWiki.org and on Master.

Since the dataModel seems to change, and the problem *seems* to be in the ce.Surface not changing, I am in dire need of help. 

Based on advice from Roan, I've repeatedly checked the transaction history, and it shows a correct transaction on both meta/language annotation and link/mwInternal and link/mwExternal as it should, based on the annotation actions.

And yet, while the datamodel seems to be updated, the ce.Surface does not.
Following on from the reports at bug 51142 comments 5-9 

In every case where the last character of a link is non-alphanumeric and any text is inserted before that character. It seems that the underscore behaves as an alphanumeric character, and that script is irrelevant. It doesn't matter if the link was added in the current editing session or not.

e.g. [[Link|Link.]] → [[Link]]<nowiki />s[[Link|.]]
but [[Links]] → [[Linkers]] (this is the expected behaviour for all situations)

See https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox3&diff=573654600&oldid=573653290

If due to this a non-alphanumeric character that was previously mid-link but now becomes the last character of the link, adding any character before it triggers the bug again.

See https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox3&diff=573655981&oldid=573654600

In VE it is easy to include trailing punctuation (particularly commas and full stops) in a link without realising it (this is a side-effect of the WYSIWYG), meaning this occurs more often than might be expected (see comments at bug 51142).

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51442
Change 86235 merged by jenkins-bot:
Typing into an annotation next to a word break keeps annotation

https://gerrit.wikimedia.org/r/86235
btw, the <nowiki/> is inserted by Parsoid to make sure the document we have (<a>Foo/a>ish<a>?</a>) is translated properly into what the PHP parser understands as by default the PHP parser treats "<a> + adjecent text" as a shortcut to extend the lable (e.g. [[book]]s becomes <a href="book">books</a>).
Change 86235 had a related patch set uploaded by Esanders:
Typing into an annotation next to a word break

https://gerrit.wikimedia.org/r/86235
Yeah, this looks like an off-by-one error in the code for link annotations to not span "word break" characters.
You are right, Chris. I just thought VE could easily recognize cases in which punctuation could just be included by mistake, because the wikilink would be something like [[Fun.]], not [[Fun|Fun.]] .
In some cases the non-alphnumeric is desired - [[Fun.]], [[Westward Ho!]] and [[C++]] are cases that spring immediately to mind.

I think it is best that VE does what you ask it to, whether that is what you wanted or not. Anything typed in the middle of a link should be included in that link in all cases, which would make spotting that trailing punctuation is limited easier.
(I'd add that, at least for me, there is a desired outcome, which is that VE puts the non-alphanumeric character outside the link - of course, I am not sure this is doable or desirable, but this is why I had added my report to 51442.)
How to reproduce

1. Load any page in VE
2. Type any sequence of characters ending in one or more non-space characters followed by any non-alphanumeric character except space or underscore. For example: Foo?
3. Link what you have written, including the last character, to any target (e.g. [[Wikipedia]].
4. add any text immediately before the last character. eg. change Foo? to Fooish?
5. Save and look at the diff.

Expected wikitext:
[[Wikipedia|Fooish?]]

Actual wikitext:
[[Wikipedia|Foo]]<nowiki />ish[[Wikipedia|?]]

(In reply to comment #1)
> I think you mean bug 51442

I do. Dyslexia strikes again :(
I think you mean bug 51442
Current VisualEditor-Version:
commit c98a964d5f8495f0d16af9229abbeb0449042d1e
Merge: 3d01a5b e7aed52
Author: jenkins-bot <jenkins-bot@gerrit.wikimedia.org>
Date:   Wed Sep 18 01:11:46 2013 +0000
Merge "Fix check for preformatted when stripping whitespace"

Browser: Firefox 24.0 on Windows 7 64bit


Description:
I updated my VisualEditor via git yesterday. Before that I didnt update for 4 weeks. Now when openening a page on my MediaWiki in VE-Editmode I cant assign a page category (See screenshot).

I tried to debug with Firebug: When I click on categories the following error gets fired:

TypeError: style is null
http://XYZ/load.php?debug=false&lang=de&modules=ext.visualEditor.core%2Cdata%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=vector&version=20130919T072806Z&*
Line 9

--------------------------
**Version**: unspecified
**Severity**: blocker
Have split the new failure into bug 54928 and am re-closing this one.
(In reply to comment #7)
> This should be fixed in https://gerrit.wikimedia.org/r/#/c/85692 , which is
> in
> wmf19 but not in wmf18. enwiki is being upgraded from wmf18 to wmf19 today,
> hopefully that'll fix it.

That's the patch that closed this bug (comment 3). But it appears there is indeed a new bug that causes the page settings dialog to be broken again due to an uncaught exception when the dialog is first created when clicking the page settings button.


It fails in Chrome like this:

Uncaught TypeError: Cannot use 'in' operator to search for 'scrollTop' in undefined load.php?…:102
vendorPropName load.php?…:102
jQuery.extend.css load.php?…:105
Tween.propHooks._default.get load.php?…:136
Tween.cur load.php?…:136
Tween.init load.php?…:135
Tween load.php?…:135
Animation.deferred.promise.createTween load.php?…:131
tweeners.* load.php?…:129
(anonymous function) load.php?…:130
jQuery.extend.each load.php?…:8
createTweens load.php?…:130
Animation load.php?…:132
doAnimation load.php?…:137
jQuery.extend.dequeue load.php?…:25
(anonymous function) load.php?…:26
jQuery.extend.each load.php?…:8
jQuery.fn.jQuery.each load.php?…:4
jQuery.fn.extend.queue load.php?…:26
jQuery.fn.extend.animate load.php?…:138
ve.Element.scrollIntoView load.php?ext.visualEditor…:11
ve.Element.scrollElementIntoView load.php?ext.visualEditor…:12
ve.ui.OptionWidget.setSelected load.php?ext.visualEditor…:404
ve.ui.SelectWidget.selectItem load.php?ext.visualEditor…:400
ve.ui.PagedDialog.addPage load.php?ext.visualEditor…:458
ve.ui.MWMetaDialog.initialize load.php?ext.visualEditor…:461
ve.ui.Window.onFrameInitialize load.php?ext.visualEditor…:353
oo.EventEmitter.emit load.php?ext.visualEditor.bas…:133
ve.ui.Frame.load load.php?ext.visualEditor…:351
ve.ui.WindowSet.open load.php?ext.visualEditor…:356
ve.init.mw.ViewPageTarget.onToolbarMwMetaButtonClick load.php?ext.visualEditor.bas…:87
proxy load.php?…:10
jQuery.event.dispatch load.php?…:45
elemData.handle.eventHandle load.php?…:38
This should be fixed in https://gerrit.wikimedia.org/r/#/c/85692 , which is in wmf19 but not in wmf18. enwiki is being upgraded from wmf18 to wmf19 today, hopefully that'll fix it.
Confirmed:

* Working on latest master locally (Chrome).
* Broken on mediawik.org (Chrome).
It's still happening, unfortunately. Ed found out it works fine on local and mediawiki.org, though.

TeamGale mentioned this today at en.wp:
<<Just wanted to ask...how can we add categories with VE? In the past I could do it by clicking on "Page settings" but now when I click on it nothing happens! Is there somewhere else a button that adds categories? I searched everywhere but I can't find it. If it's still on the "Page settings" then something is not working right... Thanks TeamGale 09:54, 3 October 2013 (UTC)>>

Fram tested as well:

<<Tested this. FIrst click on "page settings" gives no results. Second click opens the page setting window. But I can't do anything there.>>

I can confirm that the second click just launches an empty window, with only the "categories" label text on the left column.

<<Actually this one with the categories is happening for a while for me. Just when I first found it I was in a hurry and couldn't leave a feedback. Then I totally forgot about it till now that I needed to use it again. It's weird that no one else mentioned it here before though.
Elitre, I don't know if it's a cache problem but I'll try to clean my cache again and re-test it. But the "after a few attempts" is still not right for me. Shouldn't this happening in the first attempt? TeamGale 10:12, 3 October 2013 (UTC)
Update: Nop, still happening the same for me even if I clean cache, cookies etc... TeamGale 10:20, 3 October 2013 (UTC)
Hmm...it seems to be only a Mozilla issue. I just tried it with Mozilla on Greek WP and it still doesn't work. But when I tested it on Google, it was working just fine. TeamGale 11:00, 3 October 2013 (UTC)>>
Problem solved. Tested with Firefox 24.0 on Windows 7 64BIT.
>> Page-settings dialog is operational and working.
Change 85692 merged by jenkins-bot:
ve.Element: Account for getComputerStyle returning null

https://gerrit.wikimedia.org/r/85692
Change 85692 had a related patch set uploaded by Krinkle:
ve.Element: Account for getComputerStyle returning null

https://gerrit.wikimedia.org/r/85692
I can confirm. When trying to open the Page settings dialog, an exception is thrown for "style is null":

ve.Element.js, line:
 		top = parseFloat( loc ? style.borderTopWidth : $el.css( 'borderTopWidth' ) ) || 0,

Context:
ve.Element.getBorders = function ( el ) {
	var doc = el.ownerDocument,
		win = doc.parentWindow || doc.defaultView,
		style = win && win.getComputedStyle ?
			win.getComputedStyle( el, null ) : el.currentStyle,
		loc = win && win.getComputedStyle ? true : false,
		$el = $( el ),
		top = parseFloat( loc ? style.borderTopWidth : $el.css( 'borderTopWidth' ) ) || 0,
Steps to reproduce bug:
1. Edit a page
2. Insert a transclusion, apply changes
# The transclusion is now selected (VE does this automatically for newly inserted nodes)
3. Type a characters
# Selected content is removed, text is inserted
4. Undo

The expected result is the text being replaced with the transclusion. Instead a pawn is inserted.

Upon further inspection I noticed that the transclusion isn't lost, however. In fact it is right there when you Undo again (after getting the pawn).

So it looks like the pawn was inserted as a transaction in the middle of removing the transclusion (its own transaction but not supposed to be?) and inserting the text.

We auto-select the template after insertion and it is relatively easy to accidentally press a key afterwards. And Undo then shows the user something scary (their template appears lost). A fairly high priority bug regarding user experience.

Not sure if this is a regression or not.

--------------------------
**Version**: unspecified
**Severity**: major
This is now fixed, AFAICS. Marking as such.
I did this in wmf7.
FYI, he conversation is now happening at https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Toolbar .
Conversation on the best order of the toolbar is continuing and is pretty thoughtful and indepth at the English VE feedback page. :)

Live link: https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Toolbar_button_priority_proposal

Permanent link to its current state:
https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=573642781#Toolbar_button_priority_proposal
My feelings are similar to John's on this.  We can't bury important buttons like references in a dropdown menu.  And, as John points out, for the english user base anyway, the options of underline and strikethrough are very rarely used.  New users are going to experiment with the options most prominently placed, these should be the most useful tools that would lead to a constructive (i.e. not reverted) edit.
Grouping commands under a "Text format" drop-down menu is a natural (obvious, intuitive) way to collect commands that are rarely used. For example, bolding of text, in articles, is typically done ONCE (in the lead paragraph, by the author of the article), and then never again. 

A "Text format" drop-down menu would take all of the following off of the main toolbar line, leaving space for (at the moment) everything else:

* Bold
* Italic
* Superscript
* Subscript
* Programming language 
* Underline
* Strikethrough
* Clear formatting

Putting all these under a single menu has the advantage of - in the future - allowing projects to control which options are visible in which namespaces. For example, on the English Wikipedia, strikethrough almost certainly should not be a (visible) user choice in mainspace (articlespace), nor should underlining. 

It's important, for SPEED, that frequently used functions are immediately accessible. Articles should have lots of footnotes, a fair number of templates (particularly for footnotes), and at least a couple of images. Putting the related commands into a drop-down menu, as opposed to having them directly on the toolbar, is undesirable: It makes VE less attractive to experienced editors (slower to use) and more difficult for new editors (because now they have to be instructed on, and remember, a TWO-step process (menu, select) rather than a one-step process (click), for important things like images and footnotes.
User Pointillist on the English Wikipedia has some really interesting ideas on this subject, posted here: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=573508478#Toolbar_button_priority_proposal

Without all the very useful images, he writes (please pardon my clumsy textual effort to reproduce his proposal and check out the link to see it the way it should look):

Summary: as discussed above and in bug 54271, the sequence of buttons in the toolbar isn't appropriate for typical article editing activities.

The current toolbar gives too much priority to hard-coded formatting such as Bold, Italic, Lists and Indents. As a result:
* The most important buttons (e.g. for referencing) are pushed into a secondary position and may even be forced onto the "More" drop-down
* Wikilinking is incorrectly associated with formatting
* Formatting buttons are divided between the left-end of the toolbar and the "More" drop-down
* It isn't immediately clear what "More" is offering


I propose that article content buttons should be at the left end and formatting should be at the right end of the toolbar, so something like this:
[Undo * Redo * Link * Media * Reference * References * Template * Equation * Paragraph * Clear formatting * Bold * Italic * Superscript * Subscript * Programming language * Unordered list * Ordered list * Reduce indent * Increase indent]

If "More" is necessary, it would probably be inserted into the formatting buttons, and the users would expect to find more of them in the drop-down, like this:
[Undo * Redo * Link * Media * Reference * References * Template * Equation * Paragraph * Clear formatting * Bold * Italic * Superscript * More]

Of course, this is only a starting point. By the way: underscore and strikeout shouldn't be formatting options in the article space, "Page title" isn't necessary as a paragraph style. Thoughts?
I thought there was a bug for this, but I can't find it...

Warning:  Recursion detected in RequestContext::getLanguage in /usr/local/apache/common-local/php-1.22wmf16/includes/context/RequestContext.php on line 281


The amount of the warnings seems to have increased a lot more in wmf16/wmf17

Such occurrences and stracktraces can be found in logstash with `_type: mediawiki` and `channel: recursion-guard`.
No events logged in the recursion-guard channel since December 2016.
Change 273586 merged by jenkins-bot:
Fix 'localpage' message handling

[[https://gerrit.wikimedia.org/r/273586]]
Change 273586 had a related patch set uploaded (by Anomie):
Fix 'localpage' message handling

[[https://gerrit.wikimedia.org/r/273586]]
>>! In T56193#2068539, @Mattflaschen wrote:
> P2680

> 16 0.8985 8361744 Message->isDisabled( ) ../TitleBlacklist.list.php:98

WTF are you doing there, TitleBlacklist?
P2680
Got this locally on MediaWiki-Vagrant.
>>! In T56193#1926036, @mmodell wrote:
> @bd808: do you think there is any value in keeping this error message?  It seems to me like it's expected behavior at this point and not really valuable.

Disabling the log message has been proposed as a patch before (<https://gerrit.wikimedia.org/r/#/c/102557/>) and @TStarling at that time wanted the message to stay until the underlying bug was fixed.
@bd808: do you think there is any value in keeping this error message?  It seems to me like it's expected behavior at this point and not really valuable.
>>! In T56193#1603723, @Southparkfan wrote:
> Seems to not be Wikimedia-only, I experience this error too:

This looks to be a variant on one of the patterns noted in T56193#554201:
* getLanguage() → Log in from cookies → User::isUsableName() → Message → getLanguage()

In this particular case, the `wfMessage()` call is going to be rendered using the `inContentLanguage()` method but before it can get that far the Parser wants to know the User's language.

The statement of "It should be a pretty simple change for Brad or Chris." in T56193#554221 has thus far proved to be a variant on [[https://en.wikipedia.org/wiki/Fermat's_Last_Theorem|Fermat's Last Theorem]]. Many people have looked for the proof but none have yet been able to provide one.
That is still hitting us, stracktraces can be found in logstash with _type: mediawiki and channel: recursion-guard.

Is anyone working on it?
Change 174057 abandoned by Umherirrender:
Avoid calling Title::makeTitleSafe in User::idFromName

Reason:
Old branch, proper fix already in master (Ib902573996c69d1e77527cc7b2faf4e7fa5d3daf)

[[https://gerrit.wikimedia.org/r/174057]]
Change 174057 had a related patch set uploaded by Ori.livneh:
Avoid calling Title::makeTitleSafe in User::idFromName

https://gerrit.wikimedia.org/r/174057
Change 174051 merged by jenkins-bot:
Avoid calling Title::makeTitleSafe in User::idFromName

https://gerrit.wikimedia.org/r/174051
Change 174051 had a related patch set uploaded by Ori.livneh:
Avoid calling Title::makeTitleSafe in User::idFromName

https://gerrit.wikimedia.org/r/174051
(In reply to Tim Starling from comment #17)
> Looks like bug 41201 again ("UserLoadFromSession considered evil"). I
> probably should have pushed that one a bit harder during the CA2 sprint. It
> should be a pretty simple change for Brad or Chris.

Is it?
Looks like bug 41201 again ("UserLoadFromSession considered evil"). I probably should have pushed that one a bit harder during the CA2 sprint. It should be a pretty simple change for Brad or Chris.
Hiding the warning in fatal monitor with Gerrit change #102557 - the stacktrace logging is still on
So the problem generally appears to be that Language::getLanguage() unstubs the User object by trying to fetch the 'language' pref, and the various hooks called during that process may themselves wind up doing something that tries to call Language::getLanguage(). There are also some instances where something hooking 'UserGetLanguageObject' tries to call getLanguage().

Code paths I see in a quick look through the log include:
* getLanguage() → Log in from cookies → Trying to get the localized alias for NS_USER on wikis with variants → getLanguage()
** This seems to be a large number of the instances: srwiki, uzwiktionary, kuwiktionary, etc.
* getLanguage() → Autocreate account → AbuseFilter's checkNewAccount hook → dividebyzero → Trying to get localized error message → getLanguage()
** enwiki and eswiki have this
* getLanguage() → ULS's getLanguage hook → User::saveOptions → BetaFeatures's hook on UserSaveOptions → VisualEditor's onGetBetaPreferences hook or VectorBeta's prefs hook → getLanguage()
* getLanguage() → Autocreate account → User::saveOptions → BetaFeatures's hook on UserSaveOptions → VisualEditor's onGetBetaPreferences hook or VectorBeta's prefs hook → getLanguage()
* getLanguage() → Autocreate account → TitleBlacklist hit → Trying to get localized error message → getLanguage()
* getLanguage() → Autocreate account → NewUserMessage::createNewUserMessage → various different code paths involving the parser and/or MessageCache → getLanguage()

I think that the fallback behavior added in Gerrit change 48080 is probably the best thing to do in general.

BTW, the previous bug on this topic was probably bug 44754.
(In reply to comment #12)
> What a scary backtrace. It seems to relate on automatic creation of local
> accounts interacting with abuse filter. No wonder it seems to only happen in
> production.
> 
> I have no idea how to fix this. Perhaps automatic local account creation
> should
> happen somewhere else?

cc Anomie
Given the backtrace, this does not seem to be an i18n issue, except for that the class (Stub)Language is involved at one level. Reclassifying and updating CCs accordingly. Niklas and I will stay on CC.
What a scary backtrace. It seems to relate on automatic creation of local accounts interacting with abuse filter. No wonder it seems to only happen in production.

I have no idea how to fix this. Perhaps automatic local account creation should happen somewhere else?
(In reply to comment #6)
> Would it be possible to provide more information about which wiki(s) display
> this behavior, or possibly even page(s)? Being able t reproduce this would
> probably go a long way towards resolving it.

I added a trace; additional ones are available in fluorine:/a/mw-log/recursion-guard-stack-trace.log. If you want me to grab additional ones, let me know.

(In reply to comment #7)
> Side note: the logs this information is extracted from, could we make those
> more widely available so they could get more eyeballs? From my experience
> doing this at translatewiki.net it often helps in identifying issues a lot
> earlier.

Yeah, fair point. We (platform & ops) are working on setting up a better platform for log analysis, probably using logstash. The current situation sucks.
Created attachment 13858
stack trace from fluorine:/a/mw-log/recursion-guard-stack-trace.log

**Attached**: {F11344}
Change 96709 merged by Ori.livneh:
Enable recursion-guard log bucket to investigate bug 54193

https://gerrit.wikimedia.org/r/96709
Change 96709 had a related patch set uploaded by Ori.livneh:
Enable recursion-guard log bucket to investigate bug 54193

https://gerrit.wikimedia.org/r/96709
Side note: the logs this information is extracted from, could we make those more widely available so they could get more eyeballs? From my experience doing this at translatewiki.net it often helps in identifying issues a lot earlier.
Would it be possible to provide more information about which wiki(s) display this behavior, or possibly even page(s)?

Being able t reproduce this would probably go a long way towards resolving it.
>200 of these every hour in /a/mw-log/apache2.log
Every 2.0s: tail -n 1000 /home/wikipedia/syslog/apache.log | grep -v 'Search backend error' | grep -v -i 'swift' | grep 'PHP\|Segmentation ...  Tue Nov 12 22:33:46 2013

    240 Warning:  Recursion detected in RequestContext::getLanguage in /usr/local/apache/common-local/php-1.23wmf3/includes/context/RequestContext.php on line 284
     72 Warning:  Recursion detected in RequestContext::getLanguage in /usr/local/apache/common-local/php-1.23wmf2/includes/context/RequestContext.php on line 284
Yup, there are these warnings almost always shown in the last 1000 lines of the apache syslogs
Sam, are these still being observed, or have they gone away?
I can't do anything about this without a backtrace. Not sure how to mark that.
e.g. Template:Information could be documented at TemplateData:Information instead of inside the source code of Template:Information.

Pros:

%%%1. More standard use of ContentHandler for JSON across projects
2. Document templates without needing to make edits to templates that are potentially transcluded across large swaths of pages
3. Easier to implement custom editors for ContentHandler pages than for portions of wikitext pages.%%%

Cons:

%%%1. Would need to have two separate systems - one for the JSON storage, then another to transclude the generated documentation onto template doc pages, e.g. with <templatedata /> or {{#templatedata}} or so (no params needed, because the TemplateData namespace page can be of the same name, like a talk page)
2. Would need to rework the existing editor (sorry, mooeypoo) to work with the new system%%%

--------------------------
**See Also**: {T52512}
This could be held like doc subpages or currently deployed css subpages instead
I do raise two issues against the proposal, at least for mandatory evaluation of JSON pages only.
* Pro #2 reads as: “Document templates without needing to make edits to templates that are potentially transcluded across large swaths of pages”
** This goes for any kind of lengthy documentation, and is usually solved by transclusion of a separated ##/doc## into main template page.
** German Wikipedia is using that technique for any longer template documentation since 2008, and enforces TemplateData on separated docpage for all productive templates.
* There are JSON objects built by template-like transclusion via ##{{#tag:}}## syntax.
** See [[https://de.wikipedia.org/wiki/Kategorie:Vorlage:Metadokumentation | Kategorie:Vorlage:Metadokumentation]] on German Wikipedia – a dozen of so-called “meta documentation” pattern pages is generating nearly thousand TemplateData objects on particular template pages, controlled by template name and sommetimes parameters.
Optional separated ##.json## subpages may be introduced, but classic ##<templatedata>## approach needs to be supported, too.
I've fiddled with this because either {T487} or {T107595} would both meet this need. I think the latter is both more likely to occur and a better outcome, but…
Re-wording; this is blocked by https://www.mediawiki.org/wiki/Requests_for_comment/Associated_namespaces being implemented.
See also:
https://www.mediawiki.org/wiki/Requests_for_comment/Associated_namespaces#Use_case_2b:_Structured_template_documentation
I talked about that briefly on IRC, we decided that since this is specifically about the namespace proposal, until we decided what to do about it, we'd leave both open. And closing that bug may not necessarily close this bug.
Is this a dupe of https://bugzilla.wikimedia.org/show_bug.cgi?id=50512#c0 ?
When requesting random images from Commons' MediaWiki API and requesting a thumbnail for it, I often get a HTTP 500.

For example:



GET http://upload.wikimedia.org/wikipedia/commons/thumb/f/fb/USMC-05934.jpg/400px-USMC-05934.jpg
HTTP 500
<html><head><title>Error generating thumbnail</title></head>
<body>
<h1>Error generating thumbnail</h1>
<p>
Error creating thumbnail:
</p>
<!-- http://commons.wikimedia.org/w/thumb_handler.php/f/fb/USMC-05934.jpg/400px-USMC-05934.jpg -->
<!-- mw1154 -->
</body>
</html>

Usually when trying again, it just works.

I've been getting these errors in many different environments:
* When reading articles and HiDPI plugin swaps the src attributes (the larger version would fail maybe)
* When opening the VisualEditor (rendering the new DOM means we re-parse the <img>tag and thus re-request it, thus making it more likely for the error to happen again)
* When working with gadgets that render image galleries through requesting file category members and the thumbnail url.

I don't think the scenario is relevant, there is either something wrong with the thumbnail generator script that is triggered by lots of images. Or there is a few faulty servers in the upload.wikimedia.org pool that cause the errors.

--------------------------
**Version**: wmf-deployment
**Severity**: critical
[02:06:08] <Reedy> Can someone depool mw1154 from the image scaler cluster?
[02:06:20] <paravoid> what's wrong with it?
[02:07:40] <Reedy> It's seemingly generating a lot more errors (by a factor of 2 or so) than any of the other scalers
[02:07:41] <Reedy> https://bugzilla.wikimedia.org/show_bug.cgi?id=54045
[02:08:32] <paravoid> root@mw1154:~# ls /sys/fs/cgroup/memory/mediawiki/job
[02:08:33] <paravoid> ls: cannot access /sys/fs/cgroup/memory/mediawiki/job: No such file or directory
[02:08:35] <paravoid> blergh
[02:09:01] <paravoid> fixed
[02:09:58] <Reedy> is that's what's up with it?
[02:10:05] <paravoid> yes, fixed
[02:10:09] <Reedy> awesome
[02:10:10] <Reedy> thanks
Yup, still mw1154


reedy@fluorine:/a/mw-log$ grep -c mw1153 thumbnail.log
50057
reedy@fluorine:/a/mw-log$ grep -c mw1154 thumbnail.log
125850
reedy@fluorine:/a/mw-log$ grep -c mw1155 thumbnail.log
50451
reedy@fluorine:/a/mw-log$ grep -c mw1156 thumbnail.log
50584
reedy@fluorine:/a/mw-log$ grep -c mw1157 thumbnail.log
51015
reedy@fluorine:/a/mw-log$ grep -c mw1158 thumbnail.log
50386
reedy@fluorine:/a/mw-log$ grep -c mw1159 thumbnail.log
50134
reedy@fluorine:/a/mw-log$ grep -c mw1160 thumbnail.log
51486
Ganglia graphs suggest so (mw1154 has less activity) but I haven't specificly tested.
Part of the question would be is it still the same machine? (based on the fact it's already changed once)
Could this server be taken out of rotation until the issue is resolved?
Btw, good debugging step would be for someone with shell to try running the convert command by hand (with limit.sh) to see what happens (e.g. if issue with cgroup config this would give an error that wouldn't be included in thumb log)

See also gerrit change 83974 which would give more useful error messages in certain circumstances (which may or may not help for the current situation)
*** Bug 54188 has been marked as a duplicate of this bug. ***
(In reply to comment #5)
> reedy@fluorine:/a/mw-log$ grep mw1154 thumbnail.log |grep -c error
> 55424
> reedy@fluorine:/a/mw-log$ grep -c mw1154 thumbnail.log
> 111320

We pass things with \n's in them to wfDebugLog for the thumbnail log. I don't think we log successful thumbnailing events at all. So I think all that means is many of the thumbnail error log messages span several lines.
When you look at the 500 error message, its supposed to include all the stdout and stderr from convert. However these are empty. Perhaps https://gerrit.wikimedia.org/r/83974 would help debug the situation (including stderr from limit.sh in the 500 error message).
reedy@fluorine:/a/mw-log$ grep mw1154 thumbnail.log |grep -c error
55424
reedy@fluorine:/a/mw-log$ grep -c mw1154 thumbnail.log
111320
I just did a test on commons - visited a page with 200 images which I suspect were not previously rendered before (note: all were tiff files). 28 of them failed, all from mw1154. There's only 8 image scalars. 200/8 = 25, so its not hard to imagine this means all requests to mw1154 are failing.

Perhaps something is wrong with the cgroups config on that host (or something else that would prevent all shell commands from succeeding)

The ganglia graph seems to indicate that the CPU usage on that host has dropped off since friday - http://ganglia.wikimedia.org/latest/graph.php?g=cpu_report&z=xlarge&c=Image%20scalers%20eqiad&h=mw1154.eqiad.wmnet&l=e2ecff&v=&r=week&su=1&st=1378942982&x=0&n=0
Looks like mw1153 has stopped being so noisy, and it's now mw1154. Which I guess makes this a dupe of 53753

reedy@fluorine:/a/mw-log$ grep -c error thumbnail.log
324850
reedy@fluorine:/a/mw-log$ grep mw1153 thumbnail.log |grep -c error
22013
reedy@fluorine:/a/mw-log$ grep mw1154 thumbnail.log |grep -c error
54280
reedy@fluorine:/a/mw-log$ grep mw1155 thumbnail.log |grep -c error
22011
reedy@fluorine:/a/mw-log$ grep mw1156 thumbnail.log |grep -c error
21980
reedy@fluorine:/a/mw-log$ grep mw1157 thumbnail.log |grep -c error
21847
reedy@fluorine:/a/mw-log$ grep mw1158 thumbnail.log |grep -c error
22146
reedy@fluorine:/a/mw-log$ grep mw1159 thumbnail.log |grep -c error
21905
reedy@fluorine:/a/mw-log$ grep mw1160 thumbnail.log |grep -c error
22107
Always mw1154?

See also bug 53573, mw1153 was (not sure if it's changed) seemingly causing a lot more errors than its counterparts
See also bug 53573. (which was mostly mw1153)
-----
>I don't think the scenario is relevant, there is either something wrong with
>the thumbnail generator script that is triggered by lots of images. Or there is
>a few faulty servers in the upload.wikimedia.org pool that cause the errors.

Thumbnail generation should be entirely independent of page view actions, so the scenario should definitely not matter
Change 142320 merged by jenkins-bot:
Set wgGitInfoCacheDirectory to point to scap managed location

https://gerrit.wikimedia.org/r/142320
Yay, thanks Bryan.
Change 142319 merged by jenkins-bot:
Fix GitInfo cache file path computation and storage location

https://gerrit.wikimedia.org/r/142319
Change 142320 had a related patch set uploaded by Krinkle:
Set wgGitInfoCacheDirectory to point to scap managed location

https://gerrit.wikimedia.org/r/142320
Change 142319 had a related patch set uploaded by BryanDavis:
Fix GitInfo cache file path computation and storage location

https://gerrit.wikimedia.org/r/142319
(In reply to Bryan Davis from comment #18)
> I'll spend some more time looking into why $IP isn't what I
> (and the paths inside $wgExtensionCredits) think it should be.

Today I learned that WebStart.php clears $IP and then recreates it from the first of the MW_INSTALL_PATH environment variable, `realpath( '.' )` or `dirname( __DIR__ )`. In beta, the realpath branch wins and sets $IP to '/srv/common-local/php-master'.
So when I echo $IP from `mweval` in beta I get /srv/common-local/php-master but apparently inside Apache $IP is /usr/local/apache/common-local/php-master. The latter is a symlink to former. This difference is causing GitInfo::getCacheFilePath() to compute the wrong path for the cache file. I'll spend some more time looking into why $IP isn't what I (and the paths inside $wgExtensionCredits) think it should be.
I'm looking into this again and still can't figure out why http://en.wikipedia.beta.wmflabs.org/wiki/Special:Version isn't displaying the git SHA1 for extensions now.

Debugging using `mwscript eval.php --wiki=enwiki` on deployment-apache01 and deployment-apache02 shows that GitInfo can read the precomputed git information there:

    > $wgDebugLogGroups = array(); $wgDebugLogFile = 'php://stdout';
    > $gitinfo = new GitInfo($IP); $coreId = $gitinfo->getHeadSHA1();
    > $cache = wfGetCache( CACHE_ANYTHING );
    > $path = "$IP/extensions/VisualEditor/VisualEditor.php";
    > $memcKey = wfMemcKey( 'specialversion-ext-version-text', $path, $coreId );
    > echo $memcKey;
    enwiki:specialversion-ext-version-text:/srv/common-local/php-master/extensions/VisualEditor/VisualEditor.php:49952a405014c89b239da3bcaea158c47faf8251
    > var_dump( $cache->get( $memcKey ) );
    enwiki-bca38539: 649.4035  25.8M  [memcached] get(enwiki:specialversion-ext-version-text:/srv/common-local/php-master/extensions/VisualEditor/VisualEditor.php:49952a405014c89b239da3bcaea158c47faf8251)
    enwiki-bca38539: 649.4047  25.8M  [memcached] result: NOT FOUND
    bool(false)

    > $gitinfo = new GitInfo( dirname( $path ) );
    > echo $gitinfo->getHeadSHA1();
    fefd3a5d72c118993cc555f0a53a561f58a5fd19
    > echo $gitinfo->getHeadViewUrl();
    https://git.wikimedia.org/commit/mediawiki%2Fextensions%2FVisualEditor.git/fefd3a5d72c118993cc555f0a53a561f58a5fd19
    > echo $gitinfo->getHeadCommitDate();
    1400528579

I've verified that apache is running as the user "apache" on these nodes and that apache can read the *info.json files. The output of `eval.php` above shows that the php code is functional when executed from the cli. At this point I'm unable to understand why this output differs from SpecialVersion::getCreditsForExtension(). I'm sure I'm missing something in my analysis but I'm at a loss for what it is.
Still not seeing data in Special:Version. There must be something that I'm not understanding about the environment. I can get the info via eval.php as shown above.
I put a temporary hack in place on the beta nodes that run MediaWiki (apache0[12], jobrunner01, and videoscaler01) by symlinking $wgCacheDirectory/gitinfo to $IP/cache/gitinfo. This should make the git version data visible on the Special:Version page the next time that the MW-Core hash changes (memcache cache buster).

    deployment-apache01:~
    bd808$ mwscript eval.php --wiki=enwiki
    > var_dump( $gi = new GitInfo( "$IP/extensions/VisualEditor" ) );
    object(GitInfo)#113 (3) {
      ["basedir":protected]=>
      NULL
      ["cacheFile":protected]=>
      string(62) "/tmp/mw-cache-master/gitinfo/info-extensions-VisualEditor.json"
      ["cache":protected]=>
      array(6) {
        ["head"]=>
        string(40) "0496bd84506927039958cc683a35a5e3b5da2584"
        ["remoteURL"]=>
        string(70) "https://gerrit.wikimedia.org/r/p/mediawiki/extensions/VisualEditor.git"
        ["branch"]=>
        string(40) "0496bd84506927039958cc683a35a5e3b5da2584"
        ["headCommitDate"]=>
        string(10) "1399417572"
        ["headSHA1"]=>
        string(40) "0496bd84506927039958cc683a35a5e3b5da2584"
        ["@directory"]=>
        string(44) "/a/common/php-master/extensions/VisualEditor"
      }
    }
Patches are merged, but not sufficient. I didn't look into the value of $wgCacheDirectory in operations/mediawiki-config.git. In beta and the prod cluster we set the cache directory to a location outside of $IP rather than $IP/cache as I expected/coded the scap side to this change for.

I'll either need to add a new global to set/change the location where GitInfo looks for the cache or add yet another scap step to copy the generated files around to adjust for this.
Change 130560 merged by jenkins-bot:
Precompute data for GitInfo

https://gerrit.wikimedia.org/r/130560
Change 130498 merged by jenkins-bot:
Support precomputed data in GitInfo

https://gerrit.wikimedia.org/r/130498
Change 130560 had a related patch set uploaded by BryanDavis:
Precompute data for GitInfo

https://gerrit.wikimedia.org/r/130560
Change 130498 had a related patch set uploaded by BryanDavis:
Support precomputed data in GitInfo

https://gerrit.wikimedia.org/r/130498
I'm working on a fix for this problem by adding a step to scap that precomputes the information needed by GitInfo.php to json files that can be synced to the apaches. This would fix the path change issue and should slightly reduce runtime cost of Special:Version and other pages that use GitInfo. It would also allow us to drop syncing of the .git directories all together if we wanted.
(In reply to Bryan Davis from comment #2)
> I can't find any reason by grepping in operations/puppet that the general
> mw* nodes would have /a and/or /a/common created but /a/common exists as an
> empty directory on all of them that I randomly sampled.

I eventually found the puppet code that creates /a/common as an empty directory on many hosts. The misc::deployment::vars class which in included from the misc::deployment::scap_scripts class creates the directory if it doesn't exist [0].

[0]: https://github.com/wikimedia/operations-puppet/blob/c5b8fa0631d3b28b6ca062e313b98e80d7325d80/manifests/misc/deployment.pp#L368-L374
(In reply to James Forrester from comment #6)
> Could we just have scap re-write the .git files (or have them be relative
> and not absolute in the first place)?

Having them be relative in the first place would really be nicest. Do we have a git guru who could look into that?

I had the same idea about rewriting the .git files as a scap step. It shouldn't be too hard to do. Because of the way that scap works right now we'd need to do this on each host as a post-update step similarly to the way that the l10n JSON intermediate files are recompiled into CDB files.
Could we just have scap re-write the .git files (or have them be relative and not absolute in the first place)?
This bug affects the beta environment now that scap is being used to deploy code there. The ideas for creating symlinks to restore the scame directory structure that is used on the deploy host (deployment-bastion.eqiad.wfmlabs) make even less sense in beta. Here's an example .git file from an extension there:

    gitdir: /mnt/srv/scap-stage-dir/php-master/extensions/.git/modules/MultimediaViewer
*** Bug 62760 has been marked as a duplicate of this bug. ***
*** Bug 53070 has been marked as a duplicate of this bug. ***
(In reply to Krinkle from comment #0)
> I'm not sure what the semantic meaning is of these directories (/a/ seems to
> be an existing but unused directory on all hosts other than tin).

/a/common is the rsync server source directory on tin for scap. This directory is used to prepare the files that will be pushed out by scap to the members of the /etc/dsh/group/scap-proxies group and then subsequently to the rest of the cluster.

The misc::deployment::vars puppet class ensures that this directory is created on all hosts where the misc::deployment::scap_scripts puppet class is applied. The misc::deployment::scap_scripts class is applied directly to arsenic, hume, terbium, and tin in site.pp. It's also applied indirectly on the snapshot* servers by the mediawiki::sync class.

I can't find any reason by grepping in operations/puppet that the general mw* nodes would have /a and/or /a/common created but /a/common exists as an empty directory on all of them that I randomly sampled. It seems like it should be possible to add some puppet config (maybe in role::applicationserver::webserver?) to ensure that the /a directory is created and then symlink /a/common to /usr/local/apache/common.
(In reply to comment #0)
> I'm not sure what the semantic meaning is of these directories (/a/ seems to
> be
> an existing but unused directory on all hosts other than tin).

fluorine
On translatewiki.net during running repoupdate script: Randomly the script bails out with

hash mismatch
key_verify failed for server_host_key
fatal: The remote end hung up unexpectedly
error: Could not fetch origin

This happens since migration of Gerrit to the new server two days ago.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
<3
The fix has been deployed at gerrit.wikimedia.org.
Change 143388 merged by Chad:
Upgrade sshd to include the fix for hash mismatch

https://gerrit.wikimedia.org/r/143388
I have upgraded Gerrit on my test instance integration-dev.eqiad.wmflabs . There is no more any hash mismatch triggered when running for a while:

while true; do ssh -p 29418 localhost; done;
(In reply to Antoine "hashar" Musso from comment #25)
> Christian could you possibly providee a gerrit.war  that has the patch ?

Sure. For the next 2 weeks, you can fetch it from

  http://quelltextlich.at/gerrit-2.8.1-4-ga1048ce.war

> I
> would like to test it out on the labs instance I am using for CI dev.

Seeing the description of SSHD-330 allowed me to come up with an environment
that allows to reproduce the bug. There, our deployed gerrit war failed for
14 of 10000 connection attempts. The war I linked above showed 0 failures for
10000 connection attempts.

^d already said he'll discuss deploying the war with greg-g. So we'll
hopefully see it live soon.
Christian could you possibly providee a gerrit.war  that has the patch ? I would like to test it out on the labs instance I am using for CI dev. Thanks!
Change 143388 had a related patch set uploaded by QChris:
Upgrade sshd to include the fix for hash mismatch

https://gerrit.wikimedia.org/r/143388
The description of the SSHD-330 issue explains pretty much every aspect of
the bug that we experienced.

From it's sporadic nature to the ways some people could reproduce, but others
couldn't.

I'll see to preparing a new gerrit release ... hopefully we can get something
deployed around that.
The google group topic mentioned this issue in Apache mina-sshd (upstream from Gerrit):

https://issues.apache.org/jira/browse/SSHD-330

Which has been fixed in https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=commit;h=2aed686bdb21681a421033c6ee5997e5cd8a9a83

If that is indeed the root issue, we them to make a minor release and Gerrit to upgrade to it.
**paul.bourke** wrote:

Hi, I've been able to reproduce this on a local Gerrit instance quite reliably by running the following:

while true; do ssh <gerrit> -p 29418; done

A workaround that does work is to use the bouncy castle SSL library.  See the following thread for more info: https://groups.google.com/forum/#!topic/repo-discuss/JE7OM6o7DMs
Bartosz: there is no need more for more examples.  We have traces of those errors in Zuul log and it happens a couple time per day.

Marcin: we could tcpdump it if only we had a way to reliably reproduce the issue :-(
Two examples from just today:
* https://gerrit.wikimedia.org/r/#/c/139807/
* https://gerrit.wikimedia.org/r/#/c/140046/
Today again: https://gerrit.wikimedia.org/r/#/c/139047/
Could somebody tcpdump it? It seems it me more like a broken (suddenly terminated) connection, probably occuring (mostly) early in the SSH negotiation phase.
Subsided for a while, then started happening a bit more often for me locally. Example in Gerrit from today: https://gerrit.wikimedia.org/r/#/c/138992/1
This continues to happen, nearly daily.

You could probably get a good list of affected changesets by grepping logs of #wikimedia-dev for my name and "ignore jenkins" :/
Another example, this time with the job that sync VisualEditor in mediawiki/extensions.git.  The merge of https://gerrit.wikimedia.org/r/#/c/111608/ triggered job http://integration.wikimedia.org/ci/job/mwext-VisualEditor-sync-gerrit/61/console which shows:

  ssh -i /var/lib/jenkins/.ssh/jenkins-mwext-sync_id_rsa \
    -p 29418 jenkins-mwext-sync@gerrit.wikimedia.org \
    'gerrit review --code-review +2 --verified +2 --submit b519550809bba725b017281fe6c33c4c2fd123c1'
  hash mismatch
  key_verify failed for server_host_key
(In reply to comment #12)
> Is this related: https://gerrit.wikimedia.org/r/#/c/107036/ ?

Looking at Zuul debugging log on gallium.wikimedia.org it is a different issue. Filled another bug 59991 for it. Seems to be an issue in the python git module.
Is this related: https://gerrit.wikimedia.org/r/#/c/107036/ ?
Also got one today in command line.

FYI: the -1s in Jenkins caused by this are very confusing.
That does happen once or two per day on Zuul. Usually "hash mismatch" errors though we had some host key verification failed on Nov 20th.
*** Bug 57483 has been marked as a duplicate of this bug. ***
Just happened to me w/operations/puppet.

$ git pull
hash mismatch
key_verify failed for server_host_key
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
(Worked for me when I tried again)
Several reports of this in the last few days. Reporters include Krenair, YuviPanda, and Krinkle.
Still seeing this error randomly.
(In reply to comment #2)
> We changed IP addresses when moving servers (shouldn't have to ever happen
> again), so please check your known_hosts for any outdated entries that you
> can remove.

How can I identify outdated entries? There are no IP addresses in known_hosts. Sample entry:

 |1|umKi+qzw6pf8uXi/Z6/KtqlisCw=|YFoX/CdDjXhcVUVJ803EiP9nyro= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA2JmNg8ir9QvWwmS/C2k0PEqty1O26D0Nq24YGKC5jq1cr/0a92Pk7wa9FMMM/2O88bbe6rXZUPBKzDX1vVtYD+5vR4/c1XTnHWlNJ9sd6xSYjHhznqYs81VnjGMCLMPV1GhlIfUZsnQ+
w1FaQUvJe39TEtwADA7ZOFAfT0M/Oqk=
So, this sounds like you've got an old entry in your known_hosts files pointing to the old box.

We changed IP addresses when moving servers (shouldn't have to ever happen again), so please check your known_hosts for any outdated entries that you can remove.
We retained the same key for exactly this reason...
The Multimedia team has come up with this framework, wrapped in an extension, for experimental features. It's part of our rollout plan to get it on test2 and mediawiki.org, so we can also start deploying extensions that use its framework.

VisualEditor, Multimedia, Mobile, and E2 are all planning on using this framework in the coming quarter to gate features they aren't ready to release on an opt-out basis.

Please review for security and performance (in particular the update jobs for user counts may be tricky for the latter) and add it to the extensions enabled on mediawiki.org and test2.

Thanks!

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/Extension:BetaFeatures
We deployed to MediaWiki.org already. We were trying to deploy VectorBeta yesterday, but as you said, it crapped out - hence, bug 55749 stays open but this one got closed (and should have been closed much earlier)
Because this was supposed to happen yesterday, but the servers crapped themselves. I think the new deployment date is Monday.
Why is this bug marked fixed?
Ready to deploy.
Adding dependencies - we're not deploying BF until the three listed extensions are also deployable. We're hoping that'll happen by Thursday morning.

AWAY!!!!
Security fixes in https://gerrit.wikimedia.org/r/86023 should close the review portion of this bug - ready for deployment.

We'll discuss deployment strategy after that patch is merged and we have a better idea of what we want out of it.
Design review is done - security review only remaining review.

== TODO/Check list ==
Extension page on mediawiki.org: yes 
Bugzilla component: yes
Extension in Gerrit: yes
Design Review: yes
Archeticecture/Performance Review: yes
Security Review: no
Screencast (if applicable): N/A
Community support: I believe so
Reedy did architecture/performance review. Chris will be doing security review sometime early next week. Design review is being finalized as we speak.

We'll be rolling this out in tandem with a bunch of other changes, so the deployment won't happen right away, and it will happen in stages (like Notifications, basically).
Hello, this is a quasi-automated-but-not-really message:

I am reviewing all tracking bugs for extensions to review and deploy to WMF servers. See the list here:
https://bugzilla.wikimedia.org/showdependencytree.cgi?id=31235&hide_resolved=1

The [[mw:Review queue]] page lists the steps necessary to complete the review. I have copied them below and done some initial filling out based on what I can easily gleen from this bug and any linked to sources that are obvious. If I miss something/state something false, please do correct me.

Also, if you haven't yet done so, please review the information on and linked to from:
https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment


== TODO/Check list ==
Extension page on mediawiki.org: yes 
Bugzilla component: yes
Extension in Gerrit: yes
Design Review: yes
Archeticecture/Performance Review: no
Security Review: no
Screencast (if applicable): no
Community support: I believe so
https://gerrit.wikimedia.org/r/#/c/82796/ - sha1: 8587e2e4b4f90ca9cdba0f39e647b235921a5ae8

Missing on git.wm.o, gerrit, github:

https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FMassMessage.git

https://github.com/wikimedia/mediawiki-extensions-MassMessage/commits/master 

km-mpb:~ km$ git clone ssh://legoktm@gerrit.wikimedia.org:29418/mediawiki/extensions/MassMessage.git
Cloning into 'MassMessage'...
[snipped]
Checking connectivity... done
km-mpb:~ km$ cd MassMessage/
km-mpb:MassMessage km$ git log --oneline
85283ca Localisation updates from http://translatewiki.net.
b9ccd1c Autocomplete suggestions for spamlist input
3027dc6 Localisation updates from http://translatewiki.net.
8d106e1 Localisation updates from http://translatewiki.net.
[snipped]

Luckily this is a pretty minor change, so I can re-do it, but it really shouldn't have disappeared in the first place...

--------------------------
**Version**: wmf-deployment
**Severity**: major
*** This bug has been marked as a duplicate of bug 53841 ***
(In reply to comment #7)
> (In reply to comment #6)
> > I don't think my issue is the same since the commit is missing from both the
> > web viewers on git.wm.o and github.
> > 
> > I'm not sure I've hardcoded an IP anywhere, I just use gerrit.wikimedia.org
> > when cloning.
> 
> So what happened here was the change was merged without a merge commit. Will
> require some manual wrangling one way or the other to fix.

Maybe I'm misunderstanding, but the commit was merged just fine. It didn't need a merge commit since at the time, it was directly on top of the current HEAD. It was replicated to github fine, and I pulled locally using my gerrit remote. When the upgrade happened it vanished. At that point, it was missing from gerrit.wm.o, but it was still visible on github, until the l10n-bot updated the translations, off of the HEAD on gerrit, which was (force?) pushed to github and overrode the "fix typo" commit.
(In reply to comment #6)
> I don't think my issue is the same since the commit is missing from both the
> web viewers on git.wm.o and github.
> 
> I'm not sure I've hardcoded an IP anywhere, I just use gerrit.wikimedia.org
> when cloning.

So what happened here was the change was merged without a merge commit. Will require some manual wrangling one way or the other to fix.
I don't think my issue is the same since the commit is missing from both the web viewers on git.wm.o and github.

I'm not sure I've hardcoded an IP anywhere, I just use gerrit.wikimedia.org when cloning.
To the original reporter: can you confirm the IP address you are using for gerrit.wikimedia.org?  That would let us figure out if you have the same issue I was having, or a different one.
Mea culpa -- my bug (in comment 2) was caused by an out-of-date entry for gerrit.wikimedia.org in my /etc/hosts file.  =(
(In reply to comment #2)
> This breakage seems to be a side-effect of the gerrit migration.  For me,
> 
> $ git clone
> https://gerrit.wikimedia.org/r/p/mediawiki/extensions/VisualEditor
> $ cd VisualEditor ; git log --oneline -1
> feff1fb Merge "Improve welcome dialog support for large fonts"
> 
I can't reproduce. I get
47545a5 Remove no-insertion metadata corner case from `ve.dm.Transaction.pushReplace()`.

as expected.
This breakage seems to be a side-effect of the gerrit migration.  For me,

$ git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/VisualEditor
$ cd VisualEditor ; git log --oneline -1
feff1fb Merge "Improve welcome dialog support for large fonts"

versus

$ git clone https://git.wikimedia.org/git/mediawiki/extensions/VisualEditor.git
$ cd VisualEditor ; git log --oneline -1
47545a5 Remove no-insertion metadata corner case from `ve.dm.Transaction.pushReplace()`


Note that https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FVisualEditor shows the latter commit, but 'git review -s ; git log gerrit/master' shows the former.
Eventhough the WebUI shows the change as having status 'Merged', the
change cannot be fetched directly:

  git fetch ssh://qchris@gerrit.wikimedia.org:29418/mediawiki/extensions/MassMessage refs/changes/96/82796/1
  fatal: Couldn't find remote ref refs/changes/96/82796/1
*Problem Description: If for spelling correction purposes only few charecters within any word are selected and replaced with other charecter of same or lesser length, without movement of arrow keys or spacebar, save button does not get enabled, so effectively we would not be able to save the change.

**Additional details : Problem was identified when we were trying to reproduce bug 53758, intution is it may be some how indirectly related to bug 53758


*Tested Browser and OS =Firefox+Win7

**Were enabled: VisualEditor+ULS Method of input = अक्षरांतरण language=Marathi 
Script=Devanagari  (Non-VE source edit environ,ULS Method of input = अक्षरांतरण
works normal)     

Steps to reproduce:
* Steps to reproduce:
1. Go to existing page with considerable Marathi Devnagari text may be like
https://mr.wikipedia.org/wiki/अभिमन्यु

2. Go to माझ्या पसंती (Preferences), संपादन and enable last option:
यथादृश्यसंपादक कार्यान्वित करा (केवळ मुख्य(लेख) आणि सदस्य नामविश्वात) - this
enables VisualEditor
3. Click cog next to इतर भाषांमध्ये
4. Under क्षेपन (टायपींग ईनपुट) make sure to choose अक्षरांतरण

5. Select any random  marathi word from existing paragraph text 

6.Make the changes in the word by changing alphabate but see that length of the word remains less after the change.
**Please note do not move arrow keys or spacebar

7 Save button does not apear

--------------------------
**Version**: unspecified
**Severity**: major
Based on your comments, I'm marking this as FIXED - please check, and reopen if it's not!
(In reply to comment #4)

*This Test phase seems to have fixed problem on mediawiki.Tested at my user page on mediawiki at https://www.mediawiki.org/wiki/User:Mahitgar now works well


*Still to be fixed on rest of the wikis including mr wikipedia   https://mr.wikipedia.org/wiki/अभिमन्यु

Thanks and Regards

-Mahitgar
There's code to address this bug in the following patch, which is due to go live by mediawiki.org on 13 September 2013:

https://gerrit.wikimedia.org/r/#/c/82858/

Please let us know whether it fixes the bug!
(In reply to comment #2)

Firefox version- 23.0.1 It gets automatically updated

Rgds
(In reply to comment #0)
> *Tested Browser and OS =Firefox+Win7

Please always provide exact version info (your Firefox version).
Sorry 
*7 Save button does not get enabled
In the mid to end 2021 timeframe, the Parsing Team is aiming to start migrating read views for Wikimedia wikis from the core parser to Parsoid.

https://www.mediawiki.org/wiki/Parsing/Parser_Unification is the wiki page for this project.

This is a tracking task for getting this done. Subtasks track the specific work for getting this done.
Wikimedia Developer Summit 2016 ended two weeks ago. This task is still open. **If the session in this task took place**, please make sure 1) that the session Etherpad notes are linked from this task, 2) that followup tasks for any actions identified have been created and linked from this task, 3) to change the status of this task to "resolved". **If this session did not take place**, change the task status to "declined". **If this task** itself has become a well-defined action which **is not finished yet**, drag and drop this task into the "Work continues after Summit" column on the project workboard. Thank you for your help!
Today is November 6, and this proposal is basically not on track. Unless the situation suddenly changes and/or @robla-wmf and the Architecture Committee really want to schedule it, it will be removed as a #Wikimedia-Developer-Summit-2016 proposal.
@mobrovac: if you really think this should happen, you should drive it rather than delegate it to #ArchCom.  @gwicke //might// volunteer to take this on, but I'm not going to speak for him.
@Qgil, the reason is that this requires a wide cross-org consensus (and later work), so I'd say the ArchCom should drive this one.
With so many blocking/blocked tasks, no specific Summit plans specified in the description, and no assignee, it is difficult to evaluate whether this Summit proposal is On Track with ongoing discussion. Can someone step in as driver of the discussion and confirm the interest in getting a slot in the Summit schedule, please?
Congratulations! This is one of the 52 proposals that made it through the first deadline of the #Wikimedia-Developer-Summit-2016  [[ https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016#Submissions_and_selection_process | selection process ]]. Please pay attention to the next one:  > By **6 Nov 2015**, all Summit proposals must have active discussions and a Summit plan documented in the description. Proposals not reaching this critical mass can continue at their own path out of the Summit.
FWIW, I did get some informal agreement that using Parsoid HTML for "Printable page" views was a reasonable thing to deploy on wikitech, as a first step.  I may try to write a standalone extension to do this.
>>! In T55784#1047315, @GWicke wrote:
> @jdforrester-wmf, is this really high priority for you right now right now? Should we prioritize intermediate steps higher?

It's not a Q3 urgency for VisualEditor, no.
@jdforrester-wmf, is this really high priority for you right now right now? Should we prioritize intermediate steps higher?
*** Bug 53780 has been marked as a duplicate of this bug. ***
*Problem Description:Where text is already present,Along with any of above problems, Some times edited aspect is shown in edit window but does not reflect in edit preview 

**Additional Details : Probably problem arises when we insert any additional charecters or word between two existing words in a sentence.


I suppose this would be easy to reproduce screen shot & will do it soon.


* Steps to reproduce:
1. Go to existing page with considerable Marathi Devnagari text may be like
https://mr.wikipedia.org/wiki/अभिमन्यु

2. Go to माझ्या पसंती (Preferences), संपादन and enable last option:
यथादृश्यसंपादक कार्यान्वित करा (केवळ मुख्य(लेख) आणि सदस्य नामविश्वात) - this
enables VisualEditor
3. Click cog next to इतर भाषांमध्ये
4. Under क्षेपन (टायपींग ईनपुट) make sure to choose अक्षरांतरण

5. Select any random  two marathi word from existing paragraph text 

6. insert any additional charecters or word between two existing words in a sentence.

**Problem is not always but frequent .Tested on Win7 +Firefox

--------------------------
**Version**: unspecified
**Severity**: major
Based on your comments, I'm marking this as FIXED - please check, and reopen if it's not!
*Done first round of testing seems to have solved but since problem is not frequent one for final confirmation we will need to have more tests and time.

Thanks and regards
There's code to address this bug in the following patch, which is due to go live by mediawiki.org on 13 September 2013:

https://gerrit.wikimedia.org/r/#/c/82858/

Please let us know whether it fixes the bug!
Usually this problem does not come in isolation but comes when some other problems are happening reported in earlier bugs for Marathi/Devnagri but it is defficult to specify that the problem will come when exactly a specific other problem is existent.May need more observation to notify exact time of ocurrance.
*Problem description : spell correction of any word eats up text (with continuous motion) on right side until you press spacebar 

**Additional Details: The problem is quite frequent but not always.Observed specially when we give backpace and add up more charecters to the word than earlier length of of the word  

* Steps to reproduce:
1. Go to existing page with considerable Marathi Devnagari text may be like https://mr.wikipedia.org/wiki/अभिमन्यु

2. Go to माझ्या पसंती (Preferences), संपादन and enable last option:
यथादृश्यसंपादक कार्यान्वित करा (केवळ मुख्य(लेख) आणि सदस्य नामविश्वात) - this
enables VisualEditor
3. Click cog next to इतर भाषांमध्ये
4. Under क्षेपन (टायपींग ईनपुट) make sure to choose अक्षरांतरण

5. Select any random  marathi word from text 

6. delet few charecters with backspace

7. Add few new marathi charectes to the word

8. If the problem is not observed in single effort try spell corrections again in some other words 


*VisualEditor+ULS Method of input = अक्षरांतरण language=Marathi 
Script=Devanagari  (Non-VE source edit environ,ULS Method of input = अक्षरांतरण
works normal   

*Tested Browser and OS =Firefox+Win7

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51472
Change 80689 merged by jenkins-bot:
Revert model to use simple UTF-16 code units

https://gerrit.wikimedia.org/r/80689
Change 80689 had a related patch set uploaded by Divec:
Revert model to use simple UTF-16 code units

https://gerrit.wikimedia.org/r/80689
Hello,

Would it be possible to test this against current master? You can use this at
http://en.wikipedia.beta.wmflabs.org/ - we believe that we may have fixed the
issues (or, at least, changed the behaviour) since you tested it.

Thank you!
(In reply to comment #1)

*Did one round of test at my user page on media wiki https://www.mediawiki.org/wiki/User:Mahitgar 

Seems to get partially fixed with some different wierdness in some other case so will need more tests and time to confirm


Rgds
There's code to address this bug in the following patch, which is due to go live by mediawiki.org on 13 September 2013:

https://gerrit.wikimedia.org/r/#/c/82858/

Please let us know whether it fixes the bug!
an IP editor at en.wp reports:
"At any given page, as long the edit box is selected (with the cursor blinking) pressing 'page down' or 'page up' takes you to the end of the page. Firefox 23.0, Linux Mint."
The example page they gave was [[Jet Lee]]

Using Firefox 23 on Xubuntu linux with the monobook skin I am unable to duplicate that behaviour, but:
At [[Jet Lee]] and [[User:Thryduulf/sandbox2]]: pressing page down or page up works as expected once but then does nothing. I then click anywhere in the body and again one of them works once, and then not until I click. However, once I've viewed the end of the page it expected. 

At [[User:Thryduulf/sandbox]] and [[Timbuktu]] it works as expected from the start. 

At [[Nigeria]] I saw the same behaviour as at [[Jet Lee]] but when I returned to the top of the page it went back to working only once.

At [[Great Balls of Fire]] page down worked once, then didn't. I clicked and it worked as expected subsequently.

At [[Malvern Link]] I saw the same as at [[Nigeria]], but after pressing page up both page up and page down then worked as expected.

I'm struggling to see any pattern.

Bug 33047 was suggested as having potential relevance, but that was fixed in October 2012 so my gut feeling is that its unlikely.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51957
https://bugzilla.wikimedia.org/show_bug.cgi?id=50726
AFAICT this is now works in Firefox since the Firefox-related CE fixes, though there are some oddities generally about Page Up / Page Down. Closing as such for now, but happy to re-open if I've missed something.
I am able to reproduce this on Firefox 24/Linux.
Page down on the following articles jumps to the bottom of the article, irrespective of where the cursor is placed.  Even stranger, page up also goes to the bottom of the article.
https://en.wikipedia.org/wiki/Nigeria?veaction=edit
https://en.wikipedia.org/wiki/Great_Balls_of_Fire?veaction=edit

The problematic behaviour doesnt happen on simpler articles like
https://en.wikipedia.org/w/index.php?title=Walter_T._Downing&veaction=edit
https://en.wikipedia.org/w/index.php?title=Sienno,_W%C4%85growiec_County&veaction=edit

Bug 51957 is another Firefox only keyboard navigation problem.
Germanjoe comments suggests it may be related to problems establishing cursor position relative to templates:

"Maybe a related error occured, while testing in [[Nigeria]], Firefox 23, mono. Enter VE-mode and click below one of the huge (really huge) navbox farms at the end of the article (in the blank line below them). Now i made two tests:

Click "Page up" => OK, scrolls up as expected. 
Now click "Page up" again => ERROR, jumps down to the initial position below the navbox.
        
another test from the same initial position below the huge navbox: 
"Page up", then "Page down", then "Page up" and a second "Page up" => works OK.

If i had to guess (uneducated as always), it looks like VE has problems storing or establishing the cursor position while scrolling through some huge or complex templates. "
It's Windows 7, sorry. I am also the original reporter of the related bug 52445, whose effect is also being kicked to the end of the edit box and Firefox only.
the same IP user has followed up saying (while I was reporting this) that they have been unable to reproduce their original report in Firefox 23.0.1 in Windows (they don't say which version)
My goal next week is to be able to run the VE tests in a mediawiki-vagrant instance. When I added the role, I get puppet errors. Just in case you ran into this, here's the error:

notice: /Stage[main]/Browsertests/Exec[install browsertests bundle]/returns: Installing ffi (1.9.0) with native extensions /usr/lib/ruby/1.9.1/rubygems/installer.rb:552:in `rescue in block in build_extensions': ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)
notice: /Stage[main]/Browsertests/Exec[install browsertests bundle]/returns: 
notice: /Stage[main]/Browsertests/Exec[install browsertests bundle]/returns:         /usr/bin/ruby1.9.1 extconf.rb 

         notice: /Stage[main]/Browsertests/Exec[install browsertests bundle]/returns: Results logged to /home/vagrant/.gem/ruby/1.9.1/gems/ffi-1.9.0/ext/ffi_c/gem_make.out

and all that contains is the line
  /usr/bin/ruby1.9.1 extconf.rb 

There's an extconf.rb in ~/.gem/ruby/1.9.1/gems/ffi-1.9.0/ext/ffi_c , so I ran that line, it created a Makefile, I ran make, and it built something.  But the next time I ran browsertests, it failed again.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Closing since this looks like it has been fixed to me. Please reopen if needed.
**jhall** wrote:

I was able to get this working on my MacBook Air with the following workflow (I have not been able to verify that this works on platforms other than Mac OS):

1. vagrant enable-role visualeditor
2. vagrant up
3. vagrant provision
4. vagrant ssh -- -X
5. cd /srv/VisualEditor/VisualEditor/modules/ve-mw/test/browser
6. export MEDIAWIKI_URL=<value>
7. export MEDIAWIKI_USER=<value>
8. export MEDIAWIKI_PASSWORD=<value>
9. export PATH=$PATH:/home/vagrant/.gem/ruby/1.9.1/gems/cucumber-1.3.8/bin 
10. bundle exec cucumber <value>
Similar to bug 52120 for ULS. Once we've got this running on merge, we'll want to move to running on submit (V+2 submit?), but for now…

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52120
https://bugzilla.wikimedia.org/show_bug.cgi?id=57560
**jhall** wrote:

Basic test is merged and in place, so marking this bug resolved.
Change 111890 merged by jenkins-bot:
[Browser test] Headless browser test(s)

https://gerrit.wikimedia.org/r/111890
Change 100797 abandoned by Hashar:
[browser test] Cucumber default profile for CI

Reason:
we are using something different than the ciwmf profile.

https://gerrit.wikimedia.org/r/100797
Change 111890 had a related patch set uploaded by Jhall:
[Browser test] New test for headless browser testing on a fresh Mediawiki install with VisualEditor.

https://gerrit.wikimedia.org/r/111890
Change 110468 abandoned by Jhall:
[Browser test] WIP Headless test for VE verification on a fresh Mediawiki install (as on Integration server).

Reason:
Abandoning this change since I'm going to start fresh with a slightly different approach.

https://gerrit.wikimedia.org/r/110468
Change 110468 had a related patch set uploaded by Jhall:
[Browser test] WIP Headless test for VE verification on a fresh Mediawiki install (as on Integration server).

https://gerrit.wikimedia.org/r/110468
Change 102960 abandoned by Jhall:
[Browser test] WIP Modifications for PhantomJS compatibility

Reason:
Abandoning this patch since we have implemented support for headless browser testing in the mediawiki-selenium Rubygem (rather than implementing it in each individual repo).

https://gerrit.wikimedia.org/r/102960
**jhall** wrote:

After some further investigation, we've decided to use the "headless" Rubygem for headless browser testing, and we've decided to incorporate that support into the mediawiki-selenium Rubygem so that it will be available to all WMF repositories that have browser tests.  The task for updating the mediawiki-selenium is captured in Bugzilla 60584.
**jhall** wrote:

Scripts used to evaluate PhantomJS "bind" injection

After a pairing session with Željko, I went back to basics and tried to get Function.prototype.bind injection working directly with PhantomJS (ignoring the rest of our test infrastructure for the time being).  

Per the attached scripts, I tried all of the relevant methods noted in the PhantomJS API documentation:

http://phantomjs.org/api/webpage/

...and still no luck.  The Main_Page loads fine, with the exception of the VE editing link/tab, which is available to other browsers (Chrome, Firefox, etc) at the same URL.

Per a suggestion from Antoine, it might be time to investigate using Firefox in a headless mode as a potential substitute for PhantomJS.

**Attached**: {F11112}
**jhall** wrote:

Changing bug status since task in still WIP.
Change 102960 had a related patch set uploaded by Jhall:
[Browser test] WIP Modifications for PhantomJS compatibility

https://gerrit.wikimedia.org/r/102960
**jhall** wrote:

Timo pointed me in the right direction:


jeffrey-hall:browser jeffreyhall$ phantomjs
phantomjs> Function.prototype.bind
undefined


Turns out PhantomJS is built with an old version of JavaScriptCore that is missing the "bind" implementation, which is needed to satisfy Visual Editor's es5 features check: 

https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/cf7f2b141d/modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.init.js#L72-L84

…but a workaround is available:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind?redirectlocale=en-US&redirectslug=JavaScript%2FReference%2FGlobal_Objects%2FFunction%2Fbind#Compatibility

…so I'll investigate the workaround next.
Created attachment 14138
ve phantomjs

**Attached**: {F11111}
Created attachment 14137
ve ff

**Attached**: {F11109}
Strange. I am pretty sure PhantomJS has JS. :)

But, this simple script takes screen shot that shows it can not load visual editor.

require "watir-webdriver"
browser = Watir::Browser.new :phantomjs
browser.goto "https://test2.wikipedia.org/wiki/User:Zeljko.filipin%28WMF%29?veaction=edit&vewhitelist=1"
browser.window.resize_to 1280, 1024
browser.screenshot.save "ve.png"

If :phantomjs is replaced with :firefox, then visual editor opens just fine (see screen shots).
If a browser is not on the blacklist, and meets the functionality criteria, then the edit tabs for VisualEditor should show up. A browser not being on the whitelist just means the user gets a warning when they edit. Adding PhantomJS to the whitelist will not make VisualEditor appear if it doesn't already.

(Also, you can bypass the blacklist with ?veaction=edit&vewhitelist=1 which should trigger VE even if you don't have a functional browser, as long as it has JS.)
**jhall** wrote:

Ah, I believe Željko is correct - looks like VE has a whitelist in addition to a blacklist.  See section beginning on line 169 in this file:

https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FVisualEditor/1cd761dad8aed132619c2897abe367404ca8f3ca/modules%2Fve-mw%2Finit%2Ftargets%2Fve.init.mw.ViewPageTarget.js

Will talk to the VE dev team and see if we can get PhantomJS whitelisted.
Created attachment 14130
phantomjs screen shot

**Attached**: {F11108}
Looks like phantomjs is blacklisted (or not whitelisted). There is no visual editor edit option (see screen shot).
**jhall** wrote:

Looks like it's not a problem with PhantomJS being blacklisted, per the VisualEditor browser blacklist which begins at line 890 of this file:

https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FVisualEditor/b922592902ad57f770b6810566b820aada74aa47/VisualEditor.php

…so I'll spend some more time tomorrow to see if I can figure out why PhantomJS doesn't seem to work as intended even when navigating directly to an "editing mode" URL.
Could it be that phantomjs lack some javascript functionality that would cause VisualEditor to disable itself ?  Might be a browser whitelist as well.  Honestly, I have no clue how it is handled in VisualEditor.
**jhall** wrote:

PhantomJS screenshot from VE editing mode URL

Thanks Željko.  I tried modifying the "anon.feature" test to navigate directly to the Visual Editor editing URL (?veaction=edit), but from capturing both a screenshot (attached) and the raw HTML that PhantomJS lands on, it does not appear that PhantomJS is successfully entering into Visual Editor editing mode.

In any case, we're getting closer step-by-step, so I'll continue to work on this.

**Attached**: {F11106}
Created attachment 14080
phantomjs screen shot

**Attached**: {F11105}
(In reply to comment #6)
> The test case currently does not work with PhantomJS, so I'll spend more time
> tomorrow trying to figure out why PhantomJS can't click into Visual Editor
> editing mode.

In phantomjs, "edit" link is not visible by default, see attached screen shot.
**jhall** wrote:

I went ahead and amended the existing Gerrit ID:

https://gerrit.wikimedia.org/r/#/c/100797/

…with an additional anon test case that edits a random page (which will likely always be the "Main Page" for a fresh wiki install).  

The test case currently does not work with PhantomJS, so I'll spend more time tomorrow trying to figure out why PhantomJS can't click into Visual Editor editing mode.
Jeff : sure, if you can get a test that roughly does:

 - anonymous user
 - go to main page
 - press Edit (visual editor version)
 - ensure visual editor is loaded

That would be a nice first step that would validate the Jenkins job and VE/Parsoid is properly setup :-)
**jhall** wrote:

Sorry I wasn't able to get to work on this bug quickly Antoine - let me know if you want me to work on creating a new browser test that will succeed in this scenario (the existing anon test will fail since it presumes the existence of a User page in the target wiki).
And I manage to get VisualEditor + Parsoid to be setup automatically using Jenkins. The related job configuration is pending in https://gerrit.wikimedia.org/r/#/c/100800/ (need to be polished).

I confirmed the wiki is functional and managed to edit a page using VE \O/

Next steps:
* cleanup the job configuration
* make the wiki faster (sqlite is not on tmpfs as an example)
* try to get at least ONE browser test scenario to pass (anon ones are good candidates apparently)
Change 100797 had a related patch set uploaded by Hashar:
[browser test] cucumber default profile for CI

https://gerrit.wikimedia.org/r/100797
**jhall** wrote:

Assigning to myself per an e-mail thread with Antoine, Chris, and Željko.
When editing, clicking in the middle of or adjacent to an existing word in Latin, Hebrew, Arabic or Cyrillic scripts (others not tested) and pressing ctrl+k or clicking the link icon selects that word as the suggested sequence that is desired to be linked. When doing the same in Thai text nothing is selected by default.

--------------------------
**Version**: unspecified
**Severity**: major
This is not a "bug" per se - VisualEditor's word boundary detection only works for scripts that use word boundaries. Consequently it doesn't operate on Chinese or Thai (which don't use word boundaries), but does for Korean, Latin and Cyrillic languages, and others (which do).

Theoretically it would be possible to build some code for applying algorithmic word boundary rules for Thai, but that's both complex and slow, so if that is desired it should be opened as an enhancement (and we'd need to see how we can make it only slow down users who are editing in Thai).

Marking as INVALID.
I tested with Telugu and Malayalam, and this doesn't happen there. Must be something special with Thai.
Confirmed in Thai Wikipedia and in the English Wikipedia with Thai words.

Furthermore, if you Ctrl-K on a Latin word and then Ctrl-K on a Thai word, the Latin word appears in the input box. See this test case:
https://en.wikipedia.org/wiki/User:Amire80/VE-Thai
I tried editing [[Fred Pittman]], including adding a comma after a link. The editor auto-added it to the link text, which wasn't what I wanted, so I selected the comma and clicked the remove-formatting button. This replaced the comma with a snowman. Woo!

I'd also say that the auto-link-addition heuristic is a little buggy if it includes commas, but that's maybe just me. :)

--------------------------
**Version**: unspecified
**Severity**: major
This was fixed two weeks ago; sorry for the slowness in replying.
When adding a link from scratch (without marking an existing word first)  the cursor ends up being at the beginning of the new link rather than at its end -- which stops fluent typing.

Reproduce:
1. Go to an RTL wiki.
2. Go to a new sentence or new paragraph (cursor should be in an empty space)
3. Create link, followed by enter/enter to close the inspector
4. The cursor appears at the left of the word (which is the beginning in RTL) rather than the right of the word.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 81872 merged by jenkins-bot:
Cursor fix after link insertion

https://gerrit.wikimedia.org/r/81872
Change 81872 had a related patch set uploaded by Jforrester:
Cursor fix after link insertion

https://gerrit.wikimedia.org/r/81872
This was actually not just for RTL wikis, and the submitted patch fixes the problem for both directions in Annotation Inspector (for both links and languages)
**Author:** `wojciech.r`

**Description:**
When I edit existing content in <source> tags, while editing it, error is shown about invalid language specified (lang=) and after saving it puts fragment of HTML code of this tag divs and entities into source of page and my code is broken.

https://www.mediawiki.org/w/index.php?title=VisualEditor:Test&oldid=773552

--------------------------
**Version**: unspecified
**Severity**: major
This is now fixed in master, and will be released to MediaWiki.org on Thursday 5 September. Sorry for the disruption.
Change 82063 merged by jenkins-bot:
Round trip alien extensions correctly when edited

https://gerrit.wikimedia.org/r/82063
This fix preserves attributes correctly. The above bug would allow you to edit them.
Related bug 53614
Change 82063 had a related patch set uploaded by Esanders:
Round trip alien extensions correctly when edited

https://gerrit.wikimedia.org/r/82063
--------------------------
**Version**: unspecified
**Severity**: normal
Change 81596 merged by jenkins-bot:
Move contentEditable=false to protected node

https://gerrit.wikimedia.org/r/81596
Change 81596 had a related patch set uploaded by Esanders:
Move contentEditable=false to protected node

https://gerrit.wikimedia.org/r/81596
For those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled "Create source". (VE is not enabled in the Education Program: namespace, so it should remain simply "Edit".)

Example institution page:
http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma

Example course page:
http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma/History_of_Science_from_Antiquity_to_Newton_(Fall_2013)

--------------------------
**Version**: unspecified
**Severity**: normal
**andrew.green.df** wrote:

P.S. Go to a production wiki and try this in a js console:

mw.config.get('wgContentNamespaces')

The results coincide:

https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L9292-9349

I lost the scent of $wgVisualEditorNamespaces following a brief pursuit, though...
**andrew.green.df** wrote:

Added a comment on the Gerrit change. tl;dr: Is $wgContentNamespaces getting checked? I don't see how EP_NS could be there, and checking it in js seems to fix the issue. Thanks!
Change 125233 merged by jenkins-bot:
Don't change tabs on Education Program pages

https://gerrit.wikimedia.org/r/125233
(In reply to Andrew Green from comment #9)
> I can look into making the EP extension warn VE through some generic
> mechanism.

Ideally EP would warn VE through the existing generic mechanisms that Krinkle suggested; this would avoid VE having to have EP-specific code in it entirely. :-)


> BTW, I wouldn't recommend that anyone try to make major changes to the EP
> extension, as the plan is just to rewrite it.

Understood. 


> Alex's patch also looks like a fine temporary solution. :)

Alex's patch is necessarily a horrible hack, but yeah…
**andrew.green.df** wrote:

I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes.

BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it.

The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)
(In reply to Krinkle from comment #7)
> I'd say EP should either let us know how to generically detect it without
> being EP specific, or it should implement support to at least do one thing
> right. Possibly we could do the latter ourselves (maybe Alex is interested
> in patching EP).

I don't really think this bug is important enough to VE to justify making big changes to how another extension works...
Change 125233 had a related patch set uploaded by Alex Monk:
Only make tab changes on articles

https://gerrit.wikimedia.org/r/125233
I think VE shouldn't be modifying tabs on pages which aren't articles (check wgIsArticle is true before doing anything).
Slinging to Alex – not sure what the fix here would be (it feels like overriding the semantics of a tab is something that should involve a class change, really) – thoughts?
Hi James, just noting for the record that this is still quite problematic, and we very much appreciate any efforts to fix it. :)
*** Bug 56844 has been marked as a duplicate of this bug. ***
@James: Any chance of getting this fixed soon? Now is when many instructors who are new to Wikipedia will be trying to set up their course pages, and the mislabeled tab is likely to confuse.
The final case in ve.dm.Document.getMetadataReplace() applies if insert.length > remove.length.  But in this case only the 'retain' and 'insert' fields are set on the returned object.  In ve.dm.Transaction.pushReplace() we only add the {retain,remove,insert}Metadata fields to the operation if the 'remove' field on the object returned from getMetadataReplace() is not undefined.  So these fields won't be set correctly if insert.length > remove.length.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 81928 merged by jenkins-bot:
Collapse metadata on any removal.

https://gerrit.wikimedia.org/r/81928
Change 81928 had a related patch set uploaded by Cscott:
Collapse metadata on any removal.

https://gerrit.wikimedia.org/r/81928
In ve.dm.Document.getMetadataReplace(), we only merge metadata if the amount removed is larger than the amount inserted.  But this could end up putting metadata in odd positions, for example if you have Foo[[Category:Bar]]BazQuux and you delete 'ooBa' and replace it with {image}xxx{/image}, then the category ends up inside the image.

We should always merge metadata when a segment is deleted, so that it appears outside any new structure added.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 81928 merged by jenkins-bot:
Collapse metadata on any removal.

https://gerrit.wikimedia.org/r/81928
Change 81928 had a related patch set uploaded by Cscott:
Collapse metadata on any removal.

https://gerrit.wikimedia.org/r/81928
Right now VisualEditor transforms the HTML Parsoid gives us (which is nicely-structured <figure>s) into the mess of <div>s that MediaWiki's PHP parser throws out (up?). This is so that VE's rendered HTML magically inherits the styling that the images get on the read page, which includes

Instead, we should just style these using CSS. However, this is difficult because the styles are specific to <div>s with known classes (and Parsoid's HTML has no <div>s), and is often over-ridden in wiki- or user-specific CSS (e.g. Wikia's sites' skins, or that on Cherokee Wikipedia).

From quickly playing around, a basic CSS style that implements core-MW would be something like:

figure
	float: right;
	border: 1px solid #CCC;
	padding: 3px;
	width: 172px;
	background: #FAFAFA;
	font-size: 13px;
	margin-right: 1.2em;

img
	border: 1px solid #CCC;

figcaption
	padding: 3px;
	font-size: smaller;
	line-height: 1.4em;
	width: 15em;
	margin: 2px 0px;
	padding-top: 0px;

--------------------------
**Version**: unspecified
**Severity**: major
Change 93417 merged by jenkins-bot:
Render CE MWBlockImageNodes as styled <figure>s

https://gerrit.wikimedia.org/r/93417
Change 93417 had a related patch set uploaded by Jforrester:
Render CE MWBlockImageNodes as styled <figure>s

https://gerrit.wikimedia.org/r/93417
Right now it is only intended for data about custom wiki-made templates.

To support magic words and parser functions, we'll need to make a few changes to make sure there are no conflicts or wrong assumptions.

A few random points:
* 'titles' parameter in the API module
* The PHP parser prefers native magic word over templates (creating Template:PAGENAME and using {{PAGENAME}}, will not use that template).
* Should there be an implied property 'type':
  - type:template -> {{Foo}}, {{:Foo}}, {{Template:Foo}}, {{Project:Foo}}
  - type:parserfunction -> {{PAGENAME}}, {{urlencode:123}}, {{#special:Watchlist}}

* parser functions don't have numerical parameters, and the first parameter is separated by colon, not by pipe. So we need a way (both in TemplateData and VisualEditor) to insert unnamed parameters without using numbers.

 e.g. {{urlencode:Foo|WIKI}} is correct, but {{urlencode:Foo|1=WIKI}} or {{urlencode:1=Foo|2=WIKI}} or {{urlencode|1=Foo|2=WIKI}} is wrong.

--------------------------
**Version**: unspecified
**Severity**: normal
Steps to produce the error

1. Edit a page with VE
2. Cut a block of text containing a reference tag
3. Paste it somewhere else

Now try to move the cursor by arrow keys

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
Firefox and Chrome on Mac - a cursor, when moved with arrow keys,  successfully skips the ref section.  Checked in test2/production.
Firefox and Chrome on Mac - a cursor, when moved with arrow keys,  successfully skips the ref section.  Checked in test2. 

Since it's an old bug - marking it's an invalid for now.
Only workaround I can think of is to create a fake hidden selection whenever a FocusableNode(s) is selected on it's own.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 83222 merged by jenkins-bot:
The Great [...] Rewrite of 2013: Clipboard edition

https://gerrit.wikimedia.org/r/83222
Change 83222 had a related patch set uploaded by Esanders:
The Great [...] Rewrite of 2013: Clipboard edition

https://gerrit.wikimedia.org/r/83222
This causes an exception to be thrown if you try to delete a content node at the end of the visible document (e.g. a reference list)

--------------------------
**Version**: unspecified
**Severity**: normal
ElementLinearData#getRelativeOffset now checks for handlesOwnChildren, which prevents this from being an issue.
May have been ameliorated by https://gerrit.wikimedia.org/r/98515
1. Copy and paste an unnamed reference
2. It doesn't appear as a subitem in the ref list
3. Undo. The reference is now index 0.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 81417 merged by jenkins-bot:
Always give references names. Ignore if used once.

https://gerrit.wikimedia.org/r/81417
Change 81417 had a related patch set uploaded by Esanders:
Always give references names. Ignore if used once.

https://gerrit.wikimedia.org/r/81417
Select text around a content node (e.g. a reference: "foo [1] bar" ) and then copy paste it. Note you now have extra newlines.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 81028 merged by jenkins-bot:
When pasting, try to use original range

https://gerrit.wikimedia.org/r/81028
Change 81028 had a related patch set uploaded by Esanders:
When pasting, try to use original range

https://gerrit.wikimedia.org/r/81028
1. select a focusable node only (e.g. a reference)
2. Cut it (ctrl+x)
3. Note you now have no cursor/selection

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed in master; will be deployed on Thursday as part of the regular push.
Change 81027 merged by jenkins-bot:
Give document real focus after cut

https://gerrit.wikimedia.org/r/81027
Change 81027 had a related patch set uploaded by Jforrester:
Give document real focus after cut

https://gerrit.wikimedia.org/r/81027
https://gerrit.wikimedia.org/r/#/c/81027/ fixes
example 1

new issue as of Aug 26, seen on test2wiki

this is easily triggered by an automated browser test but can also be triggered manually: 

while typing edits, click the Save page button.  
click Review 

Edited page and diff view contents are not the same. See screen shot examples 1 and 2. 

ex 1: "asfdaEdit" in edited page vs "asEdadit" in diff view where original page has "Edit"

ex 2: "aaqaaaStarting" in edited page vs "aSqaaatarting" in diff view where original page has "Starting"

in at least one case, the actual saved contents of the page differs from the buffer that appears upon clicking Edit to invoke VE, see example 3

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F11309}
This has been fixed in VisualEditor master as part of gerrit 81213, and we will do an emergency push of this to wmf14 tomorrow to fix it in product; sorry for the disruption.
I should mention that the (corrupted) diff view contents is what is actually saved when finally saving the page in VE
I can reproduce this consistently on test2wiki most of the time manually and automatedly all of the time as of the last VE deploy.  To repro manually (I use Chrome): 

* Pick a random page on test2wiki that has existing text
* click Edit for VE. click no other thing.
* Poise your right hand so that you are prepared to click 'Save page'
* With your left hand type randomly very very quickly. While typing with your left hand, click 'Save page' with your right hand

* take a look at the VE page contents (CE I assume).  It will appear to be accurate.  It will be different than what is in the diff view (DM I assume). 

Note: the automated test moves quickly enough that *nothing* typed into the VE edit interface is reflected in the diff view.  I can demo this if you'd like.

Again, this is new behavior as of Aug 26.
I still can't reproduce these in Chrome/Firefox/Safari/Opera testing on local master, on production test2, or production enwiki/mediawikiwiki.

What does "can also be triggered manually" mean - how? Or is this an unreliable/occasional thing? Possibly a system-load issue?

Is this specific to test2?

From the screenshots, the displayed content (from CE) and the data model (in DM) appear to have gotten out of sync, which Shouldn't Ever Happen(tm).
Created attachment 13176
example 3

**Attached**: {F11316}
Created attachment 13175
example 3

**Attached**: {F11315}
Created attachment 13174
example 2

**Attached**: {F11312}
Created attachment 13173
example 2

**Attached**: {F11311}
Created attachment 13172
example 1

**Attached**: {F11310}
See https://pl.wikipedia.org/w/index.php?title=Wojnicz&diff=37347163&oldid=37312891 for an example - I'm not sure what the problem is, here, since that's a meaningless tag :/.

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed in master; will be deployed on Thursday as part of the regular push.
Change 81438 merged by jenkins-bot:
Disable inserting/changing references when surface widget is empty

https://gerrit.wikimedia.org/r/81438
Change 81438 had a related patch set uploaded by Esanders:
Disable inserting/changing references when surface widget is empty

https://gerrit.wikimedia.org/r/81438
Looks like it's what happens when you insert a reference without typing anything into the box. Hit "insert reference", leave the main field blank, go immediately to the insert button, and... https://pl.wikipedia.org/w/index.php?title=Wikipedysta%3AOkeyes_%28WMF%29&diff=37370424&oldid=37257359
From http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#VE.2C_Sfn_template_within_reference.2C_Vcite_error

Adding a <ref> tag (e.g., a bibliographic citation) inside another <ref> tag with a different group (e.g., an explanatory footnote), displays as desired in VisualEditor, but when you save the page, it isn't visible because of T22707 in Cite.php

This is most likely to happen with a ref-creating template like {{sfn}}, since VisualEditor doesn't have the buttons to created nested ref tags directly.

--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=570036528&oldid=570035364
We have mismatched behavior.  Either *both* systems should display nested refs, or VisualEditor should stop displaying nested refs to match the limited features available to readers.

Whether this mismatch should be solved by reducing VisualEditor's ability to process nested refs or by increasing the other system's ability to process nested refs is beyond my paygrade.
(In reply to comment #0)
> Adding a <ref> tag (e.g., a bibliographic citation) inside another <ref> tag
> with a different group (e.g., an explanatory footnote), displays as desired
> in
> VisualEditor, but when you save the page, it isn't visible because of Bug
> 20707
> in Cite.php

If this problem is covered in bug 20707 already I'm not sure what your intention was to file another bug report. Could you clarify please?
The editor has the title and tooltip "LaTeX". This is not entirely correct. It's just the math environment subset for LaTeX that we can handle and support.

The label also conflicts with the visual symbol, which clearly communicates the Math function using the sum symbol. Remember that many people might not even know what LaTeX even is, causing further confusion.

The problem here is that we want to explain to the user that we want him to enter the math using LaTeX, because otherwise he might not understand how to enter his formula. Perhaps that is why the LaTeX label was chosen.

We should find a better way. Perhaps using a label or placeholder. "Enter formula using AMS-LaTeX"

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=43058
verified in test2:https://test2.wikipedia.org/w/index.php?title=13th_december&veaction=edit
Verified in Betalabs
This is now fixed in betalabs after we caused the English messages to get re-synched.
okay but I checked it on Betalabs.
@ryasmeen Fixed != deployed to production. That happens at a later time, usually somewhere within 2 weeks after getting fixed.
I am still seeing label Latex instead of Formula
Change 100112 merged by jenkins-bot:
Re-label the formula inspector to not be LaTeX

https://gerrit.wikimedia.org/r/100112
Change 100112 had a related patch set uploaded by Jforrester:
Re-label the formula inspector to not be LaTeX

https://gerrit.wikimedia.org/r/100112
I'm minded to just call it "Formula". Thoughts?
From http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Bold_and_nowiki.2C_other_markup

If you add a nowiki tag by itself, the angle brackets get escaped out (&amp;lt;nowiki&amp;gt;, or does just plain &lt;/nowiki&gt; work here at Bugzilla?).  If you add a nowiki tag plus some wikimarkup, like an asterisk at the start of a line or bold text, it doesn't.  This results in unpaired tags, sometimes functional wikimarkup, and always unexpected results.

Try this:

* You need a </nowiki> tag '''here'''.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 137525 merged by jenkins-bot:
Escape nowiki when combined with other wiki markup

https://gerrit.wikimedia.org/r/137525
Change 137525 had a related patch set uploaded by Arlolra:
Escape nowiki when combined with other wiki markup

https://gerrit.wikimedia.org/r/137525
This is a Parsoid serializer bug:

[subbu@earth tests] echo '* &lt;/nowiki&gt; tag' | node parse --html2wt
<nowiki>* </nowiki></nowiki> tag
At https://en.wikipedia.org/w/index.php?title=Churnet_Valley_Railway&diff=prev&oldid=569277862 it seems that a table ending with trailing new line syntax

|-
|}

caused pawns to be added to the article. As discussed at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=569732999#Chess_pieces_still_happening this syntax, although technically wrong, will continue to be added to articles. VE and Parsoid should therefore deal with this cleanly without the addition of any pawns to the article.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 119067 merged by jenkins-bot:
Only insert slugs where paragraphs are allowed

https://gerrit.wikimedia.org/r/119067
Change 119067 had a related patch set uploaded by Esanders:
Only insert slugs where paragraphs are allowed

https://gerrit.wikimedia.org/r/119067
I think this edit https://fr.wikipedia.org/w/index.php?title=Cash_investigation&diff=96500094&oldid=95914321 is related.
(In reply to comment #2)
> To perhaps clarify, VE and parsoid should accept both
> 
> |content
> |-
> |}
> 
> and
> 
> |content
> |}
> 
> as validly closed templates that should be displayed and rendered
> identically.

We currently don't strip empty table rows, which seems to be done in some conditions in the PHP parser + tidy combo. We could emulate this behavior in templated content and maybe also outside of templated content, but will need to avoid dirty diffs and preserve WYSIWYG behavior even when another row is added in VE.

> Both syntaxes should be retained as is when roundtripping.

This should already be the case in Parsoid. I just verified this at http://parsoid.wmflabs.org/_rtform/. Pawn insertion would a DOM modification in VE.
To perhaps clarify, VE and parsoid should accept both

|content
|-
|}

and

|content
|}

as validly closed templates that should be displayed and rendered identically. Both syntaxes should be retained as is when roundtripping.
Pawns are firmly VE territory. Moving to the VisualEditor product.
<<If I edit a blank page, press on the number list or bullet list icon and then press enter, the page remains blank but I have no cursor. Then other strange things start to happen. Pressing the link icon does not seem to do anything. I can press some icons (transclusion, references, etc) and they will appear, but if I then exit it, pressing it again or any other icon does nothing. Undo works though. FF 23.0.1 Win7. --Atethnekos (Discussion, Contributions) 21:27, 21 August 2013 (UTC) >>

Same for me, on Chrome the cursor does not disappear and you can press icons more than once, but if you type a word it will be split on more lines and you won't be able to wikilink it.
Thanks.

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed a long while ago.
There is no way to convert an image wrapped in a link to wikitext, so we shouldn't let a user do it. A plain image, on the other hand, can be link wrapped and we already handle this correctly.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 85010 merged by jenkins-bot:
Node annotation blacklists

https://gerrit.wikimedia.org/r/85010
Change 85011 merged by jenkins-bot:
MW*ImageNode's can't take link annotations

https://gerrit.wikimedia.org/r/85011
Change 85011 had a related patch set uploaded by Esanders:
MW*ImageNode's can't take link annotations

https://gerrit.wikimedia.org/r/85011
Change 85010 had a related patch set uploaded by Esanders:
Node annotation blacklists

https://gerrit.wikimedia.org/r/85010
Implement non-linear transitions between steps.  This is one of the key goals of the planned update to the API.  

The idea is that each step has a callback function which decides which step to proceed to.  This callback is called when an event occurs, such certain mw.hook, a user-provided event (there will be a way to tell the tour to check at a particular time), or a page change.

There can also be global transitions, which apply throughout the whole tour (for example, clicking "edit source" at any time may transition to the first step of the wikitext editing flow).

Simple use case:

Have a single tour with the basics of both wikitext and VisualEditor editing.  When you click "edit source" or "edit beta" at any time (unlike today, you don't have to be at the beginning), it transitions to the appropriate step.  You can then walk through the basic flows of the editors (as today)

More elaborate:

Your are in a detailed tour for VisualEditor.  You are in the step for the references dialog.  You click the template button, and it transitions to the step for adding a template.  When you walk through and save that, it transitions to a step for saving the reference.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 116228 merged by jenkins-bot:
Refactor and add non-linear tours, with tests

https://gerrit.wikimedia.org/r/116228
Change 116228 had a related patch set uploaded by Mattflaschen:
WIP: Refactor and add non-linear tours

https://gerrit.wikimedia.org/r/116228
This seems sporadic, and while it doesn't happen all the time, it does happen a lot, so I hope I am giving enough details to repeat this:

1. Put the cursor on an empty line without text.
2. Click the "Bold" button.
3. Type gibberish fast (ldkjlskdfjlkdjs lskdjf lsdkjflsdkjljsf....)
4. Witness weirdness: new characters pop up in the line underneath or in between the bits of gibberish, and if I try "backspace" to erase the lines even weirder stuff happen (like characters popup instead of being deleted, etc.

This doesn't happen when I typed regular language, I suspect, then, that it has to do with the speed of the insertion?

But after a single occurrence of this bug, the behavior of delete/backspace creates further bugs even if I stop typing quickly, or start new lines, etc.

--------------------------
**Version**: unspecified
**Severity**: major
*** Bug 53317 has been marked as a duplicate of this bug. ***
Change 81213 merged by jenkins-bot:
Detect outdated pending post KeyPress handler

https://gerrit.wikimedia.org/r/81213
Further to my previous comment: it seems that it's actually onDocumentKeyPress which is doing the setTimeout which gets outdated; and that we can code our way around it because it's just there to do a surface-to-model poll.
Change 81213 had a related patch set uploaded by Divec:
Detect outdated pending post KeyPress handler

https://gerrit.wikimedia.org/r/81213
I can reproduce this just by holding a key down for a few seconds. It seems to be because of setTimeout( f(), 0 ) causing event handling to overlap. This could be challenging to resolve because of the way browser event handling works. Gory details below :-)

On my slow Ubuntu laptop, I can reliably reproduce the bug. It happens if I just hold the 'x' key down inside a <h1> for a couple of seconds.

I'm pretty sure it's happening because we use setTimeout to process events. This can get complex up when two events are emitted by the browser at virtually the same time. In this case, ve.ce.SurfaceObserver.onDocumentKeyDown receives event 1, does some processing, then effectively does a setTimeout( f(), 0 ) to finish the processing. But by that time, the browser has already queued the handlers for event 2, so the processing for event 2 will start before the processing for event 1 has finished.

I tested this by putting two lines at the top of onDocumentKeydown: a ve.log("main...") and a setTimeout( ve.log("post..."), 0) . The corruption happens exactly when we get "main..." twice in a row followed by "post..." twice in a row. See http://pastebin.com/dzGYbpDq for full output.

This may be challenging to resolve, because we probably need to do stuff both before and after the browser's native keydown handler. We can't manage all the handling in our own queue, because (afaik) the browser's native handling can't be postponed. So it seems the only obvious option would be to detect when there are overlapping events, and try and do act delicately enough that things don't break.

Timo, any thoughts?
This is problematic, since I couldn't properly and reliably replicate the bug since then, it only happens occasionally, I'm not sure if it's because of the speed or some other aspect. 

But I did find that it happens not only with the Bold button - it happens either with "just" rapid text (no annotation) and with strikethrough and italics as well. I think it's probably safe to say that this isn't a specific annotation bug.

Another small detail about that bug was that once it *does* happen, the rest of the editing is a mess -- that is, once it happens, even if I stop rapid typing, and then start editing normally, I still get random letters and gibberish added, and the 'delete' functionality goes wonky. To get rid of it I need to refresh the page and start over. 

Also, This happened on my local wiki (using current VisualEditor master), installed on Ubuntu 13.04, and used through Firefox, and I just replicated it in MediaWiki.org
<<First, I noticed a strange behavior where anything I typed at the end of that third line, if I then hit enter, it would be duplicated in the fourth line, and my cursor would move to the fifth (blank) line. I then took a look at the wikitext generated by VE, and it looked odd, so I copied it into a wikitext editor, and got a rather different looking result than VE was showing. Also, upon saving with VE, I got this result, which is the same as copying into wikitext editor, but not what VE was showing me. Chris857 (talk) 20:54, 25 August 2013 (UTC) >>

http://www.mediawiki.org/w/index.php?title=User:Chris857&oldid=770602
http://en.wikipedia.org/wiki/File:Visual_Editor_-_subscript_and_superscript.PNG
http://en.wikipedia.org/wiki/File:Wikitext_editor_-_subscript_and_superscript.PNG

The user think this is related to the new super/sub script features.


I don't think it has to do with them. Proof is, I can reproduce (on Mediawiki) the same bug without using them. You just need to add quickly casual sequences of words, as if you were vandalizing the page. In this diff http://www.mediawiki.org/w/index.php?title=User:Elitre_(WMF)/SandboxVE&diff=prev&oldid=771184 I kept writing on the third line, it was VE which splitted what I wrote on more lines. I was also able to reproduce the difference among the content you "write" and the one which is saved. I can recall a vaguely similar behavior (not with casual letters though) when starting a list, but I can't say which bug that would be. I am also not sure whether this is a real bug or some counter-vandalism filter in action :)
Thanks.
Hi Moriel, David, can you please specify on which wiki this happens?
I am not able to reproduce it on en.wp or it.wp, 
but it does happen on mw.org - even if you do not use the Bold button or the new features, like another user suggested. 
I'd say this bug probably needs to be renamed.
I can reproduce this in Firefox but not in Chromium, on a slowish Ubuntu machine.
From WP:VE/F page (http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=567413854)

------------------------------
Following a report on frwiki, I tried a simple modification by changing a text into a wikilink. VE messed up the article by duplicating parts (not even complete parts), see [http://fr.wikipedia.org/w/index.php?title=Gen%C3%A8ve&diff=95604102&oldid=95601955 diff]. It seems to be reproducible on this article. --[[User:NicoV|NicoV]] <sup>([[:fr:Discussion Utilisateur:NicoV|Talk on frwiki]])</sup> 15:51, 6 August 2013 (UTC)
------------------------------

A cursory investigation back then revealed that this could be because of incorrect DOM fragment reuse for figures which all had about=null.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=47326
I am marking this resolved. Haven't seen any reports about this in a while.
Is this still happening in production?
https://gerrit.wikimedia.org/r/#/c/83216/ fixes the dsr inconsistency warnings  reported in this bug.
Sorry, I linked the wrong bug which is how you got the email ;-) .. fixing it.
You guys sure you wanted me on the CC for this bug?  I'm just making sure it wasn't another "Dan" :)
Based on IRC discussions, we figured that there are different bugs that are interaction and producing the same end result -- duplication in some cases.  The Trieste bug could be a result of a bad parse of ''[[Foo|''bar'']]'' and interaction of the about=null issue.  Dalmine seems to be something else.
This patch addresses the about="null" issue.

I am however not 100% sure that this is indeed the root cause for bug 53071. A
scenario I can think of is this:

1) getAboutSiblings returned sibling nodes without about attributes
2) for some reason that is unclear to me those were *not* assigned
   about="null" attributes in unpackDOMFragments on reuse
3) the serializer faithfully serialized out the new content


The diffs in
https://it.wikipedia.org/w/index.php?title=Trieste&diff=prev&oldid=61046913
would support this, as the entire image link is duplicated.

The diff in https://it.wikipedia.org/w/index.php?title=Dalmine&oldid=61238456
however looks like an incomplete image duplication. 

There are several figure-related DSR errors when parsing that page of this pattern:

WARNING: DSR inconsistency: cs/s mismatch for node: FIGURE s: 22704; cs: 22817
WARNING: DSR inconsistency: cs/s mismatch for node: FIGURE s: 18478; cs: 18586

Those warnings are still there when parsing the page with fragment reuse
enabled, so this might be a different issue.
Change 82676 merged by jenkins-bot:
Bug 53071: Handle about-less images better

https://gerrit.wikimedia.org/r/82676
Change 82676 had a related patch set uploaded by GWicke:
Bug 53071: Handle about-less images better

https://gerrit.wikimedia.org/r/82676
One more example:

https://it.wikipedia.org/w/index.php?title=Dalmine&diff=61238476&oldid=61238456
One more instance now reported on itwiki:

1. Diff: https://it.wikipedia.org/w/index.php?title=Trieste&diff=prev&oldid=61046913 (see 2 images duplicated further down)

2. Open https://it.wikipedia.org/w/index.php?title=Trieste&oldid=61038476&veaction=edit in Chrome and dump Parsoid HTML in the console "copy(ve.init.mw.targets[0].originalHtml)" You will see a lot of <figure> tags with about=null
Create an empty document by deleting everything. Enable Input method (e.g. Ibus Chinese Cantonese). Start typing, e.g. "jung" (select "中") then "gwok" (select "國"). The second character will overwrite the first, leaving just "國" instead of "中國".

Observed using chromium and firefox on Ubuntu. Happens with the following ibus input methods: Chinese cantonese, Chinese Pinyin, Korean, Malayalam swanalekha, Hindi inscript. Does not seem to happen with Kannada inscript.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 45240 ***
Quite often we get bug reports for issues that have been recently fixed but not deployed to the smaller wikis.

It would be very useful if we had build numbers that we could access (e.g. ve.version) in the client so we could tell quickly how out of date the deployed code is before we waste time debugging an issue someone else has already fixed.

--------------------------
**Version**: unspecified
**Severity**: enhancement
FYI - This might be removed in {T119750}
Change 84334 merged by jenkins-bot:
Hide version info if not available

https://gerrit.wikimedia.org/r/84334
Change 84334 had a related patch set uploaded by Esanders:
Hide version info if not available

https://gerrit.wikimedia.org/r/84334
Yes, there's an issue with our deployment process which prevents it from working ATM. We're working on a fix.
This isn't working.  When I click on "Beta" to see this, it says "Version false", with a link to https://en.wikipedia.org/w/false (from userspace) or https://en.wikipedia.org/wiki/false (from article space).
Change 81877 merged by jenkins-bot:
Expose version information in the client

https://gerrit.wikimedia.org/r/81877
Change 81877 had a related patch set uploaded by Esanders:
Expose version information in the client

https://gerrit.wikimedia.org/r/81877
Line height example

See screenshot for 1.25em vs 1.5em.

--------------------------
**Version**: unspecified
**Severity**: trivial

**Attached**: {F11545}
Change 79804 merged by jenkins-bot:
Increase line height in beta warning

https://gerrit.wikimedia.org/r/79804
Change 79804 had a related patch set uploaded by Esanders:
Increase line height in beta warning

https://gerrit.wikimedia.org/r/79804
See the third example at https://www.mediawiki.org/w/index.php?title=User:Miya/VE4&oldid=762831.

--------------------------
**Version**: unspecified
**Severity**: normal
Marking this as "FIXED" on the expectation that it's fixed - please re-open if you find that it is still occurring.
There's code to address this bug in the following patch, which is due to go live by mediawiki.org on 13 September 2013:

https://gerrit.wikimedia.org/r/#/c/82858/

Please let us know whether it fixes the bug!
This might have been fixed with the changes in gerrit 79451 - David, does this fit the same pattern?
I cannot take a screenshot ;)

* Scroll over a the toolbar
The button group outline, focused button box, and finger pointer flicker for a frame, then disappear.  Now the buttons to not go <click>, and I have the arrow pointer.

--------------------------
**Version**: unspecified
**Severity**: normal
Still can't reproduce, unfortunately. :-(
My VE just died with a slightly different behavior.  Now, the highlighting and outlining is drawn correctly, and persists, also the pointer is the index finger, indicating elements are click-enabled.  However, clicking Nothing Happens.

FF 23.0.1
Created attachment 13119
screenshot, I lied

**Attached**: {F11406}
screenshot

I opened a wiki page, clicked "Edit", modified some stuff in the first paragraph involving links and a footnote reference.  Next, I demoted my outline from Page title to Heading, lowering all subheadings as well.  Said action was performed by triple-clicking each heading like, then mousing to the heading toolbar and clicking on the next level down.

I believe I was on the last heading, when some magic combination of arrow keys and actions involving the heading level toolbar (I may have cursored down and hit <return> this time) caused a total HsiT scramble.  A sequence of characters of roughly equivalent length replaced the heading line I had been editing.

The damage seems to have spread elsewhere in the document.  See attached screenshot.

Separate but related bugs from the same editing session have been filed, jfyi to flesh out this story ;)

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

**Attached**: {F11397}
I *believe* that this may be related to bug 53360, which is now fixed, and so will mark as "WORKSFORME" (I can't make "FIXED" stand up given the lack of reproducible steps from these kinds of issues).

Sorry for the disruption. :-(
This was fixed by 283bfd554bf1, so closing this bug. Please reopen if there is something we overlooked.
Meta tags in foster-parentable positions aren't really an issue anymore.
Screenshot

On wikis with FlaggedRevs, the interface historically displays buttons in the order [edit][pending changes]. This seems logical.

Under the VE (screenshot attached) it goes [edit][pending changes][edit source]. This doesn't ;p. Restoring the previous setup (so that it would show as [edit][edit source][pending changes]) would be good.

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

**Attached**: {F11122}
Change 110862 merged by Catrope:
Don't try to insert the pending changes in the middle of VE's 'Edit' and 'Edit source'

https://gerrit.wikimedia.org/r/110862
Change 110862 had a related patch set uploaded by Alex Monk:
Don't try to insert the pending changes in the middle of VE's 'Edit' and 'Edit source'

https://gerrit.wikimedia.org/r/110862
For me it shows [pending changes][edit] without VE (and the comments indicate this is the intended behaviur), so I think with VE should be [pending changes][edit][edit source].
Hasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g. Math) we need it to work in block mode as well.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 79055 merged by jenkins-bot:
Fix rendering of inspector for embedded buttons

https://gerrit.wikimedia.org/r/79055
Change 79055 had a related patch set uploaded by Esanders:
Fix rendering of inspector for embedded buttons

https://gerrit.wikimedia.org/r/79055
If you copy a block level element and try to paste it all the annotations (links, bold, italic etc.) are removed and it is just pasted as plain text. You need to select the whole line with the selection region going all the way to the right of the screen. 

For example in 
http://en.wikipedia.org/wiki/User:Salix_alba/VE_test 
selecting the whole of the final paragraph and coping and pasting loses anotation.

Examining the clipboard in this case its something like
<meta charset='utf-8'><p data-parsoid ...</p><br class="Apple-interchange-newline">

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52770
Can confirm that this has been incidentally fixed as part of Ed's work on copy-and-paste - tested in Chrome/Firefox/Safari/Opera. (Yay.)
Can't reproduce.
See https://ja.wikipedia.org/w/index.php?title=%E5%88%A9%E7%94%A8%E8%80%85:Frozen-mikan/sandbox&diff=48779068&oldid=48778951 which used https://ja.wikipedia.org/wiki/Template:%E3%83%AA%E3%83%B3%E3%82%AF%E4%BF%AE%E6%AD%A3%E4%BE%9D%E9%A0%BC/%E6%94%B9%E5%90%8D

--------------------------
**Version**: unspecified
**Severity**: normal
AFAICT this is fixed; no recurrences in months have been reported.
Aha; sorry :).
Thank you.

(In reply to comment #0)
> which used
> https://ja.wikipedia.org/wiki/Template:
> %E3%83%AA%E3%83%B3%E3%82%AF%E4%BF%AE%E6%AD%A3%E4%BE%9D%E9%A0%BC/
> %E6%94%B9%E5%90%8D

I do not use this template. I used a dummy template. This is not created.
https://ja.wikipedia.org/wiki/%E5%88%A9%E7%94%A8%E8%80%85:Frozen-mikan/Template:%E7%A9%BA%E3%81%AE%E5%BC%95%E6%95%B0
Output after saving

My setup:

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

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

ParsoidServer:
commit a4fec47e5201c329925967376f4106abd11178e3
Merge: fdb6e06 30315ed Author: jenkins-bot <jenkins-bot@gerrit.wikimedia.org>
Date:   Fri Aug 9 02:43:12 2013 +0000


When I put in a simple Unsorted list the Parsoid Server throws an error message:
Incompatible constraints 1: LI P {a:{min: 0, max: 0}, b:{min: 1, max: 2}, min:0, max 0}


Attached you find the resulting output after I saved the page. Notice the extra Line that got added by Parsoid.

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

**Attached**: {F11826}
Change 78913 merged by jenkins-bot:
(Bug 52751): Serialize p-wrapped list items correctly

https://gerrit.wikimedia.org/r/78913
Change 78913 had a related patch set uploaded by Subramanya Sastry:
(Bug 52751): Serialize p-wrapped list items correctly

https://gerrit.wikimedia.org/r/78913
git bisect shows that c0de1d5839430e9fde79ff4195caf6841baab0d3 is the culprit.  Will investigate and fix.
I suspect this is a regression of some sort.  Can be duplicated with this HTML below (VE wraps li-content in p-tags).

[subbu@earth tests] echo "<ul><li><p>a</p></li></ul>" | node parse --html2wt
Incompatible constraints 1: LI P { a: { min: 0, max: 0 }, b: { min: 1, max: 2 }, min: 0, max: 0 }
* 
a
It is requested to implement a keyboard shortcut for Save the edits. Ctrl+Shift+S combination will be the most suitable for this, as it is being used by the conventional editor right now.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Merging with another suggestion for the same.

*** This bug has been marked as a duplicate of bug 50897 ***
> Ctrl+Shift+S

Sorry, I meant Alt+Shift+S
When you edit captions and input Japanese text with Japanese input method (of ことえり, the default Japanese method of Mac OS X), for example 生醤油 (kijouyu), the cursor will place itself after the first character, but it should place itself after the last (3rd) character. Tested on Firefox and OSX, but may happen in other browsers and operating systems. Thanks to Takashi Ota and Josh Lim for testing and reporting.

--------------------------
**Version**: unspecified
**Severity**: major
Given that this is now merged, I'm going to mark this as fixed. However, this is provisional - please re-open if you think that this has not worked!
Change 80080 merged by jenkins-bot:
Don't emit Surface changes back to the Surface

https://gerrit.wikimedia.org/r/80080
Change 80080 had a related patch set uploaded by Jforrester:
WIP:Don't emit Surface changes back to the Surface

https://gerrit.wikimedia.org/r/80080
Patch has been reverted due to other issues, sadly.
Doesn't seem to be happening any more.
This seems to be caused by a call to surfaceObserver.stop() in Surface's onDocumentKeyDown method, which is wrongly asynchronous. The same problem was affecting Malayalam and probably other scripts/IMEs too.

I *think* it should be fixed by https://gerrit.wikimedia.org/r/#/c/79451 (just merged).
Now I tested it myself on Fedora 18 with Firefox. It happens there too. To reproduce:

1. Enabled the "Japanese (Anthy)" keyboard in GNOME input sources.
2. In a VisualEditor window type "mitsubishi". It appears as four Kana characters: "みつびし".
3. Press the space bar. The four characters change to two Kanji characters: "三菱".
4. Press Enter. This accepts the Kanji representation.

Observed: The cursor is placed between 三 and 菱.
Expected: The cursor should be placed after 三菱. That is what happens in other text editors on my system.
The Swedish chapter would like to get Notifications enabled on their wiki at se.wikimedia.org. Please use the default settings.

Poll here: http://se.wikimedia.org/wiki/Tråd:Wikimedia:Bybrunnen/VisualEditor_och_Notifications

/Jan
CEO

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
Seems like this wiki was included in the last roll-out.
Thank you, it was my pleasure! Bear in mind that this is an additional request to enable it on the chapter wiki, and we do not need to wait for a specific date there, just turn it on at your will.
Thanks, Jan!

It was a pleasure to meet you at Wikimania last week.

I am so glad that the Swedish Wikipedia will be one of the first non-English Wikipedia to deploy Echo next week, as outlined in this release plan:

http://www.mediawiki.org/wiki/Echo/Release_Plan_2013

We're now scheduled to deploy on Tuesday August 20 at 12pm PT - on the French, Polish, Portuguese and Swedish Wikipedias, if all goes well. 

Please let us know if you have any final questions.

Cheers ...
I don't think Echo is under general deployment yet.

CC'ing Fabrice
Because we love Mark:

http://m.mediawiki.org/wiki/Extension:BetaFeatures

--------------------------
**Version**: unspecified
**Severity**: enhancement
Done in gerrit 91108.
Change 78795 merged by jenkins-bot:
Integrate with BetaPreferences

https://gerrit.wikimedia.org/r/78795
Change 78795 had a related patch set uploaded by Esanders:
[WIP] Integrate with BetaPreferences

https://gerrit.wikimedia.org/r/78795
When the list of potential articles is longer than the displayed list there is no way to see other articles without continuing to type part of the name. In some cases this isn't going to be much of a problem, but when there are lots of items that could have the same title (e.g. [[Nexus]]) it essentially requires you to know which disambiguator is used, defeating the point of the suggestions list.

--------------------------
**Version**: unspecified
**Severity**: enhancement
No, it was in error. Sorry!
James, did you mean to reopen this four seconds after closing it?
I believe that this was fixed in the scrollable-update in October. Sorry for the slow triage.
Screenshot FF, vector skin, mediawiki,ca-action

[Regression]: mw-notification-area makes vector-hover-dropdown closing
----
How to reproduce:
* Be an admin at Commons or have otherwise at least 3 entries in your ca-action dropdown.
* Fire mw.notify('foo') in your js-console
* Scroll to top
* Click the message ('foo') to "hide" it
* Hover the ca-action arrow.
* Try to click "protect" (see screenshot)

As soon as your cursor is over the mw-notification-area (made visible in other screenshot), the dropdown closes.

----
Expected behaviour: Can move/protect page. Dropdown does not close out of the blue.

--------------------------
**Version**: 1.22.0
**Severity**: normal

**Attached**: {F11622}
Change 158659 merged by jenkins-bot:
mediawiki.notification: Also hide #mw-notification-area upon creation

https://gerrit.wikimedia.org/r/158659
*** Bug 55457 has been marked as a duplicate of this bug. ***
Change 158659 had a related patch set uploaded by Catrope:
Followup 6c5b246: also hide #mw-notification-area upon creation

https://gerrit.wikimedia.org/r/158659
Change 109124 merged by jenkins-bot:
mediawiki.notification: Hide #mw-notification-area when it's empty

https://gerrit.wikimedia.org/r/109124
Rephrasing bug title as it was cut-off.
Thanks, Bartosz.
Change 109124 had a related patch set uploaded by Bartosz Dziewoński:
mediawiki.notification: Hide #mw-notification-area when it's empty

https://gerrit.wikimedia.org/r/109124
Ugh, I guess no one will do this if I don't.
I am resetting this to high priority only as per the maintainer judgement in comment 4.
jforrester: Should this really be highest priority (set in comment 7), or be
kept as high (as you did in comment 4)?
jforrester: Should this really be highest priority (set in comment 7), or be kept as high (as you did in comment 4)?
(In reply to comment #2)
> Unless somebody has a better idea, we should probably implement toggling
> 'display' in JavaScript.

If the ca-action dropdown is the only exposed UI problem, perhaps the ca-action dropdown buttons could have a higher z-index, as a temporary fix at least?

(In reply to comment #5)
> So I was right that VE is *pushed* by the Wikimedia Foundation:
> https://bugzilla.wikimedia.org/show_activity.cgi?id=52659

It certainly is. While this regression outside of VisualEditor codebase is regrettable, and hopefully will be fixed soon, the VE team have pushed lots of great JS into core, and fixed bugs like bug 38081 which will benefit Wikimedia Commons.

I have bumped the importance up (but not wedded to it) as it is a regression caused by VE and affecting non-VE environments, and was reported two months ago, and the code change causing it was deployed in July.

In addition to impacting sysops with three ca-actions, it also affects non-sysops on every wiki, although not as pronounced.  Non sysops only have the the 'Move' button in the ca-action dropdown of Vector, and it is partially inaccessible.  If the user slowly moves their mouse cursor down into the dropdown, they can click the move icon if the click on the first few pixels above the word 'Move' - if they continue going down so that their mouse cursor hovers over the word 'Move', the drop down disappears.
(In reply to comment #5)
> So I was right that VE is *pushed* by the Wikimedia Foundation:
> https://bugzilla.wikimedia.org/show_activity.cgi?id=52659

I'm confused. What are you saying?
So I was right that VE is *pushed* by the Wikimedia Foundation: https://bugzilla.wikimedia.org/show_activity.cgi?id=52659
From bug 55457 comment 0:

| 1. Trigger a notification
| 2. Click on the notification to dismiss it
| 3. The notification area (<div id="mw-notification-area">) is now empty, but
| still obscures a narrow strip in the top right corner:
| 
| > $('#mw-notification-area').outerHeight()
| 12
| > $('#mw-notification-area').outerWidth()
| 269
| > $('#mw-notification-area').position()
| Object {top: 89.59375, left: 1251.203125}
| > $('#mw-notification-area').css('z-index')
| "10000"
| 
| This is a problem because the div steals events and mouse interaction from the
| UI elements below it. For instance, in VisualEditor:
| 1. Open a page in VE
| 2. Type '[['. The wikitext warning appears
| 3. Click the warning to dismiss it
| 4. Reveal #mw-notification-area in the inspector and observe how it's on top
|    of part of the save button
| 5. Very carefully move the mouse over the save button, and you'll notice a
|    small (12px tall) area where mouse pointer is a normal pointer instead of a
|    hand. Clicking in this area does not press the save button.
*** Bug 55457 has been marked as a duplicate of this bug. ***
The culprit is this line:
	padding: 1em 1em 0 0;
in mediawiki.notification.css. It causes .mw-notification-area to have a non-zero height and thus cover other elements, like the dropdown.

There are two obvious ways to fix it which don't work:

* Change the padding to margin. This causes the notifications to "jump" slightly when scrolling, as detailed in commit message of https://gerrit.wikimedia.org/r/#/c/75614/

* Add .mw-notification-area:empty { display: none; }. This doesn't work on IE<9 and other old browsers. [http://caniuse.com/#feat=css-sel3]

Unless somebody has a better idea, we should probably implement toggling 'display' in JavaScript.
Created attachment 13078
Screenshot FF, vector skin, mediawiki, mw-notify

I suppose this regression was introduced by fixing https://bugzilla.wikimedia.org/show_bug.cgi?id=50870
- When I test locally (codebase about 4 weeks old), the menu/dropdown does not close unexpectedly.

**Attached**: {F11623}
Cache is now purged.  I tested on http://en.wikipedia.org/wiki/Crayon_Shin-chan (another page that had been reported with the bug) and verified fixed.
Fix deployed -- cache is not yet purged, but on purge tomorrow, this will be fixed.
Change 78242 merged by jenkins-bot:
(Bug 52638) Fix selser regression introduced by fix for bug 51217

https://gerrit.wikimedia.org/r/78242
Change 78242 had a related patch set uploaded by Subramanya Sastry:
(Bug 52638) Fix selser regression introduced by fix for bug 51217

https://gerrit.wikimedia.org/r/78242
Reduced test case on which the problem can be reproduced:

{|
{{echo|a}}
|-
|x
}}

This is a selser regression introduced by a fix for bug 51217.

A fix will be in shortly.
Confirmed. 

It is not a double-closed infobox.  It is an infobox within an infobox.  Although, I have gone through a number of these scenarios of infoboxes within infoboxes earlier and handled them in our regular serializer ... and confirmed that normal WTS (wt serializer) can handle it.  Now examining what gives selser the fits.

Thanks for the thorough testing and a way to reproduce it.  Will find a reduced test case and proceed.
**Author:** `sandrobt.wiki`

**Description:**
When trying to link a page with less than or equal to 3 characters, the page is often indicated as New Page in the link box. For example, try to link "A", "AB" or "ABB" on en.wiki (both with capital letters and in lower case, the latter being redirects). 

Notice that this problem doesn't happen with CD and NBA, but it does with Cd and Nba (all these pages are redirects on en.wiki).

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50898
*** This bug has been marked as a duplicate of bug 51013 ***
This is because VisualEditor relies on MediaWiki's search system to work out what pages exist, and the search engine ignores short strings as not worth bothering with.

We could theoretically fix this in VisualEditor with a hack, but fixing search would be a better solution.
*** Bug 53547 has been marked as a duplicate of this bug. ***
Indeed very, very odd. I've adjusted the bug summary to reflect the discovered behaviour. It is almost certainly unrelated to redirects though.
**sandrobt.wiki** wrote:

Another surprising case is "Cara" on it.wiki. It exists and it is not a redirect but is not recognized as existent (neither writing "Cara" nor "cara"), and "CARA" doesn't exist at all. 
So I guess this is not (only) related with redirects and it definitely appears also with pages with more than one character.
Hmm, not necessarily as simple as that as it recognises [[User:ABC]] and [[user:APL]]. It recognises both [[User:BBX]] and [[User:Bbx]] which are different pages and different users (the former Irish the latter a Finland-Swede).

It doesn't recognise [[User:Jim]] but that is a redirect to [[User:Jim (usurped)]].

It does recognise [[User:RVJ]], [[User:ZzZ]] and [[User:PQ3]]. 

I'm stumped!
(edit conflict)
Actually assuming that what happens in the user: namespace matches what happens in the article namespace then it is to do with the presence of a redirect. [[User:Rob]] exists but no pages (redirects or otherwise) exist for other capitalisations of those three letters. [[User:Rob]] does appear in the list of suggestions. Now whether that is this bug or bug 50898 I haven't got a clue, so I'll comment there as well.

(new text)
So it appears that it might be capitalisation related rather than redirect related - it works with sentence case Rob but not allcaps AB and FRA.
**sandrobt.wiki** wrote:

> Hmm, although redirects do exist at Ab and Fra which is probably confusing
> the
> issue. I think all TLAs exist as redirects or articles in uppercase and
> titlecase form so I don't know how to test this.

Also User:AB and User:FRA erroneously appear as non-existing (and user:Ab and User:Fra don't exist).
(In reply to comment #3)
> What about "AB" or "FRA"? Those are not redirects. Maybe "single character
> titles" is not accurate enough.

Hmm, although redirects do exist at Ab and Fra which is probably confusing the issue. I think all TLAs exist as redirects or articles in uppercase and titlecase form so I don't know how to test this.

(In reply to comment #4)
> Created attachment 13081 [details]
> Link dialog doesn't recognise that existence of single-character page names

This shows that it is the page name (excluding namespace) not the full page name (including namespace) that matters as [[User:A]] (which exists) is not recognised.

**Attached**: {F11470}
Created attachment 13081
Link dialog doesn't recognise that existence of single-character page names

**Attached**: {F11470}
**sandrobt.wiki** wrote:

What about "AB" or "FRA"? Those are not redirects. Maybe "single character titles" is not accurate enough.
Redirects not showing in the list are due to case sensitivity issues, see bug 50898 

Single character titles are never recognised, whether they are articles (e.g [[A]], [[Ä]]) or redirects, so I'm boldly refocusing this bug solely on this issue.
**sandrobt.wiki** wrote:

Maybe writing "short" in the title was a mistake (but anyway this bug appears more often with short titles): SEGA, FIDO and GOOGLE also are not recognized as existing pages. However these are all redirects, so perhaps this is another known independent issue?
From Cryptic C62:

Load VE on any page. Click and hold the left mouse button anywhere inside the browser window. Move the mouse on top of any button in the VE toolbar. Release the left mouse button. This activates the button.

--------------------------
**Version**: unspecified
**Severity**: normal
I cant reproduce any combination supported on Linux, or Firefox/Windows/monobook.
Does this still occur for anyone?
Using the version of VE currently live on en.wp in Firefox 24/monobook/Linux I can't reproduce this at all, not even the way I could in comment 2
After clarification I have done more testing and found that I can't reproduce this when any text is selected (including text in a table), but I can if the selection is exclusively an image or template (including an image in table).

Further Cryptic C62 uses Windows Vista not Windows 7.
Cryptic stated in the original bug report "Some testing shows that this is universal (Firefox/Vector, Opera/Vector, Safari/Monobook)". From other bug reports of theirs I believe that they run Windows 7.

I have not been able to reproduce this in Firefox 22 on Xubuntu linux using Monobook. The toolbar button depresses as if it were going to apply its function, but nothing actually happens.
As an editor has pointed out on Mediawiki, the link dialog appears below the selected link.  If an editor has selected text at the bottom of the visible page area, the dialog appears "below the fold" and the editor must scroll down to access it.  Dialog should be forced to appear in the area currently visible when it is activated.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 163228 merged by jenkins-bot:
DesktopContext: Ensure that inspectors/menus are fully visible when created

https://gerrit.wikimedia.org/r/163228
(This only affects inspectors, and they're a VE feature; moving.)
Change 163280 merged by jenkins-bot:
PopupWidget: Make $element not be a 0x0 box

https://gerrit.wikimedia.org/r/163280
Change 163280 had a related patch set uploaded by Bartosz Dziewoński:
PopupWidget: Make $element not be a 0x0 box

https://gerrit.wikimedia.org/r/163280
Change 163228 had a related patch set uploaded by Bartosz Dziewoński:
[WIP] DesktopContext: Ensure that inspectors/menus are fully visible when created

https://gerrit.wikimedia.org/r/163228
This is fixed for dialogs in gerrit 139550. It's not yet fixed for inspectors (which I suppose should scroll-into-view?).
At https://en.wikipedia.org/w/index.php?title=Indian_massacre_of_1622&oldid=564508110&veaction=edit, I can not unitalicize 'Nemattanew' ("In the spring of 1622, after a settler murdered his adviser ''[[Nemattanew]]'',") in Firefox/Iceweasel 21.  It marks it as unitalicized in the toolbar, but if you click away and click back it shows italics again.

I confirmed it wasn't related to my preferences by testing logged out (still in Firefox).  However, it does work fine logged out in Chromium.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=Indian_massacre_of_1622&oldid=564508110&veaction=edit
Change 114000 merged by jenkins-bot:
Fix ce#getOffset when cursor is to the left of an annotation.

https://gerrit.wikimedia.org/r/114000
Change 114000 had a related patch set uploaded by Esanders:
Fix ce#getOffset when cursor is to the left of an annotation.

https://gerrit.wikimedia.org/r/114000
(In reply to Ed Sanders from comment #3)
> Can't reproduce in FF 27. Can someone else?

Yes.
Can't reproduce in FF 27. Can someone else?
Confirmed. Very odd. Note that making the selection broader (e.g. a character either side of the link) lets you make it bold/remove italics/etc.

Sorry for very slow triage.
Note, the way I tried to unitalicize was by double-clicking the name (so it's all highlighted), then clicking the toolbar italics icon (which showed as enabled before I clicked).
It should go without saying, but you can't see it anymore when you scroll down, on occasion :D
A few unrelated ways to reproduce this:

1) http://en.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&diff=prev&oldid=567022295 here, the removed lines triggered this bug (original reporter experienced this while creating a page with that text). Also, when VEditing the version on the left, an "up arrow" before the very first word.

2) http://en.wikipedia.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandbox&diff=567025383&oldid=567025004 that is, throw some text on an existing link, you'll lose the toolbar as well.
Thanks.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52433
https://bugzilla.wikimedia.org/show_bug.cgi?id=52441
(In reply to comment #4)
> I can't reproduce this now, is anyone else still seeing it or can we presume
> that bug 52441 did fix the issue?

My test file doesn't show the problem any more, certainly: seems to be fixed, thanks.
I can't reproduce this now, is anyone else still seeing it or can we presume that bug 52441 did fix the issue?
Will the fix of Bug 52441 (awaiting deployment) also solve this?
Compare http://en.wikipedia.org/wiki/User:PamD/sandbox_for_VE/test2 (top bar disappears) http://en.wikipedia.org/wiki/User:PamD/sandbox_for_VE/test3 (no problem): only difference is addition of "a " before the linked text on first line. No other links, templates, complexities, in the files.
http://en.wikipedia.org/w/index.php?title=User%3APamD%2Fsandbox_for_VE%2Ftest1&diff=567087060&oldid=567086998  Unlinking the first word seems to have solved the problem. Given that most dab pages with titles in "Foo (disambiguation)" start off with a bolded link to Foo, this is a problem.
Specifically [[Template:Football kit]] which was created in 2004 by some young genius.

The rules which cause problems are:

.ve-ce-protectedNode * {
	position: relative !important;
	top: 0 !important;
	left: 0 !important;
	bottom: 0 !important;
	right: 0 !important;
...
}

in ve.ce.Node.css

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61497
Change 130823 merged by jenkins-bot:
Remove '*' selector for protected nodes

https://gerrit.wikimedia.org/r/130823
Created attachment 15263
Screenshot of problem and patched version

**Attached**: {F11282}
Change 130823 had a related patch set uploaded by Esanders:
Remove '*' selector for protected nodes

https://gerrit.wikimedia.org/r/130823
In the VE editing Window, VE does now not show references or only some of them on De.WP; both in editing the entire article and only the respective section:

http://de.wikipedia.org/wiki/Google#Einzelnachweise 1 out of 55

http://de.wikipedia.org/wiki/Chaim_Perelman#Einzelnachweise 0 out of 1

http://de.wikipedia.org/wiki/Seilkorb#Einzelnachweise 5 out of 15

http://de.wikipedia.org/wiki/Joan_Coromines#Fu.C3.9Fnoten 0 out of 3

Three people looked at it but it is hard to track down a pattern. Perhabs (wild ceteris paribus-guess) related to 51741?

Report:

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

--------------------------
**Version**: unspecified
**Severity**: major
This was fixed by https://gerrit.wikimedia.org/r/#/c/77346/1 . Apparently yet to deploy on de.wiki.
This looks like a bug we fixed recently with unnamed references. What version is deployed to de.wiki?
Does de.wp have more than one method of displaying references (equivalent to en's {{reflist}} and <references />)? If so then this could be related to bug 52371
Looks like we don't account for the API returning an error in ve.ce.MWTransclusionNode.prototype.generateContents. Unconditionally response.visualeditor.content is accessed.

API has a clear path both for dieUsage() and result === success.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 77460 merged by jenkins-bot:
ve.ce.MWTransclusionNode: Check for API errors

https://gerrit.wikimedia.org/r/77460
Change 77460 had a related patch set uploaded by Krinkle:
ve.ce.MWTransclusionNode: Check for API errors

https://gerrit.wikimedia.org/r/77460
We want to be able to treat some pairs (more than pairs?) of annotations as the same, edited in the same way:

* code / tt
* b / strong
* i / em

--------------------------
**Version**: unspecified
**Severity**: normal
Change 78204 merged by jenkins-bot:
Generic support for multiple tags in TextStyleAnnotation

https://gerrit.wikimedia.org/r/78204
Change 78204 had a related patch set uploaded by Catrope:
Generic support for multiple tags in TextStyleAnnotation

https://gerrit.wikimedia.org/r/78204
code/tt duplicate of bug 52352
VE changed the edit tab selectors as part of their UI update to show it's in Beta.

Now, on English Wikipedia, with VE enabled:

* ca-edit is source editing
* ca-ve-edit is VE editing

In a blacklisted browser:

* ca-edit is source editing
* ca-ve-edit is hidden

The tours need to be adjusted accordingly.

--------------------------
**Version**: unspecified
**Severity**: major
Change 78026 merged by jenkins-bot:
Update VE section edit selector

https://gerrit.wikimedia.org/r/78026
Change 78026 had a related patch set uploaded by Mattflaschen:
Update VE section edit selector

https://gerrit.wikimedia.org/r/78026
Change 77387 merged by jenkins-bot:
Update to match new VisualEditor edit tab selector

https://gerrit.wikimedia.org/r/77387
Change 77387 had a related patch set uploaded by Mattflaschen:
Update to match new VisualEditor edit tab selector

https://gerrit.wikimedia.org/r/77387
**swalling** wrote:

Yes, without this fixed I get the gettinstartedtasktoolbarve tour (meant for VE) pointing to edit source, not the new beta tab. 

Thankfully it's just missing some steps, not causing any visibly broken or confusing behavior.
From user:PamD at en.wp:

Clicking on the "Read the User Guide" link (within the Beta/questionmark popup) has the effect of losing all current editing, because it opens the User Guide in the current window, without warning that it's going to do so. Imagine: half an hour's editing, find a problem, remember seeing that link and think it might offer advice, click for the popup, click to open the User Guide, and ... one very unhappy editor. I suggest that either the User Guide should open in a new tab or window, or, if this is impossible, there should be a warning "Read the User Guide (and lose any current edits)".

--------------------------
**Version**: unspecified
**Severity**: normal
Thanks for the reply, that is very useful to know.

Brevity is not my strong suit so I've refrained from making a change to it myself. I've asked for suggestions at [[WP:VE/F#User Manual should open in new tab/window]], feel free to opine.
The text is controlled by https://en.wikipedia.org/wiki/MediaWiki:Visualeditor-help-label - but I'd counsel against putting a lot of text into it, as it may not look very good.
Thanks for the super-quick fix.

As for the wait until deployment, would it be possible to add something like "(hold CTRL while clicking this link to open it in a new window)" before this goes live?
If not it's not worth doing anything, but if we can as an interim measure help some people that's better than nothing.
Now fixed in the code; next scheduled deployment is not until 15 August, however. :-(
Change 77374 merged by jenkins-bot:
Make the link to the user guide open in a new window

https://gerrit.wikimedia.org/r/77374
Change 77374 had a related patch set uploaded by Jforrester:
Make the link to the user guide open in a new window

https://gerrit.wikimedia.org/r/77374
Marking as high priority like similar bug 52093
en.wp user:Wouterstomp asks.
"When no image is found, please display a message saying so, now it looks like nothing is happening (especially [if you] missed the short busy animation of the search bar)"
The context is the image insertion dialog.

--------------------------
**Version**: unspecified
**Severity**: trivial
Verified in production
Verified the fix in Betalabs
Change 133864 merged by jenkins-bot:
Hide 'no results found' once there's at least one result

https://gerrit.wikimedia.org/r/133864
Change 133864 had a related patch set uploaded by Jforrester:
Hide 'no results found' once there's at least one result

https://gerrit.wikimedia.org/r/133864
Change 133858 merged by jenkins-bot:
Hide 'no results found' once there's at least one result

https://gerrit.wikimedia.org/r/133858
Change 133858 had a related patch set uploaded by Mooeypoo:
Hide 'no results found' once there's at least one result

https://gerrit.wikimedia.org/r/133858
Created attachment 15419
Screenshot

**Attached**: {F11195}
The message "No results found" stays in the dialog even if user changed the search string and the matched images appear inside the dialog.See the screenshot attached
Change 133050 merged by jenkins-bot:
If no media is found display a message in media insert dialog

https://gerrit.wikimedia.org/r/133050
Change 133050 had a related patch set uploaded by Mooeypoo:
If no media is found display a message in media insert dialog

https://gerrit.wikimedia.org/r/133050
WhatamIdoing, there is a design that has not been implemented yet for the image dialog that allow quick access to users uploads, perhaps in the case of zero search results, we can automatically show that mode.
*** Bug 60932 has been marked as a duplicate of this bug. ***
Given the fact that users often want to add the image that they just uploaded, and that Commons's search is fairly often taking a couple of days to "notice" that these images exist, the default message on wikis that use Commons should say something like "No image was found.  If you just uploaded an image with this name, this may be due to the image not being indexed in Commons's search database yet.  Please try again in a couple of days."

It might also be worth linking to a help page that describes limitations in the search protocol.  For example, it will find images if I give it the whole name ("2013AliceAndBob") but not if I give it just the start of the name ("2013Alice").
When a user tries to inset an image or other media while they have text selected, the text is replaced by the media. This probably is not what they want and is contrary to how the transclusion editor works (inserts the template after the selected text).

--------------------------
**Version**: unspecified
**Severity**: normal
Change 82463 merged by jenkins-bot:
Insert images after selection, not in place of it

https://gerrit.wikimedia.org/r/82463
Change 82463 had a related patch set uploaded by Trevor Parscal:
Insert images after selection, not in place of it

https://gerrit.wikimedia.org/r/82463
As of recently the toolbar no longer goes in/out of floating mode after opening an inspector. It will stay in whatever position it was (fixed/absolute, top/left/right/height)

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52504
*** Bug 52739 has been marked as a duplicate of this bug. ***
*** Bug 52789 has been marked as a duplicate of this bug. ***
*** Bug 52433 has been marked as a duplicate of this bug. ***
*** Bug 52326 has been marked as a duplicate of this bug. ***
Now fixed in the code; next scheduled deployment is not until 15 August,
however. :-(
Change 77274 merged by jenkins-bot:
ve.ui.Toolbar: Use closure instead of ve.bind for event handlers

https://gerrit.wikimedia.org/r/77274
Change 77274 had a related patch set uploaded by Krinkle:
ve.ui.Toolbar: Use closure instead of ve.bind for event handlers

https://gerrit.wikimedia.org/r/77274
Similar to bug 51289 and bug 52398 references that are defined in image captions do not appear in reflists. Example at [[Radiocarbon dating]].

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51289
https://bugzilla.wikimedia.org/show_bug.cgi?id=52398
https://bugzilla.wikimedia.org/show_bug.cgi?id=50459
Re-setting as FIXED, and have raised the regression as bug 57228.
<<[...] the references 20 and 21 in https://en.wikipedia.org/wiki/Baruch_Spinoza?veaction=edit which are in image captions disappear from the references list in VE and the numbering becomes discombobulated. Win7 FF 24.0 Monobook. --Atethnekos (Discussion, Contributions) 05:42, 12 November 2013 (UTC)>>.
Change 77346 merged by jenkins-bot:
Only skip past empty keyedNodes sets if key exists

https://gerrit.wikimedia.org/r/77346
Change 77346 had a related patch set uploaded by Esanders:
Only skip past empty keyedNodes sets if key exists

https://gerrit.wikimedia.org/r/77346
**kwwilliams** wrote:

52300 may also be related.
At https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=566679647#Spellchecking_wikilinks_causes_odd_behavior en.wp editor Cryptic C62 has identified that spellchecking links causes inconsistent and apparently unpredictable behaviour. Undoing that change sometimes introduces another layer of inconsistent behaviour.

On some occasions both correcting the spelling and undoing it works as it should, but there are at least six types of undesired behaviour where some or all of the link is unlinked. 

Detailed examples are at the above link.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 50822 ***
**crypticc62** wrote:

I've found that a similar problem occurs with Chrome on an iPad 3, though with very different results. In this environment, the spellcheck seems to work fine, but undo causes the original string to be appended to the new string, rather than replacing it.
The current beta notice for VisualEditor is currently easy to miss. While it uses a circled "?" and the text "BETA", it can blend in with the rest of the VisualEditor editing interface pretty easily (I only really noticed that there was any kind of warning today).

The notice that VisualEditor is beta software should be made more prominent.

James has suggested showing a more prominent notice for first-time VisualEditor users (presumably based on a cookie).

My preference is to make the notice dismissable (using a hidden user preference).

--------------------------
**Version**: unspecified
**Severity**: normal
We've now made a modal dialog pop up warning the user about the beta status of VisualEditor, and labelled VisualEditor as "beta" on its edit tab (and the edit section links that launch it).

I'm going to presumptively (;-)) mark this as "fixed", but please re-open if you think we should do more.
One of the pain points we're seeing is that disabling VisualEditor is cumbersome. Even though there's now a user preference to disable the software, going to [[Special:Preferences]] is disruptive to user workflow.

James and I discussed the possibility of adding a switch to the user interface to enable or disable VisualEditor.

This switch might be located in the personal tools section, it might be a sidebar section, or it might be elsewhere. It should be viewable from ?action=view, ?action=edit, and ?veaction=edit.

This switch might affect only VisualEditor or it might affect all "beta" features deployed to Wikimedia wikis.

This switch will be available to both logged-in users and anonymous users.

I believe this is a high priority bug to address.

--------------------------
**Version**: wmf-deployment
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54862
BetaFeatures is in place for this now.
Hi MZMcBride, a desktop framework for beta testing features is already underway[1}, although it was originally envisioned for smaller experiments we can certainly think about the idea of leveraging it for larger pieces of functionality as well. 


[1] http://www.mediawiki.org/wiki/Beta_Experiments
wrapped inline alien: incorrect highlighting in chromium

If an inline alien gets word wrapped, then selecting it leads to incorrect highlighting.

Reproducing: make a <tt> ... </tt> with enough content to word wrap. Select with the mouse (or use CTRL+A).

In chromium, the highlighter erroneously draws a box enclosing the first character and the last (see first attachment).

In firefox, the highlighter erroneously highlights to the end of the first line only (see second attachment).

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

**Attached**: {F11839}
*** Bug 67062 has been marked as a duplicate of this bug. ***
Change 139805 merged by jenkins-bot:
Shields are dead, long live getClientRects

https://gerrit.wikimedia.org/r/139805
Change 139805 had a related patch set uploaded by Esanders:
Shields are dead, long live getClientRects

https://gerrit.wikimedia.org/r/139805
Created attachment 13036
wrapped inline alien: incorrect highlighting in firefox

**Attached**: {F11840}
Created attachment 13035
wrapped inline alien: incorrect highlighting in firefox

//attachment wrapped-inline-alien-firefox.png ignored as obsolete//
Toolbar overlapping page head links Firefox 22/Linux/Monobook

In Firefox 22 on Linux with Monobook skin (not tested in other combinations) sometimes the VE toolbar overlaps the page head links and tabs (userpage etc). See the screenshot.

I haven't figured out how to reliably reproduce this but the following sequence /usually/ seems to work.
1. Make one or more changes to a page in VE
2. click on an element near the left or bottom of the window (to trigger bug 52317)
3. open the save page dialog
4. with the dialog still open, scroll to the very top and very bottom of the page
5. close the save dialog without saving
6. click a different element and repeat steps 3 to 5.
7. scroll to the top of the screen and observe the position of the toolbar.

If it doesn't work, try again from step 2.
It doesn't always work, but actions like this do seem to trigger it more often than not. I don't know whether this is dependent on bug 52317 but it was in testing that bug that I found this one.

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

**Attached**: {F11800}
I guess https://bugzilla.wikimedia.org/show_bug.cgi?id=52433 is a duplicate then?
Thanks.
This was fixed last week (but not deployed yet, sorry) - merging with the other report.

*** This bug has been marked as a duplicate of bug 52441 ***
users Jay8g and Wouterstomp at en.wp have confirmed this happening in "Monobook, FF 22, Windows 7" and in Chrome (presumably on Windows) respectively.

Jay8g provided a screenshot at https://en.wikipedia.org/wiki/File:VE_error-top_bar_over_toolbar.jpg
**sandrobt.wiki** wrote:

It happen to me several tipe with MacOS 10.6 and Firexfox 22.0. 

I didn't need to do all those step to get this bug, it was enough to scroll down, modify something and then go back up. It doens't always happen, but when it doesn't, it is usually enough to repeati the above operation to get the overlapping.
User CrypticC62 at en.wp has reproduced this in the following environments:


    Firefox 22 / Monobook / Windows Vista: Reproduced (followed steps, occurred in one attempt)
    Chrome 28 / Vector / Windows Vista: Found similar effect after step 3. See screenshot.


The screenshot referred to is [[File:VE Chrome Toolbar Overlap.png]]
When working with tags in edits, the tag can be localised in the page history (and recent changes, etc.). For example the history of [[mw:Localisation]][1] shows "(Tag: VisualEditor)" where "tag" links to [[mw:Special:Tags]] and "VisualEditor" links to [[mw:VisualEditor]].

When viewing the same history in Dutch[2], this log line part displays as "Label: Visuele tekstverwerker", which in itself is a correct localisation for Dutch. When inspecting the links, the following observations are made:

Observed:
I. "Label" links to Special:Tags (expected)
II. "Visuele tekstverwerker" links to "Visuele tekstverwerker"

Expected:
III. "Visuele tekstverwerker" links to the documentation page in the content language (in this example "VisualEditor"). Otherwise each wiki would be expected to have documentation in all usable user interface languages (or at least redirects) to avoid red links.

[1] https://www.mediawiki.org/w/index.php?title=Localisation&action=history&uselang=en
[2] https://www.mediawiki.org/w/index.php?title=Localisation&action=history&uselang=nl

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed; we'll deploy this later today.
Change 76763 merged by jenkins-bot:
Partial revert of gerrit 8ed6dfa5423 to avoid i18n mis-links

https://gerrit.wikimedia.org/r/76763
Change 76763 had a related patch set uploaded by Jforrester:
Partial revert of gerrit 8ed6dfa5423 to avoid i18n mis-links

https://gerrit.wikimedia.org/r/76763
This was caused by gerrit 75559 - will partially-revert.
Right. It should probably be [[{{MediaWiki:visualeditor-descriptionpagelink}}|VisualEditor]].
[[mw:MediaWiki:Tag-visualeditor]] is using int: to fetch the visualeditor-descriptionpagelink, that should be done only for the content language. The link should be changed to {{MediaWiki:visualeditor-descriptionpagelink}}.

That is a problem in VisualEditor, moving component
Mike Christie at en.wp reports that when performing the sequence: 
1. copy template, 
2. paste template, 
3. edit parameter of pasted template, 
4. paste template
Step 4 pastes the template with the parameter values added in step 3 not the original ones.

"To reproduce:

1   Edit [[User:Mike Christie/Sandbox3]] in VE.
2   Select the 13 C (produced with {{chem|13|C}} ) in the middle using the mouse; make sure to select some text on either side, since pasting a template doesn't work unless it's embedded in a string. The colons are there to make it easy to be sure you've got some text in addition to the template.
3    Copy the selected text and then paste it at the end of the sentence.
4    Click on the pasted template, click on the jigsaw piece, and change the 13 in parameter 1 to a 15. Apply changes.
5    Now paste again at the end of the sentence. You'll see that the pasted template contains a 15, not a 13; so the copy/paste buffer was modified by the edit to the pasted template."

Another test case using a different template:
1. Edit https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox&oldid=566402676#Section_3:_tl.2C_etc_templates_added_in_VE in VE
2. select "tlp: {{tlp|as of|1999}} :" and copy it to the clipboard
3. paste the template elsewhere.
4. edit the template you have just pasted (change parameter 2 to 2013) and apply the changes.
5. paste the template again.
Expected result: tlp: {{tlp|as of|1999}} :
Actual result: tlp: {{tlp|as of|2013}} :

Interestingly, pasting into a text editor gives the 1999 value as originally copied, not the 2013 value you get pasting into VE.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49396
(In reply to comment #2)
> This appears to be fixed in master.

Confirmed - fixed in master, broken in wmf15. Marking as such.
This appears to be fixed in master.
Mike Christie comments further:
What is saved is not always what you see on screen.

To reproduce in a sandbox:

Add a template such as {{chem}}; I used 14C, created by {{chem|14|C}}. Put some text on either side of it so you can copy/paste it with text, since templates won't copy/paste successfully by themselves.

Save that page, and edit again.


Now copy the template and paste it twice, so you have something like this:
-- 14C -- -- 14C -- -- 14C --

Now edit the first pasted one -- the middle one in the example above -- so that it changes a parameter:

-- 14C -- -- 12C -- -- 14C --

Paste again; the pasted version will be 12C, which is bug 52271.

a) I've seen two different behaviours for the next step. One is that you'll now see this:

-- 14C -- -- 12C -- -- 14C -- -- 12C --

but when you save the third one will be a 12 -- that is, it will have changed what you see on screen to be different in the saved file.

b) The other behaviour I've seen is that after the final paste, all four of the templates show "12", not "14".
ve.Factory.prototype.create throws an Error, "No class registered by that name: undefined" when using the link widget.  It can be reproduced with:

1. Start with blank document
2. Hit Ctrl-K
3. Type some page name that doesn't exist
4. Hit escape twice.

This leaves a broken widget that takes several clicks (not sure the exact pattern here) to clear.

5. Try to open the link widget again.  It won't be possible, either with Ctrl+K or the button.

This is live on English Wikipedia.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50446
This seems to be fixed by https://gerrit.wikimedia.org/r/#/c/81437/
It also copies the page name from the link widget to the document as apparent plain text, even though you exit out with double-ESC.
Created attachment 13014
Broken link widget after pressing Ctrl-K on empty page, then exiting

**Attached**: {F11679}
See https://sv.wikipedia.org/w/index.php?title=Tjeckiens_president&diff=22846804&oldid=21540497 and https://pl.wikipedia.org/w/index.php?title=Mi%C4%99dzynarodowa_Federacja_Tenisa_Sto%C5%82owego&curid=407381&diff=37148333&oldid=37118048 - no duplication (ahahaha) steps of which I'm aware, I'm afraid.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54169
Going out in a little while.
Change 76665 merged by jenkins-bot:
Don't duplicate categories when unlisting

https://gerrit.wikimedia.org/r/76665
Change 76665 had a related patch set uploaded by Catrope:
Don't duplicate categories when unlisting

https://gerrit.wikimedia.org/r/76665
Isolated test case:

1. Create a page with "*Foo\n[[Category:Bar]]\n[[Category:Baz]]"
2. Edit the page in VE
3. Move the cursor to the end of the list item and press enter. This creates a new list item and puts the cursor in it
4. Click the list button (the one that's depressed) in the toolbar. This causes the list item to go away and makes the cursor jump out of the list.
5. Review changes. The diff will duplicate both of the categories at the beginning of the page, preceded by a newline.
http://youtu.be/1rmp5rTDPOM
Following a report of the issue by a user, I attempted to add multiple consecutive references. I began with bare URLs and started with 6. You can see that VE thinks it is going okay (http://en.wikipedia.org/wiki/File:VEmultiref.png), but when you save it only saves one (http://en.wikipedia.org/w/index.php?title=User%3AMdennis_%28WMF%29%2Fsandbox&diff=566304458&oldid=566304152)

I tested it all the way down to two.

In case it was an issue with bare refs, I tried it using citation templates, and it would also not save two in a row. It still only saved one:
http://en.wikipedia.org/w/index.php?title=User%3AMdennis_%28WMF%29%2Fsandbox&diff=566306613&oldid=566306049

I'm using Chrome, Windows 7.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #6)
> Users are reporting that VE is still not saving multiple references:

Unfortunately, this is "again", not "still", and is caused by bug 53434 in Parsoid, I think. :-( Marking this as "fixed" but highlighting on that one how urgent this is. Sorry for the disruption.
Users are reporting that VE is still not saving multiple references:

Reported today by The Devil's Advocate
if I add multiple citations to back a statement, the Visual Editor only saves the first citation I added. This happened once when I added three citations to back a claim and had to add each one individually over the course of three edits and again just now when I had to add a second citation after it didn't get saved. Multiple citations can be added if they are separate as I had added a citation for another statement in the same edit and it was saved.

Reported on the 22nd by Sue Gardner
Last night I created a new article with multiple references, and when I saved the page many of the references disappeared and some I think had jumped around. (I didn't save-as-I-went -- I wrote the whole thing and saved once, at the end.) I can't describe exactly what happened, but here's a diff: [1] the latest revision [2] is roughly what I was aiming to do, and the earlier revision [3] is what I actually achieved. (Ignore the missing reflist: I just hadn't gotten around to figuring out how to add it in VE yet, so I did it afterwards in wiki syntax.)

So, in my initial VE save, it looks like references #5, 6 & 7 disappeared as did #14 and 15. (Numbers taken from the latest revision.) This suggests to me there's a problem with VE saving multiple adjacent references -- when there are multiples adjacent, it seems to save only the first. I think also some references jumped around, but I'm not 100% sure about that.

[1] https://en.wikipedia.org/w/index.php?title=Mansplaining&diff=569638597&oldid=569526861
[2] https://en.wikipedia.org/w/index.php?title=Mansplaining&oldid=569638597
[3] https://en.wikipedia.org/w/index.php?title=Mansplaining&oldid=569526861
*** Bug 52269 has been marked as a duplicate of this bug. ***
Fixed and will get deployed in a little while.
Change 76836 merged by jenkins-bot:
Remove the DM 'about' attribute from references and reference lists

https://gerrit.wikimedia.org/r/76836
Change 76836 had a related patch set uploaded by Catrope:
Remove the DM 'about' attribute from references and reference lists

https://gerrit.wikimedia.org/r/76836
This happens because we send Parsoid something like

<span about="undefined" typeof="mw:Extension/ref" data-mw="..."></span><span about="undefined" typeof="mw:Extension/ref" data-mw="..."></span>

which then gets about-grouped. We need to just drop the about attribute if we don't have it.

Ironically we've had breakage in the other direction before, where Parsoid output multiple adjacent images with about="null". Karma's a bitch :)
+++ This bug was initially created as a clone of Bug #50170 +++

1. Edit [[mw:VisualEditor:Sfioj]] in VE
2. Make a selection such as

     These wor[ds are ve]ry bold

3. Click the "Bold" button on the toolbar

The selected text goes extra-bold, in Firefox 22. 

I should mention that in my case, the font is Arial, which has an extra bold "Arial-Black" variant.

Basically the same as 50170 except that this is narrower.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 119282 merged by jenkins-bot:
Prevent comparable annotations from being applied twice

https://gerrit.wikimedia.org/r/119282
Change 119282 had a related patch set uploaded by Esanders:
Prevent comparable annotations from being applied twice

https://gerrit.wikimedia.org/r/119282
No it isn't: if you follow the STR, you will still see this bug on Firefox 25.
This was the same bug as bug 50170, however; merging.

*** This bug has been marked as a duplicate of bug 50170 ***
(In reply to comment #0)
> this is narrower.

A narrower set of circumstances, not a narrower font!
**Author:** `jonathan_haas`

**Description:**
To reproduce:

Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit

1. Click on infobox
2. Hit the "a" key
3. Hit ctrl+z

Repeat steps 1-3 as long as necessary (about 1-6 times)

Current result:

Instead of being restored on ctrl+z, sometimes the infobox is replaced by a pawn.
The article begins with "♙The Binding of Isaac" then.

Also, ctrl+z should probably also restore the selection, so I think it's another bugh that you have to repeat step 1 every time.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52113
Pressing anything other than delete no longer does anything for me, which seems sensible.
Bumping; this is happening 100% of the time now.
**jonathan.haas** wrote:

Using the current Firefox 27 alpha (Aurora build), the problem seems to be much worse, as the pawn appears reliably in step 2 just after pressing "a". Maybe it's a different issue, but maybe it helps debugging this one.

TBH, this pawn stuff seems to be very weird and unstable to me. Why can they appear in the first place?
I can occasionally reproduce this in Chrome and Firefox, but not reliably (roughly 1 in 10 replacements). Race condition on the change stack or something?
**p.selitskas** wrote:

I could reproduce this with cyrillic letters in be-x-old.wikipedia.org, at least a few weeks ago.
I can't reproduce after about 20 tries in Firefox 23/Linux/Monobook
**jonathan_haas** wrote:

Screenshot

Also managed to reproduce in Chrome 28.

No error in javascript console in both browsers.

**Attached**: {F11523}
**jonathan_haas** wrote:

I still can (FF23). Just managed on first try.
Can't reproduce in Chrome or FF
This is possibly bug 51532
Reproduced; I havent looked to see if this scenario has been reported already.
**Author:** `jonathan_haas`

**Description:**
I can't find a possible way to add or edit tables, except changing the content of cells.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52641
post-deploy testing in test2 - VisualEditor has added functiona lity to insert/remove tables and modify tables - insert columns and rows  in tables.
Done in gerrit 159310 and related stack.
Swedish Wikipedian Sebbes333 [1] reports here [2] that he "would like to insert a new column in a 2D table, [however] do not think it will go into beta editor yet." 

[1]
https://sv.wikipedia.org/wiki/Anv%C3%A4ndare:Sebbes333

[2]
https://sv.wikipedia.org/wiki/Wikipedia:VisualEditor/%C3%85terkoppling#Infoga_ny_kolumn_i_en_2D_tabell_i_beta_redigeraren.
*** Bug 53325 has been marked as a duplicate of this bug. ***
Ok, will move it elsewhere. Thanks.
**jonathan_haas** wrote:

(In reply to comment #2)
> <<I was editing my userpage with VE today, and I noticed that, in the part
> of a
> table with an empty cell, VE seemed to move the two pipes inside the cell on
> the left, and the empty cell didn't show. -- t numbermaniac c 03:02, 6 August
> 2013 (UTC)>> (first line of the Redirect table in
> http://en.wikipedia.org/wiki/User:Numbermaniac?veaction=edit ).

Confirmed, but I think this deserves another, separate bug report.
<<I was editing my userpage with VE today, and I noticed that, in the part of a table with an empty cell, VE seemed to move the two pipes inside the cell on the left, and the empty cell didn't show. -- t numbermaniac c 03:02, 6 August 2013 (UTC)>> (first line of the Redirect table in http://en.wikipedia.org/wiki/User:Numbermaniac?veaction=edit ).
I couldnt find another bug for creating tables.
screenshot

When using German language (on German and English Wikipedia, but also likely everywhere else), the layout of the minor changes & watchlist checkboxes on the save dialog is not appropriate when viewed in Firefox.  Attached is Vector; same problem exists in Monobook.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52176

//attachment VE_de_Firefox_save_dialog .png ignored as obsolete//
The line-height is too large and the second line is offset to left.
Reset as FIXED. The screenshot you attach looks normal - could you annotate the parts you think aren't correct? Probably as a new bug…
Created attachment 13820
Screenshot, 2013-11-17 (in Polish)

This appears to still not fixed :( I'm adding an up-to-date screenshot.

**Attached**: {F11479}
The fix for this is now merged and will be deployed on Thursday 10 October to MediaWiki.org, and to Wikipedias on Thursday 17 October.
Change 81876 merged by jenkins-bot:
Make the save dialog an actual dialog

https://gerrit.wikimedia.org/r/81876
*** Bug 54802 has been marked as a duplicate of this bug. ***
Change 81876 had a related patch set uploaded by Jforrester:
Make the save dialog an actual dialog

https://gerrit.wikimedia.org/r/81876
Created attachment 13242
pl.wp screenshot

It breaks particularly badly on wikis with FlaggedRevs.

//attachment 2013-09-04 22_07_50-Edytujesz Rafał Kosik - Wikipedia - Opera.png ignored as obsolete//
*** Bug 52176 has been marked as a duplicate of this bug. ***
Created attachment 12997
Windows 7 screenshot

Font is obviously a contributing factor here; on Windows the layout problem almost disappears.

//attachment VE_de_save_dialog_checkboxes_Firefox_on_Windows.png ignored as obsolete//
**Author:** `jonathan_haas`

**Description:**
To reproduce:

1. Goto http://de.wikipedia.org/wiki/Hint
2. Open visual editor
3. Select all (ctrl+a)
4. Enter "foobar" (without quotation marks)

Expected: 

- page contains "foobar"

Actual:

- page contains

ffoffoffoffoofbar|foffoffof
foo


| = cursor position

--------------------------
**Version**: unspecified
**Severity**: major
Confirmed now fixed.
WFM in Firefox
(In reply to Jonathan Haas from comment #4)
> The underlying bug doesn't seem to be fixed.
> 
> To reproduce (Linux, Firefox):
> 
> 1. Copy the Text "Foundation" (without quotation marks) to the clipboard
> 2. Open: https://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
> 3. Select all (Ctrl+A)
> 4. Paste Clipboard (Ctrl+V)
> 5. Type "foobar"
> 
> Expected result:
> 
> Page contains "Foundationfoobar"
> 
> Actual result:
> 
> Page contains:
> 
> obar|
> 
> oo
> 
> fo
> Foundationf


Interesting. This worked for me when I tested it, but doesn't now; perhaps it's content-driven (as well as being a symptom of how broken bits of Firefox are).
**jonathan_haas** wrote:

The underlying bug doesn't seem to be fixed.

To reproduce (Linux, Firefox):

1. Copy the Text "Foundation" (without quotation marks) to the clipboard
2. Open: https://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
3. Select all (Ctrl+A)
4. Paste Clipboard (Ctrl+V)
5. Type "foobar"

Expected result:

Page contains "Foundationfoobar"

Actual result:

Page contains:

obar|

oo

fo
Foundationf
Was fixed by something Ed did a while ago.
**jonathan_haas** wrote:

Note that the above result was created using Firefox 23.

Chrome 28 produces the following (equally wrong) result:

fbar|ofo
o
foo
Reproduced.
When a reference is edited, the updated version will not appear in the reference list when attempting to insert an existing reference. Instead, the reference that will appear in the reference list will be the reference as it was when the page editing started.

To reproduce, go to a page with references. Edit one of the references, and don't save. Then, do as if you wanted to insert an existing reference and look at the list of existing references. The edit to the reference you have edited will not appear.

--------------------------
**Version**: unspecified
**Severity**: normal
@Cainamarques, please see https://bugzilla.wikimedia.org/show_bug.cgi?id=57209 and comment there if you really manage to properly see and choose from the list of reusable references. Thanks.
This bug seems to be fixed, I can perfectly edit and reuse references using Firefox 25.0
(Wondering if this is related to https://bugzilla.wikimedia.org/show_bug.cgi?id=51689.)
Likewise, the reference list is not updated if I add a new reference to the page, thus being unable to reuse it in the current edit.
Confirmed.  Use existing reference shows original references, before they were modified.
When an existing reference is inserted, it is put at the start of the paragraph the cursor is currently in, regardless of where it is in that paragraph. This has happened to me while I was attempting to use in a paragraph a reference that was already used in that paragraph: the reference got inserted at the start of the paragraph and I was not able to move it. I tried again some times but it still did not work and I had to use the wikitext editor.

--------------------------
**Version**: unspecified
**Severity**: normal
*** Bug 52594 has been marked as a duplicate of this bug. ***
Should now be fixed; we will deploy this earlier than scheduled, later today.
Change 80056 merged by jenkins-bot:
Preserve selection when inserting references

https://gerrit.wikimedia.org/r/80056
Change 80056 had a related patch set uploaded by Esanders:
Preserve selection when inserting references

https://gerrit.wikimedia.org/r/80056
AFAICT this only happens in the first paragraph (and only in Firefox).

This is throwing an error in Rangy:

  TypeError: sel.nativeSelection is null
  sel._ranges.length = sel.rangeCount = sel.nativeSelection.rangeCount;

… but for some reason I can't get Firebug to give me a trace.
At en.wp WhatamIdoing reports:
I was just trying to add the ref to the other sentences. It misplaced two copies at the start of the paragraph when I wanted one at the end of the first line of the first paragraph (perhaps I clicked too high on the top line of the edit window?). After I removed those, I couldn't add any more. Clicking the ref button did nothing." He gives the following URL:
https://en.wikipedia.org/w/index.php?title=Swing_%28seat%29&diff=568557479&oldid=568556853
I have done similar manipulations in other articles at some moments, and it seems it sometimes works and sometimes doesn't. There are many things that are strange concerning how the existing references system works.

Regardless, I set up a sandbox page on my user space, added a reference and then tried to re-use that reference using the VisualEditor. The reference was added at the start of the paragraph. I've done some more experimenting, and I've written steps to reproduce the bug; the first block reproduces the bug and the following blocks are other experimentations that give more strange results.

1. Go to [[User:Rastus Vernon/VisualEditor Sandbox]].
2. Edit the page with the VisualEditor.
3. Click somewhere in the first paragraph, not at the start.
4. Click on the reference button and re-use the reference (there is only one).
5. Note how the reference was inserted at the start of the paragraph instead of being inserted where your cursor was.

6. Click in another paragraph, not at the start.
7. Insert the same reference again.
8. Note how the reference was inserted at the right position.

9. Perform steps 7 and 8 again.
10. Note how it was again inserted at the right position, although the reference is already in that paragraph.

11. Try inserting it again in the first paragraph.
12. Note how it still inserts it at the start of the paragraph instead of inserting it in the right location.

13. Be confused because you don't understand anything about this inconsistent behavior.
I did only a quick test, and could not reproduce this bug.  Could you give more detailed instructions?
Tested on Firefox 22 (Monobook) and Chrome 28 (Vector)

Steps to reproduce:
- Edit the [[Nodeulseom]] page in the visual editor.
- Click reference [1] and edit it.
- Click the hyperlink in the reference and point it to "http://www.koreatimes.co.kr/" (Eg: Just remove the last part from the reference)
- Apply the change.
- Hit "Save Page" and review the changes.

Instead of replacing the old link, it seems that the preview suggest that the link will be duplicated, leaving both the old and new link in the reference.

(Diff)
<ref>[http://www.koreatimes.co.kr/ (The Korea Times)][http://www.koreatimes.co.kr/www/news/nation/nation_view.asp?newsIdx=5635&categoryCode=115 <!-- Bot generated title -->]</ref>

--------------------------
**Version**: unspecified
**Severity**: major
This is now fixed because comments are editable (finally), but there's a wider, lower-priority issue for non-comments, for which I have created bug 68779 to track.
(In reply to Gerrit Notification Bot from comment #3)
> Change 141063 merged by jenkins-bot:
> Also annotate metadata in TransactionProcessor
> 
> https://gerrit.wikimedia.org/r/141063

Helpfully, this doesn't actually fix the bug (just a number of related bugs where the comment isn't on the edge of the link). Assigned.
Change 141063 merged by jenkins-bot:
Also annotate metadata in TransactionProcessor

https://gerrit.wikimedia.org/r/141063
Change 141063 had a related patch set uploaded by Catrope:
Also annotate metadata in TransactionProcessor

https://gerrit.wikimedia.org/r/141063
This is a more general problem. We never unannotate comments or any other metadata. For instance:

* If you have [[Foo|Bar<!--Baz-->Quux]] and change the link target, you'll split the link: [[Foo2|Bar]][[Foo|<!--Baz-->]][[Foo2|Quux]] (that's also what happened here)
* If you have Foo<!--Bar-->Baz, it renders as "FooBar". If you then make that italic, you'll get ''Foo''<!--Bar-->''Baz''

The root of the problem is that ve.dm.TransactionProcessor#applyAnnotations doesn't annotate/unannotate metadata. Tomorrow I'll see if I can write a failing test case and fix applyAnnotations()
This makes sense for ULS because they have a reasonable number of merges in a day, see https://gerrit.wikimedia.org/r/#/q/status:merged+project:mediawiki/extensions/UniversalLanguageSelector,n,z 

This would entail: 

* Put the ULS tests into their own Jenkins build, and possibly into their own code repo the way Mobile is

* Have Jenkins kick off the build of ULS tests targeting beta labs upon code merged in the ULS branch

* Report the build status after each run

This came up because we found Bug 52115 in a timely way.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52890
https://bugzilla.wikimedia.org/show_bug.cgi?id=53691
https://bugzilla.wikimedia.org/show_bug.cgi?id=57560
The job got fixed yesterday and browser tests are passing right now. It is not blocking changes yet though.
The trigger has been added in Zuul with https://gerrit.wikimedia.org/r/97741

The job will success whenever ULS change https://gerrit.wikimedia.org/r/#/c/97487/ is merged in.
Change 97741 merged by jenkins-bot:
ULS browsertests on check pipeline

https://gerrit.wikimedia.org/r/97741
Change 97741 had a related patch set uploaded by Hashar:
ULS browsertests on check pipeline

https://gerrit.wikimedia.org/r/97741
The browser tests manage to pass with above change:

https://integration.wikimedia.org/ci/job/mwext-browsertests-UniversalLanguageSelector-phantomjs/27/consoleFull

With a nice HTML report:
https://integration.wikimedia.org/ci/job/mwext-browsertests-UniversalLanguageSelector-phantomjs/27/artifact/report.html

Whenever the change in comment #5 is merged in, I will validate with i18n team how to get it triggered by Zuul.
Following a pair session with Željko, the tests can be flagged with a tag which we can then exclude when running tests. For ULS, I have introduced the tag @specific-settings which let us skip any tests that are not going to pass on a fresh wiki installation: https://gerrit.wikimedia.org/r/#/c/97487/
Moving this under Continuous Integration radar.
Have added bug 53691 for the same for the VisualEditor repo.
What about running the tests on patch submission?
Is this still something we want to do? ULS tests are now in ULS repo, so this should be doable. The only problem is that ULS tests are not stable enough:

https://wmf.ci.cloudbees.com/view/r-uls/
Tested on Firefox 22 (Monobook) and Chrome 28 (Vector)

Steps to reproduce:
- Open any random page in the visual editor. Personally i used [[Botnet]].
- Add the word "Test" to the page.
- Press Ctrl + Z to undo the edit. Keep pressing till the edit is gone, then press it once more.

Once you have done this, the Redo button and the Redo shortcut (Ctrl+Shift+Z) no longer seem to restore the previous edits. Any subsequent edit seems to reset the undo / redo buttons to an "There were no previous edits" state.

Inconsistent results:

Besides the above result that i can always reproduce using these steps, i have seen various other results. I have seen each of these at least twice but no matter what i try, i cannot seem to find any method of reproducing these reliably.

- An entry in the console log stating "Error: Cannot roll back a transaction that has not been committed "
- An entry in the console log stating "Error: Range error: Range is no longer valid after DOM mutation ([WrappedRange("Zz":1, "Zz":1)]) "
- The redo button suddenly inserting "♙" once in Chrome.
- The undo button suddenly inserting an endless steam "♙" in Firefox.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51532
https://bugzilla.wikimedia.org/show_bug.cgi?id=52185
Now merged into master; will be deployed in the next push.
Change 79049 merged by jenkins-bot:
Check for past/future state in undo/redo before setting breakpoint

https://gerrit.wikimedia.org/r/79049
Change 79049 had a related patch set uploaded by Esanders:
Check for past/future state in undo/redo before setting breakpoint

https://gerrit.wikimedia.org/r/79049
It's obviusly inviting you to play chess :)
I've reproduced a few of these permutations.
Firefox 22 - Error console.

Tested on Firefox 22 (Monobook) and Chrome 28 (Vector)

Steps to reproduce:
1) Open the [[Martin J. Silverstein]] in the visual editor.
2) Click on the empty line between the "Diplomatic posts" and "United States Ambassadors to Uruguay Uruguay" template
3) Click the "Transclusions" button, add the "Botnets" template and apply the edit.
4) Try to use any button on the visual toolbar that creates a window, or try to open any existing item that creates a window. This will no longer be possible.

Console log:
- The added screenshot is the error console as seen in Firefox. On step 3 the "DOM Offset" error is added.
- On step 4 (And after every subsequent click on an element that creates a window) the "Cannot create a window" error will be added.

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

**Attached**: {F11357}
This appears to now be fixed - marking as WORKSFORME.
I can't reproduce this.
Thought we had fixed insertion into slugs in bug 44084 - has this re-surfaced?
Having tested a few more scenario's it would seem that editing near templates in general causes console errors, though none of these seem to cause any lasting issues.

- Selecting the line mentioned in step 2 and pressing enter will return the console error "TypeError: outermostNode is null"
- Typing a text under the bottom template of the page and then pressing backpace till the text and that template are gone will cause an error if that edit is undone afterwards:
-- "Error: Range error: Range is no longer valid after DOM mutation "
-- "Error: Offset could not be translated to a DOM element and offset: 1405"

As mentioned before, neither of these errors seem to impact anything in the editor or the edit itself.
Relevant error: "Error: Offset could not be translated to a DOM element and offset: 1407"

The inability to open other dialogs is because the error causes the first dialog to never close, and so opening other dialogs fails because VE thinks you've already got a dialog open.

Is this due to adding a transclusion in a slug, perhaps?
--------------------------
**Version**: unspecified
**Severity**: major
Change 82790 merged by jenkins-bot:
Introduce newFromDocumentReplace() transaction builder

https://gerrit.wikimedia.org/r/82790
Change 82790 had a related patch set uploaded by Jforrester:
Introduce newFromDocumentReplace() transaction builder

https://gerrit.wikimedia.org/r/82790
Change 71661 abandoned by Catrope:
[WIP] ve.dm.Transaction: Implement newFromDocumentInsertion, take 2

Reason:
Superseded by https://gerrit.wikimedia.org/r/82790

https://gerrit.wikimedia.org/r/71661
Change 71661 had a related patch set uploaded by Jforrester:
[WIP] ve.dm.Transaction: Implement newFromDocumentInsertion, take 2

https://gerrit.wikimedia.org/r/71661
From bug 49820 comment 27:
John Broughton 2013-07-25 23:13:48 UTC
If it's not one thing, it's another ... The popup message is now visible no
matter where in a page the wikitext is being entered. So that's progress.

The popup is still too inconspicuous for my tastes (and a great opportunity for
A/B testing), but that's not what I'm posting about. My concern is with the
link that the popup message includes (the label is "wikitext"; the target is
[[Help:Wiki markup]]). If that link is clicked, the system **asks the user
whether he/she wants to leave the editing page**. That's a bit user-unfriendly.

I realize that smarter users can right-click and then open the link in either
another tab or a new page, avoiding the question of whether they want to leave
their editing session. But if we're aiming at the average user, it would be
great if this link were pre-defined as opening another window, so that a simple
click on the link didn't result in a perturbed user.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51585
https://bugzilla.wikimedia.org/show_bug.cgi?id=51122
This is now done and we'll get it deployed soon.
Change 76701 merged by jenkins-bot:
Set links in wikitext warning to load in new window

https://gerrit.wikimedia.org/r/76701
Change 76701 had a related patch set uploaded by Helder.wiki:
Set links in wikitext warning to load in new window

https://gerrit.wikimedia.org/r/76701
Reported: https://en.wikipedia.org/wiki/Wikipedia_talk:Tags#Incorrect_tagging
and
https://en.wikipedia.org/wiki/Wikipedia:VPT#Blanking_filter_misfire

**See Also**:
* {T54049}
* {T54062}
I think this really was a problem with AbuseFilter and not the hook; the hook documentation was unclear. My fix for T73947 fixes this too, so I proposed that the patch be reverted at https://gerrit.wikimedia.org/r/282101.
*** Bug 52895 has been marked as a duplicate of this bug. ***
*** Bug 52062 has been marked as a duplicate of this bug. ***
Change 76082 merged by jenkins-bot:
Make APIEditBeforeSave give the whole revision

https://gerrit.wikimedia.org/r/76082
See also:
* [[Wikipedia talk:Edit filter#Abusefilter bug on mobile version]]
Change 76082 had a related patch set uploaded by Hoo man:
Make APIEditBeforeSave give the whole revision

https://gerrit.wikimedia.org/r/76082
After some investigation it turns out, that this is an issue with the edit API. I'm just preparing a fix, but takes some time as both the API and EditPage itself are rather messy.
Hoo suspects that this is a problem with VisualEditor. Copying a few folks accordingly.
Marius, can you take a look at these? Chris is on vacation right now.
The edits in question:
https://en.wikipedia.org/w/index.php?title=Christoph_Waltz&diff=565783472&oldid=565445126

and

https://en.wikipedia.org/w/index.php?title=Stone_Gossard&diff=565724723&oldid=563438457
If the TemplateData for a template specifies a default value for a given parameter (see bug 52028) then that value should be prefilled when that parameter is added to the template. 

An example would be the current date for an accessdate parameter.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 146396 merged by jenkins-bot:
Add 'autovalue' to TemplateData

https://gerrit.wikimedia.org/r/146396
Change 146396 had a related patch set uploaded by Jforrester:
[wip] Add 'autovalue' to TemplateData

https://gerrit.wikimedia.org/r/146396
That's not the meaning of the "default" flag on parameters, but of the proposed "autofill" concept from bug 51428; relabelling for clarity.
In Firefox, scrolling a large VE page is very slow, with visible pauses between repaints, predominantly because of the floating toolbar. Calling disableFloating() on the toolbar from the JS console causes scrolling to be roughly as fast as scrolling the non-VE page view.

Timo says he knows how to fix this.

--------------------------
**Version**: unspecified
**Severity**: normal
Merged and deployed.
Change 76241 merged by jenkins-bot:
ve.ui.Toolbar: Refactor floating logic for performance

https://gerrit.wikimedia.org/r/76241
Change 76241 had a related patch set uploaded by Jforrester:
ve.ui.Toolbar: Refactor floating logic for performance

https://gerrit.wikimedia.org/r/76241
https://gerrit.wikimedia.org/r/#/c/76241/
(In reply to comment #1)
> @Krinkle: How are you going to fix this? :-)

<Krinkle> I already did, in a way. Earlier this week I re-used that logic for mw.notification (which now also has a floating mode, previously mw.notify messages weren't visible if you scroll down the page, which is a problem for VE). However I noticed a few things that could be optimised that I did 'right' from the get go for mw.notify. I should be able to apply that to ve as well
<Krinkle> most notably the fact that floating calculation for ve toolbar calls offset() each time
<Krinkle> which is a repaint for something that is unlikely to ever change
<Krinkle> I realised it when I was doing mwnotify but never remembered to fix it in VE
@Krinkle: How are you going to fix this? :-)
Using the backspace or delete key to delete plain text on a large page takes hundreds of milliseconds per character, predominantly because ve.dm.Document.prototype.commit() is called, which leads to ve.ce.ContentBranchNode.prototype.onChildUpdate(), which leads to ve.dm.Converter.openAndCloseAnnotations(), which calls containsComparableForSerialization(), which is apparently O(N). 

Bug 52012 also affects backspace performance.

--------------------------
**Version**: unspecified
**Severity**: normal
Merged and deployed.
Change 76110 merged by jenkins-bot:
Speed up openAndCloseAnnotations by using store indexes

https://gerrit.wikimedia.org/r/76110
Change 76100 merged by jenkins-bot:
Quick optimisation to avoid containsComparableForSerialization

https://gerrit.wikimedia.org/r/76100
With these two patches ^^^ getDomFromData has sped up from 1150ms to 180ms on my local copy of en:Argentina.
Change 76110 had a related patch set uploaded by Esanders:
Further annotation optimisations

https://gerrit.wikimedia.org/r/76110
Change 76100 had a related patch set uploaded by Esanders:
Quick optimisation to avoid containsComparableForSerialization

https://gerrit.wikimedia.org/r/76100
(In reply to comment #5)
> Even further suggestion from Tim: make the IVStore use a binary search tree,
> where the nodes are something like { index: number, value: Object } and the
> comparison operates on the objects, something similar to oo.compare() but
> returns < or >. This requires an ordering on the keys. We could do alphabetic
> order like in keySortReplacer, but it would be more efficient to have the
> ve.dm.Annotation object return an ordering on the keys. Or something. This is
> an incomplete thought and requires experimentation.

The point of this would be to reduce the memory usage of IVStore by eliminating the duplication caused by using the JSON as a key, and also to reduce the CPU overhead of ve.getHash(). But note that neither of these things are confirmed as performance issues in the profiling I have done so far.

In any case, comparison of store indexes would obviously be faster than binary search followed by value comparison. So I think index comparison should be the priority, of the ideas discussed here, assuming it can be implemented in such a way that pressing backspace on plain text will predominantly hit index comparison rather than value comparison. After that is implemented, we can do more profiling and decide whether the use of ve.getHash() is a problem worthy of significant development time.
(In reply to comment #3)
> Suggestion from IRC, posting to the bug for prosperity:

s/prosperity/posterity/ ;-)

[cf. bug 49198 comment 5]
Even further suggestion from Tim: make the IVStore use a binary search tree, where the nodes are something like { index: number, value: Object } and the comparison operates on the objects, something similar to oo.compare() but returns < or >. This requires an ordering on the keys. We could do alphabetic order like in keySortReplacer, but it would be more efficient to have the ve.dm.Annotation object return an ordering on the keys. Or something. This is an incomplete thought and requires experimentation.

Giving this to Ed because he's a machine that turns vague incomplete suggestions into working code and fixes a few bugs in the process too ;)
Further suggestion: when we're comparing annotations, try to compare store indexes wherever possible. When we're comparing for identity, like when comparing for serialization when both annotations are generated, we could compare store indexes rather than using ve.compare(). And if we throw comparable objects into the store, we might be able to do index comparison there too.

Maybe ve.dm.Annotation instances should have properties that track the store index of their this.element and their comparable objects?

Ed, could you play with this?
Suggestion from IRC, posting to the bug for prosperity:

[15:12]	<RoanKattouw> TimStarling: As a hack, could you try to set ve.compare = function ( a, b ) { return ve.getHash( a ) === ve.getHash( b ); }; instead of ve.compare = oo.compare; (in ve.js) and see how much that mitigates the problem?
(In reply to comment #1)
> In both actions, on my favourite test case for today ([[Argentina]]), about
> 10s of CPU usage is attributable to openAndCloseAnnotations(), and about 80%
> of that is from oo.compare().

Perhaps related to bug 51948.
The slowness of ve.dm.Converter.openAndCloseAnnotations() also dominates the performance of ve.dm.Converter.prototype.getDomFromData(), severely affecting both initial setup and "review changes". In both actions, on my favourite test case for today ([[Argentina]]), about 10s of CPU usage is attributable to openAndCloseAnnotations(), and about 80% of that is from oo.compare().
Change 119204 merged by jenkins-bot:
Show blockedtext message in edit notices

https://gerrit.wikimedia.org/r/119204
Change 119204 had a related patch set uploaded by Alex Monk:
Show blockedtext message in edit notices

https://gerrit.wikimedia.org/r/119204
(In reply to Roan Kattouw from comment #4)
> We already put random junk in the paction=parse response, I wouldn't be
> opposed to adding blocked-ness to that. Another paction would be OK too, but
> then we'd have to make two API requests.
> 
> There are significant speed benefits in combining everything into one API
> request. I think we should stop kidding ourselves that paction=parse is a
> clean, only-does-one-thing action, and perhaps rename it if we want, rather
> than trying to split it into separate actions, because the latter would just
> make client-side performance worse.

Yes, since writing that comment I decided to just add it in to paction=parse, especially since talking to James - he wants this to be an edit notice like the others. I probably should have left a new comment about it.

The problem now is coming up with a nice way to fit the autoblockedtext message (blockedtext is okay) in to the edit notices popup.
James suggested I tackle this bug. I messed around with the API for a little bit and assuming I didn't miss anything:

I think that if we tried to fill out the 'blockedtext' message properly on the client we'd have to:
* Query the API for the user's blockinfo to determine whether or not they're blocked. If they are:
** Query the API for more info about this block which meta=userinfo&uiprop=blockinfo doesn't provide but we need to substitute into the message (expiry, user, timestamp).
** Query the API to parse the blockedtext message because it can't be done on the client (even the default message includes stuff mw.msg can't handle)
** Substitute the data we have into the message (and we still won't have $3 - the current IP)
*** Mess around with dates/times because they won't be in the right format.

Another way we could do this is return the full warning from action=visualeditor&paction=parse (therefore adding no extra API requests) which would cause the client to stop loading. I don't like this idea because obviously that paction is not intended for checking this kind of thing...

Or we could ignore the core blockedtext message and use our own "Your username or IP address has been blocked", possibly with the info that just meta=userinfo&uiprop=blockinfo provides (block ID, performer, reason).

Or we could add a new API module/paction that can be queried once and provides all the relevant info. I don't like this idea either but it seems the nicest.

Thoughts?
Created attachment 12954
What a blocked user sees immediately they the source editor loads

**Attached**: {F11061}
Created attachment 12953
What a blocked user sees when they try to save an edit in VE

**Attached**: {F11060}
Users can't reuse a reference belonging to non-default group. It's just not shown on the list and I've been unable to get such refs to show up there.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51838
Change 81964 merged by jenkins-bot:
Re-build reference search index so they can be used mid-edit

https://gerrit.wikimedia.org/r/81964
Now fixed in master and will be deployed next week.
Change 81964 had a related patch set uploaded by Trevor Parscal:
Bug 51689 & 52000 - Reusing new references

https://gerrit.wikimedia.org/r/81964
Change 81964 had a related patch set uploaded by Trevor Parscal:
Bug 52000 - Reusing new reference groups

https://gerrit.wikimedia.org/r/81964
This works if the group exists when VE loads the page, but if the group is added after load then it's items don't show up in the search.
A user on en.wp has reported the following:

"Editing anonymously from my school computers is blocked, and for fun I tried editing a page using VE. It lets me edit the page fully, ''until'' I try to click the save page button. No matter how many times I click it it doesn't save, but there's no notification telling me why it doesn't save. A bit weird really"

I blocked my legitimate alternate user and then tried to edit a page. The editor loaded fine but when I clicked to save the edit I saw the message:
"Error loading data from server: Unsuccessful request: You have been blocked from editing."

I am on a shared connection so I do not want to do any testing of ipblocks, etc.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52004
This was fixed in the fix for bug 52004.
The original reporter, numbermaniac, has done some additional testing and found that they do see the message when pressing save in Chrome on Windows 7. Their initial report was using iMac Safari.

My testing was done using Firefox 22 on Xubuntu Linux
For instance instead of class 'tright' or 'tleft' just class 't' gets added. It is regression of this change: https://gerrit.wikimedia.org/r/#/c/75526/

--------------------------
**Version**: unspecified
**Severity**: normal
Now fixed in master and will be deployed in a few minutes' time.
Change 75803 merged by jenkins-bot:
Fix MWBlockImageNodes' default horizontal location code

https://gerrit.wikimedia.org/r/75803
Change 75803 had a related patch set uploaded by Jforrester:
(bug 51995) Bugfix

https://gerrit.wikimedia.org/r/75803
Change 75803 had a related patch set uploaded by Inez:
(bug 51995) Bugfix

https://gerrit.wikimedia.org/r/75803
Firefox - Detected script lockup.

Misplacing a bulleted / numbered list can cause a script lockup. Tested on both Firefox 22 and Chrome 28

Steps to reproduce:
- Navigate to [[Lauda Air Flight 004]] and open it with the visual editor.
- Click the "Lauda Air Flight 004" infobox and make sure it remains selected.
- Click the "Bulleted List" button. A list bullet is added to the article.
- Click right after the bullet that was just inserted. Now click the "Bulleted list" button again.

Normally this would remove the bullet again. Instead of that both Firefox and Chrome seem to lock up. Firefox will lock up entirely (All open tabs will freeze) and eventually an unresponsive script error will be displayed. Cancelling the script allows you to regain browser control. On Chrome the lockup seems isolated to the tab where we edit Wikipedia, but it only offers the option to close the tab after a while (Losing all changes)

In practice one would never want to add a bulleted list this way, but actually "crashing" makes it severe enough to report i would assume.

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

**Attached**: {F11897}
Resetting to FIXED; this was a confirmed broken behaviour which has subsequently been FIXED, as far as we can tell - probably by the re-write of the Content Editable surface interaction model.
(In reply to comment #3)
> Cannot reproduce it now with MAC OS using FireFox and Chrome.

Please ALWAYS provide version information for browsers. 
Note that comment 0 says "Tested on both Firefox 22 and Chrome 28".

> So changing the status of the bug as resolved.

No identifiable code commit, hence changing to WORKSFORME instead of FIXED. Also see https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle
Cannot reproduce it now with MAC OS using FireFox and Chrome.So changing the status of the bug as resolved.
If you can still reproduce it ,please reopen the bug.
This is an infinite loop inside either Rangy or the bit of ContentEditable that calls it - lots of calls to sel.getRangeAt(index) which end up taking so long that the browser dies (?)
We should have a 'crash' or 'dataloss' keyword.  Bumping priority to get more attention/triaging in case the underlying cause is able to be triggered in other ways.
The particular article in the URL field of this bug report doesn't not display the Save button in Firefox.

The Save button is displayed in Chrome, and it is displayed in other articles in Firefox.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%93_%28%D7%9E%D7%99%D7%AA%D7%95%D7%9C%D7%95%D7%92%D7%99%D7%94%29?veaction=edit
This is now fixed in master; we will make sure it is deployed tomorrow.
Change 75785 merged by jenkins-bot:
Fix the save button disappearing on certain pages in Firefox

https://gerrit.wikimedia.org/r/75785
Change 75785 had a related patch set uploaded by Catrope:
Fix the save button disappearing on certain pages in Firefox

https://gerrit.wikimedia.org/r/75785
Another article where this happens:

https://he.wikipedia.org/wiki/%D7%A4%D7%9C%D7%99%D7%98%D7%99_%D7%9E%D7%9C%D7%97%D7%9E%D7%AA_%D7%94%D7%90%D7%96%D7%A8%D7%97%D7%99%D7%9D_%D7%91%D7%A1%D7%95%D7%A8%D7%99%D7%94?veaction=edit
(Tested in Firefox 22 and Chrome 28)

Steps to reproduce:
- Open [[Portland Ice Arena (Oregon)]] with the visual editor.
- Click the hyperlink button (Don't select anything). The hyperlink window should pop up.
- Now click anywhere else in the article without entering any data in the hyperlink popup. 
- An empty popup balloon will remain behind. There are no controls on that popup anymore.
- Click around the article a bit - eventually that balloon will be removed. However, the link button will now fail to work no matter what you do.

This may or may not be related to bug 48549, which seems to have been fixed in todays deployment.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 51404 ***
most likely duplicate of bug 51404, which should be subsequently renamed from "crashing when inserting link without selection" to "crashing when inserting link on non-linkable or empty selection"
Addendum:
After some more testing it would seem that the link button will always break whenever the user selects an element that normally wouldn't be hyperlinked. If one does select a non linkable element and presses the hyperlink button the empty balloon popup will always occur.  

These elements include - among others - images, templates, references and objects that cannot be edited in the visual editor yet. Unfortunately there seems to be no way restore the link buttons functionality without reloading the editor itself.
I was able to reproduce following the steps in comment 3.
Chrome 28 - Error console

And last: A screenshot of chrome's console. It seems to be a tad more in depth than the error Firefox displays.

**Attached**: {F11891}
Yep, one pops up on step 3:

[23:46:29.770] Error: No class registered by that name: undefined @ https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=monobook&version=20130724T164530Z&*:2

The above screenshot displays what occurs on the page. Also, a more specific set of steps that might help to reproduce this:

1) Edit the [[Portland Ice Arena (Oregon)]] page in the visual editor.
2) Place the cursor directly after reference [2]. 
3) Click the hyperlink button. It should create the regular hyperlink balloon as seen in the left side of the attached screenshot.
4) Click the 'Not to be confused with Portland Ice Arena (Maine).' template. This will cause the template to "blank" itself as seen in the right side of the screenshot. 
5) Click the 'Not to be confused with Portland Ice Arena (Maine).' template another time. This will cause the empty edit balloon to disappear. 
6) Try the edit link button anywhere in the page itself - it will no longer work (Not on existing links nor on new ones)

Note that it is not required to click the template - clicking elsewhere will work as well.
Error screenshot.

**Attached**: {F11890}
I can't reproduce this. Do you see any errors in your JS console?
The Hebrew Wikipedia frequently uses the template {{כ}} ( https://he.wikipedia.orgw/wiki/Template:Rlm ), which inserts the &rlm; entity. This entity translates to an invisible zero-width control character, the [[right-to-left mark]]. This template works correctly when the article is rendered to the reader, but when the article is being edited in VE, the text behaves as if it's not there.

For reference, see https://en.wikipedia.org/wiki/Right-to-left_mark .

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://he.wikipedia.org/wiki/User:Amire80/ve-rlm
(In reply to Amir E. Aharoni from comment #6)
> At Wikimania Moriel, Roan and I found that the bug, as originally reported,
> appears to be fixed. I don't know when exactly did the fix happen.
> 
> Using the {{כ}} template works correctly while editing articles, and the
> original test page https://he.wikipedia.org/wiki/User:Amire80/ve-rlm shows
> everything correctly.

This would probably have been fixed by Ed's work on unwrapping generated content nodes.

> That said, there are issues with handling this template after it's inserted:
> * The bubble that shows its name appears in a wrong location.

Yeah, the context seems to find the nearest thing that actually displays and attaches to that. Probably the same issue as the below.

> * It's hard to know that it's there while editing in visual mode, because it
> is zero-width. Showing some kind of a flag there, as it's done with single
> line breaks, would be a nice idea.

That's bug 49806.

> Should I close this bug and open separate bugs for these issues?

Have done so. Yay.
At Wikimania Moriel, Roan and I found that the bug, as originally reported, appears to be fixed. I don't know when exactly did the fix happen.

Using the {{כ}} template works correctly while editing articles, and the original test page https://he.wikipedia.org/wiki/User:Amire80/ve-rlm shows everything correctly.

That said, there are issues with handling this template after it's inserted:
* The bubble that shows its name appears in a wrong location.
* It's hard to know that it's there while editing in visual mode, because it is zero-width. Showing some kind of a flag there, as it's done with single line breaks, would be a nice idea.

Should I close this bug and open separate bugs for these issues?
(In reply to comment #4)
> 2. Language definition to assign directionality rather than RLM is good
> approach, but it isn't possible to replace all the RLM uses:
> A. for normal users it is annoying to meet wiki-text editing HTML code of
> <span
> dir="">...

That's why Moriel invested so much time in an easy graphical way to do it :)

It's still in the "finishing touches" stage.

The trouble is that while bidi isolation replaces most or all of the uses of RLM, it doesn't work in IE. Saw it coming? :)

In fact, IE 10 and 11 (!) even show some elements with bidi isolation very incorrectly. Test the following page:
https://en.wikipedia.org/wiki/User:Amire80/bidi-isolate

> Regarding the issue of "invisible template" which the VE users don't know it
> is
> there - I think it will be nice (and maybe there is already exist) to add
> ability to add text that appears only in VE editing mode [either with CSS
> which
> tells the content to display:none, and only in VE it appears, or with
> dedicated
> parser tag <onlyve>. This solution may be useful for other cases of
> "invisible
> templates".

I love this proposal.
1. I think that adding display:inline-block by the VE (to any transclusion node - and particularly to this template)  is a bug, We should consider either removing this css or changing it to inline instead of inline-block
2. Language definition to assign directionality rather than RLM is good approach, but it isn't possible to replace all the RLM uses:
A. for normal users it is annoying to meet wiki-text editing HTML code of <span dir="">...
B. Sometimes specifying direction/language is overkill and the simple and best solution is to use RLM. 

Regarding the issue of "invisible template" which the VE users don't know it is there - I think it will be nice (and maybe there is already exist) to add ability to add text that appears only in VE editing mode [either with CSS which tells the content to display:none, and only in VE it appears, or with dedicated parser tag <onlyve>. This solution may be useful for other cases of "invisible templates".
Hint: when disabling inline-block display for the template 
(e.g removing:
.ve-ce-mwTransclusionInlineNode {
    display: inline-block;
}
)
it behaves properly.
See https://he.wikipedia.org/wiki/User:Amire80/ve-rlm for a demostration.
1. https://en.wikipedia.org/wiki/User:Raymond/Gallery?veaction=edit
2. Put the cursor after the first ':'
3. Press the down arrow - cursor should now be far right of window, beside the gallery
4. Type 'a'
5. Press Control-Z

Results vary.

1. Sometimes two characters will appear: 'A' <new line> 'a', and 'Save page' is enabled.  Control-Z removes only one of them, and the 'Save page' button returns to disabled, with one added character still on the screen.

2. Sometimes a pawn appears.

3. Sometimes only one character appears, and the 'Save page' button remains disabled.

On the gallery at the bottom of https://de.wikipedia.org/wiki/Hollenegg?veaction=edit , option (3) happens most often.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53750
https://bugzilla.wikimedia.org/show_bug.cgi?id=56248
I believe that this is now fixed, after the Firefox CE re-write, though I could be wrong – please re-open if so.
In addition to <gallery>, and corruption, a less significant problem is that the down cursor becomes stuck at any block that consumes the entire page with (such as the references block or navbars); pressing the down arrow on the keyboard does not move the cursor to the next item underneath the block.

Steps to reproduce:
1. Load any page in VE with a references block and something underneath it. e.g.
   https://en.wikipedia.org/wiki/Jos%C3%A9_Cl%C3%A1udio_Ribeiro_da_Silva?veaction=edit
   https://en.wikipedia.org/wiki/Marty_Callaghan?veaction=edit

   or a similar block like in this article

   https://en.wikipedia.org/w/index.php?title=Mary_Louise_Smith_%28Republican_Party_leader%29&veaction=edit

2. Repeat pressing down key to reach the bottom of the article

Expected results:
Down key continues to step down through the article until it reaches the bottom.

Actual results:
Down key works until the references block.  It becomes stuck on the right hand side of the block.

Im adding this here as it appears to be the exact same underlying problem, as typing when the cursor is on the right-hand side of other wide objects, such as references, also produces unexpected results.
Confirmed bug in Firefox. Specifically:

(In reply to comment #0)
> 1. https://en.wikipedia.org/wiki/User:Raymond/Gallery?veaction=edit
> 2. Put the cursor after the first ':'
> 3. Press the down arrow - cursor should now be far right of window, beside
> the gallery

No, it really shouldn't - it should be in the next heading ("Anzahl Bilder pro Reihe: perrow=2"). See the behaviour in Chrome/Safari for reference. This is a bug specific to Firefox AFAICT.
Reliable snowmen

1. https://de.wikipedia.org/wiki/Benutzer:John_Vandenberg/test?veaction=edit
2. Place the cursor above the image (which is inside a template)
3. press down so that the cursor is beside the image/template
4. press 'a'

Win: snowman + 'a'
Overlapping template selection box in Firefox 22 on Linux

When templates do not have a defined width the blue selection box extends the whole width of the window, regardless of whether the template does. This means that in some cases, e.g. at [[Where Does This Door Go]], the transclusion editor icon is displayed not on top of the template.

More seriously it also means that smaller templates to the right of larger ones are difficult of impossible to access because they are completely covered by the other template's selection box. At the same article, the "Professional ratings" translcusion is difficult to select (you need to click it in line with the slug between the templates on the left) and the tooltip icon does not appear.

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

**Attached**: {F11785}
Both of the examples linked to work now.
Partially mitigated by the above but I believe not fixed. Resetting.
Change 138338 merged by jenkins-bot:
Special case for shielding of generated content wrappers

https://gerrit.wikimedia.org/r/138338
Change 138338 had a related patch set uploaded by Esanders:
Special case for shielding of generated content wrappers

https://gerrit.wikimedia.org/r/138338
*** Bug 54301 has been marked as a duplicate of this bug. ***
*** Bug 50970 has been marked as a duplicate of this bug. ***
The edit icon showing up in random places is also mentioned at https://bugzilla.wikimedia.org/show_bug.cgi?id=51548 .
*overlapping blocks, or templates, or whatever, you understood me :)
I arrived here to document the same situation. A user at en.wp reports he's not able to edit reviews with VE at http://en.wikipedia.org/wiki/X_(Def_Leppard_album) because of the overlapping windows. While for me this is certainly the case with FF, with Chrome instead I am able to select the template if I click on the Review Scores line. This said, the icon to actually edit contents only appears... at the top of the Infobox album - definitely not where one would expect it to.
Cloning from bug 50897 comment 2:

In the old editor, I would simply use TAB to reach the edit summary, type my
edit summary and press ENTER to activate the "Save page" button and save. If I
wanted to mark the edit minor, then I could type my edit summary, press TAB,
SPACE, and then ENTER to "Save page".

I can see that the new box for entering an edit summary allows newlines to be
entered. I am not sure this is a good idea, because I just used a WSYIWYG
editor and now "What I see" - well-formatted paragraphs describing my edit - is
not going to be "what I get" - everything smashed on one line in the article
history. But that is perhaps grist for another bug mill.

It seems that the "Save page" button never receives caret focus if I use TAB to
try to get there. This would seem to have accessibility ramifications.

--------------------------
**Version**: unspecified
**Severity**: minor
At least for me, this is not browser-specific: I get the problem in both Chrome and FFox. (The other problem is, I agree, browser-specific.)
(In reply to Luis Villa (personal-for work use lvilla@wikimedia.org) from comment #11)
> This is broken (again?) The three license links come up before the action
> buttons (and save page never comes up, but that is bug 50047 I think?)

Was going to re-open, but because it's a browser-specific issue I've instead opened bug 65554 to get this fixed.
This is broken (again?) The three license links come up before the action buttons (and save page never comes up, but that is bug 50047 I think?)
*** Bug 53257 has been marked as a duplicate of this bug. ***
The fix for this is now merged and will be deployed on Thursday 10 October to MediaWiki.org, and to Wikipedias on Thursday 17 October.
Change 81876 merged by jenkins-bot:
Make the save dialog an actual dialog

https://gerrit.wikimedia.org/r/81876
Change 81876 had a related patch set uploaded by Jforrester:
Make the save dialog an actual dialog

https://gerrit.wikimedia.org/r/81876
*** Bug 53257 has been marked as a duplicate of this bug. ***
Dcoetzee at en.wp reports that the tab order differs in different browsers, and that at a certain point in firefox the focus gets stuck and neither tab nor shift-tab can move it.

The full comment is below:
    "On Chrome Version 28.0.1500.95 m on Windows 7 x64: It starts in the edit summary field, goes to the "minor edit" link (not the checkbox), then the Save page button, then the Review your changes button (moving right to left), then the three links in the small text at the bottom, then the address bar, then the Search box, then the minor edit checkbox, then the "Interactions" menu drop down on the left sidebar (???), then the Watch this page checkbox. If I use SHIFT+TAB it goes to Edit summary link, then jumps straight to the Mediawiki logo way in the bottom right.

    On Firefox 22.0 and 23.0 on Windows 7 x64: It starts in the edit summary field, goes to the "minor edit" link (not the checkbox), then the Save page button, then thereafter neither TAB nor SHIFT+TAB do anything (focus is stuck - this is a serious problem as it may require reloading the page and losing edits). SHIFT+TAB is same as in Chrome.

Conventionally, tab order is supposed to go in a logical reading order: left-to-right, top-to-bottom. My expected order was something like this:

    Starts in edit summary field, goes to minor edit checkbox, then minor edit link, then Watch this page checkbox, then Review your changes button, then Save page button, then the three links at the bottom. If I use SHIFT+TAB to tab backwards, I expect to visit the Edit summary link, then (if possible) the arrow to collapse/abort the Save, then the Search box."
There has been a slight change to this recently but it is still wrong.

Current behaviour: Pressing tab from the summary box leads to the minor edit link
Desired behaviour: It should lead to the minor edit checkbox (not the link)
*** Bug 52080 has been marked as a duplicate of this bug. ***
That is an enhancement MZMcBride.

*** This bug has been marked as a duplicate of bug 50047 ***
Yeah, VisualEditor is kind of disruptive in this way. I'd like some further thought here.
(This sounds exactly like bug 50424, but that was marked fixed on 2013-07-15 with "deployed within the hour".)

I had made source edits to a mediawiki.org page over https. Looking at it 30+ minutes later I wanted to make one more quick edit, so I clicked [Edit].  VE worked fine, Save dialog, [Review your changes] worked, but the final [Save page] drew blue bars before doing nothing.

Firebug's network console showed the API requst visualeditoredit with 
  basetimestamp	20130723212405
  format	json
  minor	1
  oldid	745108
  page	Manual:How_to_debug
  starttimestamp	20130723232059
was failing with 
  {"servedby":"mw1139","error":{"code":"badtoken","info":"Invalid token"}}

I had a similar occurrence a few days ago where the API reported badtoken. I can't remember the specifics of that, but I assumed it was my mistake because I was using multiple accounts on different wikis.  This time I wasn't doing anything special.  Connecting to https://www.mediawiki.org/wiki/Special:Version in another tab shows me as still logged in.

Maybe there are two bugs here: VE's inability to recover from this, and the lack of a "VE had an internal error" with suggestion as to how to what to do (e.g. copy the right-hand column of [Review changes]. Regarding the former, when I've lost state with source editing I usually find [Show preview] brings it back, maybe VE can implement something like this internally.

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed in gerrit 76859 which was merged yesterday and will go out today.
**mael.leguevel** wrote:

I had the same message with the following scenario:
Edit an article, not logged in. Then, log in from another tab. Trying to save the article from the first tab, I get the same error message.
en.wp editor Rpyle731 has just reported an occurrence of this:
"While putting in stub templates in article "[[Zhang Shi (prince)]]" using the visual editor, when trying to save I got the text 

"Error loading data from server. Unsuccessful request: Invalid token.""
(In reply to comment #1)
FWIW when I investigated this by clicking the final [Save page] again, I only saw the one visualeditoredit API request in Firebug's Network tab.
When the API responds with badtoken, VE *should* refetch the token and try again. I'm fairly sure that was implemented, but not 100% sure.
If you look at page settings under https://sv.wikipedia.org/wiki/Violin?veaction=edit you'll see the category "Wikipedia". This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon.

--------------------------
**Version**: unspecified
**Severity**: normal
Now fixed in master.
Change 75859 merged by jenkins-bot:
Parse category names correctly

https://gerrit.wikimedia.org/r/75859
Change 75859 had a related patch set uploaded by Esanders:
Parse category names correctly

https://gerrit.wikimedia.org/r/75859
This style of category name also appears at de.wikipedia, e.g., [[:de:Kategorie:Wikipedia:Schnelllöschen]].
The error can be seen at http://ja.wikipedia.org/w/index.php?title=ロマン主義&diff=prev&oldid=48242310

Each language template in the lead sentence (e.g., {{lang-en}}, used for providing translations of the article title into English) was replaced by two snowmen.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://ja.wikipedia.org/w/index.php?title=ロマン主義&diff=prev&oldid=48242310
I think that this was finally fixed in Roan's great re-working of snowmen.
I have just duplicated this in Thai wikipedia.  Not only does the {{lang-en}} template turn into snowmen, the surrounding text gets rendered into (bolded) English upon saving. 

Diff:https://th.wikipedia.org/w/index.php?title=%E0%B8%81%E0%B8%8E%E0%B8%AB%E0%B8%A1%E0%B8%B2%E0%B8%A2%E0%B8%9B%E0%B8%B4%E0%B8%94%E0%B8%9B%E0%B8%B2%E0%B8%81&diff=5062666&oldid=4871033

Chrome 28.0.1500.71, OS 10.6.8
I quickly tried to reproduce this, and failed.  It might have been fixed by improvements to the code.  It would be good if someone can ask B637pcgt what they did to cause this issue.

jawp still has only a few VE edits per day
https://ja.wikipedia.org/wiki/special:recentchanges?tagfilter=visualeditor&days=30&limit=500
The VisualEditor explicitly sets all images that are inserted using the dialog as thumb and right. "thumb" is fine, because it's not default, but that's what people want most of the time, but "right" shouldn't be there. "right" is the default for left-to-right Wikipedias, so it's redundant in English. The default for right-to-left Wikipedias is "left", so for these languages this behavior is unexpected.

The best solution is simply not to set the alignment and let the user change if it is needed.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 75526 merged by jenkins-bot:
Image insertion alignment fix

https://gerrit.wikimedia.org/r/75526
Change 75526 had a related patch set uploaded by Mooeypoo:
Image insertion alignment fix

https://gerrit.wikimedia.org/r/75526
*** Bug 51295 has been marked as a duplicate of this bug. ***
Unless I'm missing something, just remove if it's the default anyway. See an example:
https://en.wikipedia.org/wiki/User:Amire80/ve_default_image_alignment
Should we remove the alignment completely (and risk people not putting one in? what's the potential side-effect of that?) or change the 'right' to 'left' on RTL wikis?
Given that I'm editing an article in an RTL wiki: https://he.wikipedia.org/wiki/ASCII
   And I press the "Transclude" button in the toolbar (puzzle piece)
   And I type "A"
Then I should see a list of autocompletions of templates that start with A

Currently I don't see a list of autocompletions.

This bug is quite similar to Bug 51490.

[This was an experiment with writing bug reports as Cucumber-style test scenarios. Let me know if you don't like it.]

--------------------------
**Version**: unspecified
**Severity**: normal
Done and will be deployed tomorrow. Thanks, Moriel!
This bug will be fixed with this patchset: https://gerrit.wikimedia.org/r/#/c/74835/

See also https://bugzilla.wikimedia.org/show_bug.cgi?id=51490
screenshot

When you click an infobox template in an RTL wiki, the puzzle piece icon is supposed to appear somewhere on the transparent blue background to make the template editable.

In an RTL wiki, this template appears outside of the transparent blue area on the other side of the screen.

You can test it with the following article:
https://he.wikipedia.org/wiki/%D7%9C%D7%95%D7%93?veaction=edit

See also the screenshot.

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

**Attached**: {F11560}
Merged and will go out tomorrow.
Change 75246 merged by jenkins-bot:
Quickfix for Transclusion icon in RTL wikis

https://gerrit.wikimedia.org/r/75246
Change 75246 had a related patch set uploaded by Mooeypoo:
Quickfix for Transclusion icon in RTL wikis

https://gerrit.wikimedia.org/r/75246
TempalteData-provided parameter list in template editor is not scrollable.

For example, try adding [[pl:Template:Okręt infobox]] to any article there.

Confirmed on latest versions of Firefox and Opera.

Screenshot: http://i.imgur.com/e3VSqVs.png

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51672
Done and will be deployed tomorrow.
Change 74836 merged by jenkins-bot:
Ensure ve-ui-panelLayout-scrollable is actually scrollable

https://gerrit.wikimedia.org/r/74836
*** Bug 51810 has been marked as a duplicate of this bug. ***
Patch by Rillke from bug 51793: https://gerrit.wikimedia.org/r/75083
*** Bug 51793 has been marked as a duplicate of this bug. ***
*** Bug 51671 has been marked as a duplicate of this bug. ***
Change 74836 had a related patch set uploaded by Matmarex:
Ensure ve-ui-panelLayout-scrollable is actually scrollable

https://gerrit.wikimedia.org/r/74836
Caused by 8409d16f0f2392cea321aa3d8d6bc692f3f04f27
GUI for the existing TemplateDataEditor

Not the same as bug 50964: it would be really nice to provide a tool for editing TemplateData also outside VisualEditor (I even think it's better than inside VisualEditor because VE doesn't work on Template namespace right now).

The existing TemplateDataEditor script (created by Ltrlg on frwiki, translated for enwiki by me), can be a good start. Benefits for including some equivalent in TemplateData extensions are important :
* Available to all wikis
* Translations can be done like they are done for TemplateData

Links :
* http://en.wikipedia.org/wiki/User:NicoV/TemplateDataEditor
* http://fr.wikipedia.org/wiki/Utilisateur:Ltrlg/scripts/TemplateDataEditor.js

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50169

**Attached**: {F11375}
Follow-up in 60158.
Created attachment 14428
TemplateDataGenertor screenshot

I made a screenshot. I’ve cropped it to show only TemplateDataGenerator: it is a jQuery UI dialog centered on the screen.

**Attached**: {F11377}
As I said, the current information (or lack of) is confusing. Is there any wiki page or screenshot or anything we can link to?

In any case, ca.wiki wants to try it.  :)
$wgTemplateDataUseGUI activates neither TemplateDataEditor nor TDSkell but TemplateDataGenerator. The two screenshots attached to this bug are for 'TemplateDataEditor' and 'TemplateData Editor', so the one you gave on cawiki is not correct.
ca.wiki is also happy to test it, see https://ca.wikipedia.org/wiki/Viquip%C3%A8dia:La_taverna/Propostes#Activar_TemplateDataEditor
**M8R-0p6s0d** wrote:

Hi, we would like to try the TempalteDataEditor on NL wiki, see https://nl.wikipedia.org/wiki/Wikipedia:De_kroeg#Aanzetten_TemplateData-editor_op_nl-wiki
No, this is the GUI we developed hidden behind $wgTemplateDataUseGUI.
(In reply to comment #11)
> If
> a particular wiki is happy to be a guinea pig we can switch it on there for a
> little for some real-world testing.

Sound interesting, but I'm missing a bit of background...

Do you mean "switch on" https://en.wikipedia.org/wiki/User:Salix_alba/TDSkell ? Would it be enabled to all users of a wiki or can it be restricted to a certain user group in order limit the experiment a bit?

There is clear interest in improving template data coverage in Catalan Wikipedia but, guess what, nobody really enjoys editing JSON syntax.  :)
This is done in I863a8199c0b08cc52b320ed00dcba912dd2aeefc (though it's not yet deployed, as it is currently hidden behind a feature flag). Closing for now. If a particular wiki is happy to be a guinea pig we can switch it on there for a little for some real-world testing.
Change 85400 had a related patch set uploaded by Jforrester:
TemplateData Generator GUI

https://gerrit.wikimedia.org/r/85400
Skeleton generator now in javascript and at http://en.wikipedia.org/wiki/User:Salix_alba/TDSkell
its quite handy for getting a complete list of parameters. The human written documentation is not always upto date.
I don't know how I messed up with the bug number (probably several bugzilla windows opened and I paste the wrong one) ;-) Sorry, bug 50169 of course.

I also think having a button in the toolbar would be a better place than the sidebar.


Other possible optimization: combine it with the "Skeleton generator" so that parameter names are automatically retrieved from the template source code for initializing the templatedata the first time. Care must be taken since the templatedata will often be on the documentation page.

http://singsurf.org/things/TemplateData.php?Source=true
(In reply to comment #0)
> Created attachment 12900 [details]
> GUI for the existing TemplateDataEditor
> 
> Not the same as bug 50964

Indeed, bug 50964 is not the same, but also (apparently) completely unrelated. I assume you meant bug 50169.

If this should not (also) be inside VisualEditor, can we be specific in what we want it to be then?

e.g. WikiEditor, legacy toolbar, ...

The referenced gadget 'parses' the wikitext textarea and adds a link in the sidebar toolbox that opens a dialog. I don't think the sidebar would be an acceptable entry point to edit the wikitext. Should be something in the toolbar.

I agree we should re-use the data logic between these 2 or 3 different things. At least we can expose the data logic separately from the plugin we make for VisualEditor so that other ones can be created as gadget (until (if) we make one of the WikiEditor and/or legacy toolbar).

**Attached**: {F11375}
Created attachment 12957
Screenshot of http://tools.wikimedia.pl/~mlazowik/templatedata/

**Attached**: {F11376}
This is, indeed, not a duplicate of bug 50169, though it might as well be done in one go. Relabelling as such.
(In reply to comment #1)
> Could you please define what that "tool" would exactly do? 
> Otherwise it will be extremely hard to define when this bug report could be
> considered "fixed" at some point. :)

Being able to edit a <templatedata> tag in a user frienly way, much like what TemplateDataEditor allows (see the attached screenshot in my first comment). JSON is not very friendly for human editors.
Basically, a window showing all the informations in the <templatedata/> and allowing a human editor to modify them easily.

Extra advantage of including this in the TemplateData extension :
* Users don't have to modify their common.js to have access to an editor
(In reply to comment #0)
...
> editing TemplateData also outside VisualEditor (I even think it's better than
> inside VisualEditor because VE doesn't work on Template namespace right now).

BTW: depending on the resolution of bug 50512, the data might be migrated from Template namespace to a specific one.
Tool = something at least as good as the TemplateDataEditor linked above.
Could you please define what that "tool" would exactly do? 
Otherwise it will be extremely hard to define when this bug report could be considered "fixed" at some point. :)
In Visual Editor edit screen templates that produce a single line of displayed text (regardless of the length of that line) do not wrap on word boundaries.

Steps to reproduce:
1. Insert a picture or other right-aligned object that text should wrap around.
2. Transclude a template that produces a single line of text. {{EW charity|123456|This charity has got a long name to make it easy to test this bug}} is an example
3. Reduce the width of your browser window until the text produced by the template is longer than the avaialble space between the left margin and the picture.

Expected behaviour: The last word(s) of the text produced by the template wraps onto a second line.
Actual behaviour: The entire line moves to below the picture as a single unit.

Any template that produces two or more lines of displayed text (on an infinitely wide window) does not exhibit this behaviour and wraps correctly. For example:

"Long text<br>1" wraps correctly

"Long text
1"
"Long text<br>" and
"Long text<br>
<!--hidden-->" all exhibit this bug.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52445
https://bugzilla.wikimedia.org/show_bug.cgi?id=50395
Change 139806 merged by jenkins-bot:
Remove display:inline-block highlight hacks

https://gerrit.wikimedia.org/r/139806
Change 139806 had a related patch set uploaded by Esanders:
Remove display:inline-block highlight hacks

https://gerrit.wikimedia.org/r/139806
Inline templates are overridden to inline-block, but setting them back to inline would mean we have to calculate the highlights using getClientRects. Might want to wait for the much discussed SVG highlights for this?
*** Bug 62800 has been marked as a duplicate of this bug. ***
*** Bug 52320 has been marked as a duplicate of this bug. ***
See http://it.wikipedia.org/wiki/File:Pic_-_VE_-_it_-_18_July_2013.png .

http://it.wikipedia.org/wiki/Tellururo_di_mercurio_e_cadmio

My understanding is that unlinking can be both done by the clear formatting button or by the trash button in the linking tool.

If you don't select exactly the word that you want to unlink (so if you include even just a space, which I guess can surely happen), you'll be able to unlink via the linking tool by clicking on the garbage can: but then, a weird cursor appears and you can no longer edit links or templates. 

According to me and itwp users that happens with both FF and Chrome.

--------------------------
**Version**: unspecified
**Severity**: normal
Worksforus, at it.wp. Will re-open if necessary.
Switching to Unconfirmed, since I can no longer reproduce this. Will ask other Italian testers if they can, otherwise I'll mark it as Resolved.
Another user reports getting the weird cursor but being still able to work regularly after that (his specs, Firefox on W7 64bit, Monobook).
I'm looking for the quickest way to produce screencasts for you (Chrome does not seem to have valid plugins for that unfortunately).
Don't even mention it, James :)
Sorry I can't provide a video today ;)
but will try to explain more carefully.
It definitely still occurs, it was just reported (among other things) in

http://it.wikipedia.org/wiki/Rodney .

The clear formatting works fine.
Properly unlinking a single word works fine.
In this article, if I just select, say, from "toponimo" to "antica" and use the linking tool to unlink, I will be able to do it the first time but then I'll get the limited functionalities listed above.
The same if I just select "adespota," .
I don't do anything else before or after that.
It happens with both Monobook and Vector and on en.wp as well, I just tried editing the article "Penguin".

Thanks.
I can't reproduce this in either Chrome or Firefox - by drag-selecting the word with the mouse, right-clicking, double-clicking; and by selection with the keyboard or drag-clicking with the mouse to select more than the word, using both the link inspector and its remove ("trash") icon and the general "clear formatting" tool. :-(

Does this occur on every page? What about after a hard-refresh? Can you make a video/screencast of you doing this so I can see exactly how it occurs? Sorry to ask so much!
Two screenshots showing the search function applied to {{cite book}} on en.wp

A user on the English Wikipedia reports that when entering a template using the transclusion editor, the search for parameters fails when the parameter includes a space:

"when I start typing "Source date" (without quotes, of course) into the search box, something interesting happens when I get to the "d" - the search results say "Unknown parameter". That is, at the point where I've typed "Source d", then - essentially - the search fails; the search software decides that there are no matching entries."

I've tested this with both {{cite web}} and {{cite book}}

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51822

**Attached**: {F11265}
Will this allow searching on instring matches of both title and label? 

If not, will that be covered by bug 51822 or is a new bug required?
This is now fixed in master, and will be released to MediaWiki.org on Thursday 5 September, and to Wikipedias on Thursday 12 September. Sorry for the disruption.
Change 82055 merged by jenkins-bot:
Include param label in search index

https://gerrit.wikimedia.org/r/82055
Change 82055 had a related patch set uploaded by Trevor Parscal:
Include param label in search index

https://gerrit.wikimedia.org/r/82055
A user on Wikipedia has determined that the cause is that the data the search function searches on is the internal parameter name, which is invisible to the user, not the visible label. This is very wrong. 

"So VE users have learned that the only way, in the Transclusion/Template dialog, to add a parameter is to type the parameter name, then press Enter. But that just changed - now you click the parameter name to select it. That's more obvious - but if, for some reason, having learned the old way, you continue to use it - that's trouble.

Example: Cite web. Let's suppose I want to add the parameter "Month of publication". I type that, hit Enter, and there it is, on the left. Except, not really. VE thinks this is a parameter not on its list - you can tell that because there is no description just above the input box where you enter the value of that parameter. (Compare to entering a value for the parameter "Source title").

Under the hood, here's what happens: VE knows that "Source title" is the label (via TemplateData) for the parameter "title". (Similarly, "URL" is the label for the parameter "url" - and yes, parameters are case sensitive.) But VE doesn't know that "Month of publication" (typed) is the label for the parameter "month". So the template code that VE actually stores is this:

    {{Cite web|url = http://example.com|title = Whatever the title is|Month of publication = June}}

That doesn't cause a visible problem on the VE edit page. However, in this case, after saving the page, what is displayed to readers is "Unknown parameter |Month of publication= ignored (help) "

Recommendation: If a person types the name of a parameter and presses Enter, VE should check the typed name against the list of labels in TemplateData, for that template, and if there is a match, handle the new parameter just as if the person had clicked the matching parameter rather than typed it."
**Author:** `kwang`

**Description:**
This shows the article and the visual editor save dialog

I added a link to a new page but it wouldn't let me save my edit. Every time I saved it would load but then display the save page dialog again.

I ended up creating the link in the source.

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

**Attached**: {F11178}
Fixed and will get deployed in a few minutes' time.
Change 75561 merged by jenkins-bot:
Show error when trying to save in read-only mode

https://gerrit.wikimedia.org/r/75561
Change 75561 had a related patch set uploaded by Esanders:
Show when trying to save in read-only mode

https://gerrit.wikimedia.org/r/75561
Two other users have reported the same thing on en.wikipedia, so the cause was the database being locked.

Could be related to Bug 50472 which is marked as fixed but has apparently not yet been deployed?
**kwang** wrote:

error while editing source code.

**Attached**: {F11179}
**kwang** wrote:

More details: when I edited the source it said that the database was locked. This is likely the issue that was happening, but the error wasn't showing up in the visual editor.
Browser: Chrome any version.

1. Open VE
2. Type or copy-paste സന്തോഷ്
3. Move the cursor to the end of that word.
4. Press left arrow to move the caret backwards.
5. In the second keypress onwards cursor is stuck.(like സന്തോ|ഷ് )

Expected: cursor keep moving to left. 

Observed. cursor stuck.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 80689 merged by jenkins-bot:
Revert model to use simple UTF-16 code units

https://gerrit.wikimedia.org/r/80689
Change 80689 had a related patch set uploaded by Divec:
DONTMERGE:Revert model to use simple UTF-16 code units

https://gerrit.wikimedia.org/r/80689
There's code in progress to fix this in gerrit 80689 which is currently a work-in-progress.
There's code to address this bug in the following patch, which is due to go live on mediawiki.org by 13 September 2013:

https://gerrit.wikimedia.org/r/#/c/82858/

It does not fix this completely, but it does make it possible to cursor left through the cluster with repeated consecutive keypresses.
Debug Information:

Grapheme breaks as per unicodejs:
0: "സ"
1: "ന്"
2: "തോ"
3: "ഷ്"

Ligature break 1 and 2 logically wrong because they form a single cluster ന്തോ. You cannot place a cursor in between this cluster. It is a single syllable too. Firefox allows you to place the cursor at all of these breaks anyway. Infact Firefox allows you to place the cursor even inside ligature programatically. Chrome allows cursor positioning only at logical positions.

In this specific case. VE is asking Chrome to place the cursor at end of  grapheme break #1(ന്). but Chrome does not obey it and place it at the end of #2 (തോ). This repeats in every left cursor movement and it looks like cursor is stuck at the end of തോ.

In my quick observation those logical positions does not match with the grapheme cluster boundary specification of Unicode (www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries).

That causes lot of inconstancy in the offset known to the data model of VE and the actual offset appearing in browser. It will lead to many unexpected behavior of cursor positioning and text selections.
On a regular page load:

* http://en.wikipedia.org/wiki/Roadblock_(disambiguation)
* Logged-out (Chromium Incognito mode)

We get this (did a full analysis while I had the data in front of me, but focus on "On Edit":

Top:
 - [core]   load.php?modules=startup
 - [misc]   load.php?modules=.. top queue ...
 - [vector] load.php?modules=ext.vector.footerCleanup (bug 51564)
 * [ve]     load.php?modules=ext.visualEditor.viewPageTarget.init
 - [core]   load.php?modules=site

Bottom:
 - [misc]   load.php?modules=.. bottom queue ...
 - [vector] load.php?modules=ext.vector.collapsibleNav (bug 51564)
 - [misc]   load.php?modules=.. jquery.ui ...
    (dependency of something in the bottom queue, separate cache group)

On Edit:
 * [ve]     load.php?modules=ext.visualEditor.base,mediawiki,viewPageTarget|jquery.visibleText|oojs|unicodejs.wordbreak
 * [ve]     load.php?modules=jquery.byteLength,byteLimit|mediawiki.api.edit|mediawiki.feedback|ext.visualEditor.core,icons-vector|ext.visualEditor.viewPageTarget.icons-vector|rangy
 * [ve]     load.php?modules=ext.visualEditor.specialMessages
 - [ve]     api.php POST action=visualeditor & paction=parse
 - [ve]     api.php?action=query&meta=userinfo

These shouldn't be 3 separate load.php requests. Ideally it'd be 1, but we should at least cut it down to 2. We should figure out why they are split.
Change 197402 merged by jenkins-bot:
Load RL modules in one load.php request, rather than in two stages

[[https://gerrit.wikimedia.org/r/197402]]
Change 197402 had a related patch set uploaded (by Jforrester):
Load RL modules in one load.php request, rather than in two stages

[[https://gerrit.wikimedia.org/r/197402]]
Change 193026 merged by jenkins-bot:
Load RL modules in one load.php request, rather than in two stages

[[https://gerrit.wikimedia.org/r/193026]]
Saves 1 request and 3KB.

From 20 total request (521KB), to 19 total requests (518KB).

Tested on localhost. (Page view + load editor; includes two EventLogging requests and some images).
Saves 1 request and 3KB.

From 20 total request (512KB), to 19 total requests (518KB).

Tested on localhost. (Page view + load editor; includes two EventLogging requests and some images).
Change 193026 had a related patch set uploaded (by Jforrester):
[WIP] Factor out loading code into TargetLoader

[[https://gerrit.wikimedia.org/r/193026]]
* Select some text forwards and copy-paste it, everything is great.
* Select some text backwards and copy-paste it, you now have an extra linebreak.

?!???!

--------------------------
**Version**: unspecified
**Severity**: normal
Now merged; will go out with next push.
Change 80299 merged by jenkins-bot:
Fix copy and paste of backwards selction

https://gerrit.wikimedia.org/r/80299
Change 80299 had a related patch set uploaded by Esanders:
Fix copy and paste of backwards selction

https://gerrit.wikimedia.org/r/80299
I can confirm this is still happening in Firefox 23/linux
When typing in visual editor, sometimes pressing CTRL+Z will replace the last entered character with a pawn (♙).

I've encountered this most frequently when undoing text that appeared as a link when I didn't want it to (see bug 51531) but occasionally when undoing other text as well.

There are numerous other pawn insertion bugs, other editors have suggested possible relationships with bug 49732, bug 48346 or bug 51140, but none seem quite the same (e.g. there is no non-ASCII text, bold or italics involved) and all are marked as fixed. I encountered this yesterday and today (16 and 17 July).

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51762
https://bugzilla.wikimedia.org/show_bug.cgi?id=52113
I believe these issues are now fixed.
This is still happening occasionally, and almost always associated with undoing text added to a link. However I can't reproduce it every time.
en.wp thread for reference https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564648446#Adding_text_after_a_link_includes_that_text_in_the_link._Undoing_sometimes_gives_a_pawn
Screenshot of problem

1. Open https://en.wikipedia.org/wiki/Pancytopenia?veaction=edit#External_links
2. Select Commonscat template block
3. Put cursor in heading after "External links"
4. Arrow keys to navigate down (to after text in list item "* [[CDC]]")
5. Arrow keys to navigate right


> Uncaught Error: Offset could not be translated to a DOM element and offset: 2409
ve.ce.Document.getNodeAndOffset
ve.ce.Surface.showSelection
ve.ce.Surface.onChange
oo.EventEmitter.emit
ve.dm.Surface.change
ve.ce.Surface.handleLeftOrRightArrowKey
ve.ce.Surface.onDocumentKeyDown
proxy
jQuery.event.dispatch
elemData.handle.eventHandle

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

**Attached**: {F11838}
I just got that same error ("Uncaught Error: Offset could not be translated to a DOM element and offset: 458") on Meta. Sadly, I don't know what caused it.
This appears to now be fixed. Marking as such, though can't determine exactly what fixed fixed it (probably Ed's cursoring changes?).
Confirmed still happening.
When doing the steps outlined below, strange '9' character plus a newline appears and input it jumped backwards after 3 character.

See http://youtu.be/A7MWIdu3dtk for how it looks; Using http://en.wikipedia.org/wiki/Ansaldo_Poggi as test ground.

1. Place marker under "References" header
2. hit "backspace"
3. type "foobar"

--------------------------
**Version**: unspecified
**Severity**: major
**URL**: http://en.wikipedia.org/wiki/Ansaldo_Poggi
Resetting to FIXED; this was a confirmed broken behaviour which has subsequently been FIXED, as far as we can tell - probably by the re-write of the Content Editable surface interaction model.
(In reply to comment #2)
> Cannot reproduce it now on betalabs.

Where "on betalabs"? Tested how exactly (which browsers and versions)? Current steps aren't transparent so somebody else couldn't recreate your conditions...

> It might got fixed.

"Might" = no identifiable code commit = WORKSFORME instead of FIXED. See https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle
Cannot reproduce it now on betalabs.It might got fixed.So changing the status as resolved and fixed.
If you can still reproduce it, please reopen it.
TypeError: node.getParent(...) is null
http://bits.wikimedia.org/static-1.22wmf9/extensions/VisualEditor/modules/ve/ce/ve.ce.Surface.js
Line 1267
I use the "link" tool from the toolbar to in-link to other articles. However, after adding the link, the editor doesn't disappear. I have to click again, outside it, to make it go away.

--------------------------
**Version**: unspecified
**Severity**: normal
This is now merged and will be deployed later.
Change 76839 merged by jenkins-bot:
Link inspector bug fixes

https://gerrit.wikimedia.org/r/76839
Change 76839 had a related patch set uploaded by Trevor Parscal:
The greatest commit in the history of the world*

https://gerrit.wikimedia.org/r/76839
I think "Clear formatting" is important enough to justify a keyboard shortcut.  For example, there are cases where the formatting can unintentionally continue longer than you want, such as when you add a link.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53682
https://bugzilla.wikimedia.org/show_bug.cgi?id=56453
Re-closing; have made bug 56453 for the suggestion to add a new one for other keyboards.
(In reply to comment #7)
> Except there is no \ key on keyboards like the French one, so the shortcut is
> reported as not working (also, provoking weird behaviour I'll report
> elsewhere), since they should type CTRL + Alt Gr + 8. Can we do something
> about this? Thanks.

Weird behaviour reported on https://bugzilla.wikimedia.org/show_bug.cgi?id=53682
Except there is no \ key on keyboards like the French one, so the shortcut is reported as not working (also, provoking weird behaviour I'll report elsewhere), since they should type CTRL + Alt Gr + 8. Can we do something about this? Thanks.
Now merged and will go out with the next production push, probably tomorrow.
Change 76666 merged by jenkins-bot:
Add keyboard shortcut for 'clear' button

https://gerrit.wikimedia.org/r/76666
Change 76666 had a related patch set uploaded by Jforrester:
Add keyboard shortcut for 'clear' button

https://gerrit.wikimedia.org/r/76666
Ctrl + M might be a little friendlier.  I know from experience people confuse backslash and forward slash.  But I don't feel strongly about it.
I can see wanting to use Ctrl + Spacebar for a general whitespace inserter menu (nbsp/tab/etc.), so how about we go with Ctrl + \?
Shortcuts used in other programs are:

Ctrl + Spacebar - Used by Word for "Remove paragraph or character formatting."/"Remove manual character formatting" (http://support.microsoft.com/kb/290938).
Ctrl + \ - Used by Google Docs for "Clear formatting" (https://support.google.com/drive/answer/179738?hl=en)
Ctrl + M - Used by LibreOffice for "Clear direct formatting" (https://help.libreoffice.org/Common/General_Shortcut_Keys_in)
Right now the SurfaceObserver locks and unlocks a lot, firing a lot of events and stopping and restarting a lot. We should make locks wider so that this doesn't happen.

We should also eliminate cases where the SurfaceObserver responds to a DOM change that was actually made by VE itself, and we should change pawning to no longer go through the model.

--------------------------
**Version**: unspecified
**Severity**: major
Yes.
Can we now deem this to have been done?
Typing in the Devanagari script causes very unusual placement of vowels in relation to consonants. The correct place to put the vowels is always after the preceding consonant, but the VisualEditor causes very strange placement.

To try, I used the standard Hindi InScript keyboard (not ULS IME, but the operating system's InScript keyboard). I tried to type the word "अंग्रेज़ी" (the Hindi name of the English language).

To get that word with the InScript keyboard, type the following keys on the English-US keyboard:

Dxidjs;]r

The expected result is "अंग्रेज़ी".

The actual result on Firefox 22 is "अंग्ेच़ीर".

The actual result on Chrome 28 is "्रेची".

I tried this with Firefox 22 on Fedora 18.

I mark this as blocker, because in this state the VisualEditor must not be widely deployed on a Wikipedia that uses the Devanagari script, such as Hindi (hi), Marathi (mr), Nepali (ne) or Sanskrit (sa) (there are a few more languages that use it). It's OK to have it as opt-in for testing on these wikis, though.

--------------------------
**Version**: unspecified
**Severity**: blocker
master looks good to me. Thanks!
Given that this is now merged, I'm going to mark this as fixed. However, this is provisional - please re-open if you think that this has not worked!
Change 80080 merged by jenkins-bot:
Don't emit Surface changes back to the Surface

https://gerrit.wikimedia.org/r/80080
Change 80080 had a related patch set uploaded by Jforrester:
WIP:Don't emit Surface changes back to the Surface

https://gerrit.wikimedia.org/r/80080
Hi, thanks for the detailed error description with the en-US key equivalents -- it really helps!

I *think* this is resolved by the following patch: https://gerrit.wikimedia.org/r/#/c/79451 . At least, the patch seems to fix the "hindi inscript (m17n)" ibus method on Linux.
Some scripts, among them Arabic, Hebrew, and most scripts of India and SE Asia, are written as combinations of consonants and vowel marks that combine with them.

In most text editors and word processors, when the cursor is after a combination of a consonant and a vowel, and the backspace key s pressed, the vowel is deleted first and the the consonant.

For example if you have the Devanagari combination गा (ग [g] + ा [a]), these are two Unicode characters, which the font joins automatically. If the cursor is after them and you press the backspace key, then the second character ( ा) is supposed to be deleted, and only then the first (ग). That is what happens in most text editors, including MediaWiki's source editor.

In the VisualEditor, backspace immediately deletes the whole cluster. This behavior is unexpected for most users.

To complicate things, when the cursor is before the combined character and the Delete key is pressed, the expected behavior is to delete the whole cluster. This is what happens in the VisualEditor now, and this must be kept like that. For cursor movement, back and forth, the cluster must also be treated as one character, so if the cursor is before गा and the right-pointing arrow is pressed, the cursor is supposed to immediately go after the गा. This also works correctly now, and must be kept.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49233
https://bugzilla.wikimedia.org/show_bug.cgi?id=53757
Change 80689 merged by jenkins-bot:
Revert model to use simple UTF-16 code units

https://gerrit.wikimedia.org/r/80689
Change 80689 had a related patch set uploaded by Divec:
DONTMERGE:Revert model to use simple UTF-16 code units

https://gerrit.wikimedia.org/r/80689
There's code in progress to fix this in gerrit 80689 which is currently a work-in-progress.
This is how we expect backspace to work with our current support of grapheme clusters. As Denis points out, being able to delete combining marks separately would have to be enabled on a per script basis, as we wouldn't want to require multiple keystrokes to remove e-acute, or a Jamo-constructed Hangul character.
(In reply to comment #1)
> Could this be a dupe of -
> https://bugzilla.wikimedia.org/show_bug.cgi?id=49233  ?

Well, that one is marked as FIXED, and this one is definitely not fixed on master.
The expected behaviour of backspace can be different with different writing systems.

In Indic scripts, as explained in the bug description, the most common behaviour is that backspace should erase one characters and delete should erase a cluster. See http://publib.boulder.ibm.com/infocenter/hodhelp/v10r0/topic/com.ibm.hod.doc/help/hindi.html#hindispecialkeys
http://www-archive.mozilla.org/projects/ctl/tests/#indiceditoper

For other scripts it might be different, particularly for Latin, Greek and Cyrillic where, because of the precomposed accented characters, it is expected that characters and character sequences (base character + combining diacritic) that represent units will behave the same way, i.e. backspace and delete erase the base and diacritic, for example the single character à and the two characters ɛ̀ should be treated the same way.

http://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries talks about this.
Could this be a dupe of -
https://bugzilla.wikimedia.org/show_bug.cgi?id=49233  ?
With bug 49931 we currently extend link annotations when typing at the end. This makes it very difficult to type plain text after a link at the end of a paragraph.

We should change the logic to stop extending the annotation once a character is added that produces a new wordbreak.

There may be some odd cases as wordbreak logic can depend on more that two characters, e.g. a' has a wordbreak but a's doesn't, so trying to add "'s" to the end of a link label would break after the "'" even though it wouldn't if "'s" was added as one operation.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51442
*** Bug 51531 has been marked as a duplicate of this bug. ***
Fixed and will get deployed in a few minutes.
Change 74168 merged by jenkins-bot:
Split continued link annotations on wordbreaks

https://gerrit.wikimedia.org/r/74168
Change 74168 had a related patch set uploaded by Esanders:
[WIP] Split continued link annotations on wordbreaks

https://gerrit.wikimedia.org/r/74168
See, for example, https://en.wikipedia.org/w/index.php?title=Peaches_Does_Herself&diff=prev&oldid=564544238 and https://en.wikipedia.org/w/index.php?title=Carl_Rogers&diff=prev&oldid=564544061 - this is kinda a problem.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T53509}
(In reply to comment #12)
> Reopening as this is still happening:
> first nowiki after line 133 in
> https://en.wikipedia.org/w/index.
> php?title=Pet&diff=570614739&oldid=570586939 .

That's almost certainly using a cached version of the code; I can't reproduce that on Chrome/Firefox/Safari/Opera on Mac or Linux.

(In reply to comment #13)
> I am also filing a related common problem we meet at it.wp.
> If this is not the right place, just tell me and I'll copy/paste my report
> elsewhere.

Yeah, if you could file this as a new bug please - this is not related to removing whitespace from the start of paragraphs.
I am also filing a related common problem we meet at it.wp.
If this is not the right place, just tell me and I'll copy/paste my report elsewhere.

We had troubles with nowikis being thrown right after some templates when the user did not add an extra space there, but simply edited something in that page. See https://it.wikipedia.org/w/index.php?title=Wikipedia&diff=61171396&oldid=61171228 .

We actually found a workaround for this: https://it.wikipedia.org/w/index.php?title=Template:Quote&curid=224372&diff=61173726&oldid=60749506 but since this addition is apparently a nonsense, users demand that VE prevents that behaviour instead.

They also think this is related to templates featuring some kind of table.

I did some tests as well.
I was able to reproduce an unwanted situation where the first line and the table (which is actually a template) were mingled in a non-editable block https://it.wikipedia.org/w/index.php?title=Utente%3AElitre_%28WMF%29%2FSandbox_VE&diff=61181542&oldid=61181524 .

But I was also able to avoid nowikis, even if the extra span tags were not added to the template: as you can see here https://it.wikipedia.org/w/index.php?title=Utente:Elitre_(WMF)/Sandbox_VE&diff=prev&oldid=61181473, if the first letter of the line is actually closer to the template's final brace (with no space between), VEditing that page will result in the text getting automatically placed in a better position, and no nowikis in sight, even after multiple saves of the page.

Thanks.
Reopening as this is still happening:
first nowiki after line 133 in https://en.wikipedia.org/w/index.php?title=Pet&diff=570614739&oldid=570586939 .
Now fixed in the code; next scheduled deployment is not until 15 August,
however. :-(
Change 77287 merged by jenkins-bot:
Remove inserted leading whitespace

https://gerrit.wikimedia.org/r/77287
So I just implemented a fix for this, but it broke a test that asserts that whitespace inside a pre is untouched. I'll put it a check for <pre> elements but we should be aware that this is broken, because any element can have white-space:pre attached to it, e.g.

<span style="white-space:pre">    Foo</span>

Will now normalise to

<span style="white-space:pre">Foo</span>

Long term we should look into just warning the user.
Change 77287 had a related patch set uploaded by Esanders:
[WIP] Remove inserted leading whitepsace

https://gerrit.wikimedia.org/r/77287
(In reply to comment #5)
> With bug 50841 we now convert 
> 
> [space]Foo
> 
> to
> 
> <nowiki> </nowiki>Foo
> 
> (previously <nowiki> Foo</nowiki>)
> 
> This is the correct behaviour.

Also, with gerrit 76223 VisualEditor users can now edit through <nowiki>s transparently.

> Perhaps this, and other whitespace issues (e.g. double
> spaces), should be flagged up to the user (with a wiggle underline?)

That would be one solution that is quite generalisable, but could be a great deal more work.
*** Bug 52252 has been marked as a duplicate of this bug. ***
With bug 50841 we now convert 

[space]Foo

to

<nowiki> </nowiki>Foo

(previously <nowiki> Foo</nowiki>)

This is the correct behaviour.

We should be careful going do the road of automatically correcting what we believe to be typos. Perhaps this, and other whitespace issues (e.g. double spaces), should be flagged up to the user (with a wiggle underline?)
*** Bug 51509 has been marked as a duplicate of this bug. ***
Without whitespace stripping (either in VE or Parsoid) and no nowiki, that text will become <pre>-formatted.

Quickly discussed with Gabriel on IRC. It is probably better fixed in VE since Parsoid doesn't have contextual information about where the space is meaningful or not.

If leading whitespace at start of line is desired by the editor, then VE should convert them to &nbsp; or if nowikis are acceptable, the spaces can be left alone.  In either case, this kind of edits should hopefully be rare.
If VE can strip leading whitespace in paragraphs, that will eliminate these errors.  Alternatively, Parsoid can do that normalization. Unclear where this should be done.  Will discuss on IRC.
and https://en.wikipedia.org/w/index.php?title=John_Altoon&diff=prev&oldid=564536250
When creating a new article in the source editor, a box with the message newarticletext appears at the top. It doesn't appear in the VisualEditor.

Compare:

source: https://en.wikipedia.org/w/index.php?title=Aklotspa&action=edit

VE: https://en.wikipedia.org/wiki/Aklotspa?veaction=edit

--------------------------
**Version**: unspecified
**Severity**: trivial
Fixed and will get deployed in a few minutes.
Change 75563 merged by jenkins-bot:
Show newarticletext(anon) when creating a new page

https://gerrit.wikimedia.org/r/75563
Change 75563 had a related patch set uploaded by Esanders:
Show newarticletext(anon) when creating a new page

https://gerrit.wikimedia.org/r/75563
The resolution of Bug 51160 gives me hope. French Wikipedia transcludes Talk:.../Suppression subpages for some deleted articles.
 
https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial%3ARecherche&profile=advanced&search=Suppression&fulltext=Search&ns1=1&redirs=1&profile=advanced
@James, before marking this trivial, I hope you did an impact assessment on
1. https://de.wikipedia.org/wiki/MediaWiki:Newarticletext-0
2. https://es.wikipedia.org/wiki/MediaWiki:Newarticletext
3. https://fr.wikipedia.org/wiki/MediaWiki:Newarticletext
4. https://he.wikipedia.org/wiki/MediaWiki:Newarticletext
5. https://it.wikipedia.org/wiki/MediaWiki:Newarticletext
6. https://nl.wikipedia.org/wiki/MediaWiki:Newarticletext
7. https://pl.wikipedia.org/wiki/MediaWiki:Newarticletext
8. https://ru.wikipedia.org/wiki/MediaWiki:Newarticletext
9. https://sv.wikipedia.org/wiki/MediaWiki:Newarticletext

I know you didn't, because on at least one of those projects there is critical functionality in this message.  Since you and O Keyes (on a different bug about missing interface messages) are being so rude, I'll let you find out the hard way.
(In reply to comment #1)
> This is something that obviously must be fixed before VE is enabled by
> default, which is planned for Real Soon Now(tm).

By default for whom on which wiki? It's been enabled by default on enwiki since 1 July for logged-in users and since 15 July for anonymous users too.
This is something that obviously must be fixed before VE is enabled by default, which is planned for Real Soon Now(tm).
1. Edit page
2. Focus a link and open the link inspector, have the link input widget focussed
3. Make a change (or don't) and click "Save page".

The surface dims, but the inspector stays open and at full opacity.

--------------------------
**Version**: unspecified
**Severity**: normal
Confirmed, the link and language inspectors close on triggering the save dialog.
Is this fixed now? I can't reproduce this any more. Clicking Save page closes the link inspector for me, and it seems to save the changes correctly too.
*** Bug 63050 has been marked as a duplicate of this bug. ***
Same for context menu (e.g. focus a link, but don't open the inspector yet)
The link inspector ignores the text entered when the user does not wait for the "matching page" results to appear (Chrome/Ubuntu) before pressing "enter". If the user is adding a completely new link, the selection appears offscreen and we get a JavaScript error:

Uncaught Error: No class registered by that name: undefined 

This behavior is similar to earlier issues such as bug 42278 and bug 49941.

--------------------------
**Version**: unspecified
**Severity**: major
This is now merged and will be deployed later.
Change 76839 merged by jenkins-bot:
Link inspector bug fixes

https://gerrit.wikimedia.org/r/76839
*** Bug 52344 has been marked as a duplicate of this bug. ***
Change 76839 had a related patch set uploaded by Trevor Parscal:
The greatest commit in the history of the world*

https://gerrit.wikimedia.org/r/76839
Templates should not have identically named parameters  ("url=", "url=", for example). Can VisualEditor be configured to note when this happens, if not outright prevent it?

--------------------------
**Version**: unspecified
**Severity**: enhancement
I'm going to assume "yes" given testing.
Works for me... Has this been fixed since it was reported?
* Edit a page
* Put cursor at the end of a line
* Go to toolbar and Insert new link
* The input field is focussed, blur it by clicking somewhere inside the inspector outside the input field
* Click the trash can (since there is no "x" close button, that's the closest I can find in the top left or right corner)
* The inspector clears itself but stays behind (crashes half-way closing)


Uncaught Error: No class registered by that name: undefined ve.Factory.js:62
ve.Factory.create ve.Factory.js:62
ve.dm.SurfaceFragment.annotateContent ve.dm.SurfaceFragment.js:518
ve.ui.AnnotationInspector.onClose ve.ui.AnnotationInspector.js:162
ve.ui.Window.close ve.ui.Window.js:281
ve.ui.Inspector.onRemoveButtonClick ve.ui.Inspector.js:89
oo.EventEmitter.emit oo.js:421
ve.ui.IconButtonWidget.onClick ve.ui.IconButtonWidget.js:61
proxy load.php?debug=true&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20130715T175253Z:775
jQuery.event.dispatch load.php?debug=true&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20130715T175253Z:3058
elemData.handle.eventHandle


An empty inspector stays behind and the user can no longer interact with any links at this point. When doing anything (scrolling, typing) the inspector will hide. Except the bubble tip on top, that one stays behind...

--------------------------
**Version**: unspecified
**Severity**: critical
*** Bug 51984 has been marked as a duplicate of this bug. ***
This is now merged and will be deployed later.
Change 76839 merged by jenkins-bot:
Link inspector bug fixes

https://gerrit.wikimedia.org/r/76839
Change 76839 had a related patch set uploaded by Trevor Parscal:
The greatest commit in the history of the world*

https://gerrit.wikimedia.org/r/76839
I can reproduce this by putting the cursor on a blank line (such as an empty page), clicking link inspector icon, then pressing key 'Esc'.
Bug 51415 is reporting the same JS error in the same component, with different steps to reproduce.
I've just tested this and can reproduce it except for comment 3 - in my test I was able to do everything except link and the save worked as expected.
It could be just be, but I run into this quite often. Every time it happens the interface crashes unrecoverably and all work is lost.
Created attachment 12854
Screenshot of problem

**Attached**: {F11587}
Note, this doesn't seem a race condition or anything. I'm giving it at least half a second to a second of time between each distinct action.
Screenshot of problem in local VisualEditor dev

The code [1] is using $status->getHtml() but apparently it doesn't work as expected because I'm getting raw wikitext.

        "edit": {
            "code": "abusefilter-warning",
            "info": "Hit AbuseFilter: Blanking articles",
            "warning": "'''Warning:''' This action has been automatically identified as harmful.\nUnconstructive edits will be quickly reverted,\nand egregious or repeated unconstructive editing will result in your account or IP address being blocked.\nIf you believe this action to be constructive, you may submit it again to confirm it.\nA brief description of the abuse rule which your action matched is: Blanking articles",
            "result": "Failure"
        }

To import the filter, use "Special:AbuseFilter/import" on your localwiki with:

{"row":{"af_id":"1","af_pattern":"!\"autoconfirmed\" in user_groups\r\n& new_size < 50\r\n& old_size > 500\r\n& article_namespace == 0","af_user":"1","af_user_text":"Root","af_timestamp":"20130715214820","af_enabled":"1","af_comments":"","af_public_comments":"Blanking articles","af_hidden":"0","af_hit_count":"9","af_throttled":"1","af_deleted":"0","af_actions":"warn,disallow,tag","af_global":"0","af_group":"default"},"actions":{"disallow":{"action":"disallow","parameters":[""]},"tag":{"action":"tag","parameters":["blanking"]},"warn":{"action":"warn","parameters":["abusefilter-warning"]}}}



[1] https://github.com/wikimedia/mediawiki-extensions-AbuseFilter/blob/a6b1dade840841ff7adf2ff289b6428f930d6796/AbuseFilter.hooks.php#L22-L57

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

**Attached**: {F11585}
We will deploy this fix today.
Change 73895 merged by jenkins-bot:
Really parse the API warning in the APIEditBeforeSave hook

https://gerrit.wikimedia.org/r/73895
(Sorry, if my last comment was unlcear:) Showing the full warning message, I mean.
(In reply to comment #2)
> I don't think this is really what people want to be doing (regardless of
> whether HTML is being presented by this call or not). Take a look at filter
> 554
> on English Wikipedia (http://en.wikipedia.org/wiki/Special:AbuseFilter/554).
> Note how it triggers a message of abusefilter-top100. That causes the
> standard
> wikitext editor to display
> http://en.wikipedia.org/w/index.php?title=MediaWiki:abusefilter-top100 which
> explains what's wrong with the edit. That's what you need to display, not the
> short description (in this case "top100 blog charts", which doesn't mean
> squat
> to a new editor).

That's exactly what we're trying to do.
Change 73895 had a related patch set uploaded by Hoo man:
Really parse the API warning in the APIEditBeforeSave hook

https://gerrit.wikimedia.org/r/73895
**kwwilliams** wrote:

I don't think this is really what people want to be doing (regardless of whether HTML is being presented by this call or not). Take a look at filter 554 on English Wikipedia (http://en.wikipedia.org/wiki/Special:AbuseFilter/554). Note how it triggers a message of abusefilter-top100. That causes the standard wikitext editor to display http://en.wikipedia.org/w/index.php?title=MediaWiki:abusefilter-top100 which explains what's wrong with the edit. That's what you need to display, not the short description (in this case "top100 blog charts", which doesn't mean squat to a new editor).
That's because Status::getHTML isn't actually doing real parsing... going to look at this tomorrow
Sometimes for templates, you have a pre-defined set of values to use for a parameter. Perhaps it could be a nice thing to expose valid values to the user in a drop down or something.
Is this still on the docket? It's vital. Is there some other way of specifying valid string values in TemplateData (TD)? If not, that would appear to be a large oversight if TD is supposed to help users easily interact with template params
It would also be useful to be able to use a set of possible values provided by some template/module.
That's something which would be extremely useful.

I'm currently working on a proposal for ease Wikitionary contribution through templatedata. Such a feature would for example allow to select word category (verb, adjective…).
Change 263655 abandoned by Alex Monk:
[WIP] Add a parameter key to limit possible valid values to a given set

[[https://gerrit.wikimedia.org/r/263655]]
Change 263655 had a related patch set uploaded (by Alex Monk):
[WIP] Add a parameter key to limit possible valid values to a given set

[[https://gerrit.wikimedia.org/r/263655]]
>>! In T53375#564935, @Krinkle wrote:
>  params: {
>   "key": {
>     "type": ...
>     "values": [ .. ]

Seems a good way of specifying it, +1
Yeah, we should add this. Though it doesn't have to be as a parameter type. I imagine we could also do it more generically.

 params: {
  "key": {
    "type": ...
    "values": [ .. ]

The upside is that this is easier to specify and validate.

An nice bonus is that it would allow one to preserve types regardless of whether the possible values are finite or not (e.g. freeform strings, numbers, dates, page names).

Down side is that it's tricky for consumers like VisualEditor to have a dropdown menu for values that aren't simple strings.

But I think that's fine. Those consumers can choose to support it however they like. E.g. they could support "values" only for string values.

As a nice bonus this would allow VisualEditor to make dedicated select interfaces much better. E.g. a colour picker with limited values could be a row with squares and you visually pick one of those colours (like radio buttons). And a parameter that takes file names (e.g. for icons), could have live previews for the 10 different icons it supports.

The type-restricted implementation would look something like this:

 params: {
  "key": {
    "type": "options"
    "values": [ .. ]

And would treat them as type: 'string' with no further type association.

It also has the downside of having a "param" property (values) that only makes sense in combination with another. Making it slightly less intuitive.
Yeah, we should add this. Though it doesn't have to be as a parameter type. I imagine we could also do it more generically.

params: {
  "key": {
    "type": ...
    "values": [ .. ]

The upside is that this is easier to specify and validate.

An nice bonus is that it would allow one to preserve types regardless of whether the possible values are finite or not (e.g. freeform strings, numbers, dates, page names).

Down side is that it's tricky for consumers like VisualEditor to have a dropdown menu for values that aren't simple strings.

But I think that's fine. Those consumers can choose to support it however they like. E.g. they could support "values" only for string values.

As a nice bonus this would allow VisualEditor to make dedicated select interfaces much better. E.g. a colour picker with limited values could be a row with squares and you visually pick one of those colours (like radio buttons). And a parameter that takes file names (e.g. for icons), could have live previews for the 10 different icons it supports.

The type-restricted implementation would look something like this:

params: {
  "key": {
    "type": "options"
    "values": [ .. ]

And would treat them as type: 'string' with no further type association.

It also has the downside of having a "param" property (values) that only makes sense in combination with another. Making it slightly less intuitive.
*** Bug 52754 has been marked as a duplicate of this bug. ***
(In reply to comment #2)
> Ping @TrevorParscal.
> 
> Since wikitext template editing will always be possible, we can't (yet?)
> enforce values in VisualEditor. We can only suggest.
> 
> E.g. if a template parameter "foo" is specified as values: ['a', 'b']. and
> wikitext has {{echo|foo=x}}, we need to provide a way to edit that, while
> still
> being able to set it to a or b.

The "normal" way is a drop-down with the target of the drop-down being a free-entry text field that suggests entries (but does not block other entries).
*** Bug 50760 has been marked as a duplicate of this bug. ***
Ping @TrevorParscal.

Since wikitext template editing will always be possible, we can't (yet?) enforce values in VisualEditor. We can only suggest.

E.g. if a template parameter "foo" is specified as values: ['a', 'b']. and wikitext has {{echo|foo=x}}, we need to provide a way to edit that, while still being able to set it to a or b.
See "bug 50760 - Support suggested values" which is quite similar.

https://bugzilla.wikimedia.org/show_bug.cgi?id=50760
Forked from T53314#557160 (bug 51314 comment 2):

The following should be set to use B/I, rather than the generic:

* cs Czech
* he Hebrew
* pl Polish

The following should be set to use F/K, rather than the generic:

* da Danish
* no Norwegian (and nn?)
* sv Swedish
This is now done; we'll deploy this within the hour.
Change 73850 merged by jenkins-bot:
Set bold/italics icons for cs/he/pl; da/no/nn/sv

https://gerrit.wikimedia.org/r/73850
Change 73850 had a related patch set uploaded by Jforrester:
Set bold/italics icons for cs/he/pl; da/no/nn/sv

https://gerrit.wikimedia.org/r/73850
Some templates are only used to include metadata, e.g. categories. In this example http://en.wikipedia.org/w/index.php?title=Ashton_Agar&oldid=564224425&veaction=edit the document starts with two such categories, producing linebreak characters, with templates spanning 0 characters in between (accessible still be cursoring). An uninitiated user may just decide to delete this whole line at the the top, thus removing the hidden templates.

Perhaps we need to detect if a template contains no meaningful content and then move it into the metadata so it can't be accidentally deleted. We'd also need a UI for editing them though.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51420
Additional issue with empty HTML elements produced by templates (which are used for metadata) in bug 52551.
Fixed and will get deployed in a few minutes.
Change 75331 merged by jenkins-bot:
Handle meta-only transclusions as meta items

https://gerrit.wikimedia.org/r/75331
I marked this as a dup of bug 49806, not dup of 51420.
Change 75331 had a related patch set uploaded by Esanders:
Handle meta-only transculsions as meta items

https://gerrit.wikimedia.org/r/75331
This is not the same as bug 51420. This specifically concerns templates which only produce 'metadata' in the VE-data-model meaning of the term.
*** This bug has been marked as a duplicate of bug 49806 ***
Another example given on WP:VEF is {{Link FA}}
To help searching: the cited examples are {{Use dmy dates}} and {{Use Australian English}}.

Increasing importance/priority because they can be deleted unintentionally, and it is very unlikely a new user will know how to add them back before they click save.
**Author:** `wmdv`

**Description:**
I changed the word "you" to "your" by inserting an "r," in [[Gerrit/Tutorial]], but the edit summary said I inserted 10 characters, and the [https://www.mediawiki.org/w/index.php?title=Gerrit/Tutorial&diff=prev&oldid=732497 diff report] showed about 15 lines, with various things shifted around.  I was using Chrom on Windows 8.

I reported this on the support page, and 88.130.86.210‎17:17, July 13, 2013 reverted my edit, and suggested I file a bug report. [https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Extensive_diff_report. Support desk resolution.]

I have also been noticing that when a change comes up on my Wikipedia watch list, I sometimes have difficulty telling what an editor did, because the diff report is full of unmodified content.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Extensive_diff_report%2E
No ability to track this down and no recurrence in over a year; closing.
Very odd corruption; assigning.
Trying to manually encode the dot again... It didn't work even on the URL field.

https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Extensive_diff_report%2E
**wmdv** wrote:

I am unable to enter the correct url, because it ends with a period, which seems to confuse bugzilla.
**wmdv** wrote:

The url for the support desk case is [https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Extensive_diff_report.]
From English Wikipedia, John Broughton (♫♫) 22:40, 12 July 2013 (UTC):

Inserted images are formatted as right-aligned, and they can't be move to the left side of the page. Similarly, existing images that are left-aligned can't be moved to the right side of the page.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 105225 merged by jenkins-bot:
Adding position setting to media edit dialog

https://gerrit.wikimedia.org/r/105225
Change 105225 had a related patch set uploaded by Jforrester:
Adding position setting to media edit dialog

https://gerrit.wikimedia.org/r/105225
It's not a problem with right-to-left languages ;)

Removing the tracking bug.
Permanent diff: 
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564362312#Issues_with_images
I've copied his words verbatim as part of a long string of issues, but if it is helpful for you to see these word in context, it will be here until it archives:
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Templates_not_aligned
Is bug 51295 a duplicate?

(In reply to comment #0)
> From English Wikipedia, John Broughton (♫♫) 22:40, 12 July 2013 (UTC):

An URL is always highly welcome.
From English Wikipedia, John Broughton (♫♫) 22:40, 12 July 2013 (UTC):

VE allows the image to be dropped into the middle of a word. I moved the test image perhaps a dozen times, and this happened twice - that shouldn't be possible, yes? [The words that were split were "addition" and "Israel"; when I moved the image again, the words remained split (with an end-of-line inserted).]

--------------------------
**Version**: unspecified
**Severity**: enhancement
51666 is the more general bug for relocating block items.

*** This bug has been marked as a duplicate of bug 51666 ***
The initial plan is to try bug 65883 and see whether this is a good enough solution.
*** Bug 52657 has been marked as a duplicate of this bug. ***
So what is the way to fix this?
en.wp user Fram comments:
"it should be made impossible that when people move images in VE (which is very easy), they put it (inadvertently) in the middle of a word. Preferably, images should only be movable to spaces between paragraphs, but they certainly shouldn't be movable to the middle of a word. Example: [https://en.wikipedia.org/w/index.php?title=Egypt%E2%80%93United_States_relations&curid=15982815&diff=566841885&oldid=565660404]

The problem seems to be that when you move a picture, the final location is not decided by the upper left corner of the image (which seems more intuitive to me), but by the location of your cursor somewhere in the middle of the picture."
*** Bug 52178 has been marked as a duplicate of this bug. ***
On Google Chrome on Galaxy Note 2

1. open VE
2. 'click' on a link

Results:
The text cursor appears at the character of text selected.
The link editor icon appears below the character of text selected.
The text cursor makes it impossible? to click on the link editor icon.

One solution would be to place the link editor icon above the linked text, and ideally place it always at the end of the linked text instead of at the character where the text cursor.

--------------------------
**Version**: unspecified
**Severity**: normal
The mobile version of VisualEditor doesn't do text over-lays to avoid issues like this bug. Closing as INVALID now that work there is progressing.
Clicking the link icon at the top of the article works, which is a reasonable workaround. Dropping priority.
The link icon moves when the text cursor is moved.

It is possible to zoom in to press the link icon, but it is very fiddly.
tag_summary duplicates data in change_tag, but is missing some records. 

Eg:

select * from change_tag where ct_rev_id = 563615370;
+-----------+-----------+-----------+--------------+-----------+
| ct_rc_id  | ct_log_id | ct_rev_id | ct_tag       | ct_params |
+-----------+-----------+-----------+--------------+-----------+
| 589674173 |      NULL | 563615370 | visualeditor | NULL      |
+-----------+-----------+-----------+--------------+-----------+

select * from tag_summary where ts_rev_id = 563615370;
Empty set (0.01 sec)

Cause unknown at time of writing.

Relevant recent activity:

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#VisualEditor_tag_not_working_correctly

https://bugzilla.wikimedia.org/show_bug.cgi?id=40867

--------------------------
**Version**: unspecified
**Severity**: major
That was bug 52077. Closing this.
Whatever is causing that (maybe just a misconfigured local filter?), it's most likely not related to this bug.
**swalling** wrote:

(In reply to comment #16)
> Much better, but I'm still seeing some issues:
> 
> Looking for 500 "blanking" tags gives 498 "blanking" plus 2 labeled as just
> "mobile edit".
> 
> http://en.wikipedia.org/w/api.
> php?action=query&list=recentchanges&rctag=blanking&rclimit=500&rcprop=user%7C
> comment%7Ctitle%7Ctags%7Ctimestamp

There are other strange things going on with tags... 

http://en.wikipedia.org/wiki/Wikipedia_talk:Tags#Incorrect_tagging

Not sure if it's related or if we should file a separate bug for incorrect tagging. I think mobile is also suffering from this issue (or was as of yesterday).
As a follow up, the two problematic tags I note in Comment 16 are both recent.  It is possible they have a different underlying cause than the previous corruption.  For example, this might represent a logic error in how the "mobile edit" tag is being recorded.
Much better, but I'm still seeing some issues:

Looking for 500 "blanking" tags gives 498 "blanking" plus 2 labeled as just "mobile edit".

http://en.wikipedia.org/w/api.php?action=query&list=recentchanges&rctag=blanking&rclimit=500&rcprop=user%7Ccomment%7Ctitle%7Ctags%7Ctimestamp
(In reply to comment #14)
> Rebuild #2 of tag_summary has completed and the reports in comment 8 look
> better (to me). Anyone care to verify...

Appears to work for me, yes. Might be worth waiting for others to weigh-in, but from my POV this is fixed.
Rebuild #2 of tag_summary has completed and the reports in comment 8 look better (to me). Anyone care to verify...
Btw, change_tag still looks complete to me; the binlog shows no problems there. Should just be the tag_summary rebuild logic at fault.
As Robert suggested in comment 8, the rebuild process missed some rows where revisions had multiple tags.

The script has been fixed and will run in batches on enwiki today. More info shortly...
Am investigating whether the tag_summary rebuild was conceptually flawed with regard to revisions with multiple tags, or not.

Also dumping enwiki binlogs on a slave (we have a month's worth) and pulling out all change_tag queries. Will reload them offline and join against a copy of change_tag to prove whether it is, in fact, completely intact.
Lowering priority a bit since I don't there is data loss here (the table that was used to recreate the data still exists).

James: Assigning to you to determine the priority for getting around to fixing this data (since it affects VE related data, and you know what metrics are being tracked).
(In reply to comment #8)
> A API query of 200 revisions tags as flagged as "blanking":
> While this query returns 200 entries, we find that only 188 of them report as
> actually having the "blanking" tag.

That's still the case today.
Sorry to add to what I'm sure was a bit of a hectic day for someone, but I'm still seeing lingering bits of corruption.  Perhaps some sort of edge case that wasn't handled correctly by the rebuild?  99.9% of tags may be okay at this point, but here are some example that still seem to be errors.

A API query of 200 revisions tags as flagged as "blanking":

http://en.wikipedia.org/w/api.php?action=query&list=recentchanges&rctag=blanking&rclimit=200&rcprop=user%7Ccomment%7Ctitle%7Ctags%7Ctimestamp|ids&rccontinue=2013-07-12T22:20:40Z|589061595

While this query returns 200 entries, we find that only 188 of them report as actually having the "blanking" tag.

The remainder are things like 
  rcid="590123889" timestamp="2013-07-12T14:30:16Z"
  <tag>visualeditor</tag>
  
  rcid="590032703" timestamp="2013-07-12T00:33:31Z" 
  <tag>mobile edit</tag>

Where some other tag is reported but the expected "blanking" tag is not reported.

For another example of this issue see the API query for the "visualeditor-needcheck" tag:

http://en.wikipedia.org/w/api.php?action=query&list=recentchanges&rctag=visualeditor-needcheck&rclimit=200&rcprop=user%7Ccomment%7Ctitle%7Ctags%7Ctimestamp|ids

This tag should only be applied if the "visualeditor" tag is also present, but we observe that most of the results have either "visualeditor" or "visualeditor-needcheck" but not both.  A few entries even have other tags entirely.


What appears to have happened is that rebuild didn't correctly handle cases where a single revision was subject to multiple tags.  Instead it looks as though the rebuilt table applies at most one tag to each of the historical revisions.  Most of the time that's okay since few revisions actually have multiple tags, but it still leaves a bit of corruption and missing data on the rare cases when a revision is expected to have multiple tags.
**swalling** wrote:

Just checked this on-wiki as well. Seems fixed.
enwiki.tag_summary rebuild is complete.
Firstly, we've determined this problem occurred due to an (apparent) bug in pt-online-schema-change when using a combination of:

- A table without primary key
- A table with unique indexes that all include nullable columns
- An unfortunately timed REPLACE statement in normal db traffic

Posc does online table alteration by:

- Creating a copy of the table with altered schema
- Setting triggers on the original table to keep the copy updated
- Copying data across using a batch process

In this case, posc set a DELETE trigger on tag_summary using a poor UNIQUE index (ts_log_id) with low cardinality and a nullable field. Then during the batching process, an external REPLACE statement with ts_log_id=NULL caused many too many rows to be deleted in the temporary table being altered. Given that many rows in tag_summary have ts_log_id=NULL, the table was massively reduced in size.

Now to the fix:

We've checked the other wikis and found no problems; only enwiki was affected.

Furthermore, only enwiki.tag_summary was affected. We've verified that enwiki.change_tag is complete and did not suffer the same problem. This was based on:

- Index cardinality and table size information collected before running the schema migration
- An investigation of the events in the binary log surrounding the migration period

Currently we are rebuilding tag_summary based on change_tag data. That will complete within 30 mins at the time of writing this comment.
(In reply to comment #3)
> Was it determined if any other databases apart from en.wp's one were
> affected?

Not sure. The wikis that potentially may have this issue are:

+       'arwiki' => true,
+       'commonswiki' => true,
+       'cswiki' => true,
+       'dewiki' => true,
+       'elwiki' => true,
+       'enwiki' => true,
+       'enwikisource' => true,
+       'enwiktionary' => true,
+       'eswiki' => true,
+       'etwiki' => true,
+       'fawiki' => true,
+       'fiwiki' => true,
+       'frwiki' => true,
+       'hewiki' => true,
+       'huwiki' => true,
+       'idwiki' => true,
+       'itwiki' => true,
+       'jawiki' => true,
+       'ltwiki' => true,
+       'mrwiki' => true,
+       'nlwiki' => true,
+       'plwiki' => true,
+       'ptwiki' => true,
+       'rowiki' => true,
+       'ruwiki' => true,
+       'simplewiki' => true,
+       'svwiki' => true,
+       'trwiki' => true,
+       'ukwiki' => true,
+       'zhwiki' => true,

cf bug 40867#c6
Was it determined if any other databases apart from en.wp's one were affected?
Sean and Asher narrowed this down to a problem with the schema change tool that we use, and are working on a strategy to fix the data.  This looks like it's strictly a db-related problem that once fixed should stay fixed (assuming we don't try another similar schema migration before an upstream fix is made to the migration tool)
Only seems to affect en.wp right now (works correctly on pl.wp and mw.org, for example).
I'm not entirely sure if this is a VE bug or a user bug, but it shows up under the needscheck tag, so presumably the VE knows something is wrong. We have several instances of categories being stripped from articles, including:

*https://en.wikipedia.org/w/index.php?title=2013%E2%80%9314_Juventus_F.C._season&curid=39905874&diff=563942424&oldid=563942210
*https://en.wikipedia.org/w/index.php?title=A._Dakshinamurthy&curid=16805989&diff=563911982&oldid=563853744
*https://en.wikipedia.org/w/index.php?title=Body_Party&curid=38681444&diff=563891098&oldid=563879499

In the last 12 hours or so.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 73404 merged by jenkins-bot:
Fix annotated element alien metadata inside wrapped paragraph

https://gerrit.wikimedia.org/r/73404
Change 73404 had a related patch set uploaded by Esanders:
Fix annotated element alien metadata inside wrapped paragraph

https://gerrit.wikimedia.org/r/73404
Looks like those pages have unclosed big/small annotations, which are wrapping all the content beneath them, including the categories. This is triggering a previously unseen bug in the converter.
See https://en.wikipedia.org/w/index.php?title=Hungarian_algorithm&curid=2609001&diff=563951525&oldid=561480423 - another instance at https://en.wikipedia.org/w/index.php?title=Shannon_capacity_of_a_graph&curid=39932177&diff=563933550&oldid=563846095

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 49873 ***
Also https://en.wikipedia.org/w/index.php?title=Frobenius_solution_to_the_hypergeometric_equation&curid=16407499&diff=563915886&oldid=561013687
Following on from bug 50415, the old warning/error messages included the most recent & relevant log entry, and a link to view the full log.

That functionality does not exist in the VisualEditor.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50415
Change 119210 merged by jenkins-bot:
Show last protection log entry and link to full protection log on protection notice

https://gerrit.wikimedia.org/r/119210
Change 119210 had a related patch set uploaded by Alex Monk:
Show last protection log entry and link to full protection log on protection notice

https://gerrit.wikimedia.org/r/119210
The source editor transcludes [[MediaWiki:Editpage-head-copy-warn]] above the edit window. But this does not appear anywhere when using the visual editor.

Note this is distinct from [[Mediawiki:Copyrightwarning]] which appears (in a tiny font) in the edit summary tool. The two messages are not the same and do different jobs - the first is a warning that copyrighted content is not acceptable and content must be verifiable, the second is a statement that by saving you release your contributions under cc-by-sa.

--------------------------
**Version**: unspecified
**Severity**: minor
Er. What?

As I've said, VE is an extension. Parsoid is an extension. This page is not /based/ on a MediaWiki namespace page, it is based on a string in the i8on file. To fully deprecate it we'd have to find some way of fully suppressing it or remove it completely from mediawiki. This would impact not only wikis with the VE but also those without.

Moreover, I'm not sure how users receiving less information is, in this case, a problem, because I've never seen any evidence users actually /read/ those notices. I've been patrolling new pages since 2010; if CITE YOUR SOURCES! and the warning not to submit copyrighted content actually worked to inform people, I'd be the first person to hold my hands up and go "this is awesome and we need to keep it". They don't.

I'm (again) closing this as a WONTFIX. If people want to dispute that, I welcome an argument made as to how having this message helps - or how silently removing it from every Wikimedia instance of MediaWiki and dealing with the resulting fallout would be an effective use of our time.
major->minor, so it isnt red anymore.
The problem doesnt go away because itwp deleted the message.

It still exists in enwp, zhwp, viwp & hrwp, of wikis above 100,000+ pages. (fawp has a commented out notice)  Possibly many more with less pages.
These messages informed the user about verifiability as well as licensing issues.

But if this message is truly not going to be displayed in VE, and VE is the way of the future, then the message should be deprecated and deleted from those wikis (with community consensus after explaining to them they have no other option :P), otherwise user's of VE receive less information then those of SE, for good or ill.  (in this case this bug should be moved over the core component)
(In reply to comment #7)
> Resolved-Fixed -> Resolved->Invalid.  What the?!

Not a bug in VisualEditor; itwiki had removed the licence information from the, err, licence information message. Oliver fixed it by editing the message to restore the licence warning. No changes to VisualEditor actually happened.

We are fixing enough bugs without having to artificially inflate the numbers of how much we're doing. :-)
Resolved-Fixed -> Resolved->Invalid.  What the?!
Now resolved; thanks all :).
PS: (it's not just about copyright, in our case) http://www.mediawiki.org/wiki/Thread:VisualEditor/Feedback/Legal_issue:_copyright_and_other_warnings_must_be_visible_above_the_%22save%22_button

Thanks.
On the Italian Wikipedia that does not happen though, please tell me if there is anything I can do to fix this ASAP.

In the past some users at itwp asked if the copyright/warning notices we use (https://it.wikipedia.org/wiki/MediaWiki:Wikimedia-editpage-tos-summary ) under the edit windows could be removed for experienced users, but the option was always discarded on the basis that a more prominent notice than the one in the footer was necessary for "legal" reasons (yes, people don't usually read or understand what it says anyway, but certainly they can't complain they don't get enough notice about this. And we do care a lot about this topic.)
I can see the notice when I try to save on en.wp, although it is so small I almost can't read it with Monobook on Chrome, but it does not show up on it.wiki, and since I don't want patrollers to report additional copyright issues after deployment, I'd ask for advice about this. Thanks.
I'm confused. Because it's part of MediaWiki core, it can't be overridden or suppressed by an extension? A large chunk of the extensions we practically use suppresses elements of core. This would seem to conflict with the practical use and applications of our extensions. Similarly, removing it would be rather unfair to, for example, third-party users, since VisualEditor and Parsoid are both extensions. We do not include them in the standard tarball.

The message is useful, yes, but replicated in a form in the VE. If you've used the VE, you'll know the ToS link and release are given prominent placement, not "tucked away down the bottom of the page". The only occasions on which the ToS /are/ tucked away down the bottom of the page is in namespaces and wikis without VisualEditor/Parsoid....where editpage-head-copy-warn is not suppressed.
This message is part of mediawiki.  If the message is extraneous, it should be removed.  Until that happens, it should be part of the VE.

On English Wikipedia this message includes "Encyclopedic content must be verifiable." and a prominent link to the ToS, which is otherwise tucked away down the bottom of the page.
I would argue that this is somewhat extraneous; I don't think anyone actually reads it. Really it exists primarily so that when someone whines about their content being deleted, we can go "there was a notice". It undoubtedly did serve a purpose on the Good Old Days {{cn}} when our terms of service were written on a napkin - but these days Geoff and the team have produced the rather concise and all-encompassing https://wikimediafoundation.org/wiki/Terms_of_Use, which covers (amongst other things) copyright infringements and redistribution - and is linked to in the interface.

I appreciate it's slightly more obscure than an editnotice, but it's also the approach taken by every other website on the planet: users can't really claim they were ignorant unless we're the only place on the internet they visit.
1. Go to
https://pt.wikipedia.org/wiki/Associação_Médico-Espírita_do_Brasil?oldid=36199569&veaction=edit
2. Click in the box in the top of the page and delete it
3. Click on "Save page" and then "Review your changes"
The editor will add the code
<div class="reflist references-small" style><references /></div>
in the bottom of the page, as in this diff:
https://pt.wikipedia.org/wiki/Associação_Médico-Espírita_do_Brasil?diff=36364362&uselang=en

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51260
I was NOT able to reproduce it following the steps from comment 0 and of comment 3, and also in the case of comment 4. Moreover, I don't remember seeing any new reports on this, so I'm marking this as FIXED (but I don't know which code change fixed the bug).
I can't reproduce this now using a simple test case.  Has it still been happening on pt.wp?
This happened again:
https://pt.wikipedia.org/wiki/Haroldo_Palo_Jr.?diff=36430552
This little devil can be reproduced at
https://pt.wikipedia.org/wiki/User:John_Vandenberg/demo?veaction=edit
(remove the template at the top and click save)

It is a very common case, and VE cant be used safely on pt.wp until this is fixed.

Im guessing this is related to the high priority Cite enhancement bug 51260.
(In reply to comment #1)
> I don't know if this is relevant, but the same code "{{referências}}" expands
> to something different on [[pt:special:ExpandTemplates]]:
> 
> <h2 style="cursor:help" title="Esta seção não é editável por razões técnicas.
> Edite a página toda em vez disso.">Referências</h2>
> <div class="reflist references-small" style=""><references
> group=""></references></div>
> 
> 
> Direct link:
> https://pt.wikipedia.org/w/index.php?title=Especial:
> Expandir_predefini%C3%A7%C3%B5es&input=%7B%7Brefer%C3%AAncias%7D%7D&contextti
> tle=Associa%C3%A7%C3%A3o+M%C3%A9dico-
> Esp%C3%ADrita+do+Brasil&removecomments=true&removenowiki=true

That's pretty much the same as the expansion that leaks into the article, except for the first tag (the <h2>).
I don't know if this is relevant, but the same code "{{referências}}" expands to something different on [[pt:special:ExpandTemplates]]:

<h2 style="cursor:help" title="Esta seção não é editável por razões técnicas. Edite a página toda em vez disso.">Referências</h2>
<div class="reflist references-small" style=""><references group=""></references></div>


Direct link:
https://pt.wikipedia.org/w/index.php?title=Especial:Expandir_predefini%C3%A7%C3%B5es&input=%7B%7Brefer%C3%AAncias%7D%7D&contexttitle=Associa%C3%A7%C3%A3o+M%C3%A9dico-Esp%C3%ADrita+do+Brasil&removecomments=true&removenowiki=true
From English Wikipedia:

In the template dialog, in the add parameter view, I would expect double-clicking on a parameter would add it, instead of having to find the add parameter button at the end of the list (which should, by the way, not be at the end of a scrolling 

list, but always visible in a fixed place). --WS (talk) 12:17, 9 July 2013 (UTC)
Agree with this - it took me a while to figure out that I had to scroll to the bottom of a long list of reference parameters to find the button. GoingBatty (talk) 04:58, 10 July 2013 (UTC)

--------------------------
**Version**: unspecified
**Severity**: enhancement
*** Bug 51165 has been marked as a duplicate of this bug. ***
This is now done (as a single-click-to-insert), and will be deployed in the next few minutes.
Change 73865 merged by jenkins-bot:
Single-click insertion

https://gerrit.wikimedia.org/r/73865
Change 73865 had a related patch set uploaded by Trevor Parscal:
Single-click insertion

https://gerrit.wikimedia.org/r/73865
Seems to happen specifically in https://en.wikipedia.org/wiki/Jabhala?veaction=edit for no apparent reason; try it.

--------------------------
**Version**: unspecified
**Severity**: normal
*** Bug 51112 has been marked as a duplicate of this bug. ***
Fixed and merged.
Change 73874 merged by jenkins-bot:
Replace text strings with grapheme arrays in onContentChange

https://gerrit.wikimedia.org/r/73874
Change 73874 had a related patch set uploaded by Esanders:
Replace text strings with grapheme arrays in onContentChange

https://gerrit.wikimedia.org/r/73874
**weskaggs** wrote:

Further observations:  the "pawn" has utf-8 hex code E2 99 99.  The multibyte characters that provoke this behavior are either of:

devangiri letter LA, unicode 0x2354, utf-8 hex E0 A4 B2
devangiri letter BHA, unicode 0x2349, utf-8 hex E0 A4 AD
Turns out that it happens when inserting any character after the link, but only at the position immediately after the link (so the second character isn't pawned because there's something (the first pawn) between it and the link), and only if there is multibyte text in the same paragraph preceding the link.

The article's first and only paragraph starts with "Jabhala (Hindi:जभाला) is..." and so this bug affects every link on that article. But it doesn't affect any links before जभाला (there aren't any right now but you can create them), and if you use Enter to break the paragraph after the Hindi text, it doesn't affect any links in the second paragraph either.

Assigning to Ed because this is a multibyte issue.
**weskaggs** wrote:

In case it may be helpful, the character produced is a white chess pawn, unicode 0x2659 (html &#9817).  This character is produced if any character is added immediately after any of the three links in the first sentence, but not if a character is added after a link in the second sentence.  If the Hindi text in the first sentence is deleted, then characters entered after a link produce the correct result.
An English Wikipedia editor suggests that the "remove template" button should be in a section labeled "actions", not options. A non-native speaker, he does not find the "options" label intuitive.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51672
This has now been moved from the "options" section to a small rubbish bin icon next to each template's name, and duplicated in the control section in the left navigation bar.
We don't like the "Options" label either (it's a standard part of dialog panes in VE, but here it doesn't add anything).
**Author:** `p.selitskas`

**Description:**
Page where issue occures: https://be-x-old.wikipedia.org/wiki/%D0%93%D1%80%D1%8D%D0%B3%D0%B0%D1%80%D1%8B%D1%8F%D0%BD%D1%81%D0%BA%D1%96_%D0%BA%D0%B0%D0%BB%D1%8F%D0%BD%D0%B4%D0%B0%D1%80

When I change the first character of the link text by selecting it first and then typing, chess symbol ♙ replaces the original character. Due to bug 50678 not being resolved yet, I tried this way and revealed such behaviour. For the point, it's no matter how many characters are selected, chess symbol arrives if the first character in the link text is included in the selection.

It seems to take place in the lead part of the article only. When I change links in the tables and other sections of the page, it all looks fine.

Worth noticing: after I enter the editing mode and change the link in the first table header (text: Апошні дзень Юліянскага календару), it works like a charm, but as I press Ctrl+Z, it turns to «Апошні дзень ♙ліянскага календару», and I have to press Ctrl+Z once again to fix it back to the original state.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 51140 ***
Create a link and hit return before the input field in the link inspector is focused and the text in the surface will be replaced with a new line.  Not linked text.

--------------------------
**Version**: unspecified
**Severity**: normal
This code has been fixed and we'll get it deployed tomorrow.
Change 72852 merged by jenkins-bot:
Lock surface while inspectors are animating open

https://gerrit.wikimedia.org/r/72852
Change 72849 merged by jenkins-bot:
Be sure lookupMenu input is focused before showing

https://gerrit.wikimedia.org/r/72849
Change 72849 had a related patch set uploaded by Jforrester:
Be sure lookupMenu input is focused before showing.

https://gerrit.wikimedia.org/r/72849
Change 72852 had a related patch set uploaded by Robmoen:
Decrease the time it takes to focus the input element.

https://gerrit.wikimedia.org/r/72852
If an image is formatted as [[File:foo.jpg|thumb]] rather than |BARpx, image resizing does not work.

--------------------------
**Version**: unspecified
**Severity**: major
*** This bug has been marked as a duplicate of bug 50645 ***
Attaching screenshot...

--------------------------
**Version**: unspecified
**Severity**: normal
Change 109491 merged by jenkins-bot:
Fix toolbar margins in vector

https://gerrit.wikimedia.org/r/109491
Change 109491 had a related patch set uploaded by Esanders:
Fix toolbar margins in vector

https://gerrit.wikimedia.org/r/109491
*** Bug 52205 has been marked as a duplicate of this bug. ***
Same as bug 52205?
Steps to reproduce:
1. Reduce the screen width until the toolbar wraps. You should now see something like attachment 12793
2. Reduce the screen width even more until the screen is too narrow for the HD stylesheet. The skin elements will animate and you'll end up with something that looks like attachment 12794.
Created attachment 12794
<h1> protrudes into wrapped toolbar in non-HD stylesheet

**Attached**: {F11631}
Created attachment 12793
Wrapping toolbar correctly pushes down <h1> in HD stylesheet

**Attached**: {F11630}
Not sure if this is TemplateData or VisualEditor, please move it if I’m wrong.

If I edit a page where a redirection to a template is used, I don’t see the available parameters and other data that TemplateData provides, but the redirection works like the real template, so it should use the same data.

--------------------------
**Version**: unspecified
**Severity**: normal
Per report. ;-)
Confirmed fixed in 1.24wmf7, yay :-)
Change 135065 merged by jenkins-bot:
Follow redirects when looking up template data

https://gerrit.wikimedia.org/r/135065
Change 135064 merged by jenkins-bot:
Allow following of redirects via API

https://gerrit.wikimedia.org/r/135064
Change 135065 had a related patch set uploaded by Alex Monk:
Follow redirects when looking up template data

https://gerrit.wikimedia.org/r/135065
Change 135064 had a related patch set uploaded by Alex Monk:
Allow following of redirects via API

https://gerrit.wikimedia.org/r/135064
(In reply to Krinkle from comment #3)
> Both VE and TemplateData should address this in their own way. Both parties
> need to do something.
> 
> 1) Resolve redirects in API interaction:
>   - TemplateData should have an option to resolve redirects in the given
> titles (like action=query). the mapping will be added similarly to how we
> normalise titles.

This is a built-in feature in ApiPageSet, which is used by ApiQuery modules, as well as by ApiTemplateData. When enabled, passing &redirects to the request resolves redirects.
This is still a major usability issue with templatedata as template redirects are quite common. Any update?
We have been talking about returning more metadata like the list of used templates from the PHP preprocessor, and use that for dependency tracking. Even with that info I'm not convinced that we should attempt to directly skip redirects in Parsoid, as that would add a lot of complexity and unexpected behavior.

It should not be that hard to handle this in TemplateData itself, and to me it looks like the best place to do it.
This is a little tricky on the Parsoid end since Parsoid gets the PHP preprocessor to expand template source for us (which we then parse and process). So, Parsoid never sees the redirect that are embedded in templates (like {{cn}}). So, this will require us to instrument the PHP preprocessor to provide Parsoid with this information. Offhand, I cannot think of any efficient trick that will solve this.

So, I think approach (1) above where TemplateData adds redirection info and VE uses that might work for the common case where the redirect target is not a function of template args.
Should a new bug for the Parsoid part be filed, so that the Parsoid team to do their part of this? This is a very big issues as some of the most common templates like the iconic {{cn}} are redirect and was asked about again at 
http://en.wikipedia.org/w/index.php?title=Wikipedia%3AVisualEditor%2FFeedback&diff=575686867&oldid=575662727
Both VE and TemplateData should address this in their own way. Both parties need to do something.

1) Resolve redirects in API interaction:
  - TemplateData should have an option to resolve redirects in the given titles (like action=query). the mapping will be added similarly to how we normalise titles.
  - Then the VisualEditor needs to use this map as the API response will put the templatedata for the target title, not the title queried. We do this already with normalised titles, so we can extend that to include redirects in that "aliasing" logic for normalised titles.

2) Parsoid giving TemplateData the transcluded page name instead of the wikitext invocation.
  - Right now we sometimes get wikitext instead of a page name, or (in case of redirects) the sourced page name, not the one actually transcluded.
  - If/when Parsoid is able to know what the wikitext expands too etc. (not a blind call to the PHP parser as it is essentially now) this will make that a lot easier and also solve generated transclusion target page names (e.g. {{ {{foo}} }} ).
Note from bug 51791 fwiw: this issue is being discussed at
http://en.wikipedia.org/wiki/Wikipedia_talk:VisualEditor/TemplateData#What_about_redirected_templates
*** Bug 51791 has been marked as a duplicate of this bug. ***
To reproduce:

* Edit a page with some existing content in VisualEditor.
* Press Ctrl-A to select the whole text.
* Press the Delete key.

Observed: The page cannot be edited any more.

Expected: The page doesn't have any text, but text can be added.

--------------------------
**Version**: unspecified
**Severity**: major
Change 86299 merged by jenkins-bot:
ce.BranchNode: Insert slugs based on CE children length, not DM

https://gerrit.wikimedia.org/r/86299
This bug has been fixed somewhere in the past week. The range is no longer (0,0) but (0,[document length]). The document no longer crashes and properly deletes all content.

However this uncovered another bug, namely that in Firefox deleting the selection now leaves the document completely empty (not even a placeholder <p> to start typing again). That is what change 86299 (https://gerrit.wikimedia.org/r/86299) addresses.

However this bug is fixed, though I don't know which commit fixed it.
Change 86299 had a related patch set uploaded by Krinkle:
ce.BranchNode: Insert slugs based on CE children length, not DM

https://gerrit.wikimedia.org/r/86299
When the document loads in Firefox (Firefox 24, Mac) ve.ce.Document#getNodeAndOffset gets called with offset=1 to show initial selection (range: 1,1).

When selecting all and pressing backspace, ve.ce.Document#getNodeAndOffset gets called with offset = -1.

It gets there from ve.ce.Surface#handleDelete, which has a rangeToRemove (from this.model.getSelection) of 0,0.

The #handleDelete method then sees the range is collapsed, and since backspace=true, it will get a relative range on the document from the (collapsed) 0,0 rangeToRemove to -1.
This is still happening with Firefox 24 on Linux using the monobook skin (other combinations not tested)
**JohnCD67** wrote:

Occurs with Vector/Win7/FF23.0. It doesn't matter whether Ctr-A or Right-click/Select all is used, or whether "Delete" or "Backspace" is used to delete.
*** Bug 52125 has been marked as a duplicate of this bug. ***
Looking into it now.
Example from Bug 51169, which also has a screenshot.

https://en.wikipedia.org/w/index.php?title=List_of_American_Dad!_characters&curid=2082680&diff=564675517&oldid=564302759
*** Bug 51169 has been marked as a duplicate of this bug. ***
*** Bug 50519 has been marked as a duplicate of this bug. ***
Yes.

In RL debug mode I got this:

--
[11:13:55.789] TypeError: node.getParent(...) is null @ https://bits.wikimedia.org/static-1.22wmf8/extensions/VisualEditor/modules/ve/ce/ve.ce.Surface.js:1265

It only happens in Firefox.
Do any JS errors appear in the console while you do this?
From a conversation with an English Wikipedia editor user Thryduulf, he says that when it comes to editing existing links (as opposed to adding new one): 
***
there are three things you could want to do:

(1) change the link without changing the text (e.g. [[Mercury]] → [[Mercury (planet)|Mercury]])
(2) change the text without changing the link (e.g. [[Mercury (element)]] → [[Mercury (element)|Mercury]])
(3) change both (e.g. [[Mercury]] → [[Freddie Mercury]])

At present it seems that the visual editor always assumes you want to do 1, and unless you delete the link completely there is no way of doing otherwise..., but for beginners I'd say that 3 should be the default. There needs to be some way to set the target of a link independently of what is displayed, and I'm not sure how best to do that but maybe an option on the link dialog called "display as" or something like that would be the way to go.

***

(Please see http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=563383564#Changing_link_text_often_results_in_bad_code.2C_wrong_links_and_unmatched_.3C.2Fnowki.3Es

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52240
https://bugzilla.wikimedia.org/show_bug.cgi?id=50678
https://bugzilla.wikimedia.org/show_bug.cgi?id=33091
https://bugzilla.wikimedia.org/show_bug.cgi?id=50452
https://bugzilla.wikimedia.org/show_bug.cgi?id=53973
(In reply to Krinkle from comment #8)
> (removed a couple duplicate see-alsos)
> 
> Unless I misunderstood the bug, we haven't really made any progress on this
> since last year.

Yes, you have mis-understood comment 7:

(In reply to James Forrester from comment #7)
> (In reply to Elitre from comment #6)
> > What Chris described at comment#3 is still happening:
> > https://fr.wikipedia.org/w/index.
> > php?title=St%C3%A9phane_Bern&diff=100014868&oldid=98819232 .
> 
> That's now in bug 62819, which we believe we have just fixed this week (to
> go out on Thursday). Closing this. The suggestion that there be two edit
> fields in the link inspector (one for anchor, the other for target) is
> tracked in bug 53973.

The remaining parts of this bug that aren't fixed are a duplicate of bug 53973.
(removed a couple duplicate see-alsos)

Unless I misunderstood the bug, we haven't really made any progress on this since last year.

(In reply to Maggie Dennis from comment #0)
> there are three things you could want to do:
> 
> (1) change the link without changing the text (e.g. [[Mercury]] → [[Mercury
> (planet)|Mercury]])
> (2) change the text without changing the link (e.g. [[Mercury (element)]] →
> [[Mercury (element)|Mercury]])
> (3) change both (e.g. [[Mercury]] → [[Freddie Mercury]])
> 
> At present it seems that the visual editor always assumes you want to do 1,
> and unless you delete the link completely there is no way of doing
> otherwise..., but for beginners I'd say that 3 should be the default. There
> needs to be some way to set the target of a link independently of what is
> displayed, and I'm not sure how best to do that but maybe an option on the
> link dialog called "display as" or something like that would be the way to
> go.

#2 and #3 are still not possible without deleting everything and re-creating a link. The only other way is to basically type the new label somewhere within the existing label, and then strip away the old characters. That's not something any user can be expected to do.

E.g. to change label from "Foo" to "Bar" of external link http://example.org:

1. Type "Bar" inside "Foo"
   - Foo
   + FoBaro
2. Manually remove "Fo" and "o"

The main things lacking for this bug is a way to change the link label.

Or in other words, to select the contents of the label without its boundaries. Right now selecting "Foo" and typing over it removes the link...

Bug 37939 is also related (would make it easier to select it), but is not required.

Right now users would probably be forced into removing it and re-creating it, which hits bug 67086 / bug 67088.
(In reply to Elitre from comment #6)
> What Chris described at comment#3 is still happening:
> https://fr.wikipedia.org/w/index.
> php?title=St%C3%A9phane_Bern&diff=100014868&oldid=98819232 .

That's now in bug 62819, which we believe we have just fixed this week (to go out on Thursday). Closing this. The suggestion that there be two edit fields in the link inspector (one for anchor, the other for target) is tracked in bug 53973.
What Chris described at comment#3 is still happening:
https://fr.wikipedia.org/w/index.php?title=St%C3%A9phane_Bern&diff=100014868&oldid=98819232 .
This is no longer true, since late July when editing of link anchors was made "spanning"; closing.
This is causing content corruption on the live wiki.

A user apparently trying to change a link from [[Blackpool Grand Theatre]] to [[Grand Theatre, Blackpool]] over two edits failed to do this:

1. "[[Blackpool Grand Theatre]] and" → "[[Blackpool Grand Theatre|Blackpool Grand Theatre]] and"
2. "[[Blackpool Grand Theatre|Blackpool Grand Theatre]]" → "G[[Blackpool Grand theater|rand Theater, Blackpool, ]]<nowiki/>and"

https://en.wikipedia.org/w/index.php?title=Bernie_Nolan&diff=prev&oldid=564655203
https://en.wikipedia.org/w/index.php?title=Bernie_Nolan&diff=next&oldid=564655203

This should not be marked as an enhancement, changing links without mangling the text should be a core requirement of VE.
It should be. However my testing showed that this was not reliable and sometimes resulted in odd wikicode, e.g. [[Ecuador|<nowiki/>]][[Egypt|E]][[Egypt|gypt]] when changing "Ecudor" to "Egypt".

See https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox&diff=563097916&oldid=563090562
"and unless you delete the link completely there is no way of doing otherwise...,"

Isnt (2) and (3) possible by editing the text of the wikilink in the normal editor (i.e. not the link dialog), after selecting the link target?

I must admit I was dumbfounded for a few minutes when trying to do (2), until it occurred to me that I can edit the text in the page.

(3) is a bit harder, as the user must change the target from 'Mercury' to 'Freddie Mercury', then change the text to 'MFreddie Mercury', then remove the leading 'M'.
I'm guessing it would be possible for the display as thing to also have suggestions, e.g. in most cases on en.wp if a title has parentheses then you don't want to display what is in them as it is disambiguation. For example if you chose the link [[Mercury (planet)]] the software could say "Do you want to display this as "Mercury"?
Typing certain tag based code into VE such as:

<math>1+2=3</math>
<ref>Hi</ref>

Bug reported by [[User:Dragons flight|Dragons flight]] at https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Some_tags_are_not_properly_escaped

Confirmed.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 72536 merged by jenkins-bot:
(Bug 50944) Fix stale regexp in wikitext escaping for ext tags

https://gerrit.wikimedia.org/r/72536
Change 72536 had a related patch set uploaded by Subramanya Sastry:
(Bug 50944) Fix stale regexp in wikitext escaping for ext tags

https://gerrit.wikimedia.org/r/72536
Copied from English Wikipedia, where it was added by TeamGale:
"when I add the reference/template, if I want to edit it again it's not easy to choose it since the "blue line" that has to be on the text appears completely elsewhere and I can't click it. I took a screenshot"

See:
http://en.wikipedia.org/wiki/File:Misplaced_edit_for_a_template.jpg

--------------------------
**Version**: unspecified
**Severity**: major
I believe that this has now been fixed given the changes to how the CSS is cached.
As noted in the duplicate bug 50991, this issue is somewhat elusive but definitely occurring for some users. Given the impact when it does, increasing severity and importance.
*** Bug 50991 has been marked as a duplicate of this bug. ***
Replication steps:

1. go here: https://he.wikipedia.org/wiki/%D7%A8%D7%97%D7%95%D7%91_%D7%99%D7%A8%D7%95%D7%A9%D7%9C%D7%99%D7%9D?veaction=edit

2. Click the box on the left (a 'street' template in the hebrew wiki)

3. The "Transclusion" icon appears on the right edge instead of the left. 

Happens in Chrome and Firefox 22.0 under Windows.

I suspect this is again a problem with the flipped position settings. I will take a look in the code.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 79165 merged by jenkins-bot:
Fixing inspector popup position

https://gerrit.wikimedia.org/r/79165
*** Bug 53161 has been marked as a duplicate of this bug. ***
I posted a fix which seems to work but requires some testing and review. Also testing in RTL seems to work.
Change 79165 had a related patch set uploaded by Mooeypoo:
Fixing inspector popup position

https://gerrit.wikimedia.org/r/79165
(In reply to comment #2)
> This may be an issue with the way the icon appears in general, not just
> specifically RTL. It seems the transclusion icon pops up on the side of the
> page, assuming the position is always on the side -- instead of, perhaps,
> appearing where the template box is located regardless of alignment.
> 
> I am not sure if this fix shouldn't be a deeper VE fix rather than the
> language-directionality specific fix.

Yes, I think a deeper fix might be appropriate - would you want to do that, or should I ask Rob?
This may be an issue with the way the icon appears in general, not just specifically RTL. It seems the transclusion icon pops up on the side of the page, assuming the position is always on the side -- instead of, perhaps, appearing where the template box is located regardless of alignment.

I am not sure if this fix shouldn't be a deeper VE fix rather than the language-directionality specific fix.
confirmed on Arch linux with FF 22.
The character counter of the save dialog should have a tooltip/title explaining what the counter refers entails.

--------------------------
**Version**: unspecified
**Severity**: trivial
Change 112318 had a related patch set uploaded by Alex Monk:
Explain what the number on the edit summary screen means

https://gerrit.wikimedia.org/r/112318
screenshot of the dialogue

I added TemplateData to Template:X1 (this is a sandbox)
Then, I go to my personal sandbox User:Waihorace/sandbox/VE to try adding Template X1 to that page.
I pressed the button that allow me to add template (don't know its exact English wording)
It prompt me to enter a template name, so I typed in X1
Then, it comes out that the description is not shown, parma names are not shown, but the list of parma is given for me to choose.

Why the description and the name and description of the parma is not shown, while https://zh.wikipedia.org/w/api.php?action=templatedata&titles=Template:X1&format=jsonfm works?

( X1 is a template which will be cleared by a bot automatically. To reproduce, check if the content is still there or otherwise revent back to oldid=27156695 )

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

**Attached**: {F11387}
Change 92826 merged by jenkins-bot:
dm.MWTemplateSpecModel: Resolve translations through the TemplateData API

https://gerrit.wikimedia.org/r/92826
Change 92826 had a related patch set uploaded by Krinkle:
dm.MWTemplateSpecModel: Resolve translations through the TemplateData API

https://gerrit.wikimedia.org/r/92826
(In reply to comment #1)
> Created attachment 12774 [details]
> API response
> 
> To make it easier, after I restored your edit at
> https://zh.wikipedia.org/w/index.php?diff=27157124
> the content of
> https://zh.wikipedia.org/w/api.php?action=templatedata&titles=Template:
> X1&format=jsonfm
> was like in the attached file.
> 
> What was your user language preference when you tested this?
> 
> Does the problem happens on both of the following URLs?
> https://zh.wikipedia.org/wiki/User:Waihorace/sandbox/
> VE?veaction=edit&uselang=zh
> https://zh.wikipedia.org/wiki/User:Waihorace/sandbox/
> VE?veaction=edit&uselang=en
> 
> For me the bug only happens in the second one, and I think this is the same
> as
> bug 50431.

The bug only happens in the second one. 
I think the problem that I reported comes out because of the language conversion of Chinese Wikipedia. 

The TemplateData only works on zh, but not any variant of Chinese (e.g. zh-hans, zh-hant, zh-tw, zh-cn, zh-hk, zh-sg, zh-mo). Should the data in zh be applied in those 7 variants, or otherwise, editors need to set the description for every variants which is time-wasting.

**Attached**: {F11388}
Created attachment 12774
API response

To make it easier, after I restored your edit at
https://zh.wikipedia.org/w/index.php?diff=27157124
the content of
https://zh.wikipedia.org/w/api.php?action=templatedata&titles=Template:X1&format=jsonfm
was like in the attached file.

What was your user language preference when you tested this?

Does the problem happens on both of the following URLs?
https://zh.wikipedia.org/wiki/User:Waihorace/sandbox/VE?veaction=edit&uselang=zh
https://zh.wikipedia.org/wiki/User:Waihorace/sandbox/VE?veaction=edit&uselang=en

For me the bug only happens in the second one, and I think this is the same as bug 50431.

**Attached**: {F11388}
I've noticed a couple of times that users on VE/Feedback have said that they 'couldn't change the block and that it became blue', which I think is an indication they were unable to spot the template edit button.

Now I noticed that the edit button anchor for templates is always at the top right. On 100% width block elements, the content can often be completely left aligned however, and the button is then to the FAR right of the page, making it easy to miss.

For instance, take the {{Refbegin}}-{{refend} block on this page https://en.wikipedia.org/wiki/Warehouse_control_system?veaction=edit on a fairly large monitor.

It might be nice if we could come up with some idea to more intelligently place the button. if( block && !width && computedWidth > 160em && text_align == left) then align button left


Point 2:
Also, the white button on the blue mask on top of the white page is not the highest contrasting style. Styling it stronger might also make it easier to discover for users.

Point 3:
The puzzle piece in that context doesn't give the user much info. Why not a simple Edit logo ? I think that would be way easier to understand.

--------------------------
**Version**: unspecified
**Severity**: normal
Confirmed the fix in production - the templates' contextual menu is displayed either on the far right of the screen or at the middle as for 'Cite web' template.
Sorry for having not responded on this ticket; we fixed this ages ago with the new contextual menu. There are still some issues with the context appearing off-screen if the template is taller than your screen and you're down-page of it, but that is covered by different bugs.
Screenshot of cs.wp Křivá Ves shows the wrong possition of edit button.

I agree. Look at https://cs.wikipedia.org/wiki/Křivá_Ves. If you want to edit the infobox, the key/edit button goes completly to right, where you might not notice it.

**Attached**: {F11331}
I deliberately edited [[Roller coaster]], an article under Pending Changes that had an unreviewed change, using my administrator account, using VisualEditor. When editing source, there would be an edit notice advising of the pending change, which is not present with VisualEditor. Nonetheless, edits by an administrator account are supposed to be automatically accepted.  Instead, my edit was made subject to review. See screenshot at http://commons.wikimedia.org/wiki/File:CoasterCrop.png.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49699
I mis-understood the bug as reported; my apologies. It is in fact entirely a duplicate of bug 49699. Marking as such.

*** This bug has been marked as a duplicate of bug 49699 ***
Isn't this just how FlaggedRevs (this is a different name for the same thing AFAIK) work? Edits by reviewers are only autoflagged if the previous revision was flagged as well.

Unless I'm misunderstanding something, the bug as described by the current summary ("VisualEditor: Edits made by users with +reviewer rights should not get flagged on pages with FlaggedRevs enabled") would be a blocker to deployment on Wikipedia using FlaggedRevs for all articles, like the Polish Wikipedia. However it seemed to behave corrently in my testing there.
Expanding on the above, when editing a PendingChanges article with actively pending changes using source code, admins/reviewers must either accept or revert the outstanding PCs before their own edit is saved. This is not happening under VisualEditor.
1. Put the cursor in the middle of a paragraph
2. Insert an image
3. The inserted image is now selected, and displays an inspector button
4. Click the inspector button
5. You get an empty image dialog and an exception because getFocusableNode() returned null

It seems this happens because the post-insertion selection in step 3 covers something like </p><img></img><p> rather than just the image.

--------------------------
**Version**: unspecified
**Severity**: normal
This is now INVALID because we don't select the node after insertion any more (should we?).
*** Bug 51863 has been marked as a duplicate of this bug. ***
Right now the following HTML entered by a user:

<p>Hello my [[name]] is Julian and I live in the city of Rochester, New York with my friend Sandy; we write [[books]].</p>

… turns into:

<p>Hello my <nowiki>[[name]] is Julian and I live in the city of Rochester, New York with my friend Sandy; we write [[books]].</nowiki></p>

… whereas ideally it should be minimal rather than maximal:

<p>Hello my <nowiki>[[</nowiki>name<nowiki>]]</nowiki> is Julian and I live in the city of Rochester, New York with my friend Sandy; we write <nowiki>[[</nowiki>books<nowiki>]]</nowiki>.</p>

This would significantly reduce issues with users accidentally inputting wikitext.  We're taking actions in VisualEditor-land to discourage such input, but if Parsoid could help it would be hugely useful.

--------------------------
**Version**: unspecified
**Severity**: normal
There are still some scenarios where nowiki wrapping will be applied to a longer string than required.  I haven't tried to optimize it all, and if there are still issues, I can revisit it.
This will likely be deployed later today.
Change 74110 merged by jenkins-bot:
Take #2: (Bug 50841) Reduce scope of nowiki tags

https://gerrit.wikimedia.org/r/74110
Change 74110 had a related patch set uploaded by Subramanya Sastry:
Take #2: (Bug 50841) Reduce scope of nowiki tags

https://gerrit.wikimedia.org/r/74110
Change 72858 merged by jenkins-bot:
(Bug 50841): First pass reducing scope of nowiki tags

https://gerrit.wikimedia.org/r/72858
Change 72858 had a related patch set uploaded by Subramanya Sastry:
(Bug 50841): First pass reducing scope of nowiki tags

https://gerrit.wikimedia.org/r/72858
Possibly interesting nowiki watch list to monitor nowiki application in live edits:
https://en.wikipedia.org/w/index.php?title=Special:AbuseLog&offset=&limit=500&wpSearchFilter=550
(In reply to comment #11)

> Oh I got it. We want to have <nowiki>-{ }-</nowiki> work, so we can't place
> -{
> }- back until all other -{ }- markups have been processed, but this also mean
> other text in nowiki misses the chance to be converted...

I guess -{ and }- in nowiki could be escaped before applying language conversion.
(In reply to comment #10)
> (In reply to comment #8)
> > For us it would be helpful if we could separate those two aspects. If little
> > existing content relies on language conversion being disabled in nowiki, then
> > that might actually be possible.
> 
> There shouldn't be much. It's the case just because in Parser.php,
> 
> $text = $this->mStripState->unstripNoWiki( $text );
> 
> is placed after
> 
> $text = $this->getConverterLanguage()->convert( $text );
> 
> but I'm not 100% sure this is just something accidental (or placed in this
> order delibrately).

Oh I got it. We want to have <nowiki>-{ }-</nowiki> work, so we can't place -{ }- back until all other -{ }- markups have been processed, but this also mean other text in nowiki misses the chance to be converted...
(In reply to comment #8)
> For us it would be helpful if we could separate those two aspects. If little
> existing content relies on language conversion being disabled in nowiki, then
> that might actually be possible.

There shouldn't be much. It's the case just because in Parser.php,

$text = $this->mStripState->unstripNoWiki( $text );

is placed after

$text = $this->getConverterLanguage()->convert( $text );

but I'm not 100% sure this is just something accidental (or placed in this order delibrately).
Gabriel and I discussed the entity solution on IRC, and Gabriel made a good observation that fixing those in 'edit source' will become much harder compared to nowiki tags.  So, entity-based escaping makes fixups harder using the source editor, but makes it easier with VE.  With nowiki, it is the opposite.  But, presumably the noneditability of nowiki sections in VE is temporary.

I'll tackle this with nowikis today by only changing how identified text blocks are escaped without trying to optimize placement itself (Ex:, in reality it is sufficient to only escape "[[" or "]]" in [[Foo]], but that requires more global knowledge which will complicate this).

We'll try to wrap closely occurring wikitext chars in a single nowiki block.  So, "[[foo]]" will be wrapped as <nowiki>[[foo]]</nowiki>.  "Closely occurring" will be heuristic based, say within X chars.
(In reply to comment #6)
> Actually, why not use entities for escaping?  That will eliminate nowikis,
> make
> them editable, and display as text.
> 
> [[Foo]] ==> &#91;&#91;Foo&#93;&#93;
> 
> and the like.  Am I missing something that makes this problematic?

Numeric entities are very hard for users to decipher. While unwanted nowiki tags can simply be removed, fixing up unwanted entity escapes is much more work.

(In reply to comment #7)
> (In reply to comment #5)
> > Re language conversion:
> > How often is nowiki used to suppress language conversion? Could -{ }- or some
> > other syntax be used instead?
> 
> It's more like some side effect...

For us it would be helpful if we could separate those two aspects. If little existing content relies on language conversion being disabled in nowiki, then that might actually be possible.
(In reply to comment #5)
> Re language conversion:
> How often is nowiki used to suppress language conversion? Could -{ }- or some
> other syntax be used instead?

It's more like some side effect...
Actually, why not use entities for escaping?  That will eliminate nowikis, make them editable, and display as text.

[[Foo]] ==> &#91;&#91;Foo&#93;&#93;

and the like.  Am I missing something that makes this problematic?
Maybe we could still use a single wrapper but exclude unsuspicious leading / trailing text from the nowiki block. I agree with Subbu that escaping each run of dangerous characters individually would often result in too much nowiki noise.

Re language conversion:
How often is nowiki used to suppress language conversion? Could -{ }- or some other syntax be used instead?
It should be noted, that at present VE aggressively grabs normal text on either side of the offending elements as well.  For example, using VE to enter:

- I am the very model of a modern [[Major-General]], I've information vegetable, animal, and mineral, I know the kings of England, and I quote the fights historical

Becomes

- <nowiki>I am the very model of a modern [[Major-General]], I've information vegetable, animal, and mineral, I know the kings of England, and I quote the fights historical</nowiki>

Even though the plain text at either end of the wikilink could reasonably be ignored without increasing the number of nowikis.  Since VE can not currently handle nowiki elements, that also means that the entire sentence becomes uneditable in VE after saving.
Actually, another way is to use the existing algorithm to detect contexts that would have been wrapped in <nowiki>..</nowiki> and apply nowiki-escaping to all possible wikitext chars in there (which is safe, but excessive).  This will not complicate the algorithm anymore, but will also introduce more nowiki tags than strictly necessary.
I forgot whether I pointed this out or not: applying <nowiki> on "normal" text disabled language conversion on it too; we may want to <nowiki> wikitext meta characters only.
Let us discuss more on irc monday, but the general problem of escaping minimal contexts can complicate the algorithm.  That said, we could implement some special cases maybe. 

Also, a lot of nowiki-tags (as in this example) looks ugly to me (personally), and could potentially induce greater grumbling among editors.  So, my suggestion is to minimize incidences of nowiki contexts via VE (however you do it) first, and then implement a version of this proposal in Parsoid after that.

Yet another (not fully thought out) alternative is to convert wikitext chars into HTML entities which eliminates nowikis altogether.  We currently use this entity-based solution when we have to escape pipes in url/ext. links in template arg contexts and can just use that more broadly.
see report here:
[[en:Wikipedia:Village_pump_(technical)#Heavy_Javascript_load_after_loading_some_articles.]] (bottom of [[en:WP:VPT]] on July 5 2013. if you don't find it there, look in the archives).

Initial debugging of the issue points to the function injectCSS().
as it turns out, ULS calls injectCSS() once for each required font, which, on some pages (methinks pages with many interwiki links, mainly) can be dozens of times.

apparently, on some browsers injectCSS() can be expensive (maybe the browser re-renders the whole page, in light of the new stylesheet information?) and calling it dozens of times causes high CPU load.

clearly, the right thing to do here is to collect all the different CSS bits and pieces you want to inject, and call injectCSS() exactly once.

this piece of code demonstrate what some people already know: injecting stuff can be habit forming, and can be bad for your health, so you absolutely want to minimize it.


(btw: the function itself is somewhat disgusting. how is it better than

function injectCSS( css ) {
	$( '<style>' , {type: 'text/css', rel: 'stylesheet' } )
	.text( css )
	.appendTo ('head' );
}

// really no need to return anything: the single callsite ignores 
// the return value anyway. anywho, you can prepend "return" 
// to make it behave more like existing code if you really want to...


peace.

--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=563037747#Heavy_Javascript_load_after_loading_some_articles.
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49935
https://bugzilla.wikimedia.org/show_bug.cgi?id=51073
(In reply to comment #21)
> It's resolved technically, 

Closing this one then,

> but we want to write proper documentation and
> tests
> for the fix. Assigning to myself.

and split this to bug 54364, to clarify status.
What's the progress on this, Amir?
It's resolved technically, but we want to write proper documentation and tests for the fix. Assigning to myself.
Why is this still open?
as far as i can see, the patch solved the issue. is there any report about any more problems here? 
is anyone expected to do anything more regarding this issue? 
if it's not closed now, is there any chance of this getting closed ever?

peace.
What about using .eachAsync (https://git.wikimedia.org/blob/mediawiki%2Fcore.git/HEAD/resources%2Fjquery%2Fjquery.async.js) instead of the .each loop over $( '*[lang], [style], [class]' ) ? Perhaps this is not the solution for this bug, but for bug 49935, but I'm not going to read through all those comments, and I think the .eachAsync is worth a try.
*** Bug 51070 has been marked as a duplicate of this bug. ***
The above patch makes the webfonts code about 4x faster in my testing. While it is an improvement, it does not completely remove the problem. To go further we need to reconsider the logic instead of just optimizing the current code.

This patch is already on beta labs, can be tested for example in http://en.wikipedia.beta.wmflabs.org/wiki/Barack_Obama and is planned for deployment around 1800 UTC today.
Change 72967 merged by jenkins-bot:
Update jquery.webfonts from upstream

https://gerrit.wikimedia.org/r/72967
Change 72967 had a related patch set uploaded by Amire80:
Update jquery.webfonts from upstream

https://gerrit.wikimedia.org/r/72967
(In reply to comment #9)
> SpeedyGonsales: This bug report is specifically and only about "Loading a
> page
> which requires many fonts causes high CPU load". If you want to generally
> talk
> about "preferences for new things" or what MediaWiki should be, please do
> that
> on some forum or Village Pump. Thanks for your understanding.

it is unfortunate that "some forum or village pump" where the people responsible for the content of wikimedia deployment are actually listening, does not exist.

there is another bug on bugzilla ( bug 46306 ), requesting/demanding a kill switch for ULS. this bug was closed with "resolved/wontfix".

yet another open bug ( bug 51070 ) is requesting/demanding to disable ULS on enwiki. this one was not closed with "wontfix", but could have been just as well.

so complaining about these demands/requests spilling into other bug reports is somewhat unfair, IMO.

peace.
Just a note that the Language Engineering team responsible for ULS will be holding an office hour later today, at 17:00 UTC on
#wikimedia-office (on Freenode): http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg69718.html
Also reported at pl.wp: https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#Ostrze.C5.BCenie:_Skrypt_nie_odpowiada
Eduard: I can understand frustration, but no need for rhetorical questions, plus "I wasn't heard in the right place, so I tried again in some other, wrong place" is not a good argument.
Tools (like bugtrackers, mailing lists, Gerrit) serve purposes and have dedicated audiences. Bugzilla is a technical bugtracker for bug reports that refer to specific codebases. It's not for meta-level discussions on development policies, plus from experience in other open source projects I can assure you that the more comments unrelated to a bug there are in bug reports, the more devs will (understandably) also start ignoring bugmail and bug reports. I assume that's not wanted by anybody, and that's why I explained how to avoid that.
Since one is ignored "on some forum or Village Pump" (*) one tries other ways to voice one's opinion. Is it surprising that people then try it on Bugzilla where one has at least slight chances a dev will peek at one's message an comment on them?

* e.g. http://www.mediawiki.org/wiki/Thread:Talk:Universal_Language_Selector/Disabling_ULS or http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#.22Opt_out.22_of_VE_needed_under_preferences
(In reply to comment #8)

SpeedyGonsales: This bug report is specifically and only about "Loading a page which requires many fonts causes high CPU load". If you want to generally talk about "preferences for new things" or what MediaWiki should be, please do that on some forum or Village Pump. Thanks for your understanding.
If you ask me having "disable switch" ("kill switch") in user preferences is a
must for almost any new things in MediaWiki UI.

If we are unable to alter closed OS (e.g. Windows or Mac) but are able to alter 
open source one (Linux), MediaWiki should be smart and offer "disable switches" 
for new things. ULS is a good idea, but the same way I like to have "kill 
switch" for VisualEditor :) ("Remove VisualEditor from the user interface" in Gadgets), I agree there should be one for ULS, period.
(In reply to comment #5)
> ULS contains quite a lot of new JavaScript and CSS code, so it is reasonable
> to
> expect that a close scrutiny of the code will reveal some measure of
> duplicate
> work and various other performance problems. It's good that you've dug into
> the
> code and pinpointed some specific problems, but please be less adversarial.
> Measuring and optimizing client-side performance is hard enough to do when
> you
> aren't under attack; calling a developer's code "asinine" or "disgusting" is
> not likely to make it any easier.

you are correct that my style is/was a bit abrasive, and for this i apologize. however, the ULS team demonstrated pretty bad behavior of its own: please review the way Siebard responded on bug 49935 .
in addition, turning it on on many wikis before cleaning the very serious performance issues (and causing browsers to freeze _is_ very serious issue), and then arguing that this thing should not have a disable switch in user preference is just wrong.

peace.
i think you missed the main point: when we call "load" with a font family such that this.getCSS() returns false (e.g. "sans-serif" on my browser), we do not cache the result. calling getCSS() is orders of magnitude more expensive than the search, regardless of whether the search is done the right way (through hash) or the wrong way (through $.inArray).

as to profiling: the real test is to have ~20 entries in the font table (like in [[en:Japan]]), and then measure how long does it take to look for a font _which is not in the list_, which is what happens today, thanks to the problem mentioned above. you'll see that the search takes significantly longer than it should.

still, the main problem is not the inefficient search, but rather calling getCSS thousands (or tens of thousands - depends on the page content) of times instead of once per each font family present on the page.

as to why we call "load" so many times: easy. set a breakpoint, and follow the call stack upward until you'll find the call that's inside an .each() loop.


peace.
I've requested ULS be disabled, this has taken too long, it's annoying ppl without reason.

https://bugzilla.wikimedia.org/show_bug.cgi?id=51070
Why was this set back to UNCONFIRMED?  Lots of people have experienced this, and kipod has even identified the fix.
P.S: i used "abnormal" to signify that getCSS() returnd false, when called with this font family and variant "normal". i do not think this is a good name - maybe "empty" of "builtin" or something similar will be better, as long as one can be confident it's not a valid fontFamily name. it has to eveluate as boolean true, though, so you can;t use false or empty string.

alternatively, false can work, as long as you modify the first line to

if ( this.fonts.hasOwnProperty( fontFamily ) )

so the thing becomes

load: function( fontFamily ) {
    if ( this.fonts.hasOwnProperty( fontFamily ) )
        return this.fonts[fontFamily];
    var styleString = this.getCSS( fontFamily, 'normal' );
    if ( styleString ) {
        injectCSS( styleString );
        return this.fonts[fontFamily] = true;
    }
    return this.fonts[fontFamily] = false;
}

(for brevity, assign and return on one line - don't do it in real life).

peace.
the function "load" is also asinine, and can cause a high load:

it has two problems: one of them is using $.inArray() to test whether this fontface was already loaded: this means linear search on the array every single time (that is, for every single html element with either "lang", "style" or "class" attributes on the page!), and for pages with large number of elements, this can be significant. whats more, there is no reason not to add the font family to the list even when it's not found, to save us some work with future elements with same font family.

even worse, when getCSS() returns "false" (which it does for 99% of the elemnts, e.g. when fontFamily is sans-serif), we don't mark this font family as "tested", so when we find the next element with sans-serif, we do all this work again.

from performance POV, this is atrocious.


here is a better version of load() - 100% untested.

load: function( fontFamily ) {
	if ( this.fonts[fontFamily] ) 
		return this.fonts[fontFamily] != "abnormal"; 
// does the font have "normal" face?

	var styleString = this.getCSS( fontFamily, 'normal' );
	if ( styleString ) {
		injectCSS( styleString );
		this.fonts[fontFamily] = true;
		return true;
	}
	// Font does not have "normal" face.
	this.fonts[fontFamily] = "abnormal";
	return false;
}


note that "this.fonts" here is an object rather than an array (to save the linear searches), so it should be initialized to  {} rather than [].

peace.
If a user hits the spam blacklist they VE responds merely by informing them "Error: Invalid error code". This is...not helpful.

--------------------------
**Version**: unspecified
**Severity**: major
Fixed and will be going out in a few minutes.
Change 73964 merged by jenkins-bot:
mw.ViewPageTarget: Add support for spam blacklist

https://gerrit.wikimedia.org/r/73964
Though I knew that the SpamBlacklist has logic in place for returning multiple urls (bug 30332, Ia951d5795c5cedb) it didn't seem to work.

Apparently it does work now. I can't consistently reproduce it only giving one. I'll presume it was an error on my part or an edge case in the regex SpamBlacklist is using and complex wikitext as input.

I've amended the patch set to display multiple urls separated by comma if there is more than one.
Change 73964 had a related patch set uploaded by Krinkle:
mw.ViewPageTarget: Add support for spam blacklist

https://gerrit.wikimedia.org/r/73964
So we get the matched url from the API. Ideally we'd get a usable message as well.

Given the following sample (and latest mediawiki/core and SpamBlacklist configured with [[m:Spam_blacklist]])


* [http://cl.ly/foo/?bar=%22%3Equ%3Cb%3Eu%3C%2Fb%3Ex%3Ca%20href%3D%22 d]
* [http://fidosoft.de fidosoft]

index.php?action=submit gives the following:

> The text you wanted to save was blocked by the spam filter. This is probably caused by a link to a blacklisted external site.
> The following text is what triggered our spam filter: http://fidosoft.de and http://cl.ly

These are constructed in EditPage::spamPageWithContent by the "spamprotectiontext" and "spamprotectionmatch" messages respectively, which are actually in mediawiki core. The latter message takes $1 as parameter and EditPage.php sets that to the result of Language::listToText( Array ).

The API gives:

        "edit": {
            "spamblacklist": "http://cl.ly",
            "result": "Failure"
        }

For some reason it isn't getting the second url? The SpamBlacklist API hook looks like it is doing `implode( '|', Array )` but aside from an array being nicer than a pipe-separated list, we're not getting either. Only the first url is returned.

So either:

1) SpamBlacklist needs to provide a processed message

or:

* SpamBlacklist needs to provide both urls, not just the first (I tested latest master, SpamBlacklist@3390081e4c6). Though this bug should be fixed either way, if we don't get a processed message, needing both is a blocker.
* We'll load these 2 core messages as part of ve.init.mw.ViewPageTarget
* We'll need an equivalent of Language::listToText in core mediawiki.language.js (though I suppose join(', ')  could do meanwhile).
**joedecker** wrote:

Sounds like y'all have screen shots, but for those of us playing the home game, when I press "Save Page" on a blacklist-blocked edit, that window (with the edit summary, etc.) stays up, and "Error: Unknown error" appears below the edit summary box, to the left of and slightly higher than the Review your edits/Save page buttons--the latter inactive.

MacOSX/Chrome 28.0.1500.71, tested with an examiner.com URL at [[Chad Griffin]] with an incognito window/logged out.
Created attachment 12821
Developer console dump

A very helpful user in #wikipedia-en-help gave me this screenshot of what we get back from the API when TitleBlacklist rejects an edit.

**Attached**: {F11276}
*** Bug 51139 has been marked as a duplicate of this bug. ***
Quote: Using Firefox 19.0.2 on Windows Vista, editing Relativity Media. Find "subsidairies", right-click, select "subsidiaries". The word appears changed, but the "Save" button is not activated.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63462
https://bugzilla.wikimedia.org/show_bug.cgi?id=63395
https://bugzilla.wikimedia.org/show_bug.cgi?id=59748
As far as I can tell, these issues have all been fixed now. However, there's bug 72929 which I've opened for a new issue that's developed in the past few weeks.
I have issues with this locally as well (Iceweasel/Firefox 24.4.0 with VE 3b3a66763ade397b857e35efe8990ac217e5d54c , in debug mode.

In my case, when I try correct the word, it does change in that spot (fixing the misspelling), and the save button enables.  However, the change also appears at the beginning of the document. In this case the required spelling fix was adding an 'r' (occurence. to occurrence), so an 'r' ended up at the beginning of the ContentEditable.

However, in Review Changes (and the actual save), it then drops the original correction, and *only* puts the wrong edit at the beginning.
Tried to duplicate this with FF 28 on a variety of typos on different pages.  Ran into Bug 63395 a lot, but was able to save after using FF autocorrect to alter the typo text. (On a side note, hilariously, FF autocorrect suggests that "autocorrect" should be changed to "autocrat":))
*** Bug 52372 has been marked as a duplicate of this bug. ***
No i don't know, it's a report from the VE/Feedback page.
(Assigning to me absent confirmation that this problem is reproducible.)
(In reply to comment #0)
> Quote: Using Firefox 19.0.2 on Windows Vista, editing Relativity Media. Find
> "subsidairies", right-click, select "subsidiaries". The word appears changed,
> but the "Save" button is not activated.

Odd. I get the save dialog activated on making a spelling-correction changes in both Chrome and Firefox, including on that particular word in that particular page. Saved example: https://en.wikipedia.org/w/index.php?title=Relativity_Media&diff=563012676&oldid=559815961

Is the user using a non-standard way of doing the spell-correcting, do you know?
Template inspector before closing

Wikilinks like [[Foo|Bar]] are shown expanded in template inspector after closing it, see screenshots. 

Steps to reproduce:

1. Edit a template which has wikilinks like [[Foo|Bar]] as a parameter value
2. Close the template inspector, with or w/o changes does not matter.

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

**Attached**: {F11204}
We've now fixed this in master, and will back-port to production.
Change 73173 merged by jenkins-bot:
Prevent escaping of piped links in wikitext parameters

https://gerrit.wikimedia.org/r/73173
Change 73173 had a related patch set uploaded by Esanders:
Piped links in wikitext parameters getting escaped

https://gerrit.wikimedia.org/r/73173
This is a wikitext escaping bug in VE
Screenshot of different phases:

http://cl.ly/image/1X0I281n1n0G
1) PHP rendering on Read
2) VE initial rendering after Edit
3) VE rendering after opening Template dialog and making no changes and clicking Apply changes

Dirty diff: http://cl.ly/image/241h1I3T1d2d
It doesn't show in the diff, it only shown in the live rendering in VisualEditor.
Can you create a broken diff on that article for me?
As can I, hence the duplicate bugs. Firefox 22, Windows 7.
(In reply to comment #4)
> Can't reproduce this at the example URL.

I can still reproduce it :-(
Can't reproduce this at the example URL.
*** Bug 51014 has been marked as a duplicate of this bug. ***
*** Bug 50909 has been marked as a duplicate of this bug. ***
Created attachment 12761
Template inspector after closing

**Attached**: {F11205}
Screenshot

The text of the TemplateData description should have an line break (wrap into span and style per CSS?) in the template inspector.

Longer descriptions flows out of the template inspector box, see screenshot.

Related: Bug 50656 - Parse wikicode and/or HTML in interface text

--------------------------
**Version**: unspecified
**Severity**: minor

**Attached**: {F11203}
This is now fixed in master and will be deployed soon, probably tomorrow.
Change 72863 merged by jenkins-bot:
Make parameter search widget have a horizontal limit

https://gerrit.wikimedia.org/r/72863
Change 72863 had a related patch set uploaded by Trevor Parscal:
Make parameter search widget have a horizontal limit

https://gerrit.wikimedia.org/r/72863
At the moment the only way to close a page notice is to click on the interface element that launches them - which feels somewhat counterintuitive. Could we have a little close button in the notices themselves?

--------------------------
**Version**: unspecified
**Severity**: enhancement
We did this as part of the fixes to the toolbar.
This happened on MediaWiki, he.wiki and en.wiki on Chrome.

Open some article for editing (preferably a long one so the effect is seen)
add some text in the middle or end, mark it and make it a "Heading". 

Observed result: The text turns into a heading, but the entire edit section scrolls up to the top of the page. This is especially annoying when the page is long and when the edit is done in the middle.

--------------------------
**Version**: unspecified
**Severity**: minor
This is now fixed by the above commit; we'll get it deployed soon. Sorry for the disruption.
Change 72768 merged by jenkins-bot:
Affordances for MenuWidget to be optionally focusable.

https://gerrit.wikimedia.org/r/72768
Change 72768 had a related patch set uploaded by Robmoen:
Affordances for MenuWidget to be optionally focusable.

https://gerrit.wikimedia.org/r/72768
*** Bug 50860 has been marked as a duplicate of this bug. ***
Confirmed in Chrome, Safari and not in Firefox, for whatever reason.
I just checked the editor on Firefox 22.0, and it does not scroll there (works as expected). The bug seems to be in Chrome only. 

If it helps, that's the UserAgent for my Chrome browser:

 Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36
**Author:** `turingt`

**Description:**
At the Transclusion dialog, after a click or double-click on the chosen parameter, nothing happens. Is the user expected to click on the "Add parameter" label at the top? To press Enter? To read the user guide for instruction on how  ? None of these steps help.

This is a usability bug - the actual button is hidden below the fold, at the end of a very long list that is not intended to be scrolled through, and thus hard to discover. The button should be always visible in the dialog - otherwise, the dialog becomes unusable with long lists of parameters.

--------------------------
**Version**: unspecified
**Severity**: normal
This issue is now fixed (or, rather, the button is no longer needed), as we've gone instead with single-click-to-insert, which will be deployed in the next few minutes.
Change 73865 merged by jenkins-bot:
Single-click insertion

https://gerrit.wikimedia.org/r/73865
Change 73865 had a related patch set uploaded by Trevor Parscal:
Single-click insertion

https://gerrit.wikimedia.org/r/73865
Especially when a template has many parameters;
scrolling until you find the actual button to add them,
having to add them one by one and having to do so by clicking each time on the name of the template itself to get to the list again, it's confusing users.
There's already a bug about mandatory parameters not being enforced; I am not sure of the behaviour related to the order of the parameters, but it would be great if the editor could keep them in the same order they're being chosen with. Thanks :)

--------------------------
**Version**: unspecified
**Severity**: critical
There is no longer such a button (as of a week ago).
Created attachment 12830
Screenshot of how it used to be

Note that though this is how it was. It was also true that when the text in the input field was very long (like, very very long, as long as the dialog is wide) the button would jump to *below* the parameter list (as opposed to directly below the input field or just stay where it was).


I propose that we either keep the current behaviour of the input field having a fixed width, but making sure that width is without the width of the "Add" button so that that one always stays where it should be (similar to having the "Go" button of a search field next to the input and not at the bottom of a variable-length and scrollable list of results).

Alternatively we could bring back the dynamic-width behaviour but when we'd still need to make sure it doesn't go wider than the width allotted to keep the button on the same line as well.

**Attached**: {F11129}
Created attachment 12829
Screenshot of the problem (current version)

No add button anywhere in sight, users are likely to be blocked indefinitely with no ability to add any parameters.

**Attached**: {F11128}
Though I don't know for sure, I think this is a recent regression. the button used to be where it should be (next to the input field). However at that time the input field width was also dynamic (widening as you type). I suspect Trevor "fixed" that odd overflow bug by moving the bottom out of the visible form area but probably tested it only with a small template where it was still in sight.

Adding screenshots for clarity.
Works for me. Can we twiddle with the prioritisation and criticality? This is a big workflow to have practically broken.
We're getting various reports of this kind, let's try and keep them somewhat focussed on a single tangible thing. If you don't mind I'll turn this into:

The "Add parameter" confirmation button should be next to the input field

  .. not at the bottom of the page after a potential long list of paramaters one has to scroll through to even discover the button.
We really need a fix on this. I just tried to add a template (cite web) and was so confused I had to reach out to Timo and Guillaume to work out how in the hells you add a parameter. It's...tremendously counterintuitive on any template with more than 5 params.
Agreed. This is what I was going to add into a new feature request:

---------

In the current version of the template editor, the user needs to select a parameter, click "Add parameter", enter the value, go back, and rinse and repeat for all the other parameters.

There are at least two issues with this workflow:

* For templates with a long list of parameters, the "Add parameter" button is hidden at the end of the list, so it's not obvious what to do after selecting a parameter
*: Possible solution: Give each parameter a button that adds it to the left column (like a green "+" sign, or something)

* If the user needs/wants to add many parameters, the process can be quite long.
*: Possible solution: Add an "Add all parameters" button, and possibly an "Add all required parameters" button as well.
The existing editing interface stores data on hidden categories, and on the templates in use. This is not displayed in the existing VE - it seems like the sort of thing the page settings page might be good for.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Maybe we could show these a bit more clear in the dialog, but closing for now.
Change 113464 merged by jenkins-bot:
Mark hidden categories as different in the meta-data dialog

https://gerrit.wikimedia.org/r/113464
Change 113464 had a related patch set uploaded by Alex Monk:
VisualEditor: Mark hidden categories as different in the meta-data dialog so users understand they won't display

https://gerrit.wikimedia.org/r/113464
(In reply to Alex Monk from comment #4)
> Am I right in thinking that the category data comes from Parsoid? If so then
> it might be useful to include whether the category is hidden or not there?

Okay so after discussion with James and Gabriel on IRC, for now I'm going to query the API when the category dialog loads to get this information. Later to be replaced by a general CSS cache API query (see bug 37901).
Am I right in thinking that the category data comes from Parsoid? If so then it might be useful to include whether the category is hidden or not there?
Re-wording to be less confusing. Sorry!
I think I'm missing something here - it appears that I can see hidden categories and add hidden categories to pages using the categories tool. Is this bug still valid?
"A late answer to the question of whether there are hidden categories that are actually embedded in articles instead of templates: YES. For instance Category:Year of birth missing (living people) is directly embedded into some tens of thousands of them"
In this case, https://en.wikipedia.org/w/index.php?title=Long_Island&diff=562848384&oldid=562113547 - oh dear.

--------------------------
**Version**: unspecified
**Severity**: major
*** This bug has been marked as a duplicate of bug 51217 ***
A minor change in a completely unrelated part of the article causes a copy of the broken table to be injected into the article, and a '<tr' (no closing >) is also included.  Upping priority/importance as it should at least ignore elements it doesnt properly understand.  The <table> was not so broken that the wikitext up to the </table> should have been ignored.

I am able to reproduce the '<tr' being added [[testwiki:User:John_Vandenberg/Table_test]], but in my test the table wasnt copied.

After fixing the syntax on enwp, the problem goes away.

https://en.wikipedia.org/w/index.php?title=Long_Island&action=history&offset=201307180315&limit=3
Copied from English Wikipedia:

A similar bug was reported as #49536 , but closed as fixed a while ago. Article Otto I has a reference ("ref") to "Thompson" (numbered #11 in old edit mode) inside an explanatory footnote "efn". The notes are generated below the article using "notelist". Ref 11 Thompson is not included in the reflist of VE, but shown in regular read mode. Just compare the reference lists in read and in VE edit mode to see the difference. GermanJoe (talk) 13:03, 4 July 2013 (UTC)

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51289
https://bugzilla.wikimedia.org/show_bug.cgi?id=52398
Filed a bug against Parsoid: see bug 69827
Look at [[Otto I]].  It has 63 references, including ref #18 ("Thompson") from explanatory footnote [d].  This ref doesn't appear in VisualEditor.
I believe that this now has been fixed - compare https://en.wikipedia.org/wiki/Otto_I%2C_Holy_Roman_Emperor with https://en.wikipedia.org/wiki/Otto_I%2C_Holy_Roman_Emperor?veaction=edit to see the reference lists being the same in both cases. Sorry for the slow response.
TemplateData makes it possible to have 'required' parameters, but not using these parameters in the Template editor, does not alert you of the fact that these parameters are required.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60358
Verified the fix in production
Verified the fix in test2
Verified the fix to show confirmation dialog when trying to insert/edit a template with one or more missing required parameters
There are still some remaining improvements (as always), but the thrust of this bug is now done.
Change 156559 merged by jenkins-bot:
Get confirmation when trying to insert/edit template/citation with required parameters missing

https://gerrit.wikimedia.org/r/156559
Change 156559 had a related patch set uploaded by Alex Monk:
Get confirmation when trying to insert template with required parameters missing

https://gerrit.wikimedia.org/r/156559
We're also going to require the user to confirm when they try to insert a template with required parameters missing.
I just used the Cite news template in VE, via the mini-editor. That template has a number of "required" parameters. I added just a url (a non-required field), clicked "Insert citation", and the dialog closed, posting the citation to the main page.

I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, "Name". I ignored that parameter, added another one, filled in the second one, and clicked "Insert template"; the dialog box closed. And the inserted template did *not* have a value for the one required parameter.

So not only are "required" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor.

(I note, in passing, that the marking of "required" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.)

At minimum, VE should display a warning (pop-up box) that says "One or more required parameters is missing". Then the user could choose either to click on "return to dialog" or click on "insert citation"; the latter would finish the dialog.

And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.
(In reply to Alex Monk from comment #14)
> Is there anything left here to do that isn't bug 60358?

I believe that that will complete this.
Is there anything left here to do that isn't bug 60358?
I haven't tested required/optional fields in depth, but some casual tests suggest that currently

* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the "body". Not the most self-evident UX if you ask me (why not adding labels "Required" / "Optional"?), but you get the idea after filling the first templates.

* Required field aren't still enforced, nor there is any warning when they are left empty.

My expectation as an editor is that a field marked as "required" in the documentation it is actually required...
I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters.

It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that "required" parameters are non-blank, that's not going to happen - that WMF considers anything "required" to actually be just "recommended". 

As an absolute minimum, VE should issue a warning when a "required" parameter is left blank.
Not enforcing mandatory params is a bug in either design or implementation.
Should there be "not recommended" parameters (I'd suggest something like "for experts only" as a label; if something is "not recommended", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. 

More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis.

In short, a "required" and a "suggested" list (AND enforcing that the "required" list be filled in) would be a huge win for the occasional user of templates.
Indeed, I gave up doing this for the Portuguese version for now:
https://pt.wikipedia.org/wiki/Template:Info/Taxonomia?uselang=en
This topic came up in http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Duplicate_parameters_in_a_template
and  John Broughton came up with the idea that you really want more types of status: "required" - must be set, "suggested" - appears automatically on the lhs, and "optional". 

I'd possibly add a "not recommended" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. 

BTW Taxobox http://en.wikipedia.org/wiki/Taxobox is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as "suggested".
English Wikipedian Joe Decker recommends indicating required parameters perhaps with the standard red asterisk.
%%%*** Bug 51186 has been marked as a duplicate of this bug. ***%%%
Change 73136 merged by jenkins-bot:
Auto-add required params for user added templates

https://gerrit.wikimedia.org/r/73136
Leaving at "recommend" for now since we can't fully ensure that requiring all parameters is consistently the desired behavior.
(In reply to comment #2)
> Change 73136 had a related patch set uploaded by Jforrester:
> Auto-add required params for user added templates
> 
> https://gerrit.wikimedia.org/r/73136

This just adds the parameters, not "enforcing" their presence. Not sure if we should do that (or let users do what they want).

Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)
Change 73136 had a related patch set uploaded by Jforrester:
Auto-add required params for user added templates

https://gerrit.wikimedia.org/r/73136
Indeed, this seems like a low hanging fruit improvement - when inserting a new template, having all the required fields immediately be ready for use would significantly speed up template completion.
http://en.wikipedia.org/wiki/File:VisualEditor_-_Cite_template_layout_issue_%28TemplateData%29.png

Tested on Firefox 22, Mono skin:

'''Steps to reproduce'''
* Open any random page in the visual editor.
* Add a new template - use Cite Web for this.

The output will be akin to the screenshot added. Some the template parameters end up next to each other, and are thus offscreen. Even if that is not the case the description will often be to long to be displayed. Would be nice if those ended up on a new line if that occurred.

--------------------------
**Version**: unspecified
**Severity**: major
I believe that this should now be fixed; marking as such. If you can reproduce, please re-open.
We believe that this is caused by a caching issue; a big change to how the CSS for dialogs is loaded is coming in this afternoon's deployment that (hopefully) will remove these issues, so I won't close this right now, but it seems likely that we will have fixed this by the end of today. Sorry for the disruption.
I can repro in FF20 (in Vector too) but not in Chrome 28.
Also happening in chrome.
%%%*** Bug 50738 has been marked as a duplicate of this bug. ***%%%
When your edit trips the blacklist or an editfilter, you get a very technical and uninformative message.

The edit filter causes:  "Error: The notification you tried to make was aborted by an extension hook" to show in the 'save' dialog.

The URL blacklist:  "Invalid code error" apparently.

https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=562806113#Blocked_sites

Since this is quite common for newbs to trip, it should be handled better.

--------------------------
**Version**: unspecified
**Severity**: critical
**URL**: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=562806113#Blocked_sites
* AbuseFilter is bug 50472; resolved fixed, and will be deployed tomorrow.
* SpamBlacklist is bug 50826; resolved fixed, and deployed yesterday.

Marking this as a dupe of 50472.

*** This bug has been marked as a duplicate of bug 50472 ***
Bumping priority & importance as proper integration with abusefilter must be a blocker, I would think, as rules are being written to prevent VE edits that are destructive to Wikipedia content.
This broke during yesterdays deploy. Now shows <accesskey-ca-editsource> and no key is set. I think Timo fixed it already, but the fix might not have been deployed yet.

--------------------------
**Version**: unspecified
**Severity**: major
*** Bug 50817 has been marked as a duplicate of this bug. ***
Merged into master; we hope to deploy this soon.
Change 72068 merged by jenkins-bot:
mw.ViewPageTarget.init: Add missing "accesskey-ca-editsource" message

https://gerrit.wikimedia.org/r/72068
Change 72068 had a related patch set uploaded by Krinkle:
mw.ViewPageTarget.init: Add missing "accesskey-ca-editsource" message

https://gerrit.wikimedia.org/r/72068
Confirmed.
Steps to reproduce:

* Navigate to [[Mariposa botnet]] and edit the page in the visual editor.
* Make any textual change - just add "Test" somewhere for example.
* click "Save Page"
* Adding a reason doesn't matter. Just click to close the save page popup.
* Immediately open it again (Don't click anywhere else)
* Try to add a text as the reason, then press backspace or delete what you just added.

For some reason delete and backspace won't work anymore. My guess is that the backspace is send to the editing canvas instead of the textbox - try the following steps as well:

* (Do all the steps from the first section)
* Press "Review Your changes".
* Wait for the review to load, then press "Return To Save", and close the resulting form.
* Now click the search block (In mono) and enter a random search criteria.
* Once entered, try to remove it again.

What happens for me: Entering data in the search box works fine, but pressing backspace somehow causes text to be removed from the article, instead of the search box i was just typing in.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49569
The (re)fix for this is now merged and will be deployed on Thursday 10 October to MediaWiki.org, and to Wikipedias on Thursday 17 October.
Change 81876 merged by jenkins-bot:
Make the save dialog an actual dialog

https://gerrit.wikimedia.org/r/81876
At bug 53332 comment 0 Elias Hedberg notes that he encountered this bug while using Chrome 29.0.1547.57 running in OS X 10.6.8

Previously this seems only to have been encountered in Firefox. Will that affect the pending patch at all?
*** Bug 53332 has been marked as a duplicate of this bug. ***
BeroBurns at en.wp today reported experiencing this bug:
"The save form does not allow for a keyboard backspace or to highlight text using Shift+Arrows. The only way to edit your description of the changes is to highlight the words you wish to replace with the mouse and retype."

I personally haven't encountered it since my comment above though.

What is the current state, it's had a patch waiting for review nearly 20 days and is still targetted for the release a month ago yesterday?
Change 81876 had a related patch set uploaded by Jforrester:
Make the save dialog an actual dialog

https://gerrit.wikimedia.org/r/81876
I do have popups, hotcat and section edit link for the lead section installed. Plus a couple of other things a conversation on the feedback page the other day established as being on by default.

I tried to reproduce this when logged out, and couldn't.
I then logged back in and tried to reproduce it and again I couldn't, even with no changes to gadgets. I didn't try to replicate the exact edit I made though.

Earlier on today was the first time in a while I had experienced it though, which suggests to me that there is probably something more complicated behind when this happens and when it doesn't. I'll do some more detailed testing when I next get time, as it's too perplexing for 1:30am!
(In reply to comment #12)
> (In reply to comment #11)
> > 
> > With what browser?
> 
> I encountered it using Firefox 23 on linux, Tathbelin didn't note it in their
> report but I'll ask.
> 
> Sorry

OK, well, it works fine for me on enwiki right now in Firefox 23 on Mac and on Linux (doing the ^, the <, the Esc and the "return to save form" ways of bailing). This is perplexing. Do you have some odd gadgets loaded - does it still occur if you switch all gadgets off?
(In reply to comment #11)
> 
> With what browser?

I encountered it using Firefox 23 on linux, Tathbelin didn't note it in their report but I'll ask.

Sorry
(In reply to comment #9)
> I've just experienced this in my sandbox making this edit:
> https://en.wikipedia.org/w/index.
> php?title=User%3AThryduulf%2Fsandbox&diff=570859913&oldid=570858997
> (testing for bug 52399)
> 
> In this case the series of actions was:
> 1. Make some edits
> 2. Review changes
> 3. Return to editing surface (I can't remember whether I went direct using ^
> or via the save form using <)
> 4. make some more edits
> 5. add an edit summary
> 6. review changes
> 7. return to save orm
> 8. attempt to amend edit summary, but encounter this bug

With what browser?
Nearly simultaneously with my writing the above comment, en.wp user Tathbelin reported on the VE feedback page:

"I had the Problem that while I was writing my Change Summary after editing the page I wasn't able to delete what I had previously written i.e. couldn't use delete or backspace."

The edit in question was likely https://en.wikipedia.org/w/index.php?title=Henning_Wehn&diff=570856495&oldid=565884244
I've just experienced this in my sandbox making this edit:
https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox&diff=570859913&oldid=570858997 (testing for bug 52399)

In this case the series of actions was:
1. Make some edits
2. Review changes
3. Return to editing surface (I can't remember whether I went direct using ^ or via the save form using <)
4. make some more edits
5. add an edit summary
6. review changes
7. return to save orm
8. attempt to amend edit summary, but encounter this bug
I believe that this is now fixed, having followed Chris's very helpful steps to reproduce in bug 52733 comment 1 - tested in Safari, Chrome and Firefox latest on Mac just now against wmf14 as deployed on the Wikipedias right now. Marking as such.

If you can re-produce, please feel free to re-open.
*** Bug 52733 has been marked as a duplicate of this bug. ***
I updated the summary per comment 5.
I think there is no connection with ULS for this bug. The bug exists at ml.wikipedia where no ULS is installed at present.
As per comment 2 and comment 3, changing the component back to VE.
(In reply to comment #2)
> Open the the dialog for entering reason? It disappears after I click "Save
> Page". How do I open it again?

A bit more precise:
0) Navigate to [[Mariposa botnet]] and edit the page in the visual editor.
1) Make any textual change - just add "Test" somewhere for example.
2) Click "Save Page"
3) Now, the save page box titled "Save your changes" should pop up.
4) Close that box by clicking the ^ icon in the top right of that box.

Now, you should be where you started at step 2

5) Repeat steps 2 and 3
6) Try to add a text as the reason, then press backspace to delete what you just
added.
By default input method from ULS is disabled in en.wikipedia.org. ie by default it does not do anything on textareas.

Even if it is enabled, there is no input method for English except IPA which optional. 

So in the case of the above bug, before mapping it to ULS component, please tell us whether input method was activated from the cog icon in the languages menu. Also let us know whether you were using IPA.

If this is not the case, the component is not ULS.

(In reply to comment #0)
> Steps to reproduce:
> 
> * Navigate to [[Mariposa botnet]] and edit the page in the visual editor.
> * Make any textual change - just add "Test" somewhere for example.
> * click "Save Page"
> * Adding a reason doesn't matter. Just click to close the save page popup.
> * Immediately open it again (Don't click anywhere else)

Open the the dialog for entering reason? It disappears after I click "Save Page". How do I open it again?
Yes, this is a really horrible problem that we've narrowed-down to be related to ULS's munging of <textarea>s in Firefox (and possibly other browsers?). Referring to them.
(Tested on Firefox 22, Monobook skin)

Steps to reproduce

- Go to the "The Damned Thing (short story)" page and edit it with the visual editor.
- Go to the "Gothic elements" selection, and select all the text from "Gothic elements" (Header) to "inadequate." (Last word of the section). This should also select the image.
- Click and drag the entire section, and drop it of before the "Analysis" section (Just drop it right before the A in that word, make sure the text entry | is displayed. The image itself will be gone. But for the fun part: Click anywhere on the editing canvas text.

Suddenly, your entire input screen will be white. What seems to happen is that the image is blanked (Replaced by a white square) and plastered full size all over the page. You can try to drag it away, but each time you try it will replace itself over the pages content.

https://en.wikipedia.org/wiki/File:Visual_Editor_-_Giant_White_Image.png contains a screenshot of the problem.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50643
Chris: Good catch, thanks for finding that!

*** This bug has been marked as a duplicate of bug 50643 ***
I think this duplicates bug 50643
Drag and drop is disabled for only text content, however drag and drop is allowed (in monobook) when an image and something else are selected, and the result is nasty.
Drag and drop should be disabled, but cant find the bug for it.

I cant reproduce the problem at the mentioned page on Firefox 22 (Win or Linux) using Vector, but goodness me I can reproduce this when I use monobook skin.

https://en.wikipedia.org/wiki/The_Damned_Thing_%28short_story%29?veaction=edit

(page hasnt changed since the bug was raised :/)
Note that this is not the same as bug 50715. Though they behave the same from the user point of view, bug 50715 is for a case where aliases are not in play.

e.g. given our Unsigned template with parameter "user", "timestamp" and aliases "1" and "2" respectively.

Having added "mw.log('addParameterSearch-select', name, names);" to ve.ui.MWTransclusionDialog#getTemplatePage in the select event handler of the addParameterSearch object; editing the following invocations:

 case {{Unsigned|Foo|April 1}}
 case {{Unsigned|1=Foo|2=April 1}}
    typing "1"
    >  addParameterSearch-select null ["1", "2"]
    >  addParameterSearch-select "user" ["1", "2"]
    > "Add" is enabled
    typing "user"
    >  addParameterSearch-select null ["1", "2"]
    >  addParameterSearch-select "user" ["1", "2"]
    > "Add" is enabled

 case {{Unsigned|user=Foo|timestamp=April 1}}
    typing "1"
    >  addParameterSearch-select null ["date", "user"]
    >  addParameterSearch-select 1 ["date", "user"]
    > "Add" is enabled
    typing "user"
    >  addParameterSearch-select null ["date", "user"]
    >  addParameterSearch-select null ["date", "user"] 
    > "Add" is disabled

The latter case actually works as expected, although it is odd that the value given to the select callback is null and not "user" and that the button is already disabled (probably by the select widget?).

Also weird that the callback is constantly triggered twice, once for null and once for the actual value.

Anyway, the solution is to resolve the names to their alias origins before doing the names.indexOf( name ) check.

--------------------------
**Version**: unspecified
**Severity**: normal
This is now fixed in master and we will push to production very soon. Sorry for the inconvenience.
Change 73010 merged by jenkins-bot:
Retain original param names and ignore leading/trailing whitespace

https://gerrit.wikimedia.org/r/73010
Change 73010 had a related patch set uploaded by Trevor Parscal:
Retain original param names and ignore leading/trailing whitespace

https://gerrit.wikimedia.org/r/73010
Working on this.
Split from bug 50540 which is entirely different. :-)

--------------------------
**Version**: unspecified
**Severity**: normal
This was done as part of the changed integration at the beginning of the month.
Copying from English Wikipedia:

Okay, this one is probably quite tricky: When editing the source code, if an edit conflict arises, you can simply hit the back button, copy the code, and paste it into the updated version. However, with the Visual Editor, this is no longer possible. The content goes away, so you have to re-add it all, which is a huge pain if it involves references and other templates.--¿3family6 contribs 18:25, 3 July 2013 (UTC)

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=47779
https://bugzilla.wikimedia.org/show_bug.cgi?id=52519
https://bugzilla.wikimedia.org/show_bug.cgi?id=56465
*** Bug 52950 has been marked as a duplicate of this bug. ***
Just noting that this was broken in Firefox for a few weeks after launch due to bug 56767, which has now been fixed, and I have disabled my switch editor.
verified in betalabs env
Change 83049 merged by jenkins-bot:
Button tool to switch to edit source with changes

https://gerrit.wikimedia.org/r/83049
Change 92913 merged by Catrope:
Button tool to switch to edit source with changes

https://gerrit.wikimedia.org/r/92913
Change 92913 had a related patch set uploaded by Catrope:
Button tool to switch to edit source with changes

https://gerrit.wikimedia.org/r/92913
The patch was -2'd pending a rewrite of the toolbar. Although the button works, we have no sensible place to put it until those changes are finished. At the time that was supposed to be a few days, so apologies for the delay, but that work is nearly complete now.
btw I found this was requested back in April 2013

https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_04#London_Underground_article

my hack has been broken by some change in the VE product, and the deployment of this fix has now been delayed one month. Siebrand gave the patch a +1 a week ago. What is next for this to be committed and go live?
Change 83049 had a related patch set uploaded by Esanders:
Button tool to switch to edit source with changes

https://gerrit.wikimedia.org/r/83049
It isnt that tricky.  Here is a prototype.

https://en.wikipedia.org/wiki/User:John_Vandenberg/switch_editor

The UI could be improved.
Also this would be useful to allow people to save unfinished changes for later completion.
The ability to salvage incomplete edits could have other usefulness.

Copying from English Wikipedia:

I can attest to that, I have done the same thing and so due to inactivity the 'invalid token' message is appearing. No idea what to do, currently my tab is still open containing my edits which cannot be saved, I don't want to start over (quite a bit of work here), any suggestions? Copy-pasting to a text editor is not an option since I did mainly lot of linking and minor fixes. -Ugog Nizdast (talk) 10:04, 3 July 2013 (UTC)
From English Wikipedia:

'''Steps to reproduce:'''
* Edit the [[Vogrie House]] article in the visual editor.
* Resize the image. Larger or smaller doesn't matter.
* Press either CTRL + Z, or undo the edit using the undo button. 

Instead of undoing the edit, it suddenly enlarges the image object. The image is placed in the center of the screen, and the object itself even overlaps the main navigation in the Mono interface. Of course as always: Firefox 22 used to test this. [[User:Excirial|<font color="191970">'''Excirial''']]</font><sup> ([[User talk:Excirial|<font color="FF8C00">Contact me</font>]],[[Special:Contributions/Excirial|<font color="FF8C00">Contribs</font>]])</sup> 18:03, 3 July 2013 (UTC)

See screenshot:
http://en.wikipedia.org/wiki/File:VisualEditor_-_Undoing_a_resize_issue.png

I tried on Chrome on a Mac, and it didn't work there, either, but instead shoved the image to the left of the screen

--------------------------
**Version**: unspecified
**Severity**: normal
We've now fixed this, and deployed it; sorry for the issue.
In https://en.wikipedia.org/w/index.php?title=List_of_socialist_countries&curid=7252916&diff=562675715&oldid=562675131

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #4)
> Has the fix been rolled out to svwp?

It has.

> Because I just got a similar error where
> the nowiki was added far from where I was doing my actual changes:
> 
> http://sv.wikipedia.org/w/index.
> php?title=Stockholm_Arlanda_Airport&diff=22544469&oldid=22428046

I believe that that is actually a different bug here, with Parsoid being overly keen to add <nowiki>, rather than this motley collection of other kinds of <nowiki> issues. :-(
Has the fix been rolled out to svwp? Because I just got a similar error where the nowiki was added far from where I was doing my actual changes:

http://sv.wikipedia.org/w/index.php?title=Stockholm_Arlanda_Airport&diff=22544469&oldid=22428046
First one: This is NOTABUG. User has selected/inserted the wrong text if they didn't want this - see bug 51173.

Second one: Definitely a bug, and one which I believe we have now fixed with the changes to how <nowiki>s are applied in Parsoid.

Third one: Same as two - appears now to be fixed. Sorry for the inconvenience. :-(

Fourth one: This is NOTABUG. User has created a paragraph with some leading whitespace, which means Parsoid needs to do something to stop it turning into a preformatted block. The solution is inelegant (we don't need to select the entire paragraph to stop this), but that is bug 50841.
Here are two more in case it helps with diagnosis:

https://fr.wikipedia.org/w/index.php?diff=94682339

https://en.wikipedia.org/w/index.php?diff=562790609
Again at https://en.wikipedia.org/w/index.php?title=Beximco&curid=1725818&diff=562676888&oldid=561183206 (possibly related?)
See https://en.wikipedia.org/wiki/File:Visual_Editor_-_Overlapping_issue.png

--------------------------
**Version**: unspecified
**Severity**: normal
Deployed and confirmed as fixed.
I think that this was fixed in gerrit 70851 - we'll be deploying it later today.
What it says on the tin; if you resize an image, it with reports "this isn't a change, can't save" or saves and silently doesn't do anything.

--------------------------
**Version**: unspecified
**Severity**: normal
Moved to bug 61270
I'm not sure if this is the same issue, but as reported on English Wikipedia and tested by myself, using the image resizer to "Make full size" resulted in either a notice that no change had been made or a silent failure to save.

This was tested on FF26, W7 and Chrome 32.0.1700.107 m, W7. 

The reporting editor concludes that "These new settings, for what they are worth, only work if the image already has a size indication (200px, 250px*250px, whatever), not when it only has a 'thumb' indication. Sadly, the latter is the default and by far most common situation."

He also questions the purpose of "Make full size", but I'll report that separately. 

See: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=595141503#Advanced_image_settings.3F_More_VisualEditor_rubbish.
*** Bug 51026 has been marked as a duplicate of this bug. ***
Fixed and will be going out in a few minutes.
Change 73965 merged by jenkins-bot:
Create MWResizeableNode mixin to control defaultSize flag

https://gerrit.wikimedia.org/r/73965
Change 73965 had a related patch set uploaded by Esanders:
Create MWResizeableNode mixin to control defaultSize flag

https://gerrit.wikimedia.org/r/73965
From https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#VE_adding_spaces.2C_messing_with_citation_access-dates:

I noticed something odd when using VisualEditor. I decided to use it when snooping around for various "it's" typos, for removing apostrophes seemed/is faster with VE than the old fashioned way. However, some of my edits seem to have done more than take out apostrophes. Seven times today ([http://en.wikipedia.org/w/index.php?title=Highcroft_Racing&diff=prev&oldid=562630195] [http://en.wikipedia.org/w/index.php?title=So_Emotional&diff=prev&oldid=562630132] [http://en.wikipedia.org/w/index.php?title=1988_in_British_television&diff=prev&oldid=562629968] [http://en.wikipedia.org/w/index.php?title=Olmaliq_FK&diff=prev&oldid=562629768] [http://en.wikipedia.org/w/index.php?title=FC_Jazz&diff=prev&oldid=562629613] [http://en.wikipedia.org/w/index.php?title=Brian_McDaniel&diff=prev&oldid=562629235] [http://en.wikipedia.org/w/index.php?title=Highlights_(band)&diff=prev&oldid=562629182]), VE added an extra space in a random place in the article (if it's hard to tell, on the last one it added the space right after "its"). And then it altered references on [http://en.wikipedia.org/w/index.php?title=God_of_War_(series)&diff=prev&oldid=562631132 another], including changing access-dates. I don't think that's supposed to happen... [[User:Greengreengreenred|<font color="#014421">Green</font>]][[User talk:Greengreengreenred|<font color="#50C878">green</font>]][[Special:Contribs/Greengreengreenred|<font color="#66FF00">green</font>]]<font color="red">red</font> 02:25, 3 July 2013 (UTC)


Might be a Parsoid bug based on selser tracing. There seems to be only a single space both in the original and the edited HTML.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 71757 merged by jenkins-bot:
Bug 50636: Don't extrapolate DSR on change

https://gerrit.wikimedia.org/r/71757
The space issue will be fixed with the above patch. The accessdate diff (http://en.wikipedia.org/w/index.php?title=God_of_War_(series)&diff=prev&oldid=562631132) is bug 50637.
Change 71757 had a related patch set uploaded by GWicke:
Bug 50636: Don't extrapolate DSR on change

https://gerrit.wikimedia.org/r/71757
In the accessdate example, the old markup is bad (duplicate accessdate); the second one apparently wins, which makes sense.  However, there don't seem to be any actual changes in that paragraph, so it ideally shouldn't be affected at all.
Offhand, without having investigated this, it seems like a DSR issue.
Relevant part of the selser trace (note the extra space):

SS: ", an experimental racing car. The car was designed to reduce aerodynamic drag dramatically allowing for quicker straight and cornering speeds while using half as much power and half as much weight. Despite skepticism over the project, the DeltaWing made its debut at the "
SS: " "
SS: "[[2012 24 Hours of Le Mans]]"
This doesn't mean that all of the integration needs to be independent (save dialog etc.) just the initialisation.

It used to be that the integration was only initialisation (instantiate the editor with the html document to edit, basically only up to a dozen lines of code) but it has become much more than that.

We need to separate integration and initialisation (initialisation will be part of the platform specific integration, but code-wise it should be the tip of the pyramid, not the bottom), so that our MediaWiki initialisation should be completely isolated so we can load it from the <head> and it will do only 2 things:

1) Browser compatibility test (bug 50608)
   - May depend on jQuery and a few plugins
   - May not depend on any VE classes since those may break in our subset
     of supported browsers (compared to MediaWiki/jQuery)

   (if passed)
2) Perform our changes to the interface to avoid flash of "pre-init" state
   - Edit tab (bug 50542)
   - Edit section links (bug 50540)
   - Handle setup/teardown of VE from either clicking an "Edit" link
     or by url query.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50677
This is now fixed (and deployed).
Change 71929 merged by jenkins-bot:
Split off setup from the rest of mw.ViewPageTarget

https://gerrit.wikimedia.org/r/71929
Change 71929 had a related patch set uploaded by Krinkle:
Split off setup from the rest of mw.ViewPageTarget

https://gerrit.wikimedia.org/r/71929
--------------------------
**Version**: unspecified
**Severity**: normal
This is now fixed (and deployed).
Change 71929 merged by jenkins-bot:
Split off setup from the rest of mw.ViewPageTarget

https://gerrit.wikimedia.org/r/71929
Change 71929 had a related patch set uploaded by Krinkle:
Split off setup from the rest of mw.ViewPageTarget

https://gerrit.wikimedia.org/r/71929
Check page settings for https://en.wikipedia.org/wiki/User:John_of_Reading?veaction=edit - it's probably not necessary to have language linking for userspace, but if we're going to do it the ability to distinguish sandboxes from articles would be good.

--------------------------
**Version**: unspecified
**Severity**: minor
*** This bug has been marked as a duplicate of bug 49226 ***
**Author:** `Thehelpfulonewiki`

**Description:**
Page notice overlaps the close button on page settings

I tried to edit Barack Obama using the Visual Editor. The page notice came up - which is fine - but then I clicked on the page settings without dimissing the page notice and wasn't able to dismiss the page notice. The page notice covers the close button so the only button I could press is "apply changes" to causes the page settings window to go away, allowing me to hide the page notice.

I was told in #-visualeditor that you can click anywhere in the notice itself to dismiss it - something I didn't even consider doing because that's not standard behaviour for notifications (considering Facebook and even Echo). Please can we make the page notice dismissable by clicking on the "1 notice" area, even if you've got the page settings window up?

See attached screenshot for an illustration of the problem.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49059

**Attached**: {F11576}
This problem is still reproducible with the link editor dialog.
This has now been fixed by Rob; marking as such. I hope we can deploy this to production soon, possibly tomorrow.
Inside an RTL wiki, if you set your interface to English (or any other LTR language) you will see that the '[edit | edit source]' links are jumbled.

(Example: https://he.wikipedia.org/wiki/%D7%A4%D7%99%D7%96%D7%99%D7%A7%D7%94 - use English interface)

This is probably again a case of bidi isolation. I can take a look at the code.

--------------------------
**Version**: unspecified
**Severity**: normal
Merged and will go out with the next deployment.
Change 71568 merged by jenkins-bot:
Fix for edit links, RTL wikis with LTR interface

https://gerrit.wikimedia.org/r/71568
Change 71568 had a related patch set uploaded by Mooeypoo:
Fix for edit links, RTL wikis with LTR interface

https://gerrit.wikimedia.org/r/71568
The "Edit source" tab loads/renders a little bit after the "Edit" tab, sometimes more noticeably so, sometimes less. Relatedly, clicking the "Edit" tab very early on sometimes invokes the wikitext editor. 

It would be preferable for both tabs to be rendered simultaneously with the correct default behavior.

--------------------------
**Version**: unspecified
**Severity**: normal
This is now done, and deployed.
Change 77165 had a related patch set uploaded by Catrope:
Move edit tab generation into PHP and make it more configurable

https://gerrit.wikimedia.org/r/77165
(In reply to comment #10)
> Change 71929 merged by jenkins-bot:
> Split off setup from the rest of mw.ViewPageTarget
> 
> https://gerrit.wikimedia.org/r/71929
This introduces a top-loading module, but still does the tab layout from document ready, which means there's probably still is a flash. What we should really do is change the HTML from PHP, per comment 8.
Change 71929 merged by jenkins-bot:
Split off setup from the rest of mw.ViewPageTarget

https://gerrit.wikimedia.org/r/71929
Change 71929 had a related patch set uploaded by Krinkle:
Split off setup from the rest of mw.ViewPageTarget

https://gerrit.wikimedia.org/r/71929
Ideally we'd alter the HTML using a PHP hook, then have a top-loading module that just conditionally adds some CSS to make the HTML generated by the PHP hook display correctly. That should allow us to get rid of the flashing tab behavior.
(In reply to comment #6)
> Shouldn't blacklisting occur much earlier (before actually messing around
> with any buttons at all?). Before having done *anything* actually?
> 
> I'm hoping for a definite answer by James (or another dev involved).

Yes; that's bug 50608. We're re-working a whole bunch of items around the initialisation and integration code for VisualEditor right now - bug 50612 tracks that.
Shouldn't blacklisting occur much earlier (before actually messing around with any buttons at all?). Before having done *anything* actually?

I'm hoping for a definite answer by James (or another dev involved).
**pinkampersand.wikimedia** wrote:

(In reply to comment #4)

> What do you mean by "we display:none the former if the user doesn't pass the
> blacklist code"? What is the "blacklist code"?

I believe James is referring to the part of VE that checks a user's browser and compares it against a "blacklist" of non-supported browsers. "display:none"-ing the VE edit tab thereby stops people from using VE if their browser's not going to let them.

One of y'all devs can correct me if I'm wrong here.
Sounds good. This could also fix bug 50402 at the same time I think?

What do you mean by "we display:none the former if the user doesn't pass the blacklist code"? What is the "blacklist code"?
Re-titling slightly per discussion; the suggestion is now:

* VisualEditor (?in PHP for efficiency/simplicity) hooks into the page before display
* On this hook,
** we add the VE edit tab ("edit")
** we switch out the WT edit tab with a new label and tool-tip ("edit source")
** we display:none the former if the user doesn't pass the blacklist code
No, this bug is about the tabs at the top of the page (Read/Edit/Edit source), while bug 50540 is about the section-level edit links.
Should this be merged in some way with Bug 50540?
A long-standing editor feels that the delay before the "edit source" option in sections disadvantages those who wish to bypass VE. Is it possible to have the "edit source" link visible always?

See:
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=562471642#Very_slow_and_featureless

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56337
As per https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update this has been fixed.
**kwwilliams** wrote:

(In reply to comment #50)

> That RFC can provide guidance, but there are issues of ends versus means.

Exactly. The "end" of testing Visual Editor should not include the "means" of having it used by the unwary. The only people using VE at this point should be people that are completely aware that they are testing in addition to editing. We can't rely that new accounts have seen some previous notice, or that anonymous editors have seen any notice at all. The only way to ensure that people are aware that it is a beta editor is in the button text itself.
(In reply to comment #49)
> The only mention of the warning that it is beta came in the "Oppose" section.
> The very fact that two of the only three oppose votes mention placing the
> warning after VE has been invoked makes it clear that people commenting are
> commenting in the context that the *button* should warn people that it's
> beta.

That RFC can provide guidance, but there are issues of ends versus means. Changing the section edit links to read "beta" would be a bad idea both for the English Wikipedia and for VisualEditor generally.

As suggested in comment 46, the exact wording should be customizable by editing the relevant MediaWiki message pages on-wiki. This bug should focus on removing the animation altogether and providing a sane default behavior for VisualEditor.
**kwwilliams** wrote:

(In reply to comment #47)
> (In reply to comment #45)
> > I would suggest that we go with
> > 
> > [beta editor | stable editor] 
> 
> No. That RFC (linked in comment 45) ... suggests better advertising that
> VisualEditor is beta software. 

It specifically asks about the "user interface", not the advertising.

(In reply to comment #48)

> 
> ,,, we don't need to point out that it's beta in the
> section edit links (it would just be more annoying). 

I suggest that you go back and read that section. The question is explicit. 

Answer 1: The "edit" button should explicitly say "beta editor" 
Answer 4: Please label that Edit button more clearly as the way to the Beta version.
Answer 7: Indeed, per Kww (i.e. per answer 1)
Answer 17: per User:Kww (again, per answer 1)
Answer 26: There is no reason the "edit" button shouldn't mention the fact it's using VE
Answer  28: Per kww (i.e. per answer 1)
Answer 34: Per kww
Answer 39: Label "Edit for beta or worse" (just kidding). Perhaps label as "Edit slow" or "Edit risky" or such

All the remaining supports were in the context of actually changing the *button text*, even if the question said "user interface".

The only mention of the warning that it is beta came in the "Oppose" section. The very fact that two of the only three oppose votes mention placing the warning after VE has been invoked makes it clear that people commenting are commenting in the context that the *button* should warn people that it's beta.
(In reply to comment #46)
> [visual edit (beta) | source edit] would be better but not optimal I don't
> think. [edit | edit visually (beta)] is the most compact that I can come up
> with, but I'm not claiming that as perfect.

As stated in comment 47, we don't need to point out that it's beta in the section edit links (it would just be more annoying). We can advertise that VisualEditor is beta software in the VisualEditor interface itself (i.e., ?veaction=edit).
(In reply to comment #45)
> I would suggest that we go with
> 
> [beta editor | stable editor] 

No. That RFC (linked in comment 45) is specific to one wiki and doesn't suggest using [beta editor | stable editor], it suggests better advertising that VisualEditor is beta software. This request should be filed as a separate bug (and cross-referenced with [[Wikipedia:VisualEditor/Improvements]]).
I don't think [beta editor | stable editor] is good as it doesn't tell you what the functional difference between them is. We probably also want to stick with "edit" rather than "editor" (verb rather than noun). 

[visual edit (beta) | source edit] would be better but not optimal I don't think. 
[edit | edit visually (beta)] is the most compact that I can come up with, but I'm not claiming that as perfect. If one of them is labelled simply "edit" that should be listed first (regardless of which one it is).

Allowing the titles to be set by a MediaWiki: namespace page would be ideal, but that is a different request and I can't remember if it has a bug or not.
**kwwilliams** wrote:

(In reply to comment #44)
> This needs to be fixed as soon as possible. Compounded annoyance is a very
> bad
> thing.
> 
> Let's go with [edit | edit source] for now.

Based on the results so far at http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Default_State_RFC#Question_4:_Should_the_user_interface_explicitly_warn_editors_that_pressing_the_.22edit.22_button_is_using_beta_software.3F I would suggest that we go with

[beta editor | stable editor] 

or there will be more calls that WMF is not paying attention to the preferences of the Wikipedia community
This needs to be fixed as soon as possible. Compounded annoyance is a very bad thing.

Let's go with [edit | edit source] for now.
**lecotegougdelaforce** wrote:

Two more comments, after reading the discussion pointed by comment 30 : 

- this argument from Nick White needs emphasizing : "I don't think two small edit links by section headings constitute clutter. Rather it emphasises *the* key
thing about wikipedia, that editing is encouraged."

- the cluttering invoked to justify the hovering solution is actually an argument *against* the hovering : in any case when you hover the link the second option appears, so at one moment the same text will be visible anyway, and actually the hovering is adding a level of cluttering, blinking (including additional blinking when the hovering occurs without the user wanting to edit the section).
**lecotegougdelaforce** wrote:

Glad to see this report already exists.

The idea of having text for VE editing and an icon for standard editing is *wrong* : you can't have two different methods (namely text and image) for advertising two options of a single choice, it's an aberration in terms of user interface (I'm no expert though), it's completely counter-intuitive.  Furthermore people use to associate text *with* image (caption), which makes it even more counter-intuitive.

As far as I'm concerned, I'd be satisfied if we could just switch the default editing method.  That is, I don't want to use VE as a standard, but an advertisement saying it may be useful in certain situations, so I'd prefer to keep it at the hand in case I want to give it a try.  However, I want the default editing action to be the standard editing.  That is, I want the first "modify" link to open the standard editor, and the link enabled by the hovering to be the VE.  Therefore, a simple "default editor = standard/VE" in the preferences would be enough for me.

However I understand the reading issue mentioned in comment 25, so I'd prefer if the hovering was completely disabled and both links always present (possibly with the option to hide one or both in the preferences).

Furthermore, I'm strongly for the idea to give the user the choice of his editor.  And when I say "user", I also mean "new user".  Not all users are WYSIWYGers, and though people seem (and they're probably right) to think that the standard editor may frighten some new users, hiding the standard editor by default may as well repel some new users.

Therefore the best solution in my opinion would be to simply disable the hovering and keeping both links, with the possibility to hide one or both in the preferences.  The argument that it's too many links is absurd : on a webpage there are links everywhere, internet users are used to ignore them.  It's even more true for WP where almost half of words are links…
(In reply to comment #40 by kwwilliams@kwwilliams.com)

I was assuming of course that the visual editor was working well. I think that the visual editor should be turned off for anonymous IP users until it is working well. 

The VE should have true section editing (instead of whole-page editing as it does now) before IP users are allowed to use the VE. 

The VE also needs to be able to add references well before it is enabled again for IP users.
**kwwilliams** wrote:

(In reply to comment #39)
> (In reply to comment #38 by Chris McKenna)
> 
> I think completely new users would be more confused by having to choose
> between
> 2 edit links in text format. We want to encourage them to try the WYSIWYG
> visual editor first. 
> 
Why would you want to do that? Wouldn't it be better to steer them to the working editor if you need to "steer" them at all?

The navigation needs to remain *neutral*.
(In reply to comment #38 by Chris McKenna)

I think completely new users would be more confused by having to choose between 2 edit links in text format. We want to encourage them to try the WYSIWYG visual editor first. 

If there is one link and one icon they see the VE "edit" link and so they click it to edit. Nothing could be simpler up to that point. 

Then they type in some text, and maybe add bold and italic via VE. So far, it is very simple, and exactly like their email composition.  

My Google Mail "compose" link goes directly to the WYSIWYG editor. So should the "edit" link in Wikipedia. 

Google Mail offers a "plain text mode" in an unlabeled dropdown menu at the bottom right of the compose window. 

We don't want to make wikitext source editing difficult to access, and so an icon is direct access. But we won't confuse completely new users by having two openly-labeled "edit" links.
It's not about aesthetics (that's the reason we have the hover) it's about usability. 

One icon and one link would not likely slow me down considerably, but it would seriously impact new users and those who are not as computer savvy as the people who comment here. UIs need to consistent and accessible. There are two editors, and they need to be accessed in the same way. One icon and one link is guaranteed to cause confusion and it will require active thought far longer than two of the same (blame human psychology).

Take a look at the user interfaces of all the websites and programs you use, and look at the ones you don't regularly use because you can do the same easier elsewhere. Notice how all the ones you think of as good are clear, intuitive and internally consistent. This is not a coincidence.
(In reply to comment #35 by Chris McKenna)

You said the following concerning why you want consistency:

> Because there are two ways to do the same job (edit the page) the ways of
> doing this need to look the same. 

...

> As explained above, "clutter" is very significantly less important than
> consistency. If we need it to say "edit" at least once then we need two text
> links. If two text links are two cluttered then we need two icons.

I still do not see how one edit link being text, and one being an icon would slow down your editing in any way. It sounds more like an esthetic preference.  

You like things in order. My room is probably a lot messier than yours. ;)

I think many options should be put in user preferences. The more the better as far as I am concerned. More happy editors means more editing gets done.
Just to point out the importance of this bug:

I just deactivated VisualEditor for this exact reason. I hate the hovering, and I'm mis-clicking regularly because of the VE replacing my well known "Edit" button. Since it is know activated also in my Homewiki (dewiki) I can't stand it any longer. Goodby VE!

Actually I *tried* to give it a chance (I did not deactivate it up to now, although there are many possibilities around how to do it!), but the agressive way the VE is replacing UI links is just not acceptable.
(In reply to comment #34)
> Chris McKenna said that a text link and an icon link were "a nightmare from a
> usability perspective". 
> 
Yes, because they are inconsistent. 

> You are saying "it's about consistency". Something can be completely usable
> and
> not be consistent. Why is consistency important to you? I do not see the
> need. 
Because there are two ways to do the same job (edit the page) the ways of doing this need to look the same. 

> According to your logic, we should delete the watchlist star icon because it
> is
> inconsistent with the text links at the top of pages. 

The watchlist star is irrelevant to this discussion. It does not offer an alternative interface to achieve the same job as one of the text links. Completely different situation
  
> An icon avoids clutter on section header lines. We still need "edit" as text
> at
> least once, since that is what makes Wikipedia what it is; the encyclopedia
> that anybody can *edit*.

As explained above, "clutter" is very significantly less important than consistency. If we need it to say "edit" at least once then we need two text links. If two text links are two cluttered then we need two icons.
(In reply to comment #33 by Eduard Braun)
> It's not about "being difficult" it's about consistency!
> 
> We have two equivalent ways of editing an article, therefore there should be
> two equivalent buttons.
> 
> Either both of them should be textual links or both of them should be icons.

Chris McKenna said that a text link and an icon link were "a nightmare from a usability perspective". 

You are saying "it's about consistency". Something can be completely usable and not be consistent. Why is consistency important to you? I do not see the need. 

According to your logic, we should delete the watchlist star icon because it is inconsistent with the text links at the top of pages. I believe the watchlist star icon was partially implemented as a way to save space at the top of pages, and to avoid having dropdown menus in smaller screens. 

The star icon allowed the viewing of Wikipedia pages at smaller screen widths before the dropdown menus showed up at the top. 

With edit links we are trying to avoid dropdowns, hover, and hidden edit links. 

An icon avoids clutter on section header lines. We still need "edit" as text at least once, since that is what makes Wikipedia what it is; the encyclopedia that anybody can *edit*.
It's not about "being difficult" it's about consistency!

We have two equivalent ways of editing an article, therefore there should be two equivalent buttons.

Either both of them should be textual links or both of them should be icons.

None of them should be hidden by default.
(In reply to comment #31 by Chris McKenna)

I don't understand. How is it difficult to click a static icon that is there all the time (without having to go through any hovering)? There is a star icon at the top of almost every Wikipedia page for adding or removing a page from one's watchlist. 

If clicking an icon to get to the source wikitext editor is a nightmare, then how is making both links icons (as you suggest) better. I agree that the icon for the source wikitext editor should have alt text and tooltip. I should have stated that to begin with, but I assumed that would be done, just as it is for the watchlist star at the top of the page.
(In reply to comment #30)
> I think the least cluttered longterm solution for them might be
> an
> "edit" link for the visual editor, and an icon for the source wikitext
> editor.

Least cluttered perhaps, but a nightmare from a usability perspective. Either make both an icon (with alt text and tooltip) or both text links. Usability is far more important than avoiding a tiny bit of clutter.
(In reply to comment #26 by Erik Moeller)
> I agree we need to revisit this, Richard. We'll kick around some options, but
> we won't be able to get a new interface out before next week at the earliest.

I see that this is being discussed here: 
*http://lists.wikimedia.org/pipermail/design/2013-July/subject.html 

I note that in this message 
http://lists.wikimedia.org/pipermail/design/2013-July/000804.html 
you agree with Trevor Parscal: "The hover effect is easy to drop - if we are all willing to take the hit on the clutter." 

I agree with you on this: "If we want experienced users to test it every once in a while, give feedback on how it can be made better, and have them see the improvements, finding a solution that poses the least burden on them will give us the biggest win."

It needs to be emphasized that there are many experienced users who edit anonymously (IP edits). They will not be able to go to preferences to choose other options. I think both hover and dropdown will irritate those experienced IP editors. I think the least cluttered longterm solution for them might be an "edit" link for the visual editor, and an icon for the source wikitext editor.
**kwwilliams** wrote:

(In reply to comment #24)

> My first thought is that you are putting a lot of effort into preserving an
> option that doesn't work. The first and easiest step is to remove the button
> for editing sections using the source editor until you actually have a source
> editor that can edit sections. Similarly, your preference scheme seems OK,
> but
> the default should be "Edit sections as wikitext", at least until you
> actually
> have a source editor that can edit sections.
> 

Sleepiness had obviously hit. Replace with 

My first thought is that you are putting a lot of effort into preserving an
option that doesn't work. The first and easiest step is to remove the button
for editing sections using the visual editor until you actually have a visual editor that can edit sections. Similarly, your preference scheme seems OK, but
the default should be "Edit sections as wikitext", at least until you
actually have a visual editor that can edit sections.

While sleepiness had hit, the point remains valid: since Visual Editor doesn't work for sections, there's no reason to damage the user interface by pretending to support it.
What about my suggestion in comment 15? I still think this would be a workable solution resolving most of the controversy around section edit links.

The proposed setting whether to prefer VE or the WikiEditor could also be used to relabel the buttons to improve the workflow for everybody:
* "Edit" for the edit button using the preferred editor
* "Edit Source" or "Visual Edit" for the second button

This way a simple "Edit" button would be the default way to edit an article, regardless of which editor the user prefers, while the other option was around for special use cases.
(In reply to comment #24)
> The first and easiest step is to remove the button
> for editing sections using the source editor until you actually have a source
> editor that can edit sections.

To clarify, "source" is one of the terms VisualEditor uses for wikitext.  So, the wikitext/source section editor has not changed (other than the label).
I agree we need to revisit this, Richard. We'll kick around some options, but we won't be able to get a new interface out before next week at the earliest.
Discussed again at [[Wikipedia:VisualEditor/Feedback#Edit Source is upsetting. When reading is upsetting]]

I think this comment highlights the problem for readers, not just editors or power users, presumably this is effecting IP readers as well:

It is VERY unpleaseant for me to read with the new feature. When I pass the mouse over the edi button, appears a new button saying edit source. I know these things are great for editors. But they are really distracting because one scrolls the mouse accidentally, in all the horizontal white stripe, i mean one scrolls the mouse over any place at the same height of the screen that Edit button, then Wild Edit source button appears. This is horrible. Please, make it harder to find. This distracts the eye a lot, i'm tottally serious. Plase, don't take this for a joke, i'm serious, the editors may have another way to do that, for example clicking on a small STATIC button for visual editing, that would be GREAT! Thank youSantropedro1
**kwwilliams** wrote:

(In reply to comment #13)

> Section editing links
> (x) Hybrid edit / edit source links [default]
> ( ) Edit sections via VisualEditor
> ( ) Edit sections as wikitext
> ( ) Disable section editing
> 
> ...
> 
> We don't love the [ edit ] [ edit source ] static links, because it feels
> cluttered and not the kind of user experience that we want to support.
> 
> Thoughts? If either of these feels like a reasonable path forward, we can
> re-use this bug to track it, or start a new one.

My first thought is that you are putting a lot of effort into preserving an option that doesn't work. The first and easiest step is to remove the button for editing sections using the source editor until you actually have a source editor that can edit sections. Similarly, your preference scheme seems OK, but the default should be "Edit sections as wikitext", at least until you actually have a source editor that can edit sections.

My second thought is that for any choice that presents both, the animated is far worse, and probably gets worse for anyone that uses an interface with a long word that means "edit". When I see a page, it has little buttons labeled "bewerken" next to each section header, and as I'm moving my cursor there, it suddenly animates and "brontext bewerken" slides out to the side (which is strange, because my main button for editing source is labeled "bron bewerken"). Not surprisingly, I'm accustomed to having the thing I'm aiming for not purposely jump out of the way once I try to get there. I'd prefer getting a popup and having to click twice to having the thing I'm aiming for run away. Of course, I can try to remember to aim 3 cm to the right of the button and click *there*, but that is really an odd UI.

In terms of the VE feature that makes me curse every time it occurs, it's accidentally launching VE because the thing I was aiming for ran away while I was aiming for it.
(In reply to comment #13 by Erik Moeller)

> We don't love the [ edit ] [ edit source ] static links, because it feels
> cluttered and not the kind of user experience that we want to support.

If provided as a preference then it is not clutter, at least to that user. 

If you don't provide this as a baked-in MediaWiki preference in the edit tab of preferences, then probably all Wikipedias in all languages, and all MediaWiki installations outside the Wikimedia world will provide buggy gadgets to provide the 2 static links. 

For example; the buggy CSS hack described here:
*[[Wikipedia:Village pump (technical)/Archive 114]] - see section "Removing the animation from 'edit source' section links on Visual Editor".

Is it not a thousand times better for it to be a fully-maintained, baked-in preference that will not constantly become buggy after various MediaWiki updates?
**turingt** wrote:

> 
> We don't love the [ edit ] [ edit source ] static links, because it feels
> cluttered and not the kind of user experience that we want to support.
> 
> Thoughts? If either of these feels like a reasonable path forward, we can
> re-use this bug to track it, or start a new one.

You seem to be under the impression that [ edit ] [ edit source ] dynamic links that appear and disappear on hover feel ''less'' clutter, but that's not the case.

The least possible clutter that support both editors is to show shorter links, and make them static:

[ edit | source ]

or maybe get rid of the square brackets - they don't look at all necessary if both links are always visible:

Edit | source

See? No clutter at all, and more functional for all users regardless of their javascript or pointing device availability.
(In reply to comment #20)
> Are you sure the single link was the VE one?
> 
> I've seen some occasional cases where only the wikitext section links showed
> (this is also the default, e.g. if you have JavaScript disabled), but I can't
> recall one where only the VE section links showed, since the hover code has
> been setup.

It probably was a link to Source Editor, but when 'edit' could go to VE or SE, such confusion and concern results.  On mobiles, it's not possible to see what the link is without pressing it.
Are you sure the single link was the VE one?

I've seen some occasional cases where only the wikitext section links showed (this is also the default, e.g. if you have JavaScript disabled), but I can't recall one where only the VE section links showed, since the hover code has been setup.
A user on the English Wikipedia has today commented that the hover links are not always displaying when the system is being slow or unresponsive (their local system or the WMF servers). This obviously means that section editing in the classic editor is not available when its small footprint would be most beneficial

For reference they included their technical specs:
Downstream 20 Mb/s; Safari 6.0.5; Mac OS 10.8.4; 2.7 GHz Intel Core i7 (64-bit); 8 GB 1333 MHz DDR3; Flash 11.8.800.94; Java 1.6.0_51.
I'd prefer just showing them always, too (they can then be easily be hidden separately with CSS if necessary). But others prefer how it is done now (see Erik Möller's concerns in comment 13).

That's why I proposed a *prefer*ence here.

Anyway, if we should decide against a preference, showing them always is the way to go, because the current hovering effects are a nightmare for both, accessibility and customizeability.
**gigs** wrote:

Eduard Braun's preferences proposal would work to solve all the use cases, but I don't see how this is superior to just always showing both links, with a preference for reverting to the old behavior (which already exists).

Users will quickly adjust to clicking on their preferred mode, if both are always shown.
Custom CSS workaround available at https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=563794311#Removing_the_animation_from_.22edit_source.22_section_links_on_Visual_Editor
However this will be solved: Put thought in it!
I could imagine, that this decision will determine whether people will be disabling/hiding VE or keep using it along with the Wikitext editor.

A proposal from my side which might be a better fit from a user's point of view:

1) One setting (radio button) that determines which editor the user prefers for normal tasks (e.g. whether "edit" or "edit source" is shown first in toolbar or whether "edit" or "edit source" is shown as section edit link while the other one is shown on hover only)
(o) Prefer VisualEditor
( ) Prefer Wikitext Editor

2) One setting (radio button) to control how edit section links are handled
(o) show preferred edit link, show the other one on hover
( ) always show both edit section links
    ([edit|edit source] or the other way round depending on 1)
( ) only show preferred edit section link, don't show the other one at all.
( ) no edit section links at all
We've been kicking around the section editing behavior a fair bit, and we recognize the need for more flexibility, in part because the mouseover interface doesn't translate well to touch-based user interfaces. (We also recognize that section-editing in VisualEditor overall is still a bit of a crutch, but that's a larger discussion.)

What James and I would like to suggest here is a multi-way pref:

Section editing links
(x) Hybrid edit / edit source links [default]
( ) Edit sections via VisualEditor
( ) Edit sections as wikitext
( ) Disable section editing

The section editing feature is already disable-able, so we could just merge the pref.

Having three modes may seem like overkill at this stage but James feels that having an option for VisualEditor specifically at least puts a flag in the ground that we want to continue to improve section editing usability.

If folks think that's too much, we could just have a single

[ ] Support section editing via VisualEditor 

checkbox as this point, enabled by default, which turns on or off the hybrid mode.

We don't love the [ edit ] [ edit source ] static links, because it feels cluttered and not the kind of user experience that we want to support.

Thoughts? If either of these feels like a reasonable path forward, we can re-use this bug to track it, or start a new one.
I misspoke. The only VE gadget now in preferences is this one: "Remove VisualEditor from the user interface." 

But my point is that each language version of Wikipedia should not have to create gadgets to provide VE options to its editors. 

Some preferences need to be provided in all MediaWiki installations. Or at least all Wikimedia installations of MediaWiki. For example:
*Display both "edit" and "edit source" links for sections without hover.
*Remove VisualEditor from the user interface (VE still loads, but it can not be used).

The first preference will mean that far fewer people will use the second preference. And the 2 preferences should be together so that people can see why they should choose the first preference over the other. The reason being that since VE still loads, one saves no load time by blocking access to using VE.
There is no way this should be "Lowest" in importance. Moved up to "Normal". I would change enhancement to "normal" also, but developers still seem dead set against making the choice dead simple and easy; or as one recent commenter wrote: "I am talking about giving editors easy way to choose the way they want to edit wikipedia." This is a common request. 

This needs to be a baked-in option in the edit tab of preferences. Not an ad hoc addon gadget as it is now in English Wikipedia. At least then registered editors can keep editing most efficiently. Choosing instantly between visual editor and source editor as the need arises. Registered editors do twice as many edits each month as anomymous IP editors. See chart:
[[File:Anonymous, registered, and bot edits. English Wikipedia timeline by percent of edits.png]]

So if you can't get it right for anonymous editors, at least allow registered editors to get it right with an option.
**gigs** wrote:

It's difficult to focus without clicking on a touchscreen as well.
(In reply to comment #7)
> It seems no one has pointed out that pads and phones and touchscreens usually
> can't "hover".  Hover stuff should pretty much never be a necessary part of
> any web UI.

It's not a necessary part.  First, the 'edit source' link at the top does not require any hover.  Second, the same thing occurs ('edit source' section link is shown) when you focus on the 'edit' section link (onfocus).
This should be a priority and not just an enhancement. To think that future versions of MediaWiki will be crippled longterm by this incredibly buggy and slow visual editor is very discouraging. 

At the very least there needs to be a preference for direct "edit" and "edit source" links built in to MediaWiki preferences on the edit tab of preferences. MediaWiki installations should not need a "gadget" preference added for this by each webmaster of every MediaWiki installation. 

The hidden link to "edit source" is slowing down many editors. For more info and other options: 

[[Wikipedia:VisualEditor/Feedback/Archive_2013_07#Edit_and_edit_source_links_so_confusing_I_had_to_disable_Visual_Editor_in_preferences]]

[[Wikipedia:VisualEditor/Feedback/Archive_2013_07#Note_the_many_unhappy_people_who_do_not_see_the_HIDDEN_.22edit_source.22_link]]

A thread linked in a previous comment (comment 1) has been archived:
[[Wikipedia:VisualEditor/Feedback/Archive_2013_07#How_to_disable.3F]]

There have been many more comments requesting a direct link to "edit source" on each section. See:
[[Wikipedia:VisualEditor/Feedback]] and its archives.

Slowing down the many editors who will continue to need source editing to edit complex things more easily is a really dumb idea. What is the logic? That you will irritate and trick editors into using the visual editor? That they will click the "edit" link instead of the "edit source" by being tricked? It is extremely irritating to have to spend extra time to get to source editing. You will not lack in bug reports by providing direct links to "edit source". 

For help on putting links in Bugzilla threads:
[[WP:Bugzilla]]
**gigs** wrote:

It seems no one has pointed out that pads and phones and touchscreens usually can't "hover".  Hover stuff should pretty much never be a necessary part of any web UI.
Clarifying.
@Krinkle: I think the change of the summary is wrong.

This is (from what I get from the comments, the discussions linked are a little less clear I'm afraid) not about section "edit source" links being loaded with delay (although this would be an issue, too).
It's about having to hover over the "edit" link to be able to see the "edit source link". They should both be directly accessible (without hovering and visibility changes).
This is (besides bug 50542) one of the main reasons a seamless coexistence of VisualEditor and Wikitext editor is *not* possible at this time (as intended by the WMF).
Note that this request is being repeated a lot, including by people who are unhappy that mousing over causes words to pop up, which they say disrupts reading the page. They would prefer the words be always visible to avoid this.
This was proposed before and even had a rejected patch by me: I13bbb954.
Sorry - wrong section.

See:
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=562471375#How_to_disable.3F
A firefox 5.0 user is reporting that blacklisting simply isn't working - they're seeing the VE, broken. Their response to "are you spoofing user headers" was along the lines of "what the heck is that?" which answers that question.

--------------------------
**Version**: unspecified
**Severity**: normal
This is now deployed.
Change 71554 merged by jenkins-bot:
Blacklist Firefox <= 10 per reports that it's broken

https://gerrit.wikimedia.org/r/71554
(In reply to comment #6)
> I re-checked FF10 on Windows 7:  whether editing a whole page or a section
> of a page FF10 presents the loading... bars but never presents the editor

OK, we'll blacklist Firefox 10 and under per the above patch; will see if we can do a quick deploy today to avoid user confusion.
I re-checked FF10 on Windows 7:  whether editing a whole page or a section of a page FF10 presents the loading... bars but never presents the editor
Change 71554 had a related patch set uploaded by Jforrester:
Blacklist Firefox <= 10 per reports that it's broken

https://gerrit.wikimedia.org/r/71554
(In reply to comment #3)
> Tried FF 5, 9, and 10, VE "Edit" links are available in all of them along
> with
> "Edit source" links.  In each case VE only displays the loading bars and does
> not present any usable interface.

We've had a user swear blind that everything works fine in FF 10. Clearly they misled us. :-(
Tried FF 5, 9, and 10, VE "Edit" links are available in all of them along with "Edit source" links.  In each case VE only displays the loading bars and does not present any usable interface.
Wait, so non-whitelisted browsers are let through? Is this documented anywhere?

I'd suggest anything not whitelisted be blacklisted, frankly. We've got firefoxes 5, 9 and 10 producing substantial problems.
We don't blacklist Firefox 5. We currently blacklist:

* MSIE <= 10
* Android <= 3
* Blackberry
* Opera

We whitelist:
* Firefox >= 11
* Iceweasel >= 10
* Safari >= 5
* Chrome >= 19

All other browsers are let through, with a warning.

Does this mean we should blacklist Firefox 5.0?
**Author:** `rachelqa99`

**Description:**
enter erroneous text for existing reference

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/User:Rachel99/testing_070113?veaction=edit

**Attached**: {F11502}
On review this was specifically fixed by the changes to how the references list was constructed; marking as such.
I can't reproduce this either. Time for a close as "worksforme"?
Created attachment 12928
screenshot of dialog

I can't reproduce this; maybe the UI has been fixed?

Attached is the list I see.  Typing 'ux' in the input box removes references that dont match the string 'ux'.  Typing 'sys' reduces the list to one reference that does match the box.

**Attached**: {F11504}
**rachelqa99** wrote:

first reference is picked when erroneous text typed in

**Attached**: {F11503}
**rachelqa99** wrote:

I have references that already exist. I want to reuse one of them. I choose reference bookmark icon.  It lists all current references under use current reference.  It is unclear what to type here.  If I type in erroneous text, it seems to let me insert it, and it chooses the first reference [ users 1].  It does not check to see if text corresponds to existing reference.
Need directions on what to type for a existing reference, or how to choose existing reference.
I suspect this may be related to an existing bug, but if so I can't figure out how to find it.

Looking at the very bottom change on http://en.wikipedia.org/w/index.php?title=User:SLBohrman&diff=next&oldid=562259398, we see the first in a series of edits where editing elsewhere adds duplicated characters to a template that I don't believe is being edited directly. (Further duplication occurred in these edits to the same page: http://en.wikipedia.org/w/index.php?title=User:SLBohrman&diff=next&oldid=562359846, http://en.wikipedia.org/w/index.php?title=User:SLBohrman&diff=next&oldid=562363670, http://en.wikipedia.org/w/index.php?title=User:SLBohrman&diff=next&oldid=562363840)

--------------------------
**Version**: unspecified
**Severity**: major
I *believe* that this is now fixed - marking as such. Please re-open if you find it happening again.
Guillaume: This is a Parsoid bug (which I was able to reproduce). This current bug seems like a generic placeholder bug. I created bug 53429 in parsoid so we can identify more specifically what went wrong. You can add yourself to that bug if you wish.
In this edit, a table was duplicated (but it wasn't in a template):

https://fr.wikipedia.org/w/index.php?&diff=96159772

Is it the same issue or should I open a separate bug report?
Can someone check and see if https://bugzilla.wikimedia.org/show_bug.cgi?id=52618 should better be marked as a duplicate of this? Thanks!
(In reply to comment #3)
> en.wp user reports that adding a single hyphen to a page trigged this bug to
> remove part of an infbox and duplicate other templates in the middle of a
> category.
> 
> https://en.wikipedia.org/w/index.
> php?title=IBM_Personal_Computer&diff=567356453&oldid=566275349

The table at the end was not closed. I [https://en.wikipedia.org/w/index.php?title=IBM_Personal_Computer&diff=567437920&oldid=567357722 fixed it (for consistency's sake, I used the s-end template)] and VE edits and saves should not introduce dupes on this.
I think this diff from fr.wp is another example?
https://fr.wikipedia.org/w/index.php?title=Gen%C3%A8ve&diff=95604102&oldid=95601955
en.wp user reports that adding a single hyphen to a page trigged this bug to remove part of an infbox and duplicate other templates in the middle of a category.

https://en.wikipedia.org/w/index.php?title=IBM_Personal_Computer&diff=567356453&oldid=566275349
This looks like the same issue, yes.
Could this bug be responsible for these edits where one templates was duplicated and the other apparently duplicated and substed in the middle of a category link?

https://en.wikipedia.org/w/index.php?title=Ford_Figo&diff=566719977&oldid=566176664
https://en.wikipedia.org/w/index.php?title=Ford_Figo&diff=next&oldid=566719977
Screenshot of list indent problem

If I add indent to any list item, it breaks. 

The indented line gets moved to the end of the previous line.

The live-changes looks as it is working properly, but the edit-diff (preview your changes) always shows it as broken. (See attachment)

Confirmed with:
* Firefox and Chrome,
* with ordered and un-ordered list items, 
* with items added to the middle of a list, and to the end of a list,
* and with both new items added to a list, and existing items given increased indent.

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F11420}
Change 71395 merged by jenkins-bot:
Bug 50483: Make sure nested list serialization is newline-insensitive

https://gerrit.wikimedia.org/r/71395
Change 71395 had a related patch set uploaded by GWicke:
Bug 50483: Make sure nested list serialization is newline-insensitive

https://gerrit.wikimedia.org/r/71395
This is not a new bug.  This has been around for a long time.  I went back to commits almost 3 months back and tested.
Looks like Parsoid serializer is newline sensitive in this case:

$ echo '<ol><li>Foo\n<ol><li>Bar</li></ol></li></ol>' | node parse.js --html2wt
#Foo
##Bar
$ echo '<ol><li>Foo<ol><li>Bar</li></ol></li></ol>' | node js/tests/parse.js  --html2wt 
#Foo##Bar
I'm guessing that VE emits the wrong HTML here, so reassigning to VE. Please move to Parsoid again if the VE HTML is sane.
Also:
echo '<ol><li>foo</li><li>bar</li></ol>' | node parse --html2wt
#foo
#bar
Cannot reproduce:

echo -e '#foo\n#bar' | node parse --wt2wt
#foo
#bar

Can you provide the HTML the VE sends?
This appears to be a (new?) bug in Parsoid - 

# Foo
# Bar

-> 

# Foo## Bar

rather than

# Foo
## Bar

Unless we're breaking something in VisualEditor somehow?
As per http://www.mediawiki.org/wiki/Help_talk:VisualEditor/User_guide#Discoverability .
Might be handy, since we're pretty much beginners with it.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This has been done and will go out later today.
Change 71376 merged by jenkins-bot:
Add user guide link to beta icon drop down

https://gerrit.wikimedia.org/r/71376
Change 71376 had a related patch set uploaded by Jforrester:
Add user guide link to beta icon drop down

https://gerrit.wikimedia.org/r/71376
That sounds good. The link should probably be something like [[mw:Special:MyLanguage/Help:VisualEditor/User guide]] and live in a MediaWiki: interface message, so that wikis can customize it to link to a local page.

My feeling is that the link to the user guide should persist even after we're out of the beta, but we can discuss this then.
Possibly add the help icon to the "beta" label, and have it as an option in the menu?
[Forked from the more general 50350.]

Currently when AbuseFilter blocks an edit made with VE, the only response we can display is:

| The modification you tried to make was aborted by an extension hook

When bug 32216 is done - AbuseFilter is changed to use the APIEditBeforeSave hook - we can display this significantly more nicely.

--------------------------
**Version**: unspecified
**Severity**: major
Then I suspect the problem is an extension of bug 50058, which will be fixed in time. If so, it's probably not worth prioritising as a new bug (or reopening this one) since abusefilter triggerers are likely to be new users, ergo on vector.
**kwwilliams** wrote:

Of course I use Monobook, Oliver.
Are you, by any chance, on monobook?
**kwwilliams** wrote:

Tested this, now that it is deployed, and have to say that while it the change came close to being a solution, it isn't quite there. The edit-filter notice produced when using the standard editor is large, easy to read, and quite clear. The edit-filter noticed produced when using VE is tiny, uses an infinitesimal font, and is extremely difficult to read.
enhancement->major, as this is an integration bug.
*** Bug 50727 has been marked as a duplicate of this bug. ***
Warnings will now show (once we deploy).
Change 74102 merged by jenkins-bot:
mw.ViewPageTarget: Show AbuseFilter warning in save dialog

https://gerrit.wikimedia.org/r/74102
Change 74102 had a related patch set uploaded by Krinkle:
mw.ViewPageTarget: Show AbuseFilter warning in save dialog

https://gerrit.wikimedia.org/r/74102
Marked as blocked by 51403 in AbuseFilter.
Change 73877 merged by jenkins-bot:
mw.ViewPageTarget: Surface error messages from core edit api

https://gerrit.wikimedia.org/r/73877
**kwwilliams** wrote:

Just in case it's important to the fix, the message returned by the abuse filter is free format and generally contains templates and other markup.
(In reply to comment #8)
> Change 73877 had a related patch set uploaded by Krinkle:
> mw.ViewPageTarget: Surface error messages from core edit api
> 
> https://gerrit.wikimedia.org/r/73877

This is not yet sufficient since we should be surfacing the
warning associated with the filter (or the abusefilter-warning
message by default). The most significant part we're missing
right now is:
* Localization
* The fact that (at least for some filters) they can submit
  the edit by just trying again.

This is currently blocked by the AbuseFilter not sending the parsed version of the triggered warning through the API (see http://cl.ly/image/1E2r1J2U3K0v, I'm getting raw wikitext instead of HTML).

And perhaps (though less important) we could also use a boolean property to distinguish between filters that are warnings that can be bypassed by trying again and filters which prevent the user from saving.
Change 73877 had a related patch set uploaded by Krinkle:
mw.ViewPageTarget: Surface error messages from core edit api

https://gerrit.wikimedia.org/r/73877
*** Bug 51139 has been marked as a duplicate of this bug. ***
(In reply to comment #5)
> Has this actually been deployed?

No.

> I just tested, and the error message has changed (it now reads "invalid
> error code", while it used to read "Error: the notification you have made
> was aborted by an extension hook").

That's almost certainly caused by the "fixing" of bug 32216, which changes what we need to integrate with.
**kwwilliams** wrote:

Has this actually been deployed? I just tested, and the error message has changed (it now reads "invalid error code", while it used to read "Error: the notification you have made was aborted by an extension hook"). If that was the fix, I think it's pretty obvious that it's incomplete, as it still isn't displaying the warning from the edit filter.
*** Bug 50828 has been marked as a duplicate of this bug. ***
(In reply to comment #2)
> I strongly, strongly object to the categorization of this as an
> "enhancement".

"Enhancement" does not mean "not going to be done soon"; it merely means that this is not a feature that's meant to be currently working, but instead, a feature we'd like to add.

This feature in particular is on our immediate work list, and hopefully will be done in the next week or so.
**kwwilliams** wrote:

I strongly, strongly object to the categorization of this as an "enhancement". This is a basic feature that needs to be addressed. There aren't many edit filters that block edits, but when an editor trips one of the ones that does, its important that he have an idea as to what to fix. There's no place for an editor to even begin looking to find out what is happening and what it is about his edit that is causing it to fail. It's not really even obvious from the message that it's a content issue.
*** Bug 50719 has been marked as a duplicate of this bug. ***
Screenshot

See screenshot. Firefox 21.0, Windows XP. As well as misplacing the toolbar it's also hiding the 'create new source' on articles with lots of sources.

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

**Attached**: {F11391}
Roan fixed this in his mega-CSS-rewrite.
*** Bug 50455 has been marked as a duplicate of this bug. ***
Renamed (aka, I hate ResourceLoader's caching, some times :-().
The formatting icons of the VisualEditor toolbar are currently "B" for bold, "I" for italics, the chain for links and the remove icon to clear formatting.

This series of icon seems to indicate that links are a kind of formatting. However; "Clear formatting" doesn't affect links; it only removes bold and italics.

Either links *are* a kind of formatting, and the "Clear formatting" action should remove them, or they aren't, and the Link icon shouldn't stand in the middle of icons that add and clear formatting. The current order and behavior are confusing.

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed and will go out in a few minutes.
Change 73896 merged by jenkins-bot:
Compare annotations by name only when clearing/toggling

https://gerrit.wikimedia.org/r/73896
Change 73896 had a related patch set uploaded by Esanders:
Compare annotations by name only when clearing/toggling

https://gerrit.wikimedia.org/r/73896
*** Bug 51018 has been marked as a duplicate of this bug. ***
This is a regression; it used to work fine - relabelling as such.
It is currently not possible to add a reference to an image/media caption, nor to edit existing ones.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52427
https://bugzilla.wikimedia.org/show_bug.cgi?id=49657
*** Bug 54949 has been marked as a duplicate of this bug. ***
This was completed as part of the NewFromDocumentReplace work that Roan did last week.
Changing this to reflect that now references do appear in the toolbar for media items, but can't be inserted or edited (and the list of existing references to insert is blank - suggests something's pointed at the wrong document/etc.?).
bug 51992 comment 0 :
http://en.wikipedia.org/wiki/User:Kww/fileref is about as simple of a testcase
as I could develop. Given this structure:

[[File:Red Wine Glass.jpg|thumb|upright|A "large" (250&nbsp;ml) glass of
12%&nbsp;ABV red wine has about three units of alcohol. A "medium"
(175&nbsp;ml) glass, such as the one shown, has about two units.<ref> Even
though the sizes of wine glasses are defined in UK law, the terms "large",
"medium", "standard" etc are not defined in law.</ref>]]


There's no way to edit the reference.

----------------
bug 51992 comment 1 :
Simpler illustration, still in http://en.wikipedia.org/wiki/User:Kww/fileref

I don't think it's possible to edit that pesky footnote.
[[File:Red Wine Glass.jpg|thumb|upright|description<ref>pesky footnote</ref>]]

{{reflist}}
*** Bug 51992 has been marked as a duplicate of this bug. ***
This was resolved with the new citation system released last month.
*** Bug 51184 has been marked as a duplicate of this bug. ***
(In reply to comment #8)
> The "what do you want to reference?" field, which exists solely to filter
> through existing references, still displays if there are zero existing
> references.

This sounds like bug 51848
At en.wp user:Risker reports on feedback she received running an editathon. Relevant to this bug is:

To a person, they all said that VE was *more* difficult to use than wikitext, especially with respect to references. Now, they had all had reinforced to them the importance of referencing factual information, so they were all trying to include references. They pointed out that at least with the wikitext editor, they could pull up templates that were complete and they didn't have to try to figure out the parameters. They were using mostly printed sources, not websites, so there was no URL to use as a quick-and-dirty reference insertion.
Change 74191 merged by jenkins-bot:
Reference dialog commingling

https://gerrit.wikimedia.org/r/74191
Change 74191 had a related patch set uploaded by Jforrester:
Reference dialog commingling

https://gerrit.wikimedia.org/r/74191
The "what do you want to reference?" field, which exists solely to filter through existing references, still displays if there are zero existing references.
Yes, I think the "wiki-specific workflows" is key.  On wikis (including English Wikipedia) that use:

<ref>{{some template|firstparam=a}}</ref>

with a few key some templates, it's worth allowing a simplified flow for those (while still providing the full flexibility of arbitrary references and arbitrary templates where needed).

Within a template, it's also verbose due to the screen layout.  E.g. I would consider keeping parameter name and value on the same screen (for named parameters), and making it easy to add the next parameter without going up to the root.  The latter can be done without the former.

I'd recommend trying ProveIt (https://en.wikipedia.org/wiki/User:ProveIt_GT) on English Wikipedia if you haven't.  I don't expect you to take the same approach we did (and don't look at the "parser").  The reference browsing part also probably doesn't apply, but the add mode in particular shows how the GUI can be streamlined when it doesn't attempt to be fully general.
Please don't roll this out to everyone until this is fixed, as until it is there is going to be a lot of cleanup work needed. I agree with those above who say this might mean less references. I quickly disabled it the first time I tried to create a new citation.
**gwaw_2003** wrote:

I'd have to agree with PamD above. If anything, just steal the RefToolbar code, and make it work with VE as a temporary fix for enwp. This cannot be rolled out to new editors the way it is, or we'll have a ton of "well I hated how the references worked so I stopped trying to use them at all" edits from new editors.
Thanks for these comments; obviously the references system is a work in progress and we had already planned to undertake (at least most of) these improvements, but we hadn't had the time to write it down in bugzilla - will use this to track those improvements now.
Please look at how RefToolbar behaves (I choose whether my ref is a website, book, etc; I get offered a set of useful boxes into which to input the data; I click on "Preview citation" to see that it looks OK; I click on "Add citation". Job done.), and give this sort of useful guidance to editors adding references in VE.
Screenshot3

**Attached**: {F11366}
Screenshot2

**Attached**: {F11365}
When adding a new link to an existing page, the text is automatically capitalized, even if the user entered the text in lowercase. Many links don't need to be capitalized, so users shouldn't have to clean up after VisualEditor decides to capitalize them.

Note that when you're adding a new link to a page that doesn't exist, the inserted link preserves the capitalization that was entered by the user (which is the expected behavior)

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50945
https://bugzilla.wikimedia.org/show_bug.cgi?id=50678
https://bugzilla.wikimedia.org/show_bug.cgi?id=50745
https://bugzilla.wikimedia.org/show_bug.cgi?id=53566
The above changes behaviour if the user types in the entire anchor in a different case (e.g. iPhone vs. IPhone), which is I think sufficient to close this bug for now; different ways of suggesting links might want to come off the outcome of bug 53566. (It will be deployed to the cluster from Thursday 5 September, and to Wikipedias on Thursday 12 September).
Change 82054 merged by jenkins-bot:
Offer the typed text as a link suggestion if the page is valid

https://gerrit.wikimedia.org/r/82054
Change 82054 had a related patch set uploaded by Esanders:
Offer the typed text as a link suggestion if the page is valid

https://gerrit.wikimedia.org/r/82054
(In reply to comment #9)
> I think creating a bug for
> MediaWiki having page-level meta-data about the correct display of a page's
> title would be great, yes.

Done, see bug 53566
(In reply to comment #8)
> Until that happens I think we should preserve the case of the input, as even
> if that isn't what people want it is easily possible to change and pretty
> intuitive how to do it - ie, type "foo" get "[[foo]]" but wanted "[[Foo]]",
> all you need to do is type "Foo" instead. The current behaviour means you get
> "[[Foo]]" regardless of what you want or do.

Possible, but a bit messy when writing certain articles like BLPs where most link targets will be proper nouns.

> The only other thing I can think of is for VE to read and respect things like
> {{lowercase title}}. Once it does that then it should also respect things
> like {{correct title}} for a default display text, and we should probably
> create a {{Proper noun title}} for titles that should always be capitalised by
> default.
>
> Or rather than using templates we could move the title information into page
> metadata. I have no idea whether any of this is practical, but if it is I
> guess it would be better as one or maybe two separate bugs.

Yes, certainly for this to be used in VisualEditor it would need to be a proper feature and not one hacked into a template; I think creating a bug for MediaWiki having page-level meta-data about the correct display of a page's title would be great, yes.
The best thing, as noted at 48789, is for there to be two input boxes - one for the link target and one for the displayed text. 
Until that happens I think we should preserve the case of the input, as even if that isn't what people want it is easily possible to change and pretty intuitive how to do it - ie, type "foo" get "[[foo]]" but wanted "[[Foo]]", all you need to do is type "Foo" instead. The current behaviour means you get "[[Foo]]" regardless of what you want or do.

When the second input box is added then we should use the case as input as the default. 

The only other thing I can think of is for VE to read and respect things like {{lowercase title}}. Once it does that then it should also respect things like {{correct title}} for a default display text, and we should probably create a {{Proper noun title}} for titles that should always be capitalised by default. Or rather than using templates we could move the title information into page metadata. I have no idea whether any of this is practical, but if it is I guess it would be better as one or maybe two separate bugs.
Clarifying what this is in the title:

| New link annotations' anchors get their first character capitalised, even if you didn't want that

->

| When inserting a new link (not annotating on existing text), the suggested link is capitalised even if your input text isn't, so leading to unexpected capitalisation of link anchors

The problem is in the link suggester (it's the same behaviour in category and template selection, except that those always capitalise the first character so no-one cares.

When you trigger the link inspector on no selection and type in "foo", you are given suggestions like:

* Foo
* Foobar
* Fooian

Selecting any of these picks not just the target, but also the text of that target as the anchor (good) and the capitalisation of that target (less good).

However, if I've typed "foo", did I definitely want [[foo]] rather than [[Foo]]? Should we show both [[Foo]] and [[foo]] options in the list if you type in "foo", but only [[Foo]] if you type in "Foo"?
From bug 53495:
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)
*** Bug 53495 has been marked as a duplicate of this bug. ***
(In reply to comment #3)
> Are you talking about:
> 1. Ctrl+K
> 2. Type a lcase work
> 3. Press enter twice

Yes. For step 3, it also happens when you click on a suggestion.
Are you talking about:
1. Ctrl+K
2. Type a lcase work
3. Press enter twice

because that's the only way I can reproduce, and after the first press of enter it shows you that it has capitalised the word due to autocomplete?
Yes, I can still reproduce it. Note that I'm talking about the behavior when you enter Ctrl+K and type text, not the behavior when you add a link to existing text.
Is this still happening, Guillaume? I can't reproduce it.
If the cursor is in a slug and you press the link button, the selection jumps to the nearest content - which crosses out of the local <p> and into the <p> beforehand or afterwards (whoops).

Link inspector should detect that it is in a slug and not attempt to mangle the selection with nearestContentOffset, but just trigger with a 'blank' selection.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52256
This was fixed by gerrit 81437.
As a follow-up, if you have <start of document> <block slug> <block slug> <block slug> <block slug> <p> in a document, and have the cursor in the second slug, pressing Ctrl+K will move the selection to the top of the document and put the contents there (whee); in the third or fourth, to the first word of the <p>. Not great.
If you have a page like:

<ref name="foo">Foo</ref> ...... <ref name="foo">Foo</ref>

VE will normalize this to:

<ref name="foo">Foo</ref> ...... <ref name="foo" />

The contents of the second <ref> tag are obviously ignored, but we should round-trip their existence correctly.


http://tools.wmflabs.org/visualeditor/dirtydiffs/2013-06-30_00-52/Genetic_history_of_the_Iberian_Peninsula.png

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed in gerrit 71275 by Roan.
After having saved a template on a page, and edit it again, template data for the template is visible, but any parameter used is not showing templatedata, even though it displayed it correctly when I created the template

test I made on beta was {{test|name = hello}}

--------------------------
**Version**: unspecified
**Severity**: normal
Think we have subsequently fixed this, probably as part of the re-write of the transclusion dialog/TemplateData link in July; marking as such. Please re-open if it recurs.
Can't reproduce this bug.
When I make a new template entry and open the template before I've saved the page, it looks like following:
http://i.imgur.com/HxaU7F1.png

But after having saved the page, and enter template edit again, I'm getting following:
http://i.imgur.com/VPROUwb.png
(In reply to comment #0)
> After having saved a template on a page

By a template, you mean a template transclusion or the template itself?


> and edit it again, template data for
> the template is visible, but any parameter used is not showing templatedata,

So when you edit the tranclusion with VisualEditor template data for the template is visible but not for the parameters? What does that mean?

You say it is visible for the template but not for the parameters. So what is visible then?

> even though it displayed it correctly when I created the template

Displayed what?
After I added the <templatedata> to [[pt:Template:Referências]], I opened a page in which it is used, setting "uselang=pt" and "uselang=pt-br" in the URL:
1) https://pt.wikipedia.org/wiki/Arte?veaction=edit&uselang=pt
2) https://pt.wikipedia.org/wiki/Arte?veaction=edit&uselang=pt-br
In the first case, when I opened the Transclusion dialog (by clicking in the references section, where the template is used) the template description was shown (as expected). Typing one of the template parameters, I also get its label normally.

On the other hand, for the second link the user language (pt-br) was different from the content language (pt) and the user see no description and no labels.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50888
Change 87724 merged by jenkins-bot:
Implement getInterfaceTextInLanguage and use API and Parser

https://gerrit.wikimedia.org/r/87724
Change 87724 had a related patch set uploaded by Krinkle:
Implement getIntefaceTextInLanguage and use API and Parser

https://gerrit.wikimedia.org/r/87724
(In reply to comment #14)
> Oh. I assumed the jQuery.i18n (or one of the other JS, MW-independent tools
> that the Language Engineering team have built) would have this built in. Is
> that not the case?

I can't say there isn't one but I've never heard of this.

BTW I also want a similar one on server side.
(In reply to comment #17)
> Also, this way we can provide good values for languages that don't exactly
> fallback but use a language converter. Which is also something that could
> potentially be done client side, but I don't see that happening just yet.

Which isn't really doable currently I guess; or it requires delivery of huge conversion tables (for Chinese).
Also, this way we can provide good values for languages that don't exactly fallback but use a language converter. Which is also something that could potentially be done client side, but I don't see that happening just yet.
For now this is up to the client side to handle, which realistically means it won't be handled (current language > en > nothing).


For the future I intend to have the templatedata API take a parameter for language code and resolve it on the server side. For three reasons:

* On wikis where there is more than 1 language commonly used (which is the whole point of this bug and where it is relevant, since if there is only 1 language, the wiki author can just specify { "description": "Text." } without lang-codes)..., on those wikis there will be more than 1 language defined. This will result in a large blob of JSON being transferred to e.g. VisualEditor for each template which is quite a lot of data.

* Even so, it would then still require the client-side to have knowledge of all of this and process it. Which involves a lot of language data being send to the client, a lot of translations being sent to the client, and the then client having to do all the computation for it. We can solve this the same way we solved it in ResourceLoader; We'll still cache it, but fragment it by language code based on request context.
(In reply to comment #8)
> (In reply to comment #6)
> > So I'm not too Wikidata-savvy, but it seems this patch might be useful (if
> > it's
> > not, ignore me and carry on):
> > 
> > https://gerrit.wikimedia.org/r/72867
> > 
> > Right now there is no way to determine the real language of a message from
> > the
> > CDB cache. That patch changes this.
> 
> Not really. Labels and descriptions in TemplateData are stored in some JSON
> blob in a customized format, rather than normal messages.

Gotcha. Carry on. Sorry I couldn't help.
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > (In reply to comment #9)
> > > > I don't think that's a good outcome. If there isn't a description in your
> > > > language (in this case, pt), we shouldn't magically tell you that we've given
> > > > you a message in a different language (we don't do this for the MW messages
> > > > framework, for instance).
> > > 
> > > BTW this comment means WONTFIXing this whole bug.
> > 
> > Why?
> > 
> > This is just me saying that I don't think that instead of "Chien", if it
> > doesn't exist in French we should give users "Dog -- OMG We gave you this
> > message in English even though you asked for it in French!", which feels
> > significant over-kill.
> 
> Then I guess your point is that pt-br and pt are more similar, so falling
> back from pt to pt-br is acceptable, while fr and en are not this case.

Yes.

> However technically pt-br and pt have the same relationship as fr and en,
> or we'll have to compose some language similarity table ourselves, and manage
> to resolve many edge cases (eg. dialects).

Oh. I assumed the jQuery.i18n (or one of the other JS, MW-independent tools that the Language Engineering team have built) would have this built in. Is that not the case?
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #9)
> > > I don't think that's a good outcome. If there isn't a description in your
> > > language (in this case, pt), we shouldn't magically tell you that we've given
> > > you a message in a different language (we don't do this for the MW messages
> > > framework, for instance).
> > 
> > BTW this comment means WONTFIXing this whole bug.
> 
> Why?
> 
> This is just me saying that I don't think that instead of "Chien", if it
> doesn't exist in French we should give users "Dog -- OMG We gave you this
> message in English even though you asked for it in French!", which feels
> significant over-kill.

Then I guess your point is that pt-br and pt are more similar, so falling back from pt to pt-br is acceptable, while fr and en are not this case. However technically pt-br and pt have the same relationship as fr and en, or we'll have to compose some language similarity table ourselves, and manage to resolve many edge cases (eg. dialects).
(In reply to comment #11)
> (In reply to comment #9)
> > I don't think that's a good outcome. If there isn't a description in your
> > language (in this case, pt), we shouldn't magically tell you that we've given
> > you a message in a different language (we don't do this for the MW messages
> > framework, for instance).
> 
> BTW this comment means WONTFIXing this whole bug.

Why?

This is just me saying that I don't think that instead of "Chien", if it doesn't exist in French we should give users "Dog -- OMG We gave you this message in English even though you asked for it in French!", which feels significant over-kill.
(In reply to comment #9)
> I don't think that's a good outcome. If there isn't a description in your
> language (in this case, pt), we shouldn't magically tell you that we've given
> you a message in a different language (we don't do this for the MW messages
> framework, for instance).

BTW this comment means WONTFIXing this whole bug.
(In reply to comment #9)
> (In reply to comment #7)
> > (In reply to comment #5)
> > > Fine technically - I think users would be upset and confused.
> > 
> > So you'll need to prepare for some interface design to tell users that "Some
> > text written in English" and "Some other text written in Spanish" lines are
> > not in pt.
> 
> Why couldn't the TemplateData just be written in the users's language?

You can't expect all templatedata blocks to have labels in all hundreds of languages which MediaWiki supports.

> > And the format of JSON needs to be modified to include this info.
> 
> I don't think that's a good outcome. If there isn't a description in your
> language (in this case, pt), we shouldn't magically tell you that we've given
> you a message in a different language (we don't do this for the MW messages
> framework, for instance).

We do so in Wikibase, if the user indicates that they can read another language -- in our implementation it checks {{#babel: }} currently but some global preferences here will be nice of course.
(In reply to comment #7)
> (In reply to comment #5)
> > Fine technically - I think users would be upset and confused.
> 
> So you'll need to prepare for some interface design to tell users that "Some
> text written in English" and "Some other text written in Spanish" lines are
> not in pt.

Why couldn't the TemplateData just be written in the users's language?

> And the format of JSON needs to be modified to include this info.

I don't think that's a good outcome. If there isn't a description in your language (in this case, pt), we shouldn't magically tell you that we've given you a message in a different language (we don't do this for the MW messages framework, for instance).
(In reply to comment #6)
> So I'm not too Wikidata-savvy, but it seems this patch might be useful (if
> it's
> not, ignore me and carry on):
> 
> https://gerrit.wikimedia.org/r/72867
> 
> Right now there is no way to determine the real language of a message from
> the
> CDB cache. That patch changes this.

Not really. Labels and descriptions in TemplateData are stored in some JSON blob in a customized format, rather than normal messages.
(In reply to comment #5)
> Fine technically - I think users would be upset and confused.

So you'll need to prepare for some interface design to tell users that "Some text written in English" and "Some other text written in Spanish" lines are not in pt.

And the format of JSON needs to be modified to include this info. Like:

{
    "pages": {
        "1467239": {
            "title": "Predefini\u00e7\u00e3o:Refer\u00eancias",
            "description": {
                "pt": { "value": "Some text written in English", "language": "en" }
            },
            "params": {
                "t\u00edtulo": {
                    "label": {
                        "pt": { "value": "Some other text written in Spanish", "language": "es" }
                    },
                    ...
            }
            ...
     }
}
So I'm not too Wikidata-savvy, but it seems this patch might be useful (if it's not, ignore me and carry on):

https://gerrit.wikimedia.org/r/72867

Right now there is no way to determine the real language of a message from the CDB cache. That patch changes this.
(In reply to comment #4)
> (In reply to comment #2)
> > API call should ideally specify the fall-back language chain and return just
> > one set for clients (so the weight is on the server).
> 
> Do we care about the real language info of a label.

We don't, but users on multi-lingual wikis will if we send them 1 MiB of descriptions of a template when they only care about 2 KiB worth of the contents. :-)

> That is, is this fine?
> 
> {
>     "pages": {
>         "1467239": {
>             "title": "Predefini\u00e7\u00e3o:Refer\u00eancias",
>             "description": {
>                 "pt": "Some text written in English"
>             },
>             "params": {
>                 "t\u00edtulo": {
>                     "label": {
>                         "pt": "Some other text written in Spanish"
>                     },
>                     ...
>             }
>             ...
>      }
> }

Fine technically - I think users would be upset and confused.
(In reply to comment #2)
> API call should ideally specify the fall-back language chain and return just
> one set for clients (so the weight is on the server).

Do we care about the real language info of a label.

That is, is this fine?

{
    "pages": {
        "1467239": {
            "title": "Predefini\u00e7\u00e3o:Refer\u00eancias",
            "description": {
                "pt": "Some text written in English"
            },
            "params": {
                "t\u00edtulo": {
                    "label": {
                        "pt": "Some other text written in Spanish"
                    },
                    ...
            }
            ...
     }
}
Falling back to (LanguageConverter)-converted labels is needed too.

It seems my LanguageFallbackChain and related classes (currently in Wikibase) is useful here again.
API call should ideally specify the fall-back language chain and return just one set for clients (so the weight is on the server).
For the record, the data returned by the API has all the information, but it is in the "pt" properties:
https://pt.wikipedia.org/w/api.php?format=jsonfm&action=templatedata&titles=Predefini%C3%A7%C3%A3o%3Arefer%C3%AAncias
E.g.:
{
    "pages": {
        "1467239": {
            "title": "Predefini\u00e7\u00e3o:Refer\u00eancias",
            "description": {
                "pt": "Produz o t\u00edtulo da se\u00e7\u00e3o de refer\u00eancias e impede que seja edit\u00e1vel"
            },
            "params": {
                "t\u00edtulo": {
                    "label": {
                        "pt": "T\u00edtulo da se\u00e7\u00e3o"
                    },
                    ...
            }
            ...
     }
}
VE is missing the red "semi-protected page" box seen at
http://en.wikipedia.org/w/index.php?title=Muscle&action=edit and probably also the equivalent one for administrators on fully protected pages.

They should be displayed as a "notice".

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51215
This is now fixed in master and we will push to production very soon. Sorry for the inconvenience.
Change 73022 merged by jenkins-bot:
Add protected & semiprotected notices to api.

https://gerrit.wikimedia.org/r/73022
Change 73022 had a related patch set uploaded by Robmoen:
Add protected & semiprotected notices to api.

https://gerrit.wikimedia.org/r/73022
(In reply to comment #3)
> The edit box of a protected page also uses a pick background.  That is
> missing
> from VE.

No, this is enwiki's local CSS: [[MediaWiki:Group-sysop.css]] needs to be updated. I will file an edit request.
The edit box of a protected page also uses a pick background.  That is missing from VE.
This also applies to things like BLP warnings, mind; non-page-specific warnings generally seem to get cut off.
In sequencing, this should probably be above everything except the not-applicable anon warning (so anon warning > protected > editing old > page notices). Maybe we need a more formal ordering?
Possibly related to Bug 49892, VE is inserting random <span> parameters.  

See:
https://en.wikipedia.org/w/index.php?title=Ruger_P_series&diff=next&oldid=560801075

--------------------------
**Version**: unspecified
**Severity**: normal
That diff is from before we deployed the fix in 49892.  And, the oldid html is probably coming from the cache.  So, once cache is purged, this should go away.  Closing this.  Please reopen if still an issue.
I can reproduce this against current production VisualEditor/Parsoid on that oldid but not the current id. I'm presuming that this is a Parsoid bug, but not sure of the severity.
On a CAPTCHA-triggering edit, VE does not display the CAPTCHA, instead showing an alert:

Error saving data to server: Failed request: error.

Marking critical, because VE is in use by 50% of new users at enwiki, none of whom are now able to add external links for sourcing purposes.

--------------------------
**Version**: unspecified
**Severity**: critical
[[mw:Thread:Extension talk:VisualEditor/VE and ConfirmEdit]]
This is now fixed in master and will be deployed on Monday.
Change 71160 merged by jenkins-bot:
mw: Implement support for ConfirmEdit and FancyCaptcha

https://gerrit.wikimedia.org/r/71160
Change 71160 had a related patch set uploaded by Krinkle:
mw: Implement support for ConfirmEdit and FancyCaptcha

https://gerrit.wikimedia.org/r/71160
Right now the handling of any error results the following alert:

> Error saving data to server: Failed request: {api.result}.

The only variable we use is the result code, not the error code. And though the error code varies (badtoken, hookabort, needcaptcha) the result is always "error".

Fortunately (at least) the ConfirmEdit extension, and specifically the FancyCaptcha variant (which Wikimedia uses) does provide an API and exposes the following through the EditPage/ApiEdit/ApiVisualEditor result:

{
    "visualeditor": {
        "result": "error",
        "edit": {
            "captcha": {
                "type": "image",
                "mime": "image/png",
                "id": "626590462",
                "url": "//alpha.wikipedia.krinkle.dev/w/index.php?title=Special:Captcha/image&wpCaptchaId=fa4e388ad7"
            },
            "result": "Failure"
        }
    }
}

So it looks like we can use this to build the UI for it.
This depends on MediaWiki making the CAPTCHAs available through an API, which I believe is currently not done. Timo to comment.
(In reply to comment #0)
> Error saving data to server: Failed request: error.

The same error is also seen when triggering the spam blacklist.
When attempting an edit that is disallowed by AbuseFilter, you get a browser alert:

Error saving data to server: Unsuccessful request: The modification you tried to make was aborted by an extension hook.

Instead, VE should show a less cryptic message specific to AbuseFilter.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This has now been done and will go out today.
Change 71293 merged by jenkins-bot:
mw.ViewPageTarget: Show save errors in save dialog instead of alert

https://gerrit.wikimedia.org/r/71293
Given that AbuseFilter (but not others) depend on bug 32216, I'm moving that part to a new bug, bug 50472; the rest of this bug will be done today.
AbuseFilter, wgSpamRegex (core), TitleBlacklist, SpamBlacklist, ..
Change 71293 had a related patch set uploaded by Krinkle:
(DRAFT) mw.ViewPageTarget: Show unrecoverable/unknown save errors in dialog instead of alert

https://gerrit.wikimedia.org/r/71293
VE's behaviour is not as expected when I invoke my own IME for entering Kannada text. If I press Enter after typing some text, it creates a blank line above the current line rather than below the line. Some conjuncts also get dissociated and show sthe constituent Unicode character instead of the conjuncts. I am using Windows 8 and Firefox (ver 21). I tried using the built-in IME as well as Baraa IME. in both cases I could not use the VE for typing in Kannada.

--------------------------
**Version**: unspecified
**Severity**: critical
Given that this is now merged, I'm going to mark this as fixed. However, this is provisional - please re-open if you think that this has not worked!
Change 80080 merged by jenkins-bot:
Don't emit Surface changes back to the Surface

https://gerrit.wikimedia.org/r/80080
Change 80080 had a related patch set uploaded by Jforrester:
WIP:Don't emit Surface changes back to the Surface

https://gerrit.wikimedia.org/r/80080
Hi, thanks for your help.

I think the issue may be resolved by the following patch: https://gerrit.wikimedia.org/r/#/c/79451 . Or at least, the problems may be different now. I'm not sure it's working correctly with the "Kannada inscript (m17n)" ibus input method on Ubuntu+firefox, but it would be good for a Kannada reader to verify this!
VE Kannada screen shot after pressing spacebar

**Attached**: {F11104}
VE Kannada screen shot before pressing spacebar

**Attached**: {F11103}
(In reply to comment #5)
> I am not sure if the VE has been improved. But now I am able to type in
> Kannada
> if I use the Windows built-in IME as well as the Indic IME2 developed by
> Microsoft-India. But the Baraha IME is still giving problems. I am waiting
> for
> the ULS to be enabled in VE.

This was somewhat prematured comment. When I thoroughly tested I found some bugs in built-in IME as well as Indian IME2 also. It does render properly initially, but when I press space bar, the display gets spoiled. I will add the screeenshots.
I am not sure if the VE has been improved. But now I am able to type in Kannada if I use the Windows built-in IME as well as the Indic IME2 developed by Microsoft-India. But the Baraha IME is still giving problems. I am waiting for the ULS to be enabled in VE.
I treid the built-in IME of Windows 8 as well as a thrid party IME called Baraha.
Thanks for taking the time to report this and testing VE!
What are the exact steps to reproduce this?

I tried:
1. Make sure to be logged in on http://kn.wikipedia.org/
2. Make sure that on http://kn.wikipedia.org/wiki/%E0%B2%B5%E0%B2%BF%E0%B2%B6%E0%B3%87%E0%B2%B7:Preferences?uselang=en#mw-prefsection-editing > "Beta features >  Enable VisualEditor (only in the main and user namespaces)" is enabled.
3. Go to a random article like http://kn.wikipedia.org/wiki/ಔಷಧೀಯ_ರಸಾಯನಶಾಸ್ತ್ರ?veaction=edit
4. I can confirm that keyboard cursor in on top of text, but I can type (Firefox 18).

5. Click the cog next to "ಇತರ ಭಾಷೆಗಳು" (In other languages) and choose "Input settings".
6. "Input methods for ಕನ್ನಡ" says "Use native keyboard".

So here I have several options.

Could you confirm/correct the above steps, and explain which "built-in IME" you exactly tried?
VE screenshot just after pressing Enter key

**Attached**: {F11102}
VE screenshot just before pressing Enter key

**Attached**: {F11101}
As Rob spotted, we should (re-)place the cursor in the block.

--------------------------
**Version**: unspecified
**Severity**: normal
Merged and will be deployed shortly.
Change 71388 merged by jenkins-bot:
Restore focus to documentNode on convert

https://gerrit.wikimedia.org/r/71388
Change 71388 had a related patch set uploaded by Robmoen:
Restore focus to documentNode on convert

https://gerrit.wikimedia.org/r/71388
On a note about this at http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Cursor_disappears, I tested - I don't have the issue in Chrome (the cursor remains), but it is evidently still disappearing in Firefox. Just an FYI. :)
Example diff:

https://en.wikipedia.org/w/index.php?title=FC_Dila_Gori&curid=6581323&diff=561887535&oldid=561367008

Works in Parsoid:

echo '{{commons category}}' | node parse --wt2wt
{{commons category}}

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50120
This was fixed by the fix for bug 50120. The DOM produced by the {{commons category}} template is very similar to the persondata template.
Looks like a link element that is also encapsulated is not properly handled by VE:

<link rel="mw:WikiLink/Category" href="./Category:Commons_category_without_a_link_on_Wikidata" data-parsoid='{"stx":"simple","a":{"href":"./Category:Commons_category_without_a_link_on_Wikidata"},"sa":{"href":"Category:Commons category without a link on Wikidata"}}' about="#mwt1">
Screenshot

Screenshot - FireFox 21.0, Mac OS X 10.6.8

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

**Attached**: {F11044}
Yes, this was fixed but the deployment was temporarily rolled-back until ~ 13:40 UTC today.
Maybe it's fixed but not out yet? http://it.wikipedia.org/wiki/File:Schermata_2013-06-28_alle_15.15.44.png on it.wiki this afternoon.
*** Bug 50364 has been marked as a duplicate of this bug. ***
*** Bug 50276 has been marked as a duplicate of this bug. ***
Fixed and will be going out in the next few minutes.
Change 70786 merged by jenkins-bot:
Fix bug where the floating toolbar was on top of the save dialog

https://gerrit.wikimedia.org/r/70786
Change 70786 had a related patch set uploaded by Jforrester:
Fix bug where the floating toolbar was on top of the save dialog

https://gerrit.wikimedia.org/r/70786
The VisualEditor doesn't currently have a mechanism for inserting special characters - while a lot of them are unnecessary (`~~~~` for example), things like en and emdashes can be quite important for content.

**See Also**: {T13130}
(In reply to comment #36)
> 1: no one knows them/uses them

Well, that disscutalbe, but I tend to think the same. No one knows them, because you dont need to know them for normal sw use.

> So some ideas:
> 1: Educate the user: Add a 'more characters' link in the insert symbol
> editor,
> that detects OS of user and links to a page explaining how to access this
> panel
> on his OS.

Why to make it more difficult for users. We want them to attract to Wikipedia and we wont do do the environment as easy as possible. Our goal is not to educate them further things.
Change 90940 merged by jenkins-bot:
Insert special character tool

https://gerrit.wikimedia.org/r/90940
"Educating" the user strikes me as a sign of failure for a supposedly "easier" UI. The "harder" UI has it right there, after all.
> Just for reference: Either I didn't read all the comments well enough or nobody
> quite mentioned the fact that all modern desktop operating environments have a
> built-in a Character Map tool: Windows (with pretty full Unicode since NT 4),
> Gnome, KDE, and Mac OSX (called "Character viewer").

On Mountain Lion, it's even simpler. (Straight in the edit menu, ctrl-cmd-space).

I mentioned it, but the problem is indeed:
1: no one knows them/uses them
2: there is no trigger in HTML5/JS to open the panel

So some ideas:
1: Educate the user: Add a 'more characters' link in the insert symbol editor, that detects OS of user and links to a page explaining how to access this panel on his OS.
2: Lobby HTML5 WG to expose these panels to JS
(In reply to comment #34)
> At present, however, there is no way to enter non-keyboard characters unless
> you're much more familiar with your operating system
Well, how doest it come, there is no way? What about to load character box available for editing on some wikies in MonoBook?

> At present, however, there is no way to enter non-keyboard characters unless
> you're much more familiar with your operating system than almost any user is.
Do you have any statistic for this statment? I would say that most of the users are not familiar with that. But I should include it is my point of view.
Juan - I think that would quite definitely require actual usability lab testing. As would many of the suggestions in this bug.

At present, however, there is no way to enter non-keyboard characters unless you're much more familiar with your operating system than almost any user is. So doing nothing isn't really an option either.
(In reply to comment #32)
> (In reply to comment #31)
> > Just for reference: Either I didn't read all the comments well enough or
> > nobody quite mentioned the fact that all modern desktop operating
> > environments have a built-in a Character Map tool: Windows (with pretty
> > full Unicode since NT 4), Gnome, KDE, and Mac OSX (called "Character
> > viewer").
> 
> I said this, but everyone said it wasn't sufficient for them. :-(

Lets say it differenty. Visual Editor Team was made to remove obstacles in editing, to simplify the work of Wikipedia contributors. Even there are voices, that it is a wrong way and newbies should study wikitext WFM goes the way of its goal. To offer all human knowledge to give to everybody. Our aim here is to collect the knowledge of all people. Logically higher amount of obstacles reduces the number of Wikipedians. Our aim is not to push newbies to study wikitext, internal policies or typography. Our aim is to harvest their knoledge. Thus in the new trend we are removing obstacles. So if not as a default, what about as an option to define your own characters (this was always possible in wp)? Than we can tell newbies, look here we place &ndash; - its not present in VE default, but you can install an extension to your VE.
(In reply to comment #31)
> Just for reference: Either I didn't read all the comments well enough or
> nobody quite mentioned the fact that all modern desktop operating
> environments have a built-in a Character Map tool: Windows (with pretty
> full Unicode since NT 4), Gnome, KDE, and Mac OSX (called "Character
> viewer").

I said this, but everyone said it wasn't sufficient for them. :-(

> 2. It may be easier to insert at least some characters using the keyboard
> layout provided with ULS. It is disabled now in VE because of some bugs (can
> anybody help me with the numbers?), but these can be fixed, of course. If we
> know which characters are really needed (see point 1 above), we can very
> easily add them to the keyboard layouts.

Possibly. The main problem is that "ULS" is about twenty different tools, and some of them don't work in VisualEditor (yet). I doesn't seem possible to enable some of them and not others, however.
Just for reference: Either I didn't read all the comments well enough or nobody quite mentioned the fact that all modern desktop operating environments have a built-in a Character Map tool: Windows (with pretty full Unicode since NT 4), Gnome, KDE, and Mac OSX (called "Character viewer").

That said, I am very well aware of the fact that pretty much nobody but me actually uses it. A very surprising number of people, however, do use the character insertion tool in their word processors. The one in Microsoft Word is not very different from Windows' Character Map, which in my mind makes it redundant, but apparently I'm special.

Anyway, yes - a character insertion tool should be there.

But, two points:

1. There's one already in Vector, and it's quite good. It can be used for research - which characters are used most frequently in which project. Adding statistics for this is quite easy now with EventLogging.

2. It may be easier to insert at least some characters using the keyboard layout provided with ULS. It is disabled now in VE because of some bugs (can anybody help me with the numbers?), but these can be fixed, of course. If we know which characters are really needed (see point 1 above), we can very easily add them to the keyboard layouts.
Well, when creating Featured or Quality articles we (on cs.wp) looks to have them correct from typograpical point of wiev. The problem is that Czech keyboard doesnt include all characters needed, as it includes other characters, which are not native to English. The most common missing characters would be *, #, &ndash;, &nbsp;. So if not all it would be nice to have in VE or nearby the table with some most used characters. E.g. list items are present in English keyboard, while &ndash; suprisingly not.
(In reply to comment #27)
> If this selection tool is ever provided, please make sure users have an
> option not to load it at all (see bug 11130 for this problem in the context
> of MediaWiki:Edittools)

It's very unlikely that we'll start adding per-user preferences to switch things like this on and off (some VE version of bug 9754); that's a very complex and confusing thing to allow.

Note BTW that bug 11130 is complaining about assuming users have JS (already known inside VE), lack of ability to cache (fixed by VE's nature), and taking up lots of screen estate (fixed by how we'll do this); I don't think it's a direct comparison. I'd also note that bug 11130 hasn't been done despite it being filed 6 years ago, which strongly suggests that it's not a priority.
Change 90940 had a related patch set uploaded by Jforrester:
[WIP] Insert special character tool

https://gerrit.wikimedia.org/r/90940
If this selection tool is ever provided, please make sure users have an option not to load it at all (see bug 11130 for this problem in the context of MediaWiki:Edittools)
**eleriygarregwen** wrote:

When I proposed a whole collection of sequences of characters to put into the ULS input method for Welsh, which uses a lot of diacritics, the comment from CYWP was that it would be a lot of work to memorise these character sequences, and it is not easy to find out about the ULS input methods.

The bar of characters under the edit box is very easy to understand, just by looking at it, and having a go. Almost no-one needs a help page on how to use it. Once you know what it does, there is nothing to memorise, and nothing to forget. Since simplicity is the aim with VisualEditor (to encourage new users), the bar of characters wins over anything more complicated, in my opinion.
I agree with James Forrester's comment #0. Character input in particular languages should be possible, but through the universal language selector, and in all text inputs on the website.

I think the ideal way to handle en dashes and em dashes would be to make "--" be replaced by the wikitext parser by an en dash (–), "---" by an em dash (—) and "----" by an horizontal bar (―). The current horizontal rule syntax would become "-----" (it would require one more hyphen-minus because the current one would be taken by the horizontal bar character). There would therefore become part of the syntax. DokuWiki does this for en dashes and em dashes (https://www.dokuwiki.org/wiki:syntax#text_to_html_conversions), but not the others.

As I mentioned, this is what I think would be the ideal way to handle it. Practically, this is impossible because these sequences are already used in many pages for other purposes. An acceptable solution would, I believe, be to make the editor recognize those sequences and replace them automatically by the corresponding character. This would be reasonable in the VisualEditor and would be more efficient than putting a bar of characters under the edit box and hoping beginners will use it to insert dashes. However, since the sequence "--" is used in signatures on talk pages and possibly for other things in wikitext, it may be preferable to avoid doing these replacements in the source editor.

It might be a good idea to add sequences of characters for producing similar characters. As long as the sequences are well chosen, problems should not arise frequently, and this could reduce considerably the typographical burden put on beginners.
**lebo.beland** wrote:

I didn't read the whole thread,  but I suggest to look at including Mediawiki:Edittools in the Visual Editor. For many projects, this include the special characters and useful stuff specific to each project.

Thanks,
*** Bug 55496 has been marked as a duplicate of this bug. ***
Czech editors have compiled a list of characters they find are vital for their day-to-day editing. From https://cs.wikipedia.org/wiki/Diskuse_k_Wikipedii:VisualEditor



Output	Name	                                Entity	Decimal
 	nobreak space	                        &nbsp;	&#160;
 	thin space	                        &thinsp;	 
„	curly quotation marks begin (99)	&bdquo;	&#8222;
“	curly quotation marks end (66)	        &ldquo;	&#8220;
‚	simple curly quotation marks begin	&sbquo;	&#8218;
‘	simple curly quotation marks end	&lsquo;	&#8216;
–	n-dash	                                &ndash;	&#8211;
×	times	                                &times;	&#215;

In particular, both kinds of quotation marks (we are very particular about those, like the French about theirs) could be insertable either one by one or in pairs, like so: „“ and ‚‘.
In general, easy access to inserting those characters would be a very desirable feature for Czech editors – and even better would be the MS Word functionality that automatically converts minuses into n-dashes and "English quotation marks" into „Czech quotation marks“. Best, Littledogboy (diskuse) 1. 10. 2013, 11:35 (UTC)
Important: Although I've listed their codes, we usually enter n-dash and curly quotation marks NOT as html entities, but simply like so „–“ (Alt-0132, Alt-0150, Alt-0147 – yes, I am a robot). Littledogboy (diskuse) 1. 10. 2013, 11:51 (UTC)
The other problem is that with VE having no source mode as yet, I can't even resort to HTML entities.
Further to comment 18 and comment 19 a big use case of the character insertion toolbar is to insert characters one does not frequently use.

Utilities like an external character map are very inefficient because it disrupts the work flow, requires you to find the character you want, and copy and paste the character you need. It also replaces whatever else you had in the clipboard previously that you may still need.

Dead keys are useful only if you know that they exist, know how to set them up (they are not enabled by default on most US and UK systems at least), and know the combinations required to input the character you want. I have a much better memory for things like that than many people, and while I know ones like é, Ŵ, ß, ° and ö, characters like ř, Đ and ố I don't. As far as I know, characters in other scripts like д, ζ, ب ,ש, are not producible using deadkey combinations.

Input methods are a very heavy weight solution to inputting characters not found natively on one's keyboard. They always require setting up in advance for each script (and some script/language combinations I think) and learning how to produce each desired character. I only use this method for IPA because I did a lot of work with pronunciations at Wiktionary and that required learning that to produce /ˌbʌɡˈzɪlə/ I need to type /%bVg"zIl@/ - hardly something we can expect a casual editor to learn.  

One of the primary goals of VisualEditor is to reduce the barrier to contributing to Wikimedia projects, not having a character insertion tool is rather contradictory to this.
I need to point out the irony of developing an editing interface with the good faith but technically challenged user in mind, and then expecting them to know how to use their browser/operating system to insert an emdash (a character not present on the standard English keyboard, but used over a million times on English Wikipedia). Given the target group for this extension, this isn't a low-priority enhancement, it is core functionality. In fact, the existing editorial base uses the edit tools almost exclusively over their browser/operating system, and I suspect many of them (including me) have no idea how to do use the latter.
Yep. When you need to add an accented character, you need to add an accented character. This is a quite definitely missing facility.
Another request today for [[MediaWiki:Edittools]] or an equivalent to be available in VE.

I second comment 8 and comment 10 - this is one of the features of the source editor that editors really miss.
Sorry Lloffiwr, my bad: I thought that Welshp WP had somehow made that set of characters already available with VisualEditor as well.
**eleriygarregwen** wrote:

"Lloffiwr, can you link to this workaround?" - Sorry I don't know what you are asking me to do.

With regard to using our own edit tools, that would be very good. It is very simple to just click on one of a number of characters sitting on a toolbar right next to the editor. You don't have to remember key combinations, there is no need to look up a help page and learn how to insert characters. The character toolbar's purpose in the normal editor is obvious and it is ready to use for all users (you don't have to enable a special keyboard as you would with the ULS).

By the way, in the "save" dialog of the VisualEditor on CYWP, we see an image of our short character toolbar, but have no way of actually using it! I, an experienced editor, was very confused by this; the new editors for whom this tool is designed are likely to be completely floored by it.
Lloffiwr, can you link to this workaround? I tried enabling VE on your wiki but that was not enough, should I also enable some gadget maybe? 
James, until this or other IME issues are not solved, isn't there a way to let these wikis use their very own edit tools, i.e. http://pms.wikipedia.org/wiki/MediaWiki:Edittools ?
**eleriygarregwen** wrote:

To make life easy on the Welsh Wikipedia, we have added a short character set consisting only of the most commonly used special characters immediately below the edit window. We have also added a more comprehensive set of special characters further down below the edit window. I think it would be useful to add the full character set to VisualEditor as standard, but also to allow each Wikipedia to add its own special character set via an optional message.
This is among the most important missing features for dewp.
**eleriygarregwen** wrote:

Another example of a language whose users make heavy use of the character insertion tool underneath the old edit window is Welsh (cy). Some of us work with keyboards which have been specially adapted to easily type the diacritics needed (including ŵ and ŷ) but not all hardware devices have this software loaded. This means that the VisualEditor is very difficult to use for some users, making training sessions for new users (some with, some without the diacritics software) difficult to conduct using VisualEditor.
Agreed with comment 8. The special characters insertion tool in WikiEditor is very convenient when editing articles about topics that involve other scripts or diacritics. Not providing such a tool in VisualEditor would seriously reduce VE's usefulness, and would certainly provide a compelling reason to use the source editor much more often than otherwise necessary.
BTW, if we ever do get another symbol picker, please make it share it's table with WikiEditor, limiting the places where we need to maintain these chars. (We already have 3 [WikiEditor extension, MediaWiki:Edittools, MediaWiki:Edittools.js])
"Character insertion is, in general, the responsibility of your browser/operating system"

Yes and no. Yes, your computer is capable of inserting loads of characters. No, it is not always reachable.

At least, I know of no operating system + browser combination, where I can put my cursor in a text area and bring up a symbol picker from the menu or a toolbar. (Unlike spellchecking).
*** Bug 51120 has been marked as a duplicate of this bug. ***
http://en.wikipedia.org/wiki/File:VE_modified_ui_suggestion.png shows one user's suggestion.  

See http://en.wikipedia.org/w/index.php?oldid=564286664#Thoughts_about_UI_improvements for the discussion.
There was a similar request on Portuguese Wikipedia[1]. A user wanted to use the kind of tool we see in the screenshot [2].


[1] https://pt.wikipedia.org/wiki/WP:Editor_Visual/Coment%C3%A1rios?oldid=36280987&uselang=en#Adi.C3.A7.C3.A3o_de_caracteres_especial_no_Visual_editor
[2] http://postimg.org/image/mwbyn96gn/
Nonbreaking spaces would be helpful as well.
We've had another comment re: emdashes here:http://en.wikipedia.org/w/index.php?title=Wikipedia_talk:VisualEditor&curid=37920680&diff=562488469&oldid=562482174
Well, I'm sat on my windows machine here and can't see any way to type an emdash, for example :/
(In reply to comment #0)
> The VisualEditor doesn't currently have a mechanism for inserting special
> characters - while a lot of them are unnecessary (~~~~ for example), things
> like en and emdashes can be quite important for content.

Character insertion is, in general, the responsibility of your browser/operating system (same as spell check, IME and other general editing tools). Where your local OS fails, we have a 'standard' of providing general tools to let you get OS-level tools (most notably, ULS), rather than one-off "insert a bunch of random characters" micro-tools.

MediaWiki has given people tools to insert random characters primarily because they do special things, and we've given up on users being able to magically know them (like ~~~~ or {{DEFAULTSORT:}}). They're all examples of system design failure. The fact that we have extended the metaphor to give "helpful" characters that users can trivially type themselves isn't a great reason to create it from scratch.

I'm not dead-set against this, but it feels like a clunky failure. :-(
Screenshot

See the screenshot; before and after the backspace, respectively.

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

**Attached**: {F11902}
This was fixed months ago; sorry for not spotting this bug report until now.
This is the same issue as Bug 51624 that was originally reported as happening with table cells and then extended to include image captions. I'm not sure which should me marked as duplicate of the other
Screenshot

See screenshot. The template inspector overlaps not only the document (that would be good - see 50241) - but the toolbar.

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

**Attached**: {F11898}
This would have been fixed this time last week with the general z-index re-write; sorry for only getting to this now.
Another complaint about this - the editor was using Google Chrome 28.0.1500.63 on Ubuntu 13.04.
Not sure if this should be filed under VisualEditor or Translate.

When clicking the "edit source" button on a translation or a page that uses the Translate extension, it isn't possible to edit the wikitext directly; instead, the user is told to use the Translate extension to change the content.

When clicking the "edit" button on a translation of a page that uses the Translate extension, it's possible to edit the text with VisualEditor. At first, I thought this was a feature, and that changes would be propagated to the Translate extension, until I tried to save the page and got the following error:

Error saving data to server: Unsuccessful request: Unknown error: "tpt-target-page".

If VisualEditor can't be used to edit those pages, it probably shouldn't lead users to believe it can :)

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48891
https://bugzilla.wikimedia.org/show_bug.cgi?id=61218
Change 119427 merged by jenkins-bot:
Disable VisualEditor on Page Translation output pages

https://gerrit.wikimedia.org/r/119427
Change 119427 had a related patch set uploaded by Jforrester:
Disable VisualEditor on Page Translation output pages

https://gerrit.wikimedia.org/r/119427
(In reply to comment #9)
> I just VEdited a page on mw.org (Communication) and it seemed to work (beyond
> the translate tags showing up).

Nope, the error happens when you try to edit a translation, not the source page :) e.g. try to edit Communication/it
I just VEdited a page on mw.org (Communication) and it seemed to work (beyond the translate tags showing up).
I assume VE checks whether the page is editable somewhere? I wonder if changing the hook in Translate from getUserPermissionsErrorsExpensive to getUserPermissionsErrors would solve this? Would have to make sure that the hook is efficient then.
Presumably there is a simple check we can do for whether the page is under the protection of the Translate extension, so we can do

if (
  …
  if <Translate extension installed> && !<page is Translate-protected>
  …
) { <do not load> }

… in the code in ViewPageTarget init?
*** Bug 51805 has been marked as a duplicate of this bug. ***
*** Bug 51931 has been marked as a duplicate of this bug. ***
e.g.
https://www.mediawiki.org/wiki/Communication/hu?veaction=edit
%%%*** Bug 51534 has been marked as a duplicate of this bug. ***%%%
I tested this on mediawiki.org following a report on the English Wikipedia, but instead of getting an error VisualEditor just silently refused to save the page - the progress bar appeared for a typical amount of time then I was back to the save dialog as if I hadn't pressed save. Lather, rinse, repeat.
Just a note to say that this keeps happening. Thanks!
It has happened to me several times that after a simple edition VisualEditor or Parsoid breaks the "</ref>}}" at the end of a reference template. I still don't know which is the pattern, but at least this time I realized it:

http://ca.wikipedia.org/w/index.php?title=El_Chornaler&diff=11962426&oldid=11962407

Other times a second editor had to come after me fixing the broken template. In the preview before saving everything looks fine.

--------------------------
**Version**: unspecified
**Severity**: normal
I can't reproduce it either. Let's say it's fixed.
I can't now reproduce this - is it still occurring?
http://en.wikipedia.beta.wmflabs.org/wiki/Special:Version shows extension Campaigns not updated since 12 June, but should be current as of https://gerrit.wikimedia.org/r/#/c/69841/ at least.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #4)
Yes. I made a trivial update to Campaigns, and after merging to master it was on http://en.wikipedia.beta.wmflabs.org/wiki/Special:Version within minutes.
Well Campaigns is still broken right now.  I guess it will be up to date whenever a commit is merged in that repository
A bunch of them were broken.

Fixed in https://gerrit.wikimedia.org/r/#/c/70834/.
And see bug 49846 mediawiki/extensions.git does not update VisualEditor
I guess it is misconfigured on Gerrit side (see bug 49906).
if an article starts with 
==Foo==
Bar Baz Fizz Buzz

It is impossible to remove ==Foo== without having the paragraph take on the h2 markup

--------------------------
**Version**: unspecified
**Severity**: normal
**Wikifram** wrote:

(ec) Yeah, I'm a bit frustrated by the number of errors in that status update, and the apparent lack of possibilities to correct these (even as an addendum or some such) and lack of care about this among the people responsible for this. Not your fault though. Thanks for filing that bug.
Filed as bug 54964
Steady on, they're similar bugs and easy to confuse.

The case you describe at the end does sound like a separate bug.
**Wikifram** wrote:

(In reply to comment #10)
> You're confusing this with bug 50100.

Not my mistake though, this was reported like this in the VisualEditor weekly update - 2013-09-26 (MW 1.22wmf19) by Jdforrester:

"Blanking the contents of a heading, pre-formatted block or other formatting block now deletes the block rather than leaving it empty, which is consistent with how OpenOffice and Google Docs behave (bug 50254)." 

I noted that what the VE status report describes is ''not'' fixed, and followed the link number given in the VE status report. If this bug is about something else than what the VE status report described, then this is just one more in the already long list of things wrong with that status report (for which it is apparently "impossible" to write an update or correction in any way, shape or form). 

Anyway, you still get the behaviour as described: Go to the first word you want to keep (after the initial header), and use backspace to remove the header: your next paragraph now becomes the header. Only when you first empty the header (leaving the line beneath it), and then go to the text and use backspace, is it possible to remove a starting header without converting the following text into a header. I wouldn't call this "solved", perhaps "somewhat improved" assuming that the latter possibility / workaround didn't work in the past. (I note that you only go to the start of the heading, and then select "downwards" instead of "sideways"; deleting the header like this works as well)

Note also that if yu eventually get rid of that header, it seems to be impossible to remove a first empty line from an article: [https://en.wikipedia.org/w/index.php?title=User%3AFram%2Fsandbox&diff=575703425&oldid=575703070]. Probably needs a different bug (or already exists), but not really optimal either.
You're confusing this with bug 50100.
**Wikifram** wrote:

Nice that this is solved, except that it isn't. I had already noted that at MediaWiki, it still blanks the header (but doesn't add nowiki). Tested today at enwiki, and sadly, even worse, again a nowiki was added inside the header instead of removing the empty header: [https://en.wikipedia.org/w/index.php?title=Robbers_Cave_State_Park&diff=575691345&oldid=558376701]

Has this patch ever worked anywhere? Diff?
Change 85673 merged by jenkins-bot:
Delete empty nodes instead of merging into them

https://gerrit.wikimedia.org/r/85673
The delete-when-empty-merge-otherwise behaviour implemented by the patch above is also used by OO/LO & Google docs.
Change 85673 had a related patch set uploaded by Esanders:
Delete empty nodes instead of merging into them

https://gerrit.wikimedia.org/r/85673
This is a separate issue to bug 51829 (now bug 50100).
It happens to me always, even if the heading is in the middle of the page.
They definitely seem related, with the distinction that this but has the problem that there is no slug (am I using the lingo right) on the line above the first header if the header is the first element of the page. Merge however you feel is most useful.
Actually, this bug looks to be a subset of Bug 51829 is this best merged or that bug better split?
As a workaround, it is possible to convert the header to paragraph text and then delete it. That is no better though than deleting and then converting the changed text back to a paragraph.
Link shows a diff made post-deploy doing (what happened to be white-space only) normalisation in two templates (that weren't touched). :-(

--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://en.wikipedia.org/w/index.php?title=Pgeezy&curid=38061582&diff=561709972&oldid=561568473
After today's deployment this now appears to have been fixed. Marking as such.
I want to get rid of jobs on the master instance and have them all on slaves.  Master is currently gallium.wikimedia.org which also have a slave installed on it and named 'gallium'.

This is a tracking bug.

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
[adding the #tracking project to tasks blocking (now deprecated) T4007 as part of T93366]
Marked master has being down.  People should use the 'gallium' slave to tie jobs to that server or they could use a label.
https://integration.wikimedia.org/ci/computer/(master)/

Master (the master Jenkins node)
Projects tied to master
None

\O/

I guess we can now remove master as an executor.
Reduced number of executor on master from 4 to 2.  There are only the qunit jobs left there (bug 50231).
https://gerrit.wikimedia.org/r/71006 migrated the wikibase jobs:

mwext-Wikibase-client-tests
mwext-Wikibase-repo-tests
https://gerrit.wikimedia.org/r/#/c/71000/ migrates mediawiki regression jobs

mediawiki-core-regression-REL1_19
mediawiki-core-regression-REL1_20
mediawiki-core-regression-REL1_21
mediawiki-core-regression-master
https://gerrit.wikimedia.org/r/#/c/70999/ migrates some doc jobs:


mediawiki-core-doxygen-publish
mediawiki-core-jsduck-publish
mwext-VisualEditor-doc-publish
operations-puppet-doc (bug 50233)
https://gerrit.wikimedia.org/r/#/c/70917/ updated jobs:

mediawiki-core-phpunit-api
mediawiki-core-phpunit-databaseless
mediawiki-core-phpunit-misc
mediawiki-core-phpunit-parser
List of tied jobs is available at https://integration.wikimedia.org/ci/computer/(master)/  That list needs to shrink to 0 elements.
e.g. "menuitem" for options in our select widgets.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Looks fine from my POV.
Anything left to do here, Timo/James?
Change 148253 merged by jenkins-bot:
Add role attribute to a few widgets

https://gerrit.wikimedia.org/r/148253
Change 148253 had a related patch set uploaded by Alex Monk:
Add role attribute to a few widgets

https://gerrit.wikimedia.org/r/148253
Most of this has already been done in OOUI, I think.
**Author:** `swalling`

**Description:**
This tour step should only be shown in read mode.

When starting the guided tour via the "Show help" help button with GettingStarted, guided tours thinks I am in read mode and displays broken steps, rather than skipping to the appropriate editing steps.

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

**Attached**: {F11708}
Change 72682 merged by jenkins-bot:
Add tour for VisualEditor

https://gerrit.wikimedia.org/r/72682
Change 72677 merged by Ori.livneh:
Add support for VisualEditor

https://gerrit.wikimedia.org/r/72677
**swalling** wrote:

(In reply to comment #5)
> I fixed the issue where step 1 was shown when clicked "Show help" while in VE
> editor, on a page with an ambox.  That's on toro for testing.

Tested and working for me on toro. Once the patches are merged I think we can call this one fixed.
I fixed the issue where step 1 was shown when clicked "Show help" while in VE editor, on a page with an ambox.  That's on toro for testing.
This should be fixed by https://gerrit.wikimedia.org/r/#/c/72677/ and https://gerrit.wikimedia.org/r/#/c/72682/, pending review.
Change 72682 had a related patch set uploaded by Mattflaschen:
Add tour for VisualEditor

https://gerrit.wikimedia.org/r/72682
Change 72677 had a related patch set uploaded by Mattflaschen:
Add support for VisualEditor.

https://gerrit.wikimedia.org/r/72677
**swalling** wrote:

Note: this only happens if the user clicks "Show help" after editing in VE mode. Otherwise, the tour progresses normally. The easiest solution in the interim may be to ensure that we don't show the Getting Started toolbar in VE edit mode, like we do for wikitext editing.
**Author:** `p.selitskas`

**Description:**
Dash-to-underscore conversion is frucked up yet again?

When "Edit" is clicked, an API request is issued with params:
action:visualeditor
paction:parse
page:Новая_зямля
oldid:1630719
token:[screened]
format:json

Response: {"servedby":"mw1141","error":{"code":"parsoidserver-http-bad-status","info":"404"}}

VE works at be.wikipedia.org, but it doesn't work at be-x-old.wikipedia.org, bat-smg.wikipedia.org, and maybe other sites with dash in the site ID.

--------------------------
**Version**: unspecified
**Severity**: major
**p.selitskas** wrote:

(In reply to comment #3)
> I have fixed this in the Parsoid config.

Can you publish the link to the change in Gerrit (if it is publicly available), just for my interest?

Thanks for fixing, btw.
(In reply to comment #2)
> (In reply to comment #1)
> > Roan - is this a config issue at our end or something else?
> > 
> > http://titanium.wikimedia.org/be-x-oldwiki/Галоўная_старонка?oldid=1535753
> > and
> > http://parsoid.wmflabs.org/be-x-old/Галоўная_старонка?oldid=1535753 both work
> > fine for me, but in VE
> > https://be-x-old.wikipedia.org/wiki/
> > Галоўная_старонка?oldid=1535753&veaction=edit
> > does indeed 404.
> 
> I think it's a config issue.
> 
> CommonSettings.php on line 1890 says:
> $wgVisualEditorParsoidPrefix = $wgDBname;
> 
> DB names are written with underscores instead of dashes. Conversion '_'->'-'
> should be performed here.
> 
Turns out we did actually have the DB names mapped correctly, but to the wrong URLs. We had stuff like:

'map_bmswiki': 'http://map_bms.wikipedia.org/w/api.php',

which is wrong, we need URLs with dashes.

I have fixed this in the Parsoid config.
**p.selitskas** wrote:

(In reply to comment #1)
> Roan - is this a config issue at our end or something else?
> 
> http://titanium.wikimedia.org/be-x-oldwiki/Галоўная_старонка?oldid=1535753
> and
> http://parsoid.wmflabs.org/be-x-old/Галоўная_старонка?oldid=1535753 both work
> fine for me, but in VE
> https://be-x-old.wikipedia.org/wiki/
> Галоўная_старонка?oldid=1535753&veaction=edit
> does indeed 404.

I think it's a config issue.

CommonSettings.php on line 1890 says:
$wgVisualEditorParsoidPrefix = $wgDBname;

DB names are written with underscores instead of dashes. Conversion '_'->'-' should be performed here.

This is a typical error in WMF configs. I used to run against it even in MediaWiki core.
Roan - is this a config issue at our end or something else?

http://titanium.wikimedia.org/be-x-oldwiki/Галоўная_старонка?oldid=1535753 and http://parsoid.wmflabs.org/be-x-old/Галоўная_старонка?oldid=1535753 both work fine for me, but in VE https://be-x-old.wikipedia.org/wiki/Галоўная_старонка?oldid=1535753&veaction=edit does indeed 404.
1. Edit [[mw:VisualEditor:Sfioj]] in VE
2. Make a selection such as

     These [words are] very bold
or 
     These wor[ds are ve]ry bold

3. Click the "Bold" button on the toolbar

The selected text goes extra-bold, in Firefox 21. 

I should mention that in my case, the font is Arial, which has an extra bold "Arial-Black" variant.

--------------------------
**Version**: unspecified
**Severity**: normal
*** Bug 52189 has been marked as a duplicate of this bug. ***
Patched and merged: https://gerrit.wikimedia.org/r/#/c/70434/
There is a related problem with italic: try the same STR on the second line of the Sfoij page, using the "italic" toolbar button instead of "bold". But I think it is the same issue.
Groups of consecutive images are alienated under certain circumstances. 

It might have something to do with the wikilinks in the image caption, however I really just have to throw you some testcases:

---
(1) Works fine:
http://en.wikipedia.org/w/index.php?title=User:This,_that_and_the_other/sandbox/VE2&oldid=561493135&veaction=edit

(2) Similar, but doesn't work:
http://en.wikipedia.org/w/index.php?title=User:This,_that_and_the_other/sandbox/VE2&oldid=561493351&veaction=edit

(3) All three groups uneditable, even the group that is identical to (1) above:
http://en.wikipedia.org/w/index.php?title=User:This,_that_and_the_other/sandbox/VE2&oldid=561493252&veaction=edit

(4) One group fine, the other alienated:
http://en.wikipedia.org/w/index.php?title=User:This,_that_and_the_other/sandbox/VE2&oldid=561493194&veaction=edit

--------------------------
**Version**: unspecified
**Severity**: normal
See bug 51039.
(In reply to comment #3)
> (In reply to comment #1)
> > Do they work for you too?
> 
> Sorry, yes the testcases do all work now.

Yay. Marking as fixed. :-)
(In reply to comment #1)
> Do they work for you too?

Sorry, yes the testcases do all work now.
Could you check [[History of Delta Air Lines#1960s_and_1970s]]?
(In reply to comment #0)
> Groups of consecutive images are alienated under certain circumstances. 
> 
> It might have something to do with the wikilinks in the image caption,
> however
> I really just have to throw you some testcases:
> 
> ---
> (1) Works fine:
> http://en.wikipedia.org/w/index.php?title=User:This,_that_and_the_other/
> sandbox/VE2&oldid=561493135&veaction=edit
> 
> (2) Similar, but doesn't work:
> http://en.wikipedia.org/w/index.php?title=User:This,_that_and_the_other/
> sandbox/VE2&oldid=561493351&veaction=edit
> 
> (3) All three groups uneditable, even the group that is identical to (1)
> above:
> http://en.wikipedia.org/w/index.php?title=User:This,_that_and_the_other/
> sandbox/VE2&oldid=561493252&veaction=edit
> 
> (4) One group fine, the other alienated:
> http://en.wikipedia.org/w/index.php?title=User:This,_that_and_the_other/
> sandbox/VE2&oldid=561493194&veaction=edit

These now all work for me - we've updated Parsoid (and purged the cached versions to avoid corruption from old things), which is (I think) the cause of these issues. Do they work for you too?
http://it.wikipedia.org/wiki/Utente:Syrio/Bozzoli, we tried changing the author's name in ref.6 to "abbé Paul Guérin". VE allows editing it, but after clicking twice on Apply Changes, the former name is still displayed and the page can not be saved as the button does not work. (Also, it does not allow us to re-try immediately or to edit other references, you need to reload the page for that). So I did a dummy edit to plain text, and I was allowed to save then, but the result http://it.wikipedia.org/w/index.php?title=Utente%3ASyrio%2FBozzoli&diff=59659908&oldid=59651683 has nothing to do with poor abbé Guérin.

--------------------------
**Version**: unspecified
**Severity**: major
(In reply to comment #4)
> You are right, it works now. Can this be due to people adding TemplateData to
> that template?

It's possible that TemplateData would mean that it was difficult to edit, yes; sorry. :-(

> Since we're here, I attached the screenshot of what happens when
> you try and edit it with Vector. You need to reach and click the light blue
> bar in order to change something in that line. It works, though.

Argh, yes, that's bug 49818 which I thought we had fixed; is this problem still happnening for you? :-(
(Sorry, that was meant to be "with Vector on Chrome", it's ok on FF).
You are right, it works now. Can this be due to people adding TemplateData to that template? Since we're here, I attached the screenshot of what happens when you try and edit it with Vector. You need to reach and click the light blue bar in order to change something in that line. It works, though.
Created attachment 12788
Reference editing window

**Attached**: {F11670}
[Sorry, can't check before tomorrow. Thanks.]
[Sorry for being so late in replying to this bug!]

Can this still be reproduced? If so, in what browser? I can edit the reference fine in Firefox and Chrome.

(When you edit a reference, VisualEditor goes off and asks for the reference list to be re-created; temporarily, while that is happening, the original form remains shown in the reference list. However, this behaviour should be very quick, and should not prevent the user from editing.)
Screenshot

Image dialog shows thumbnails twice, see screenshots.

Maybe 1 from local wiki and 1 from Commons, which are most of the times identical?

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

**Attached**: {F11660}
This was fixed and deployed on Thursday.
Change 73190 merged by jenkins-bot:
Normalize image titles in cache to prevent duplicates.

https://gerrit.wikimedia.org/r/73190
Change 73190 had a related patch set uploaded by Robmoen:
Normalize image titles in cache to prevent duplicates.

https://gerrit.wikimedia.org/r/73190
^^ You are correct.  this is happening because we are getting results from both namespaces.  File and Fichier in this case.
(In reply to comment #2)
> I can't reproduce this in Forefix 21.

Oh, sorry, I see you were on frwiki. This doesn't happen on enwiki or mediawikiwiki, but I can reproduce it on frwiki and dewiki.

Perhaps VE doesn't know about localised names for the "File" namespace. That's just a guess.
I can't reproduce this in Forefix 21.
Created attachment 12632
Screenshot

**Attached**: {F11661}
**Author:** `brassratgirl`

**Description:**
See this diff: 
https://en.wikipedia.org/w/index.php?title=Uganda&diff=561452947&oldid=560332103

adding a sentence to the lede section saved properly, but also had unwanted behavior of cutting off the first letter of the first word of a random paragraph in a later section (removed 'l' from "Lake Kyoga" under 'geography'). 

Firefox 21.0 on Ubuntu 12.04.

--------------------------
**Version**: unspecified
**Severity**: normal
I believe we have now fixed this; please re-open if it recurs.
Can't reproduce in master yet.
**brassratgirl** wrote:

Tried editing another, later section in the same article and got this: 
https://en.wikipedia.org/w/index.php?title=Uganda&diff=561456536&oldid=561456189

the changes I intended to make were made (added a link, copyediting) but spaces around template dates were added (more normalization) and the same initial letter (the 'l' of lake) and bracket from the same image file were removed. VisEd *really* doesn't like something about that paragraph!
(In reply to comment #1)
> Also added some quotes to refnames

That's "just" normalisation, which we can fix (by making sure that what we send Parsoid is exactly the same, so it leaves it alone); see bug 50071.

> and removed a bracket from an image link later on.

Yeah, this is very not good, and really hard to understand how it happens. Roan, thoughts?
**brassratgirl** wrote:

Also added some quotes to refnames and removed a bracket from an image link later on.
They're currently enabled on page load. Even when dismissing the notice and clicking around in the first paragraph it stays.

It finally disables itself after a node change (e.g. click the second paragraph and then back).

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=44083
This has been fixed and will be deployed very soon.
Change 70936 merged by jenkins-bot:
Init surface after toolbar is setup vs. before.

https://gerrit.wikimedia.org/r/70936
Change 70936 had a related patch set uploaded by Robmoen:
Init surface after toolbar is setup vs. before.

https://gerrit.wikimedia.org/r/70936
From conversation earlier today:

It may be possible to hack the button to be disabled by default, but that would introduce the opposite bug where the indention tool would be disabled instead of enabled in a document that starts with a list, requiring the user to move out of the list and back in to be able to indent.

Basically we should make sure that our hooks that make the button enabled/disabled on node focus change also trigger when initially focussing the first node in the document (instead of only from the second node focus onwards).
--------------------------
**Version**: unspecified
**Severity**: major
This should now be fixed.
Related URL: https://gerrit.wikimedia.org/r/70333 (Gerrit Change I3818ebe9816e7d781233f087b15694bf7ba12965)
This is caused by CE placing a slug after internal nodes.  Fix in progress.
Stack error:

Uncaught Error: Offset could not be translated to a DOM element and offset: 73 ve.ce.Document.js:187
ve.ce.Document.getNodeAndOffset ve.ce.Document.js:187
ve.ce.Surface.showSelection ve.ce.Surface.js:1289
ve.ce.Surface.onChange ve.ce.Surface.js:739
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.MWReferenceDialog.onClose ve.ui.MWReferenceDialog.js:197
ve.ui.Window.close ve.ui.Window.js:332
(anonymous function) ve.ui.Dialog.js:118
proxy
Change 86664 merged by jenkins-bot:
Rich paste

https://gerrit.wikimedia.org/r/86664
Rich paste will strip all metadata and so should solve this issue.
Change 86664 had a related patch set uploaded by Esanders:
Rich paste

https://gerrit.wikimedia.org/r/86664
Bizarre indeed; presumably this is from a copy-and-paste and the "give me only the plain text" request to the browser is being ignored?
* Go here http://en.wikipedia.org/w/index.php?title=User:ESanders_(WMF)/Sandbox&oldid=561403721&veaction=edit
* Select from the end of the image to inside the link
* Observe you now have a link inspector positioned over the image.
Bonus:
* Use the inspector to edit the link
* Review your changes, the image has been killed, and the link as gone a bit crazy

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed. Will go out in next push.
Change 79919 merged by jenkins-bot:
getAnnotationsFromRange should only ignore non-content data

https://gerrit.wikimedia.org/r/79919
'Bonus' section has been filed here: https://bugzilla.wikimedia.org/show_bug.cgi?id=53151
Change 79919 had a related patch set uploaded by Esanders:
getAnnotationsFromRange should only ingnore non-content data

https://gerrit.wikimedia.org/r/79919
Screenshot of the problem in the serialization

I think this is caused by Parsoid trying to preserver/re-add whitespace when round-tripping.

Steps to reproduce issue:
* Create a page like the default MediaWiki main page:

<<<MW
'''MediaWiki has been successfully installed.'''

Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki sandbox software. 12

== Getting started ==
* [//www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list]
* [//www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]
* [//www.mediawiki.org/wiki/Localisation#Translation_resources Localise MediaWiki for your language]
MW;

* Edit it with VisualEditor
* Put the cursor before "MediaWiki release mailing list" and select back until before the first character of the heading "Getting started".
* Press backspace. You're now left with 2 of 4 items in the list and an empty heading.
* Again, out the cursor before "MediaWiki release mailing list" and delete until you're behind "software. 12". You're now left with "MediaWiki release mailing list" in the paragraph and a list with 1 item.
* Save page -> Review changes (Screenshot attached)

It inserts a lot of new lines.

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

**Attached**: {F11588}
Please reopen if this an issue in Parsoid.
There was a typo.  It should read:  ".... where there are *NONE* ...."
This seems to be a bug in the diff interface in mediawiki.  There are no extra newlines in the wikitext source as indicated by the diff.  The diff incorrectly signals newlines where there are now.

Steps to reproduce:

* Do everything as Krinkle says
* Actually save the page.
* Look at the new wikitext source and look at what the diff tells you.

I am leaving this bug open so others can verify independently.
Krinkle: Could you provide a dump of VE's input and output DOM?
Subbu, could this be caused by e90e40c26cd8?
I edited a large page on meta (1.22wmf7) in VE. All seemed fine but review showed VE had removed the first character following several closing </pre> tags. It also removed a few characters within a <source> tag.

Here's the diff showing the removal, it's self-explanatory.  <https://www.mediawiki.org/w/index.php?title=Extension%3AEventLogging%2FGuide&diff=716359&oldid=704840>.  I will restore the characters by hand.
I'm using Firefox 21.0 on Kubuntu 13.04.

I tried editing the same document again and this time VE removed more characters from the source tag, added a space after a <pre>. Hmm. I'm setting to critical as it's recoverable data loss, but maybe it's intermittent.

--------------------------
**Version**: unspecified
**Severity**: critical
Here is another example:
https://www.mediawiki.org/w/index.php?title=Gerrit/Tutorial&diff=717045
(In reply to comment #2)
> Can't reproduce in master.

Neither can I, in production or master. I'm going to close this as fixed, but please re-open if it recurs.
Can't reproduce in master.

An issue I am seeing is code inside <source> and <syntaxhighligh> blocks are losing their linebreaks. Might want to file a bug if we aren't aware of that.

Editing inside source is now bug 50224
Making this primarily about the first character after a </pre> getting lost on round-trip; I'm not sure how you were able to edit inside a <source> tag, though, so that needs exploring too if it recurs.
From http://www.mediawiki.org/wiki/Thread:VisualEditor/Feedback/Problem_with_using_shift%2B

"Hi. I have been using the visual editor for a while on ar Wikipedia, it is very nice and smooth for fast edits. However, I am facing a very strange problem when I need to add some Arabic diacritics known as tashkil; when I press shift+diacritic button (like x, e, or z) the letter I pressed starts to repeat itself endlessly, and it can only be stopped by refreshing the page and wasting the work I have did. Any thoughts?"

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50631
Given that this is now merged, I'm going to mark this as fixed. However, this is provisional - please re-open if you think that this has not worked!
Change 80080 merged by jenkins-bot:
Don't emit Surface changes back to the Surface

https://gerrit.wikimedia.org/r/80080
**aaddira** wrote:

Thank you. I have tested all possible diacritics on Arabic Wikipedia and everything is working great. Good job!
Change 80080 had a related patch set uploaded by Jforrester:
WIP:Don't emit Surface changes back to the Surface

https://gerrit.wikimedia.org/r/80080
I think this may be resolved by the following patch:
https://gerrit.wikimedia.org/r/#/c/79451 . It fixes similar bugs in other scripts with similar properties.

If it's still broken, is it possible to give a specific example of:

1. A piece of Arabic text where VisualEditor fails
2. The keystrokes required to enter the text
3. The incorrect output observed in VisualEditor
4. The OS, browser and input method used.

Thanks!
(In reply to comment #2)
> Thanks James - first bug report.

No worries. :-) Welcome to the party.
Thanks James - first bug report.
Bumping priority, moving module, assigning, slight rewording; note that we can't fix things in the past (;-)), so setting to next week's deployment deadline.
https://en.wikipedia.org/w/index.php?title=Jason_Bateman&curid=685922&diff=561337061&oldid=559944750

https://en.wikipedia.org/w/index.php?title=David_Stewart_(photographer)&curid=24365669&diff=561336970&oldid=529664374

--------------------------
**Version**: unspecified
**Severity**: normal
Confirmed that this indeed now fixed, now that everyone's caches have rotated.
comment 1 is an example that is not fixed by bug 50071, and im still seeing the problem occur.

https://en.wikipedia.org/w/index.php?title=Republic_of_Texas&diff=562971813&oldid=562786837
*** This bug has been marked as a duplicate of bug 50071 ***
https://en.wikipedia.org/w/index.php?title=Paul_Evans_(footballer_born_1973)&curid=15575267&diff=561390930&oldid=561390588
Screenshot

See screenshot; this is still happening as of [timestamp of this bug]. The VE interprets a click on 'save page' to be an attempt to interact with the infobox.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49059

**Attached**: {F11515}
**orbit** wrote:

This is fixed now in master.
Created attachment 12625
Screenshot of blue phantom overlapping save dialog using VisualEditor on the English Wikipedia, 2013-06-24

Confirmed.

**Attached**: {F11517}
Compare the references section of https://en.wikipedia.org/wiki/A_Slight_at_the_Opera in read and edit mode.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52371
No, this bug was fixed; I think that that's a different issue. Splitting.
%%%*** Bug 52371 has been marked as a duplicate of this bug. ***%%%
Reopening; see bug 52371 for an example of this still happening.
This was fixed in the re-working of references last week; marking as fixed.
I can't reproduce this using the example above now, even looking at the version that was live when the comment was left. I see four references in both read and edit modes.
(from bug 49922 comment 1)

VE is slow at selecting templates and transclusions in big pages.

For example: [[World War II]]:

 - attempt to select infobox by clicking on it: takes ~3 seconds in 
   Firefox 21 and Chrome 27, with no visual indication that anything
   is happening during the wait

 - attempt to select the reflist by clicking on it: just hangs in Firefox
   and Chrome, never actually seems to happen

This either needs to be sped up, or fail more gracefully.

In IE10, this is not such a problem \o/ - lag is actually less, and the reflist can be selected (takes about 22 seconds).

--------------------------
**Version**: unspecified
**Severity**: normal
This is an old report that I think is now closable (but performance is of course an on-going concern).

For these particular concerns, we've recently fixed a number of performance issues germane to these:

* Selection of the template, and opening the dialog, takes much less than a
  second now for me (I'd call it instant, roughly).
* Loading the second reflist is much quicker too (the first one was already near-instant).

(Note that these fixes should hit production later today.)

Consequently, I'm marking this as "FIXED", though there's always going to be more to do.
Created attachment 13765
beyond the selected reflist

**Attached**: {F11475}
Created attachment 13764
Above the reflist

**Attached**: {F11474}
Experienced the lag in selecting both the info box and reflist on that page in chrome Version 26.0.1410.65 and firefox 20 (MAC OS X version 10.8.5)

However, did not experience the hang while selecting the reflist in either of the browsers.

Also,while selecting the reflist , the blue selection box progresses beyond the reflist selected in both sides.

See the screenshots attached.
See the unexpected changes at https://en.wikipedia.org/w/index.php?title=Thomson_Airways&diff=561270595&oldid=561268927

--------------------------
**Version**: unspecified
**Severity**: major
Fixed and will go out in about an hour.
Related URL: https://gerrit.wikimedia.org/r/70133 (Gerrit Change Ib13bb206c49b1f5b186e40632a5c109def0f042e)
Data model issue.
When a page contains two identical templates right next to each other, VE removes one of them. 

Try editing [[User:This, that and the other/sandbox/VE5]] in VE, for example.
Screenshot

See screenshot. What am I meant to be paying attention to?

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

**Attached**: {F11451}
This has indeed be fixed by the above on-wiki change; closing.
(In reply to comment #9)
> .ve-init-mw-viewPageTarget-toolbar-editNotices-notice .editnotice-redlink {
> display: none !important; }
> 
> I'd recommend the community adds this to [[MediaWiki:Group-sysop.css]]

Actually, add it to [[MediaWiki:Common.css]] below ".sysop-show { display: none" because we want it to apply to non-sysops who made this visible in their user css as well. It won't affect anything else.
I agree that it isn't obvious whether the community does or doesn't want this information on the edit page. However I also want to emphasise that this is hidden by default, and thanks to our logic that strips out fake notices that have no visible content, they are hidden for the vast majority of users.

If this "Page notice" redlink is visible, it is because the user has styles in their state (either from [[MediaWiki:Group-sysop.css]] or their user stylesheet) that make ".editnotice-redlink" or ".show-sysops" visible (the element in the edit notice has both classes).

So one could argue showing it is the right thing to do, for they want to see it. Why would they want to see it on the edit page but not in VisualEditor? Likely because they don't use it that much in the first place, but it is more intruding in VisualEditor because notices pop up from the editor.

Anyway, to hide in visualeditor without hiding it else where, you can use the following line of CSS:

.ve-init-mw-viewPageTarget-toolbar-editNotices-notice .editnotice-redlink { display: none !important; }

I'd recommend the community adds this to [[MediaWiki:Group-sysop.css]] right below the rules for  ".show-sysop { display: block !important; }" and the like.

Note that we can't use ve-ui-toolbar, we can only use "ve-init-mw-viewPageTarget-toolbar-editNotices-notice" because the other elements aren't in the notice's element tree until *after* it is already in the VE DOM, and hiding it after that will merely make the link invisible, the notice container will still be there.
(In reply to comment #6)
> There isn't much we can do. If the community insists it is useful to have
> placeholder edit notices when there is no editnotice that allows opt-in users
> to create them from a red link, then this is exactly what they want, is it
> not?
> 
> It shows that on EditPage as well (except in there, they are less visible as
> actual notices but appear as part of the page).

I disagree that the consensus that the enwiki community achieved for having this edit notice in wikitext editor (a consensus which I have disagreed for years, but there you go) transfers to consensus that they want it displaying in VisualEditor.

As a quick hack, we could sniff for the edit notice having class="editnotice-redlink" on it and killing that notice from the array. It's horrible, but it will stop the problem until we fix it properly.
Last I checked, we're part of the community.
I fixed most of these last year by supporting client-side "hidden" notices as non-existent through the hasVisibleText logic I wrote.

These used to trigger a notice for all users, now it only triggers a notice for users that have css in their state that makes these red links visible (I think this is limited to MediaWiki:Group-sysop.css by default +  anyone else who likes to have it as well).

There isn't much we can do. If the community insists it is useful to have placeholder edit notices when there is no editnotice that allows opt-in users to create them from a red link, then this is exactly what they want, is it not?

It shows that on EditPage as well (except in there, they are less visible as actual notices but appear as part of the page).
This really should be solved on en.wp, not in VE.
I'd recommend prioritizing this very highly, it's a rather negative experience.
*** Bug 50531 has been marked as a duplicate of this bug. ***
(In reply to comment #1)
> (In reply to comment #0)
> > Created attachment 12619 [details]
> > Screenshot
> > 
> > See screenshot. What am I meant to be paying attention to?
> 
> That enwiki's community, in its wisdom, wants you to see that you can add a
> page notice to every page, because you're +sysop. It doesn't appear for
> non-sysops. If they want to commit to adding a class to it that we suppress
> and reduce the count by one, we're happy to do that.

Looking into this, it seems like we can use class="editnotice-redlink" to select and suppress these (including reducing the count by one). Handing to Timo to implement.

**Attached**: {F11451}
(In reply to comment #0)
> Created attachment 12619 [details]
> Screenshot
> 
> See screenshot. What am I meant to be paying attention to?

That enwiki's community, in its wisdom, wants you to see that you can add a page notice to every page, because you're +sysop. It doesn't appear for non-sysops. If they want to commit to adding a class to it that we suppress and reduce the count by one, we're happy to do that.

**Attached**: {F11451}
Click after the line "Saptaitey Chiranjeevinaha[citation needed]" on https://en.wikipedia.org/wiki/Chiranjivi and BANG! And the text is gone.

--------------------------
**Version**: unspecified
**Severity**: major
Fixed and will go out in an hour.
Change 73952 merged by jenkins-bot:
Handle backspace correctly when in a slugs

https://gerrit.wikimedia.org/r/73952
Change 73952 had a related patch set uploaded by Esanders:
Handle backspace correctly when in a root slug

https://gerrit.wikimedia.org/r/73952
(In reply to comment #4)
> Yes; you need to backspace over the DL from the block slug underneath it to
> trigger.
Yeah, that breaks it. For some reason handleDelete() tries to process *two* transactions: one successfully removes the entire <dl>, and the second tries to reinsert part of it but in the middle of a paragraph, presumably because it computed the wrong offset somehow (failing to adjust for the first transaction, maybe)?
Yes; you need to backspace over the DL from the block slug underneath it to trigger.
I can't reproduce this any more, can anyone else?
DefinitionListNode shouldn't have getAnnotatedHtml, it's not inside a content branch. Did we screw up the DM such that a definition list ended up inside a paragraph?
Yuck. Thrown error is:

  Uncaught TypeError: Object #<VeCeDefinitionListNode> has no method 'getAnnotatedHtml' 

Sounds like we didn't update the CE nodes for DLs.
See https://en.wikipedia.org/w/index.php?title=Beautiful_%28Mariah_Carey_song%29&diff=561243294&oldid=561242578

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed and will be going out today.
Related URL: https://gerrit.wikimedia.org/r/70469 (Gerrit Change I5a844e2e0655bc1db152b3805718324ca0bb04df)
*** Bug 50102 has been marked as a duplicate of this bug. ***
s/templates/references/ gah, sorry
Now appearing outside of templates; https://en.wikipedia.org/w/index.php?title=Lichens_%28musician%29&curid=16561703&diff=561390034&oldid=556766679
Roan, can you tell how we're dirtying the DOM such that Parsoid changes these at all?
See https://en.wikipedia.org/w/index.php?title=Riddler&diff=561149660&oldid=561096940

The user reports they were nowhere near the infobox.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50147
https://bugzilla.wikimedia.org/show_bug.cgi?id=50129
This is now fixed and pushed live; sorry for the failure.
*** Bug 50129 has been marked as a duplicate of this bug. ***
Bug 50147 is the underlying problem in Parsoid; this bug is for fixing the dirty-DOMing that makes Parsoid trigger on the templates.
Other examples of nowiki insertion:

http://en.wikipedia.org/w/index.php?title=Glenn_Greenwald&diff=561437483&oldid=561434741

https://en.wikipedia.org/w/index.php?title=Schuylar_Oordt&diff=561438828&oldid=561406705
Roan, can you tell how we're dirtying the DOM such that Parsoid changes these at all?
See https://en.wikipedia.org/w/index.php?title=Port_of_Hull&diff=561131671&oldid=561056099 - an attempt to enter a dash led to bolding vanishing. Not sure what's going on there.

--------------------------
**Version**: unspecified
**Severity**: normal
https://gerrit.wikimedia.org/r/70768 (Gerrit Change I69bda7db141a3302cee6ece5af5ffdc57e748d89) | change APPROVED and MERGED [by jenkins-bot]
Related URL: https://gerrit.wikimedia.org/r/70768 (Gerrit Change I69bda7db141a3302cee6ece5af5ffdc57e748d89)
Related URL: https://gerrit.wikimedia.org/r/70768 (Gerrit Change I69bda7db141a3302cee6ece5af5ffdc57e748d89)
*** Bug 50258 has been marked as a duplicate of this bug. ***
I can't reproduce the dirtying of the paragraph locally. If I make a null change, I get a null diff. If I change anything outside the bold+italic text, I get the bad diff.

There are some dirtying issues with the code that was in production at the time, and still one left for which the fix is not deployed. That said, the minimal test case for this ( https://en.wikipedia.org/w/index.php?title=User:JohnCD/VEtest5&diff=next&oldid=561489465 ) does have a neighboring change.
Here are actually two bugs:

1) a VE bug that causes that paragraph to be dirtied
2) a Parsoid bug that does not round-trip the bolding properly when using selser on bold elements

Should I open a separate bug for VisualEditor, or do you have one for this already?
This turns out to be a Parsoid bug:

$ echo "Foo '''''bar''''' baz" > wt
$ node parse.js --wt2html < wt | tee html
<body><p data-parsoid='{"dsr":[0,21,0,0]}'>Foo <i data-parsoid='{"dsr":[4,14,2,2]}'><b data-parsoid='{"autoInsertedEnd":true,"dsr":[6,12,3,0]}'>bar</b></i> baz</p>
</body>
$ sed 's/baz/baaz/g' < html | tee html2
<body><p data-parsoid='{"dsr":[0,21,0,0]}'>Foo <i data-parsoid='{"dsr":[4,14,2,2]}'><b data-parsoid='{"autoInsertedEnd":true,"dsr":[6,12,3,0]}'>bar</b></i> baaz</p>
</body>
$ node parse.js --html2wt --selser --oldtextfile wt --oldhtmlfile html < html2
Foo '''''bar'' baaz

Note that this doesn't break if there is no DOM change (i.e. if you pipe in html rather than html2 in the last step), and it also doesn't break if selser is disabled (i.e. if you omit --selser in the last step).
We've seen this come up a number of times in our testing; I haven't investigated this one yet.
Roan, can you tell how we're dirtying the DOM such that Parsoid changes these at all?
Currently we don't and cause major headaches for Parsoid.

--------------------------
**Version**: unspecified
**Severity**: major
**ignatzmice.wiki** wrote:

Apparently bug 50080 is a duplicate of this bug. However, that bug is still showing up: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=564509171#VE_totally_screwing_up
*** Bug 50108 has been marked as a duplicate of this bug. ***
*** Bug 50108 has been marked as a duplicate of this bug. ***
*** Bug 50106 has been marked as a duplicate of this bug. ***
*** Bug 50101 has been marked as a duplicate of this bug. ***
*** Bug 50099 has been marked as a duplicate of this bug. ***
*** Bug 50080 has been marked as a duplicate of this bug. ***
Related URL: https://gerrit.wikimedia.org/r/70109 (Gerrit Change If0a5bcc67d3a172de0e8839cfda11efacfbf36ff)
Which causes this dirty diff:

'''Foo<!--bar-->baz'''

=>

'''Foo'''<!--bar-->'''baz'''

Of course annotating un-deletable metadata means if 'Foobaz' is erased you will be left with:

'''<!--bar-->'''

but that's less of a problem, and could be fixed by Parsoid.

--------------------------
**Version**: unspecified
**Severity**: normal
Related URL: https://gerrit.wikimedia.org/r/70061 (Gerrit Change I40da3d5e8e987571195142304b1a853e177e36ff)
Screenshot

See the screenshot; it appears in Monobook on enwiki and mediawiki.org as of the latest release. Kiiinda a problem.

(the other interstitials there - review your changes/save page - are also shrunk).

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

**Attached**: {F11418}
Now fixed in master and will be deployed in a few minutes' time.
Change 75814 merged by jenkins-bot:
Fix font size for overlays in Monobook

https://gerrit.wikimedia.org/r/75814
I'd add that even on en.wp Monobook is used by many (at least if I read correctly  http://en.wikipedia.org/wiki/Wikipedia:Database_reports/User_preferences#Skin ).
I had quite a few complaints about this now at it.wp, so it would really great if we managed to fix this ASAP. Thanks!

(confl. by Gerrit: fixed now?)
Change 75814 had a related patch set uploaded by Esanders:
Fix font size for overlays in Monobook

https://gerrit.wikimedia.org/r/75814
**mrkmg90** wrote:

Review changes popup

The review changes popup also has the same sizing issues...

My eyes strain so hard trying to read the lines!

**Attached**: {F11419}
(In reply to comment #6)
> Can I suggest that the title of this bug is changed to something more
> meaningful?  If the words "edit summary" were included there would probably
> be fewer duplicatates reported.

Done.
Can I suggest that the title of this bug is changed to something more meaningful?  If the words "edit summary" were included there would probably be fewer duplicatates reported.
*** Bug 51315 has been marked as a duplicate of this bug. ***
*** Bug 51034 has been marked as a duplicate of this bug. ***
You could add a CSS rule that uses the same technique for the dialog.

Setting a simple relative font size (0.7em or something like that) makes it impossible to set the browser's default size to something sensible, as 0.7 * something sensible is usually too small. The non-linear nature of keyword scaling gives a good compromise between honoring a browser's font size and providing sane defaults despite 16px browser defaults.

So if there are other JS-free solutions to this issue these days then that would be great.
This is due to Monobook's "interesting" way of resetting the font-size to a consistent value cross-browser. It sets the <body> font-size to x-small, and then turn it back up to regular size with "font-size: 127%;" from their globalWrapper div.

Due to this odd construct, any new elements attached to the <body> have an exceptionally small font size.

Short of hardcoding a larger font-size for the overlay wrappers in Monobook or appending to #globalWrapper in monobook (which might cause others bugs due to not being in the <body> directly) - short of that this is a tough one to get right. Ideally core would fix this in Monobook by using the same font-size technique used by Vector.

In Monobook's author's defence (Gabriel), the browsers we had to support when Monobook was being developed made it quite difficult to do right so this was probably the best way to do it at the time – but we no longer need to worry about IE5.5, IE4-for-Mac, Opera<7 etc.
Timo, what have you wrought?! ;-)
You can't tab from the edit summary box to the "Save page" button, or the reference inspector to the "Apply changes" button, etc.

This is important for accessibility. Currently, there is no way to confirm the action using only the keyboard.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50897
Hmm, yeah, this has regressed for Firefox. Yay for browser bugs. Will follow-up on bug 51918.
Enwiki, Firefox nightly on Mac. But does seem to work on office with Chrome.
I can on enwiki, MediaWiki.org and Beta Labs – where are you having this issue?
This appears to be broken again- can't tab to "save page" in the current release. Prefer to reopen this bug or file a new one?
This bug is fixed. Will use bug 51918 to track changes to tab order instead.
*** Bug 52080 has been marked as a duplicate of this bug. ***
The current tab order is pants, and is not what was requested in comment 1 or comment 5.

From the edit summary box, the tab order is now:
1. the link "minor edit" beside the 'minor edit' checkbox.
2. "Save Page" button
3. "Review your changes" button
Then three tabs for the links in the footer of this windows.

Tabbing to the _link_ "minor edit" is a bug in the current implementation.

Unless there is a good reason to do otherwise, the tab order should be the same as the source editor (muscle memory).  See also bug 51918 for a tab order request.
Fixed and will get deployed in a few minutes.
Change 75594 merged by jenkins-bot:
Make ButtonWidgets more accessible

https://gerrit.wikimedia.org/r/75594
Patch above should fix original bug. Issue of tabbing from surface to 'Save page' is also partly fixed, but because of DOM order you have to shift+tab. If we want to switch these round, please open a new bug.
Change 75594 had a related patch set uploaded by Esanders:
Makes ButtonWidgets more accessible

https://gerrit.wikimedia.org/r/75594
There seem to be two distinct requests:

* getting from the editing "surface area" to the edit summary input (with a tab key?)

* getting from the edit summary input to the save page or review changes buttons (with a tab key)
From bug 50897 comment 2:

In the old editor, I would simply use TAB to reach the edit summary, type my
edit summary and press ENTER to activate the "Save page" button and save. If I
wanted to mark the edit minor, then I could type my edit summary, press TAB,
SPACE, and then ENTER to "Save page".

I can see that the new box for entering an edit summary allows newlines to be
entered. I am not sure this is a good idea, because I just used a WSYIWYG
editor and now "What I see" - well-formatted paragraphs describing my edit - is
not going to be "what I get" - everything smashed on one line in the article
history. But that is perhaps grist for another bug mill.

It seems that the "Save page" button never receives caret focus if I use TAB to
try to get there. This would seem to have accessibility ramifications.
*** Bug 51918 has been marked as a duplicate of this bug. ***
*** Bug 51913 has been marked as a duplicate of this bug. ***
It's not really an enhancement, since it is preventing proper accessibility. But so long as it is looked at and fixed, that's what really matters :)
attr( { role: 'button', tabIndex: 0 } ) and add return keypress events to all of them.

Also dialogs should have role = dialog and buttons that pop up dialogs should have  aria-haspopup
--------------------------
**Version**: unspecified
**Severity**: normal
Totally conceivable that we fixed this in the past 15 months with the thousands of other changes (3683 since this point by my count). Marking as WORKSFORME.
I can't reproduce this in IE10.
(In reply to This, that and the other (TTO) from comment #2)
> Does not occur in IE11. Has an official decision been made on whether to
> support IE <= 10?

The ambition is to support IE9 and up; IE10 doesn't add much compared to IE9, but is probably a necessary stepping-stone. If it turns out to be too much work, we'll abandon efforts, but for now, yes, this is on the worklist.
Does not occur in IE11. Has an official decision been made on whether to support IE <= 10?
(Does this also apply to the first comment here? :) )
In IE10, any attempt to open the transclusion editor leads to a stack overflow. 

In the dev console I get this:

--- 
SCRIPT28: Out of stack space 
load.php, line 46 character 700 [this location is different every time]

SCRIPT5: Access is denied.
load.php, line 305 character 273

SCRIPT5: Access is denied.
load.php, line 305 character 273

SCRIPT5: Access is denied.
load.php, line 305 character 273 
[... ad infinitum]

SCRIPT2343: Stack overflow at line: 46 [different every time]

SCRIPT5: Access is denied.
load.php, line 305 character 273
---

--------------------------
**Version**: unspecified
**Severity**: normal
This doesn't happen in IE10 with master.
1. Use Chrome 27 to edit [[Pancytopenia#External links]] in VE
2. Try to cut the {{Commons category}} template (using Ctrl+X/Cmd+X or right click/Cut)

The browser tab crashes.

Seen on Windows and Mac.

No idea how to find any debugging info about the crash.

--------------------------
**Version**: unspecified
**Severity**: major
Fixed in master; will be deployed on Thursday as part of the regular push.
Change 81280 merged by jenkins-bot:
Don't render <meta>/<link>/<style> tags in GeneratedContentNode

https://gerrit.wikimedia.org/r/81280
Change 81280 had a related patch set uploaded by Catrope:
Don't render <meta>/<link>/<style> tags in GeneratedContentNode

https://gerrit.wikimedia.org/r/81280
Since <link> and <style> don't render in a useful way in the DOM (if they would ever be in wikitext, they'd be exported to VE as generated content or some other special thing that we can visualise and edit through an inspector or dialog)..

It is fixed in Chromium 30.

Updated summary to mention Chromium, not Chrome. This is likely affecting Opera 15 as well, for example.

Since we don't want to 2 weeks for this to land in stable, and we can safely strip these out before we render them in CE in the first place, let's do that.
I think this is the patch that fixed it in Chrome 30:

https://codereview.chromium.org/14995014
https://trac.webkit.org/changeset/150402

Which would mean that this is the upstream bug: 

http://code.google.com/p/chromium/issues/detail?id=177470
https://bugs.webkit.org/show_bug.cgi?id=116479
(In reply to comment #13)
> @Tim: Which chromium version is the stacktrace from?

It's the Ubuntu package version 28.0.1500.71-0ubuntu1.12.04.1
I can still reproduce this on https://en.wikipedia.org/wiki/Pancytopenia?veaction=edit#External_links with Chrome 28 (stable channel).

However when testing on Chrome 30 (dev channel), I can no longer reproduce this.

Confirmed that removing the [
<link rel=​"mw:​WikiLink/​Category" href=​"./​Category:​Commons_category_without_a_link_on_Wikidata" data-parsoid=​"{"stx":​"simple","a":​{"href":​"./​Category:​Commons_category_without_a_link_on_Wikidata"}​,"sa":​{"href":​"Category:​Commons category without a link on Wikidata"}​}​" about=​"#mwt7">​
] tag from the {{commonscat}} template before cutting, prevents the crash.


@Tim: Which chromium version is the stacktrace from?

Filed upstream: https://code.google.com/p/chromium/issues/detail?id=267059
I'll try to isolate this to produce a minimal test case, see how we can work around it in VE, and report it to the Chrome people. It's not acceptable for a browser to segfault even on invalid HTML.
The node variable in frame 3 of my backtrace is indeed a <link> element.
It seems that this bug has to do with link html tag.

In both examples (Pancytopenia and Lumpectomy) if I delete <link> node (using debug tools) from inside (in second example it is not a direct child) of the node to cut then when I'm cutting it browser tab does not crash anymore.

Based on the w3c documentation it seems to me that we are using link tag incorrectly - value of attribute "rel" should be one of the values listed here http://www.w3schools.com/tags/tag_link.asp but in our case it is "mw:WikiLink/Category".

In case of templates in VE we are simply rendering HTMLDOM that we are getting from Parsoid, so fixing it in Parsoid (not using link tag incorrectly) should solve this problem. (I'm making some assumptions here - it should be verified first in some sort of isolation - jsfiddle.)

For now as a quick fix we can strip all link nodes when we are rendering template in the VE.