When running Echo extensions tests under HHVM/Zend, Jenkins ends up with a failure:

```
1) EchoTitleLocalCacheTest::testGet
Failed asserting that null is an instance of class "Title".

extensions/Echo/tests/phpunit/includes/cache/TitleLocalCacheTest.php:37
tests/phpunit/MediaWikiTestCase.php:141
```

In a workspace with the following extensions:

mediawiki/extensions/Echo
mediawiki/extensions/JsonConfig
mediawiki/extensions/Mantle
mediawiki/extensions/MobileApp
mediawiki/extensions/MobileFrontend
mediawiki/extensions/VisualEditor
mediawiki/extensions/WikiGrok
mediawiki/extensions/ZeroBanner
mediawiki/extensions/ZeroPortal


Running the Echo tests standalone pass ( php tests/phpunit/phpunit.php extensions/Echo )

The whole testsuite fails though:
```
cd tests/phpunit
php phpunit.php --testsuite extensions
```

Or slightly faster:
```
cd tests/phpunit
php phpunit.php --testsuite extensions --filter 'Echo' --stop-on-failure
```
Filed separately as T88039 since that one is not related to HHVM.
Filed separately as T88039.
Failed again just now:

https://integration.wikimedia.org/ci/job/mwext-Flow-testextension-zend/344/consoleFull
Change 184420 abandoned by Hashar:
Fix EchoTitleLocalCacheTest::testGet corner case

[[https://gerrit.wikimedia.org/r/184420]]
Change 184420 had a related patch set uploaded (by Hashar):
Fix EchoTitleLocalCacheTest::testGet corner case

[[https://gerrit.wikimedia.org/r/184420]]

#patch-for-review
I have pushed the fix to 1.25wmf13 and 1.25wmf14 mediawiki/core branches (and "deployed").
Change 184344 merged by jenkins-bot:
Fix EchoTitleLocalCacheTest::testGet corner case

[[https://gerrit.wikimedia.org/r/184344]]
Change 184343 merged by jenkins-bot:
Fix EchoTitleLocalCacheTest::testGet corner case

[[https://gerrit.wikimedia.org/r/184343]]
Change 184344 had a related patch set uploaded (by Hashar):
Fix EchoTitleLocalCacheTest::testGet corner case

[[https://gerrit.wikimedia.org/r/184344]]

#patch-for-review
Change 184343 had a related patch set uploaded (by Hashar):
Fix EchoTitleLocalCacheTest::testGet corner case

[[https://gerrit.wikimedia.org/r/184343]]

#patch-for-review
Merged in by Matthias \O/
Change 183840 merged by jenkins-bot:
Fix EchoTitleLocalCacheTest::testGet corner case

[[https://gerrit.wikimedia.org/r/183840]]
The patch [[ https://gerrit.wikimedia.org/r/183840 | 183840 ]] for Echo does fix the job testing multiple extensions together:
 
https://integration.wikimedia.org/ci/job/mediawiki-phpunit-integration-hhvm/15/console

Pending review/merge.
Change 183840 had a related patch set uploaded (by Hashar):
Fix EchoTitleLocalCacheTest::testGet corner case

[[https://gerrit.wikimedia.org/r/183840]]

#patch-for-review
Could someone from the #Collaboration-Team assist in tracking down this bug?  I have looked a bit at the cache code and attempted to debug it but eventually got lost in the code :-/

The way to reproduce:

Clone core / vendor and:

mediawiki/extensions/Echo
mediawiki/extensions/JsonConfig
mediawiki/extensions/Mantle
mediawiki/extensions/MobileApp
mediawiki/extensions/MobileFrontend
mediawiki/extensions/VisualEditor
mediawiki/extensions/WikiGrok
mediawiki/extensions/ZeroBanner
mediawiki/extensions/ZeroPortal

Setup a basic wiki via maintenance/install.php

```
cd tests/phpunit
php phpunit.php --testsuite extensions --filter 'Echo' --stop-on-failure
```

Should fails.

If one only run the Echo tests they pass ( php tests/phpunit.php extensions/Echo ).
I forgot to reopen this task, see above for a way to reproduce.
Example to reproduce:

```
cd tests/phpunit
php phpunit.php --testsuite extensions --filter 'Echo' --stop-on-failure
```

There must be a race condition somewhere in the MRU Cache or Title local cache.
The standalone job pass now https://integration.wikimedia.org/ci/job/mwext-Echo-testextension-hhvm/3/  but fails when being run with other extensions https://integration.wikimedia.org/ci/job/mediawiki-phpunit-integration-hhvm/11/console

That last job uses:

mediawiki/extensions/Echo
mediawiki/extensions/JsonConfig
mediawiki/extensions/Mantle
mediawiki/extensions/MobileApp
mediawiki/extensions/MobileFrontend
mediawiki/extensions/VisualEditor
mediawiki/extensions/WikiGrok
mediawiki/extensions/ZeroBanner
mediawiki/extensions/ZeroPortal

I can reproduce the failure on my local install using Zend
I couldn't get MediaWiki-Vagrant to work to reproduce this.
You can trigger the hhvm job on an Echo proposed patch by commenting in Gerrit: "check experimental".  That will run a build of https://integration.wikimedia.org/ci/job/mwext-Echo-testextension-hhvm/
Hi,

Visual Editor has been enabled on fr.wikt after https://phabricator.wikimedia.org/T65187 ; but now it has been disabled, it seems since last night (maybe since the installation of the version 1.25wmf9 of MediaWiki).

Any idea?
So sorry about this; now fixed.
Change 176182 merged by jenkins-bot:
Followup 313c29f: correct spelling of wiktionary

[[https://gerrit.wikimedia.org/r/176182]]
Change 176182 had a related patch set uploaded (by Catrope):
Followup 313c29f: correct spelling of wiktionary

[[https://gerrit.wikimedia.org/r/176182]]

#patch-for-review
Hey, yes, sorry, it looks like we broke this. My apologies; will get it fixed.
- go to http://en.wikipedia.beta.wmflabs.org/
- log in as Selenium user
- make sure VisualEditor is enabled at http://en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences#mw-prefsection-betafeatures
- go to http://en.wikipedia.beta.wmflabs.org/wiki/Language_Screenshot?veaction=edit
- VisualEditor never opens
- the loading bar in the top-right part of the screen just cycles (see screen shot) {F15998}
--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in en.wiki
Verified the fix in Betalabs and test2
Fixed by 

Followup ca6a16f: use parent selector both for hiding and showing windows

https://gerrit.wikimedia.org/r/173977
From Ritu Swain:

Reopen this issue.
In test2 and beta only.

steps-

1> open the link/math/comment/special characters/ inspectors in Media Settings -> caption sub-editor or the References sub-editor. The inspectors are blank with no UI.

Also see Bug 68130 https://bugzilla.wikimedia.org/show_bug.cgi?id=68130.
see e.g. http://en.wikipedia.beta.wmflabs.org/wiki/Links_VisualEditor_Test?vehidebetadialog=true&veaction=edit

see screen shot for error

--------------------------
**Version**: unspecified
**Severity**: blocker
I'm not sure why OCG broke or what that is but this would have been noticed if things ran tests for extensions that depended on them. In this case MobileFrontend should run qunit and phpunit tests for zero and Mantle should run qunit and phpunit on Flow and MobileFrontend
*** Bug 73375 has been marked as a duplicate of this bug. ***
Please correct me if I am wrong:

The change https://gerrit.wikimedia.org/r/#/c/168233/ to Mantle removed a bunch of javascript which turned out to be used by several other extensions (ZeroBanner and OCG at least).

I guess running the qunit tests of ZeroBanner and OCG with that Mantle patch applied would have caught the issue. If someone has some spare time to verify that it would be rather nice.

From there, I am willing to have a generic qunit job that will tests together all extensions having qunit jobs. This way if Mantle change something, the other extensions would complain.  Does that sounds like a good idea?
Beta labs is working again. Thanks Jon and Jeff.

No need to add anything to anything because merged changes are deployed to beta labs automatically.
(it's going to be easier to update Zero than Mantle and all its dependencies)
Greg does the patch solve the issue? Can we just add to the build?
To be clear:
This is breaking A LOT OF THINGS, pretty much all browser tests are failing all day due to bits not responding.

Jon/Jeff: Can you just revert the change ASAP? The "build is broken" as it were, we can't leave it broken all day.
This is breaking the OCG progress bar in beta as well.

I'm assuming/hoping that Top Men are hard are work on this, and the bug won't survive into production?
Change 173069 merged by jenkins-bot:
Use templates in core to avoid fatals

https://gerrit.wikimedia.org/r/173069
Change 173069 had a related patch set uploaded by Jdlrobson:
Use templates in core to avoid fatals

https://gerrit.wikimedia.org/r/173069
Jeff Hobson and I will work to get this fixed asap.
This looks like it is coming from Zero. I didn't realise they were using this class. I had thought the deprecation warning had been running for long enough to remove it. Will chat to Adam.
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/9dGlL33Y
(Not a Beta Cluster bug)
This commit <https://gerrit.wikimedia.org/r/#/c/168233/> is breaking ZeroBanner <https://github.com/wikimedia/mediawiki-extensions-ZeroBanner/commit/c930255ed39ef11288d5e9e079fa5cd5837675b6>
Failed to load resource: the server responded with a status of 503 (Service Unavailable) http://bits.beta.wmflabs.org/en.wikipedia.beta.wmflabs.org/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector&*
As visible in the first line of your screenshot, there's a load.php request that's 503ing. For me, it's an earlier load.php request that 503s (the startup request), and so I don't get the error, but no JavaScript works.

Is beta labs broken again?
Created attachment 17121
Reference error

**Attached**: {F15211}
screenshot

"Uncaught Error: Unknown dependency: rangefix"  appears while trying to load mobile VE

--------------------------
**Version**: unspecified
**Severity**: blocker

**Attached**: {F15023}
Verified the fix in production
**gerritadmin** wrote:

Change 172440 abandoned by Catrope:
Followup d4c133b: also make TargetEvents depend on ve.track()

Reason:
Sorry, this was not a wmf7 regression, so this should not be cherry-picked

https://gerrit.wikimedia.org/r/172440
**gerritadmin** wrote:

Change 172440 had a related patch set uploaded by Catrope:
Followup d4c133b: also make TargetEvents depend on ve.track()

https://gerrit.wikimedia.org/r/172440
**gerritadmin** wrote:

Change 172431 merged by jenkins-bot:
Followup d4c133b: also make TargetEvents depend on ve.track()

https://gerrit.wikimedia.org/r/172431
**gerritadmin** wrote:

Change 172431 had a related patch set uploaded by Catrope:
Followup d4c133b: also make TargetEvents depend on ve.track()

https://gerrit.wikimedia.org/r/172431
latest failures is https://integration.wikimedia.org/ci/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/322/testReport/junit/(root)/VisualEditor%20Mobile/Switch_from_VisualEditor_to_source_editor/
new js error from logged in user e.g. http://en.m.wikipedia.beta.wmflabs.org/wiki/Sextet#/editor/0 is 

Uncaught TypeError: undefined is not a function VM156:850ve.init.mw.TargetEvents.track VM156:850(anonymous function) VM156:840(anonymous function) load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=minerva&version=20141030T…:46fire load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=minerva&version=20141030T…:44self.fireWith load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=minerva&version=20141030T…:46done load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=minerva&version=20141030T…:135callback load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=minerva&version=20141030T…:141
Verified the fix in test2
Verified the fix in Betalabs
**gerritadmin** wrote:

Change 171306 merged by jenkins-bot:
Follow-up 07251d0: Add mobile target to RangeFix

https://gerrit.wikimedia.org/r/171306
**gerritadmin** wrote:

Change 171306 had a related patch set uploaded by Catrope:
Followup 07251d0: add mobile target to rangefix

https://gerrit.wikimedia.org/r/171306
*** Bug 73039 has been marked as a duplicate of this bug. ***
Can't work out why; supportedSelections is set for both.

--------------------------
**Version**: unspecified
**Severity**: critical
Verified the fix in Betalabs,test2 and production.
Fix now live in production.
**gerritadmin** wrote:

Change 171451 merged by jenkins-bot:
Followup 31bafa1: forgot to rename 'data' to 'args' for citation commands

https://gerrit.wikimedia.org/r/171451
**gerritadmin** wrote:

Change 171451 had a related patch set uploaded by Jforrester:
Followup 31bafa1: forgot to rename 'data' to 'args' for citation commands

https://gerrit.wikimedia.org/r/171451
**gerritadmin** wrote:

Change 171447 merged by jenkins-bot:
Followup 31bafa1: forgot to rename 'data' to 'args' for citation commands

https://gerrit.wikimedia.org/r/171447
**gerritadmin** wrote:

Change 171447 had a related patch set uploaded by Catrope:
Followup 31bafa1: forgot to rename 'data' to 'args' for citation commands

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

1.Insert any template in the page

Observed Result:
VE gets completely unresponsive after this action,Cannot make any other change or save the page. No error in the console.

--------------------------
**Version**: unspecified
**Severity**: critical
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
**gerritadmin** wrote:

Change 170991 merged by jenkins-bot:
Followup 0165a53: don't store an mw.Title object instead of a string in TemplateModel

https://gerrit.wikimedia.org/r/170991
**gerritadmin** wrote:

Change 170991 had a related patch set uploaded by Catrope:
Followup 0165a53: don't store an mw.Title object instead of a string in TemplateModel

https://gerrit.wikimedia.org/r/170991
On any page in beta labs e.g. http://en.wikipedia.beta.wmflabs.org/wiki/Media_Interface_VisualEditor_Test?veaction=edit

Click Cite/Website or any other Cite selection. 

Nothing happens. No Cite inspector appears.

--------------------------
**Version**: unspecified
**Severity**: major
The fix is re-verified in betalabs and test2.
Opening a distinct bug for that one.
This started happening again? Although not for basic reference but for citations and no error in console this time
Verified in betalabs  - Safari, Chrome, and FF.
**gerritadmin** wrote:

Change 170985 merged by jenkins-bot:
Followup 0165a53: fix typo causing undefined to be passed to mw.Title

https://gerrit.wikimedia.org/r/170985
**gerritadmin** wrote:

Change 170985 had a related patch set uploaded by Catrope:
Followup 0165a53: fix typo causing undefined to be passed to mw.Title

https://gerrit.wikimedia.org/r/170985
js error is "TypeError: title is undefined"
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Add a template for example: Cite Web/Citation needed
3.Save the page
4.Reopen the page
5.Reopen the Transclusion dialog for the template you just added

Observed Result:
Instead of the template dialog with all the parameters in it , it appears as an empty "Add Template" dialog 

See the screenshot attached

Environment:Betalabs

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F14841}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Fixed by: https://gerrit.wikimedia.org/r/169966
1. Go to http://en.wikipedia.beta.wmflabs.org/wiki/User:RoanKattouw/Evil_table?veaction=edit
2. Click on a non-templated cell in the table (e.g. the cell that says "simple" in row 2)
3. "undefined is not a function" error appears in console

What happens is that TableMatrix#update runs, and when it hits cell (2,0) (3rd row, 1st column), it will find that cellNode is a ve.dm.MWTransclusionNode rather than a ve.dm.TableCellNode, and so calling .getRowSpan() on it will explode.

We probably need some way to deal with templated rows/cells in the middle of an otherwise normal table, but I'm not entirely sure what that should look like. Maybe we can get away with skipping over these rows/cells everywhere in a consistent manner, and hopefully that will work out OK?

--------------------------
**Version**: unspecified
**Severity**: critical
Verified with the Evil_table given in the link - the js error is not displayed anymore.
**gerritadmin** wrote:

Change 170245 merged by jenkins-bot:
Add support for non-table nodes in tables (e.g. aliens)

https://gerrit.wikimedia.org/r/170245
**gerritadmin** wrote:

Change 170245 had a related patch set uploaded by Esanders:
Add support for non-table nodes in tables (e.g. aliens)

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

* Open https://en.wikipedia.org/wiki/Snowman?veaction=edit

* Mark the sentence "It was 113 feet 7 inches (34.62 m) tall and weighed over 9,000,000 pounds (4,080,000 kg).[1]" and cut it (Strg+X).

* Paste it in again (Strg+V).

* Click before "It" to place the cursor at the beginning of the sentence.


Result: The editor starts adding copies of the sentence in an endless loop, with the templates (see below) replaced by snowmen:

"It was ☃☃ tall and weighed over ☃☃.☃☃It was ☃☃ tall and weighed over ☃☃.☃☃It was ☃☃ tall and weighed over ☃☃.☃☃It was ☃☃ tall and weighed over ☃☃.☃☃It was ☃☃ tall and weighed over ☃☃.☃☃It was ..."

(Actually, if one scrolls or clicks somewhere in the page, the loop may stop, but I've observed it going on for more than a minute, generating 378 copies of the sentence.)


Here is the wikitext source of the sentence:

"It was {{convert|113|ft|7|in|m}} tall and weighed over {{convert|9000000|lb|kg|-4}}.<ref>{{cite web|url=http://www.sundayriveron-line.com/AngusSnowman_1.htm|title=Angus, King of the Mountain &mdash; World's Largest Snowman|date=February 19, 1999|publisher=Sunday River On-Line|archiveurl=http://web.archive.org/web/20071012082219/http://www.sundayriveron-line.com/AngusSnowman_1.htm|archivedate=2007-10-12}}</ref>"

--------------------------
**Version**: unspecified
**Severity**: major
Checked in betalabs and test2 - seems to be fixed.
*** Bug 72491 has been marked as a duplicate of this bug. ***
Yeah, sorry for this; fixed and back-ported on Monday. :-(
PS: Observed in Chromium 37 (no extensions) under Ubuntu both while logged in and while logged out. Under Firefox I can't even get the cutting (step 2) to work, which appears to be a separate bug.
screenshot

Environment- beta

1> click on Cite and pick any citation(book/web/news/journal).E.g- select cite -> book. Cite book dialog opens.
2> JS console error “Uncaught TypeError: undefined is not a function”.
3> Click to Add more information and error in console is “Uncaught TypeError: Cannot read property 'on' of undefined”. See screenshot.
4> Clicking on cancel or insert does not close the dialog.

Screenshot attached.

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F14994}
Verified the fix in production
Verified the fix on test2
Verified the fix in Betalabs
Change 166628 merged by jenkins-bot:
Followup 1fc13cc: fix JS errors caused by incorrect context binding

https://gerrit.wikimedia.org/r/166628
Change 166628 had a related patch set uploaded by Catrope:
Followup 1fc13cc: fix JS errors caused by incorrect context binding

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

Steps to reproduce:

1.Open a page with VE
2.Select any focusable node: citation note,math ,template or image

Observed Result:

The following error appears in the console:
NS_ERROR_FAILURE: 

The context menu for that focusable note is still active in CE ,if you select some other focusable note after this, no context menu appears for it or the one for previous node appears on top of it

Environment:test2 and Betalabs

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F15335}
Verified the fix in production
Verified the backport in test2
Verified the fix in Betalabs
Change 164593 merged by jenkins-bot:
Revert "ve.ce.Surface: Magic workaround for broken Firefox cursoring"

https://gerrit.wikimedia.org/r/164593
Change 164548 merged by jenkins-bot:
Revert "ve.ce.Surface: Magic workaround for broken Firefox cursoring"

https://gerrit.wikimedia.org/r/164548
Change 164593 had a related patch set uploaded by Jforrester:
Revert "ve.ce.Surface: Magic workaround for broken Firefox cursoring"

https://gerrit.wikimedia.org/r/164593
Change 164548 had a related patch set uploaded by Bartosz Dziewoński:
Revert "ve.ce.Surface: Magic workaround for broken Firefox cursoring"

https://gerrit.wikimedia.org/r/164548
Caused by 0d7eaf51767c4061b478610a035a3bc387c0973a (workaround for bug 70724 about broken Firefox cursoring). Calling .collapseToStart() sometimes fixes the selection, and sometimes causes this cryptic exception.

This looks very ugly and very internal, so I'm just going to revert the patch and update the upstream bug report.
Reproducible in standalone with comment nodes too.
Jobs running on Ubuntu Trusty for repositories with submodules are currently broken due to a bug in the Jenkins GIT Plugin.

We use Jenkins GIT Plugin 1.5.0, which uses git-client-plugin 1.0.6:
https://github.com/jenkinsci/git-client-plugin/blob/git-client-1.0.6/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L401-L412

        args.add("submodule", "foreach");
        if (recursive) {
            args.add("--recursive");
        }
        args.add("git reset");
        if (hard) {
            args.add("--hard");
        }

https://integration.wikimedia.org/ci/job/mwext-VisualEditor-npm/4684/console


Cleaning workspace
Resetting working tree
FATAL: Command "submodule foreach --recursive git reset --hard" returned status code 1:
stdout: Entering 'lib/ve'
stderr: /usr/lib/git-core/git-submodule: 552: /usr/lib/git-core/git-submodule: git reset: not found
Stopping at 'lib/ve'; script returned non-zero status.

Trying to reproduce:

jenkins-deploy@integration-slave1007:/mnt/jenkins-workspace/workspace/mwext-VisualEditor-npm$ git submodule foreach --recursive git reset --hard
> works fine

The version of git on Ubunty and Precise both support this command.
The problem lies in the quoting and separation of the arguments.

jenkins-deploy@integration-slave1007:/mnt/jenkins-workspace/workspace/mwext-VisualEditor-npm$ git submodule foreach --recursive 'git reset' --hard
> /usr/lib/git-core/git-submodule: 552: /usr/lib/git-core/git-submodule: git reset: not found

--------------------------
**Version**: wmf-deployment
**Severity**: critical
Plugin bumped to upstream 1.7.1
Apparently this is fixed upstream with: https://github.com/jenkinsci/git-client-plugin/commit/f75720d5de9d79ab4be2633a21de23b3ccbf8ce3  which was shipped with version 1.6.4

```
lang=diff
-        args.add("git reset");
-        if (hard) {
-            args.add("--hard");
-        }
+        args.add("git reset" + (hard ? " --hard" : ""));
```

Thus the whole command is passed as a single string.


Will switch from our fork/patched version to upstream one as part of T100655
Apparently this is fixed upstream with: https://github.com/jenkinsci/git-client-plugin/commit/f75720d5de9d79ab4be2633a21de23b3ccbf8ce3  which was shipped with version 1.6.4

```
lang=diff
-        args.add("git reset");
-        if (hard) {
-            args.add("--hard");
-        }
+        args.add("git reset" + (hard ? " --hard" : ""));
```

Thus the whole command is passed as a single string.
Thank you Timo!

I testing out with the job that shown the issue yesterday: https://integration.wikimedia.org/ci/job/pywikibot-core-tox-nose34-trusty/

Test case:
* Precise fresh workspace > OK
* Precise, rebuild on existing workspace > OK
* Trusty fresh workspace > OK
* Trusty, rebuild on existing workspace > OK
https://wikitech.wikimedia.org/wiki/Nova_Resource:Integration/Jenkins_Plugin

Deployed the .jpi file to Jenkins.
(In reply to Krinkle from comment #0)
> Jobs running on Ubuntu Trusty for repositories with submodules are currently
> broken due to a bug in the Jenkins GIT Plugin.
> 
> We use Jenkins GIT Plugin 1.5.0, which uses git-client-plugin 1.0.6:
> 

Actually, we while GIT Plugin requires git-client-plugin v1.0.5, we currently use git-client-plugin v1.4.6

--

https://github.com/wikimedia/git-client-plugin/commits/git-client-1.4.6%2Bwmf1
https://github.com/wikimedia/git-client-plugin/commit/5d4c940519352a0a38038154f8c9690a7a5dba58#diff-4a13310f7c84a9d6e133def48c0aed5aR558
Created attachment 16643
IRC log of a diagnostic on #pywikibot earlier (time is UTC+2)

For what it is worth, attached is an IRC log from earlier today on #pywikibot.  That resulted in the previous attachment showing the 'git reset' not found issue.

**Attached**: {F15207}
Created attachment 16642
git submodule with GIT_TRACE=1

I found that bug while testing a job for pywikibot/core.git which needs to be run on Trusty (it uses python3.4 which is not on Precise). It yielded:

 /usr/lib/git-core/git-submodule: 552: /usr/lib/git-core/git-submodule: git reset: not found

I have added to the job a parameter GIT_TRACE=1 and ran it again (see attached console output for https://integration.wikimedia.org/ci/job/pywikibot-core-tox-nose34-trusty/9/console ).  The git command shown:

 stderr: trace: exec: 'git-submodule' 'foreach' '--recursive' 'git reset' '--hard'


Note how git reset is enclosed in quote.  Since git version 1.9.0, that is passed as a single argument to git-submodule which can find such executable 'git reset'.

I eventually had an audio call and had to be back home.   The Jenkins git-client-plugin needs to be patched to split 'git reset' to be two args, then compiled via maven and uploaded to Jenkins.

You can take backup of the existing version by looking on gallium under /var/lib/jenkins/plugins/ for some .jpi files.


Note: last time I have upgraded the Jenkins git plugin,  the whole CI setup went mad :-/  I gave up investigating the java code change and just stuck to the version we currently have.

**Attached**: {F15206}
Release notes of git 1.9 detailing this change in git-submodule semantics:
 https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/1.9.0.txt

Basically, it used to interpret the argument as a long string (similar to ssh), and letting bash separate the command and arguments. And it now does this at the git level.
screenshot

Environment-test2

1> In a blank page, insert a comment.
2> open edit comment dialog. While the dialog is still open and cursor is blinking inside it, select any of the font styles except Language. For ex- select Bold or Italic.

JS console error is -:

“Uncaught NotFoundError: Failed to execute 'insertBefore' on 'Node': The node before which the new node is to be inserted is not a child of this node”

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

**Attached**: {F14867}
Verified the fix in production
(In reply to Ritu Swain from comment #6)
> Issue resolved in test2, but can be reproduced in beta.

Issue fixed in beta as well.
Issue resolved in test2, but can be reproduced in beta.
Change 163656 merged by Catrope:
Followup a618491: fix JS errors when slugging near annotated inline nodes

https://gerrit.wikimedia.org/r/163656
Change 163656 had a related patch set uploaded by Jforrester:
Followup a618491: fix JS errors when slugging near annotated inline nodes

https://gerrit.wikimedia.org/r/163656
Change 163636 merged by jenkins-bot:
Followup a618491: fix JS errors when slugging near annotated inline nodes

https://gerrit.wikimedia.org/r/163636
Change 163636 had a related patch set uploaded by Catrope:
Followup a618491: fix JS errors when slugging near annotated inline nodes

https://gerrit.wikimedia.org/r/163636
This bug also causes VE to throw errors when loading on pages like http://www.mediawiki.org/wiki/Parsoid/Deployments?debug=true&veaction=edit . This bug happens when an annotated inline node appears at the start of a paragraph.
Cannot open comment box in Betalabs. Throwing the following error in the console:
Uncaught TypeError: Cannot read property '0' of undefined

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
**gerritadmin** wrote:

Change 162647 merged by jenkins-bot:
Update VE core submodule to master (6e68242)

https://gerrit.wikimedia.org/r/162647
**gerritadmin** wrote:

Change 162647 had a related patch set uploaded by Catrope:
Update VE core submodule to master (6e68242)

https://gerrit.wikimedia.org/r/162647
**gerritadmin** wrote:

Change 162671 merged by jenkins-bot:
Account for WhitespacePreservingTextInputWidget#getValue being called early

https://gerrit.wikimedia.org/r/162671
**gerritadmin** wrote:

Change 162671 had a related patch set uploaded by Catrope:
Account for WhitespacePreservingTextInputWidget#getValue being called early

https://gerrit.wikimedia.org/r/162671
Edit any page on beta labs e.g. http://en.wikipedia.beta.wmflabs.org/wiki/Media_Interface_VisualEditor_Test?veaction=edit

Click the Link button. Nothing happens.

Error console shows "TypeError: this.isValid(...).done is not a function"

No other controls seem to be affected by this issue.

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix in production
verified the fix in test2
Verified the fix in Betalabs
**gerritadmin** wrote:

Change 162647 merged by jenkins-bot:
Update VE core submodule to master (6e68242)

https://gerrit.wikimedia.org/r/162647
**gerritadmin** wrote:

Change 162646 merged by jenkins-bot:
Account for isValid() becoming async

https://gerrit.wikimedia.org/r/162646
**gerritadmin** wrote:

Change 162647 had a related patch set uploaded by Catrope:
Make MWLinkTargetInputWidget#isValid asynchronous

https://gerrit.wikimedia.org/r/162647
**gerritadmin** wrote:

Change 162646 had a related patch set uploaded by Catrope:
Account for isValid() becoming async

https://gerrit.wikimedia.org/r/162646
http://de.wikipedia.org/w/index.php?diff=134089498
http://de.wikipedia.org/w/index.php?diff=134090414

VisualEditor is replacing categories in articles with "[[MediaWiki:Badtitletext]]". Please fix it as soon as possible or deactivate VE. We do not have any time or desire to check and correct hundreds of revisions caused by broken software.

--------------------------
**Version**: unspecified
**Severity**: critical
This is caused by bug 70894; we have made an emergency modification to VE which should stop this recurring for now whilst we fix the problem. Sorry for the disruption.
some other occurences:
[1] http://de.wikipedia.org/w/index.php?diff=134086405
[2] http://de.wikipedia.org/w/index.php?diff=134086148
[3] http://de.wikipedia.org/w/index.php?diff=134085483
[4] http://de.wikipedia.org/w/index.php?diff=134085429

in [2], there is also some garbage added to an image invocation.
When you edit a page with VE in IE, CSS styles are normalized, causing dirty diffs. This is because Internet Explorer very aggressively normalizes styles, to the point where we can't tell what the original value was without some nasty hackery.

In practice, this means that any time you save a page in IE, things like style="color: #ffffdd;" get normalized to style="color: rgb(255, 255, 221);", bgcolor="#FFFFDD" gets normalized to bgcolor="#ffffdd" and invalid CSS is removed. The former two are annoying dirty diffs, the latter is actual information loss (someone else can come along later and fix invalid CSS, but not if we remove it).

This normalization is a bug in Internet Explorer. I'm working on a workaround where I extract the original value using an XML parser and stash it so I can restore it later.

hex to rgb normalization: https://fr.wikipedia.org/?diff=107359735
bgcolor normalization: https://sv.wikipedia.org/?diff=27502354
Invalid CSS removal: https://cs.wikipedia.org/?diff=11849661

--------------------------
**Version**: unspecified
**Severity**: major
Deploy scheduled for 08:00 SF time tomorrow.
Change 160597 merged by Catrope:
Use ve.parseXhtml() and ve.serializeXhtml()

https://gerrit.wikimedia.org/r/160597
Change 160596 merged by Catrope:
Use ve.parseXhtml() and ve.serializeXhtml()

https://gerrit.wikimedia.org/r/160596
Change 160584 merged by jenkins-bot:
Use ve.parseXhtml() and ve.serializeXhtml()

https://gerrit.wikimedia.org/r/160584
Change 160597 had a related patch set uploaded by Jforrester:
Use ve.parseXhtml() and ve.serializeXhtml()

https://gerrit.wikimedia.org/r/160597
Change 160596 had a related patch set uploaded by Jforrester:
Use ve.parseXhtml() and ve.serializeXhtml()

https://gerrit.wikimedia.org/r/160596
Change 160584 had a related patch set uploaded by Catrope:
Use ve.parseXhtml() and ve.serializeXhtml()

https://gerrit.wikimedia.org/r/160584
Change 160583 had a related patch set uploaded by Catrope:
Work around IE's normalization of style attributes by abusing XML parsers

https://gerrit.wikimedia.org/r/160583
Initial case:

1. Go to https://www.mediawiki.org/wiki/VisualEditor/status?veaction=edit.
2. Scroll to the final section, remove the "…", and insert template.
3. Pick "key press" in the normal way.
4. Set parameter 1 as "Ctrl", parameter 2 as "Shift", and parameter 3 as "V".
5. Press "Insert".

Result: dialog remains pending whilst endless snowmen get inserted.

--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://www.mediawiki.org/w/index.php?title=VisualEditor/status&oldid=1152478
Verified the fix in mediawiki.org with the case mentioned above.
Change 160105 merged by jenkins-bot:
Account for the case where a FocusableNode has an empty outerRects array

https://gerrit.wikimedia.org/r/160105
Change 160105 had a related patch set uploaded by Jforrester:
Account for the case where a FocusableNode has an empty outerRects array

https://gerrit.wikimedia.org/r/160105
Change 160102 merged by jenkins-bot:
Account for the case where a FocusableNode has an empty outerRects array

https://gerrit.wikimedia.org/r/160102
Change 160102 had a related patch set uploaded by Catrope:
Account for the case where a FocusableNode has an empty outerRects array

https://gerrit.wikimedia.org/r/160102
On any page in beta labs e.g. http://en.wikipedia.beta.wmflabs.org/wiki/Cite_VisualEditor_Test?veaction=edit

click Cite, then choose any of Website, Book etc. 

User should see an inspector dialog for that cite, but nothing appears

--------------------------
**Version**: unspecified
**Severity**: critical
Verified the fix in production
Verified the fix in test2 for all dialogs in Chrome and Firefox
Believe that this is now fixed in phase 0 (test2 etc.)
Verified the fix in Betalabs but this is happening in test2 right now
This was because we failed to do the MW-core pull-through of a breaking change in OOUI (whoops).
Also true of Insert, etc, anything with a selection list
I cannot load any page with Mobile VE with iOS safari but it works fine in desktop Safari.

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix in Betalabs.
This should be fixed now.

See https://gerrit.wikimedia.org/r/#/c/150995/
This just appeared as of a couple hours ago:

1. Go into VE edit mode on beta labs
2. Select a word and tap link inspector icon in toolbar
3. Tap done to make the word a link
4. When you return to the article in edit mode, you're no longer able to scroll the content or tap in to drop the cursor anywhere. All you can do is save, reopen the link inspector, or abandon changes.

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix in betalabs and test2
Change 150719 merged by jenkins-bot:
Revert "Make scrolling in PanelLayout smoother on iOS"

https://gerrit.wikimedia.org/r/150719
Change 150719 had a related patch set uploaded by JGonera:
Revert "Make scrolling in PanelLayout smoother on iOS"

https://gerrit.wikimedia.org/r/150719
1. Make a change to a page on en.wiki and click review changes form the save dialog
2. Close the save dialog and make another change, go back to the review changes page

Observe that only your first change is visible. The same is true if you submit the change.

This does not happen on my local wiki where I don't have pre-save caching enabled, so presumably it has something to do with that.

--------------------------
**Version**: unspecified
**Severity**: critical
*** Bug 68764 has been marked as a duplicate of this bug. ***
*** Bug 68761 has been marked as a duplicate of this bug. ***
Nasty regression, but awesome response time - thanks, James & Ed!
*** Bug 68693 has been marked as a duplicate of this bug. ***
Now back-ported to wmf14 and wmf15 in production.
*** Bug 68595 has been marked as a duplicate of this bug. ***
Was fixed by https://gerrit.wikimedia.org/r/#/c/149392 . Quite serious though so should be deployed asap.
This is fixed by this - https://gerrit.wikimedia.org/r/#/c/149392/
I cannot open any page with Mobile VE with iOS Safari, however in desktop Safari I am not seeing this issue

--------------------------
**Version**: unspecified
**Severity**: critical
Verified the fix
This could be the HHVM issue…
It seems, it got resolved! Did anyone work on this one?
This occurs on desktop Safari too.

It disappears when debug=true is used. Looking at the content response, it looks like Safari is getting the gzip'ed content and not decoding it for some reason.
The error message that I get in the console is:SyntaxError: Invalid character '\u0031'
What was the error message you were seeing? Something about an invalid character.
**Author:** `jgonera`

**Description:**
When running VE on mobile, in the console:

$('.ve-ui-context')
[]
$('.ve-ui-mobileContext')
[]

I thought that the context not appearing on mobile was a CSS regression but it seems it's no longer attached to the DOM. Too tired today to figure out why (or to figure out how DesktopContext is attached to DOM).

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix in production
Verified the fix in Betalabs and test2
Change 149356 merged by jenkins-bot:
Attach mobile surface to the toolbar

https://gerrit.wikimedia.org/r/149356
Change 149356 had a related patch set uploaded by Catrope:
[WIP] Attach mobile surface to the toolbar

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

Steps to reproduce:

1.Open a page with VE which contains a link 
2.Press return after the link

Observed Result:
Uncaught TypeError: Cannot read property 'getOuterLength' of undefined VM112:521 
appears in the console

See the screenshot attached

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

**Attached**: {F14637}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Verified the fix in Betalabs
Change 148559 merged by jenkins-bot:
Followup b6cc76d4: call parent's onSetup/onTeardown

https://gerrit.wikimedia.org/r/148559
Change 148559 had a related patch set uploaded by Catrope:
Followup b6cc76d4: call parent's onSetup/onTeardown

https://gerrit.wikimedia.org/r/148559
In hebrew wikipedia, when I have created a new article, added a tamplate to it, wrote text and made it bold or italic - instead of the text appeared a pawn symbol, that was bold or italic according to the button I have clicked.

--------------------------
**Version**: unspecified
**Severity**: critical
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68147
https://bugzilla.wikimedia.org/show_bug.cgi?id=68691
Should be now fully fixed in master; deployment to production scheduled for 4 hours' time.
Change 150224 merged by jenkins-bot:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150274 merged by jenkins-bot:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150274
Change 150224 restored by Catrope:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150274 had a related patch set uploaded by Catrope:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150274
Change 150224 abandoned by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

Reason:
I give up.

https://gerrit.wikimedia.org/r/150224
Change 150224 restored by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150224 abandoned by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150224 had a related patch set uploaded by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150224
Change 150222 abandoned by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150222
Change 150222 had a related patch set uploaded by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/150222
Change 149920 merged by jenkins-bot:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/149920
Change 149920 had a related patch set uploaded by Jforrester:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/149920
Change 149920 had a related patch set uploaded by Catrope:
Generate only one pair of snowmen for multi-sibling nodes

https://gerrit.wikimedia.org/r/149920
The cause here is template with multiple unwrapped siblings,

e.g. Template:Done -> [[File:tick.svg|20px]] Done
*** Bug 68691 has been marked as a duplicate of this bug. ***
1. Add a new page in Wikipedia, with the visual editor.
2. Add tamplate to it (I used "מיון" tamplate in the hebrew wikipedia).
3. Write any text after the tamplate.
4. Select the text.
5. Click on the "bold" or "italic" buttons.
6. A pawn symbol appears.
Can you clarify the instructions?
*** Bug 67797 has been marked as a duplicate of this bug. ***
Confirmed in Chrome and Firefox.
Screenshot

After saving a page,cursor still remains enabled on readmode in Betalabs.

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

**Attached**: {F14361}
WFM – BetaLabs hiccup?
This is happening again on Betalabs
Verified the fix in test2
Verified the fix in Betalabs
Change 146984 merged by jenkins-bot:
Close the save dialog on teardown only, not on save

https://gerrit.wikimedia.org/r/146984
Change 146984 had a related patch set uploaded by Jforrester:
Close the save dialog on teardown only, not on save

https://gerrit.wikimedia.org/r/146984
<Krenair> So we're not destroying the surface, because the SaveDialog closing promise doesn't get resolved
<Krenair> it's rejected with "Cannot close window: window already closing with different data"
<TrevorParscal> Krenair: that's not good
<TrevorParscal> Krenair: have you identified why it doesn't get resolved?
<Krenair> Not past that error, yet
<Krenair> Even if I check !this.saveDialog.getManager().isClosing() before trying to this.saveDialog.close() it does that
<Krenair> It's fine if I check !this.saveDialog.getManager().closing instead though
<Krenair> well, then I get "Uncaught TypeError: Cannot read property 'getComputedStyle' of undefined", but the surface is torn down
<Krenair> TrevorParscal, want to investigate further?
<TrevorParscal> that's to do with removing the window from the dom before it's done with teardown
<TrevorParscal> I added code in my rewrite which used promises in init to wait for the window to close before removing things, I saw that same error
<TrevorParscal> maybe I missed something?
*** Bug 68116 has been marked as a duplicate of this bug. ***
*** Bug 68110 has been marked as a duplicate of this bug. ***
From bug 58221:

Tilman Bayer 2014-07-14 04:16:20 UTC

Another example:

In https://en.wikipedia.org/w/index.php?oldid=616866203&veaction=edit , place the cursor left of "F" in the word "Former" in the first paragrah, and hit the delete key. The "F" is deleted correctly, but the cursor jumps two to the left (between "s" and ".").

Reproduced in Firefox and Chromium under Ubuntu 14.04.

--------------------------
**Version**: unspecified
**Severity**: major
*** Bug 68037 has been marked as a duplicate of this bug. ***
Now fixed. Thank you, all.
Change 146166 merged by Mwalker:
Update VE core submodule to cfdb3a54

https://gerrit.wikimedia.org/r/146166
Change 146165 merged by jenkins-bot:
Update VE core submodule to e3fa7ec8

https://gerrit.wikimedia.org/r/146165
Change 146166 had a related patch set uploaded by Jforrester:
Update VE core submodule to cfdb3a54

https://gerrit.wikimedia.org/r/146166
Change 146165 had a related patch set uploaded by Jforrester:
Update VE core submodule to e3fa7ec8

https://gerrit.wikimedia.org/r/146165
Change 146161 abandoned by Jforrester:
Update VE core submodule to cfdb3a54

https://gerrit.wikimedia.org/r/146161
Change 146159 abandoned by Jforrester:
Update VE core submodule to e3fa7ec8

https://gerrit.wikimedia.org/r/146159
Change 146161 had a related patch set uploaded by Jforrester:
Update VE core submodule to cfdb3a54

https://gerrit.wikimedia.org/r/146161
Change 146159 had a related patch set uploaded by Jforrester:
Update VE core submodule to e3fa7ec8

https://gerrit.wikimedia.org/r/146159
Change 146138 merged by jenkins-bot:
Prevent double counting of DM nodes in getNodeAndOffset

https://gerrit.wikimedia.org/r/146138
Change 146137 merged by jenkins-bot:
Prevent double counting of DM nodes in getNodeAndOffset

https://gerrit.wikimedia.org/r/146137
Change 146138 had a related patch set uploaded by Jforrester:
Prevent double counting of DM nodes in getNodeAndOffset

https://gerrit.wikimedia.org/r/146138
Change 146137 had a related patch set uploaded by Jforrester:
Prevent double counting of DM nodes in getNodeAndOffset

https://gerrit.wikimedia.org/r/146137
Change 146079 merged by jenkins-bot:
Prevent double counting of DM nodes in getNodeAndOffset

https://gerrit.wikimedia.org/r/146079
Change 146079 had a related patch set uploaded by Esanders:
Prevent double counting of DM nodes in getNodeAndOffset

https://gerrit.wikimedia.org/r/146079
The problem here appears to be the IPA template which returns two <span>s which are about-grouped (about="#mwtX"). I imagine the cursoring logic is expecting an alien to consist of only one node.
Anywhere we do logical cursoring you get off by two errors, e.g. delete/backspace/arrow keys (after clicking)
Cannot open any cite options or template in betalabs or add it in an article throwing error:
Uncaught TypeError: Cannot read property 'bind' of undefined

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix in production.
Verified the fix in test 2
Change 145431 merged by jenkins-bot:
Fix cite/template dialogs

https://gerrit.wikimedia.org/r/145431
Verified the fix in Betalabs
Fixed on master. Need to get a deployer to deal with production (test sites + mediawiki.org currently effected)
Change 145427 merged by jenkins-bot:
Fix cite/template dialogs

https://gerrit.wikimedia.org/r/145427
Change 145431 had a related patch set uploaded by Jforrester:
Fix cite/template dialogs

https://gerrit.wikimedia.org/r/145431
Change 145427 had a related patch set uploaded by Alex Monk:
Fix cite/template dialogs

https://gerrit.wikimedia.org/r/145427
Whoops.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Formula
3.Attempt to insert "\pi" inside the inspector

Observed Result:
As soon as you type \ in the inspector , it loses its focus and tries to parse that \ and shows error "Failed to parse (lexing error)"


Environment:Betalabs
See the screenshot attached
Browser:Chrome

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

**Attached**: {F14534}
Verified the fix in production
Verified the fix in test2
Change 147501 merged by jenkins-bot:
Ignore staging events in CE surface

https://gerrit.wikimedia.org/r/147501
Change 145442 abandoned by Esanders:
Keep focus when live editing

Reason:
Fixed better by If03a200cead in core.

https://gerrit.wikimedia.org/r/145442
Change 147501 had a related patch set uploaded by Esanders:
Ignore staging events in CE surface

https://gerrit.wikimedia.org/r/147501
Change 145444 had a related patch set uploaded by Alex Monk:
Fix rerendering in VE

https://gerrit.wikimedia.org/r/145444
Change 145442 had a related patch set uploaded by Esanders:
Keep focus when live editing

https://gerrit.wikimedia.org/r/145442
On https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-06-11?veaction=edit I am getting this stack trace from VE:

Error: Models must be subclasses of ve.dm.Model
    at VeDmModelRegistry.ve.dm.ModelRegistry.register (eval at <anonymous> (https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=en&m…Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20140612T192101Z:4:670), <anonymous>:276:655)
    at mw.loader.implement.math-visualeditor-mwmathinspector-title (https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=en&modules=ext.math.visualEditor&skin=vector&version=20140613T004358Z&*:1:363)
    at runScript (https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=en&m…w.MwEmbedSupport&only=scripts&skin=vector&version=20140612T192101Z:171:201)
    at checkCssHandles (https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=en&m…w.MwEmbedSupport&only=scripts&skin=vector&version=20140612T192101Z:171:602)
    at execute (https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=en&m…w.MwEmbedSupport&only=scripts&skin=vector&version=20140612T192101Z:172:384)
    at Object.mw.loader.implement (https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=en&m…w.MwEmbedSupport&only=scripts&skin=vector&version=20140612T192101Z:178:208)
    at https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=en&modules=ext.math.visualEditor&skin=vector&version=20140613T004358Z&*:1:11

Chromium 35.0.1916.153, Linux

--------------------------
**Version**: unspecified
**Severity**: critical
Fixed. Thank you, Ori!
Change 139445 merged by Ori.livneh:
Fix the VisualEditor parts of Math-wmf9 with a working cherry pick of I7d5e1174

https://gerrit.wikimedia.org/r/139445
Change 139445 had a related patch set uploaded by Jforrester:
Fix the VisualEditor parts of Math-wmf9 with a cherry pick of I7d5e1174

https://gerrit.wikimedia.org/r/139445
Change 139429 merged by Ori.livneh:
Fix the VisualEditor parts of Math-wmf9 with a cherry pick of I7d5e1174

https://gerrit.wikimedia.org/r/139429
Change 139429 had a related patch set uploaded by Jforrester:
Fix the VisualEditor parts of Math-wmf9 with a cherry pick of I7d5e1174

https://gerrit.wikimedia.org/r/139429
I can reproduce this issue in Chrome 35.0.1916.114 and Firefox 29.0.1 on openSUSE, for any page on mediawiki.org.
Note: This happens in mediawiki.org (1.24wmf7 (941d0e1)), but not in en.wikipedia (1.24wmf6 (4331f6b)).

To reproduce:
1. Edit an article. Make a change.
2. Press "Save page".
3. Try writing an edit summary.

Observed: The text is added to the article.

Expected: The cursor must automatically focus in the edit summary field.

--------------------------
**Version**: unspecified
**Severity**: major
Change 137926 merged by jenkins-bot:
Move save panel init to getReadyProcess

https://gerrit.wikimedia.org/r/137926
Thanks Ed!
Change 137971 had a related patch set uploaded by Jforrester:
Move save panel init to getReadyProcess

https://gerrit.wikimedia.org/r/137971
Change 137926 had a related patch set uploaded by Esanders:
Move save panel init to onReady

https://gerrit.wikimedia.org/r/137926
Sorry, that comment was half-written about a different bug. Bah Bugzilla.

I can indeed replicate in wmf7 and above (which is now everywhere).
I can still reproduce it in Firefox and Chrome on mediawiki.org.

In Firefox after opening the Save dialog, if I type, the text is added to the article.

In Chrome the text doesn't seem to be added anywhere.

And what's worse, I can now also reproduce it in the English Wikipedia.
This is concerning; bug 65222 should have fixed this from happening. What browser were you using? I can't replicate in wmf7 in Chrome, Safari or Firefox.

However, it does seem to have regressed in wmf8.
This is bad.

--------------------------
**Version**: unspecified
**Severity**: major
Apparently…
Is this now fixed?
Change 135012 merged by jenkins-bot:
Add createSurface to base target

https://gerrit.wikimedia.org/r/135012
Change 135012 had a related patch set uploaded by Jforrester:
Add createSurface to base target

https://gerrit.wikimedia.org/r/135012
A few users are reporting (default) gadgets are missing on Portuguese Wikipedia:
* https://pt.wikipedia.org/w/index.php?oldid=38937709#Scripts_n.C3.A3o_funcionando.21
* https://pt.wikipedia.org/w/index.php?oldid=38937709#Sem_fast-buttons.2C_sem_hot-cat
* https://pt.wikipedia.org/w/index.php?oldid=38937709#Problema_com_naveboxes
* https://pt.wikipedia.org/w/index.php?oldid=38937709#Marcas_de_destaque_n.C3.A3o_aparecem

Currently, ptwiki is running 1.24wmf4.

Maybe related:
* Bug 65340
* Bug 65375

--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://pt.wikipedia.org/w/index.php?title=Wikip%C3%A9dia:Caf%C3%A9_dos_programadores&oldid=38938024#Problemas_com_os_gadgets
Thanks! :-)
Posted at https://wikitech.wikimedia.org/wiki/Incident_documentation/20140517-bits
Depooled. There is no indication that this was caused by a software fault, so I'm closing this bug as resolved. Once we have the full story on what happened to that server, a postmortem will be posted to <https://wikitech.wikimedia.org/wiki/Incident_documentation>.
Of the 4 application servers for bits in eqiad (mw1149, mw1150, mw1151, mw1152), I've identified mw1151 as the problematic one.

Using requests like the following https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.echo.badge%7Cext.gadget.BugStatusUpdate%2CDRN-wizard%2CReferenceTooltips%2CWatchlistChangesBold%2Ccharinsert%2Cedittop%2CmySandbox%2CrefToolbar%2Csearch-new-tab%2Cteahouse%7Cext.geshi.language.css%2Chtml4strict%2Cjavascript%2Ctext%7Cext.geshi.local%7Cext.uls.nojs%7Cext.visualEditor.viewPageTarget.noscript%7Cext.wikihiero%7Cmediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.skinning.interface%7Cmediawiki.ui.button%7Cmw.PopUpMediaTransform%7Cskins.vector.styles%7Cwikibase.client.init&only=styles&skin=vector&*bust123

(keep changing the bust query to make different cache misses).

Ori noticed mw1151 has as CPU spike in ganglia and disk issues.

I confirmed via mwscript on the local apache that its memcached is unable to retreive or store a value for cache key 'enwiki:gadgets-definition:7', from Gadget::loadStructuredList()

We should depool that node and have ops look into it.
Change 133871 merged by jenkins-bot:
[wmf debug] resourceloader: Output servedBy when load.php has an error

https://gerrit.wikimedia.org/r/133871
The summary as of right now is that Gadgets' generated modules are sometimes missing in load.php (and thus gadgets are not loaded) and we don't know why, but top people are on it. :P

It doesn't seem to affect any other modules nor any of Gadget's UI (like the special page or preferences).
[01:32]	<MatmaRex> Krinkle: unless you have better ideas, i'd check if Gadget::loadStructuredList is sometimes returning null when it shouldn't be, and if yes, why is it doing that
[01:33]	<Krinkle> MatmaRex: yeah, I'm mw-evalling now
[01:35]	<Krinkle> Gadget::loadStructuredList() and the underlying memcached object is fine
[01:35]	<Krinkle> at least not critical, let me inspect it
//**content hidden as private in Bugzilla**//
Change 133871 had a related patch set uploaded by Krinkle:
[wmf debug] resourceloader: Output servedBy when load.php has an error

https://gerrit.wikimedia.org/r/133871
//**content hidden as private in Bugzilla**//
Seen in Firefox 27 on Windows 8, FF 29 on OSX 10.6
Reported also on Win7, OSX 10.9

Edit any page on mw.o (or beta labs)

Save button is clickable but does nothing.

--------------------------
**Version**: unspecified
**Severity**: critical
Hm.. not caused by the save button click, but due to the dialog being opened. So the same as bug 65373.

*** This bug has been marked as a duplicate of bug 65373 ***
Also, I was wrong above, FF on Ubuntu/Linux also shows the problem.
(In reply to Krinkle from comment #3)
> (In reply to Chris McMahon from comment #2)
> > JS console log reports "JQMIGRATE: jQuery.browser is deprecated"
> 
> Unrelated.

Specifically, that's bug 65404.
(In reply to Chris McMahon from comment #2)
> JS console log reports "JQMIGRATE: jQuery.browser is deprecated"

Unrelated.
JS console log reports "JQMIGRATE: jQuery.browser is deprecated"
Note: FF on Linux is fine.
NS_ERROR_NOT_AVAILABLE: appearing while trying to save a page in Betalabs

--------------------------
**Version**: unspecified
**Severity**: critical
Verified the backported fix in test2
Marking this as "FIXED".
Change 134159 merged by jenkins-bot:
MWTransclusionDialog: Remove setMode() call from teardown()

https://gerrit.wikimedia.org/r/134159
All dialogs are now opening and closing without any error in Betalabs.
Change 134159 had a related patch set uploaded by Jforrester:
MWTransclusionDialog: Remove setMode() call from teardown()

https://gerrit.wikimedia.org/r/134159
Change 134156 merged by jenkins-bot:
MWTransclusionDialog: Remove setMode() call from teardown()

https://gerrit.wikimedia.org/r/134156
Change 134156 had a related patch set uploaded by Krinkle:
MWTransclusionDialog: Remove setMode() call from teardown()

https://gerrit.wikimedia.org/r/134156
Confirmed. Closing the Template dialog triggers it as well. Looks like we found another hole that needs to be plugged.


Trace:

 curCSS() load.php:6129
 .css() load.php:6718
 .css/<() load.php:6867
 jQuery.access() load.php:4153
 .css() load.php:6868
 OO.ui.Element.getDir() oojs-ui.js:304
 OO.ui.GridLayout.prototype.update() oojs-ui.js:4170
 OO.ui.GridLayout.prototype.layout() oojs-ui.js:4139
 OO.ui.BookletLayout.prototype.toggleOutline() oojs-ui.js:4382
 ve.ui.MWTransclusionDialog.prototype.setMode() ve.ui.MWTransclusionDialog.js:229
 ve.ui.MWTransclusionDialog.prototype.teardown() ve.ui.MWTransclusionDialog.js:335
 OO.ui.Window.prototype.close() oojs-ui.js:1357
 OO.ui.Dialog.prototype.close/<() oojs-ui.js:1753
Also, if you just close the Template insertion dialog without adding anything, it throws the error.
Yes, the dialogs are working opening for me now, but I still get this error when I click on Insert Template on Template dialog.
It has not been backported to production yet (will happen soon).

The automatic deploy to beta.wmflabs.org ran 2 minute after your comment was submitted.
Also, when I try to open Language inspector.
I am still getting that error : when I try to open Media Settings Dialog, Template and Media Settings.
(In reply to Greg Grossmeier from comment #26)
> (In reply to Gerrit Notification Bot from comment #25)
> > Change 134110 merged by jenkins-bot:
> > Window: Apply display:none after initialize, not before
> > 
> > https://gerrit.wikimedia.org/r/134110
> 
> Is this now fixed?

Yes, this should fix it.
(In reply to Gerrit Notification Bot from comment #25)
> Change 134110 merged by jenkins-bot:
> Window: Apply display:none after initialize, not before
> 
> https://gerrit.wikimedia.org/r/134110

Is this now fixed?
Change 134110 merged by jenkins-bot:
Window: Apply display:none after initialize, not before

https://gerrit.wikimedia.org/r/134110
Instead of trying to fill all the wholes where we're doing style computation to early, I've revised https://gerrit.wikimedia.org/r/134110 to instead extend the time window where we can do style computation.

I don't think it was intentionally made this short. The idea was to do it at the end of initialize(), and instead, due to our large code base and sub classes, it ended up at the beginning of initialize().

This moves it back to where it belongs.
Hmm.. with https://gerrit.wikimedia.org/r/134110 applied locally, GridLayout dialogs still fail, this time a little further down the line:

demos/dialogs.html#GridDialog
 curCSS() jquery.js:6131
 .css() jquery.js:6723
 .css/<() jquery.js:6872
 jQuery.access() jquery.js:4153
 .css() jquery.js:6873
 OO.ui.Element.getClosestScrollableContainer() oojs-ui.js:464
 OO.ui.Element.scrollIntoView() oojs-ui.js:491
 OO.ui.Element.prototype.scrollElementIntoView() oojs-ui.js:603
 OO.ui.OptionWidget.prototype.setSelected() oojs-ui.js:6171
 OO.ui.SelectWidget.prototype.selectItem() oojs-ui.js:6556
 OO.ui.BookletLayout.prototype.updateOutlineWidget() oojs-ui.js:4616
 OO.ui.BookletLayout.prototype.addPages() oojs-ui.js:4511
 GridDialog.prototype.initialize()
Change 134110 had a related patch set uploaded by Krinkle:
[WIP] GridLayout: Don't call getDir() during initialize

https://gerrit.wikimedia.org/r/134110
* Media Edit dialog
 mw.log</log.warn() load.php:11380
 curCSS() load.php:6131
 .css() load.php:6723
 .css/<() load.php:6872
 jQuery.access() load.php:4153
 .css() load.php:6873
 OO.ui.Element.getDir() oojs-ui.js:304
 OO.ui.GridLayout.prototype.update() oojs-ui.js:4168
 OO.ui.GridLayout.prototype.layout() oojs-ui.js:4137
 OoUiGridLayout() oojs-ui.js:4069
 OoUiBookletLayout() oojs-ui.js:4232
 ve.ui.MWMediaEditDialog.prototype.initialize() ve.ui.MWMediaEditDialog.js:150

* Template (transclusion)
 mw.log</log.warn() load.php:11380
 curCSS() load.php:6131
 .css() load.php:6723
 .css/<() load.php:6872
 jQuery.access() load.php:4153
 .css() load.php:6873
 OO.ui.Element.getDir() oojs-ui.js:304
 OO.ui.GridLayout.prototype.update() oojs-ui.js:4168
 OO.ui.GridLayout.prototype.layout() oojs-ui.js:4137
 OoUiGridLayout() oojs-ui.js:4069
 OoUiBookletLayout() oojs-ui.js:4232
 ve.ui.MWTemplateDialog.prototype.initialize()
 ve.ui.MWTransclusionDialog.prototype.initialize()

* Page settings
 mw.log</log.warn() load.php:11380
 curCSS() load.php:6131
 .css() load.php:6723
 .css/<() load.php:6872
 jQuery.access() load.php:4153
 .css() load.php:6873
 OO.ui.Element.getDir() oojs-ui.js:304
 OO.ui.GridLayout.prototype.update() oojs-ui.js:4168
 OO.ui.GridLayout.prototype.layout() oojs-ui.js:4137
 OoUiGridLayout() oojs-ui.js:4069
 OoUiBookletLayout() oojs-ui.js:4232
 ve.ui.MWMetaDialog.prototype.initialize() ve.ui.MWMetaDialog.js:47
btw, since Firefox's NS_ERROR_NOT_AVAILABLE exceptions have no stack trace. This is how you catch it:

Locally modify jquery.js like this:

--- a/resources/lib/jquery/jquery.js
+++ b/resources/lib/jquery/jquery.js
@@ -6122,10 +6122,15 @@ if ( window.getComputedStyle ) {
                var width, minWidth, maxWidth, ret,
                        style = elem.style;
 
+               try {
                computed = computed || getStyles( elem );
 
                // getPropertyValue is only needed for .css('filter') in IE9, see #12537
                ret = computed ? computed.getPropertyValue( name ) || computed[ name ] : undefined;
+               } catch (e) {
+                       mw.log.warn(e);
+                       throw new Error('Firefox computed styles poop');
+               }
 
                if ( computed ) {


Then reproduce the error (preferably in debug mode), and fine a stack like the following (this one is for Media Edit dialog):

console.trace:
 mw.log</log.warn() load.php:11380
 curCSS() load.php:6131
 .css() load.php:6723
 .css/<() load.php:6872
 jQuery.access() load.php:4153
 .css() load.php:6873
 OO.ui.Element.getDir() oojs-ui.js:304
 OO.ui.GridLayout.prototype.update() oojs-ui.js:4168
 OO.ui.GridLayout.prototype.layout() oojs-ui.js:4137
 OoUiGridLayout() oojs-ui.js:4069
 OoUiBookletLayout() oojs-ui.js:4232
 ve.ui.MWMediaEditDialog.prototype.initialize() ve.ui.MWMediaEditDialog.js:150


Conclusion, like in OO.ui.PanelLayout (fixed in I31b495fc2d9725f), GridLayout, too is doing (what seems to be erroneous) style computation on a hidden frame. So the values of it are already useless, but are now throwing in Firefox.

Should probably be dealt with similarly (in case we find more).
As far as I can tell the above didn't fix the issue for opening the media edit dialog. The save dialog is now working for me (bug 65401) and mobile citation dialog (bug 65422).

Dialogs that seem to work for me:

* Citation
* Reference
* Reference list
* Media insert
* Save

* Inspectors all seem to work – Link, language, hieroglyphics, gallery, special character


Dialogs that do not:

* Media edit
* Template (transclusion)
* Page settings


What's the plan for fixing these?
Change 133738 merged by jenkins-bot:
PanelLayout: Remove call to getDir()

https://gerrit.wikimedia.org/r/133738
*** Bug 65422 has been marked as a duplicate of this bug. ***
Upstream bug report:
 http://bugs.jquery.com/ticket/15098
*** Bug 65407 has been marked as a duplicate of this bug. ***
More elaborate trace:


Error: [Exception... "Component is not available"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: http://krinkle.dev/wikimedia/oojs/ui/demos/lib/jquery.js :: curCSS :: line 6128"  data: no]

Not much, but new phrases that can help are "Component is not available" and "JS frame".

Possibly related:
https://bugzilla.mozilla.org/show_bug.cgi?id=358415
> "And yes, I'm cool with getComputedStyle throwing something like NS_ERROR_NOT_AVAILABLE if there's nothing in the window. "
Happens when opening any dialog that inherits directionality (OO.ui.ConfirmationDialog, ve.ui.MWSaveDialog, etc.)
*** Bug 65401 has been marked as a duplicate of this bug. ***
Change 133738 had a related patch set uploaded by Krinkle:
[WIP] Element: Work around Firefox exception in getDir()

https://gerrit.wikimedia.org/r/133738
To reproduce:

 http://jsfiddle.net/v8Syf/4/
So it's no longer using the global window and pass the (foreign) node, but uses the correct window now (ownerDocument.defaultView). If anything, that should fix issues, not cause Firefox to throw.
Inside .css():

[1.8.3] jQuery.fn.css
-> curCSS

 computed = window.getComputedStyle( elem, null ),
 style = elem.style
 if ( computed ) {
   // getPropertyValue is needed for .css('filter') in IE9, see #12537
   ret = computed.getPropertyValue( name ) || computed[ name ];


[1.11.1] jQuery.fn.css
-> curCSS
  computed = .. || getStyles( elem );
  style = elem.style

  // getPropertyValue is needed for .css('filter') in IE9, see #12537
  ret = computed ? computed.getPropertyValue( name ) || computed[ name ] : undefined;

-> getStyles
  return elem.ownerDocument.defaultView.getComputedStyle( elem, null );
Caused by 

OO.ui.ConfirmationDialog.prototype.initialize

-> OO.ui.PanelLayout
  (only when passing $: this.$, without it it works fine, so it is frame
  related, this is OO.ui.ConfirmationDialog/OO.ui.Dialog/OO.ui.Frame.$)

-> this.$element.addClass( 'oo-ui-' + OO.ui.Element.getDir( this.$.context ) );
   Removing this line makes it go away.

-> OO.ui.Element.getDir( HTMLDocument frame$context )
   isDoc
   obj = obj.body
-> $( HTMLBodyElement obj ).css( 'direction' )


When doing it step-by-step, the error doesn't happen.
Narrowed it down...

A breakpoint doesn't seem to work as this is a lower level exception, this is most likely a bug inside Firefox as well. After this bug most of the page is unresponsive and even reloading the page in the same or a new tab doesn't work (like it has somehow frozen the network layer or no longer allows itself to make requests to this domain). So finding where in our code we go down that path is hard to find.

Inside VisualEditor, it happens for dialogs that have iframes. Specifically the kind that copies link tags. I can see that it does make requests (which get HTTP 304, as it should) for several of the parent document's stylesheets before NS_ERROR_NOT_AVAILABLE is thrown.

When using the oojs-ui dialogs demo, after having manually upgraded lib/jquery.js to jQuery 1.11.1 (without Migrate plugin), I can reproduce this exception in Firefox. But, only for the confirmation dialog. Small, medium, large, and medium footless dialogs are all fine.
Most likely, such as was with Ia7db42b7727b8ca16ae, this is one of three things:

1) We're giving the DOM or jQuery garbage, and previous versions silently just assumed stupidity and used a default. Now it's throwing the garbage back at us. In case of Ia7db42b77, we passed a VeDmDocument object as second parameter to $() for creating a new <div>. That was a nonsensical function call. It defaulted to the global Document. In many cases this would never be merged as that would obviously conflict with iframes, but it happened to be right one here.

* We're relying on an undocumented behaviour (e.g. an old bug, or feature was that really just tolerance or coincidence). E.g. weird code was written, it code worked, got shipped. A good example is eg. doing something like:
 .css( 'font-size', '100potatoes' )
or
 .css( 'font-size', '100pxlz' )

Maybe it previously used parseFloat to strip off 'px' and just assumed it was px, and changed to stripping only 'px' and passing on to the DOM without taking the blame for it and we'd now be getting weird exceptions.

(example, afaik this was not an actual change).

2) We're relying on something that was intentionally changed. Happy reading:

 http://blog.jquery.com/2013/01/15/jquery-1-9-final
 http://blog.jquery.com/2013/02/04/jquery-1-9-1-released/
 http://blog.jquery.com/2013/05/24/jquery-1-10-0
 http://blog.jquery.com/2013/05/30/jquery-1-10-1
 http://blog.jquery.com/2013/07/03/jquery-1-10-2
 http://blog.jquery.com/2014/01/24/jquery-1-11
 http://blog.jquery.com/2014/05/01/jquery-1-11-1
 http://jquery.com/upgrade-guide/1.9/

3) Oh my, jQuery can have new bugs?
Caused by the jQuery 1.11 upgrade.
Correction, not ALL dialogs. The media insertion dialog isn't affected, all the others do seem to be.
New in wmf5, happens when opening any dialog.
This is not happening with Chrome though, but with Firefox
Intention:
Fix the URL in a citation

Steps to Reproduce:
1. Open an existing citation, using the citation tool.

2. Change something.

3. Apply changes.

4. Look, now you have two:  first an old/wrong version, then a new/corrected version.

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:Whatamidoing_%28WMF%29/Sandbox&diff=91692&oldid=91691



Reproducible: Always

Same problem in Firefox and Safari.  No problems with this using the Insert>Reference editor, even though that opens the citation tool for editing citation templates.

--------------------------
**Version**: unspecified
**Severity**: major
Change 131091 merged by jenkins-bot:
Fix typo: this.transclusionNode -> this.selectedNode

https://gerrit.wikimedia.org/r/131091
Change 131065 merged by jenkins-bot:
Fix typo: this.transclusionNode -> this.selectedNode

https://gerrit.wikimedia.org/r/131065
Change 131091 had a related patch set uploaded by Jforrester:
Fix typo: this.transclusionNode -> this.selectedNode

https://gerrit.wikimedia.org/r/131091
Change 131065 had a related patch set uploaded by Esanders:
Fix typo: this.transclusionNode -> this.selectedNode

https://gerrit.wikimedia.org/r/131065
Type anything or do any edit on any page in Betalabs 

The undo button remains disabled even you made some changes to that page

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix on https://en.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/sandbox?veaction=edit
Verified the fix on test2
Verified the fix on Betalabs:
http://en.wikipedia.beta.wmflabs.org/wiki/21staprilchrome?veaction=edit
Change 127693 merged by jenkins-bot:
Revert "Add aggregate method"

https://gerrit.wikimedia.org/r/127693
Change 127693 had a related patch set uploaded by Catrope:
Revert "Add aggregate method"

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

Steps to reproduce:


1.Try to open the Heiroglyphics inspector

Observed Result:
The following error shows up in the console:
Uncaught TypeError: Cannot read property 'forcedLtr' of undefined 

See the screenshot attached

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

**Attached**: {F13714}
Verified the fix in production
Verified the fix in test2
Change 127174 merged by Catrope:
Extension inspector directionality

https://gerrit.wikimedia.org/r/127174
Verified the fix in Betalabs:
http://en.wikipedia.beta.wmflabs.org/wiki/User:RYasmeen_%28WMF%29?veaction=edit
Change 127156 merged by jenkins-bot:
Extension inspector directionality

https://gerrit.wikimedia.org/r/127156
Change 127174 had a related patch set uploaded by Jforrester:
Extension inspector directionality

https://gerrit.wikimedia.org/r/127174
Change 127156 had a related patch set uploaded by Jforrester:
Extension inspector directionality

https://gerrit.wikimedia.org/r/127156
This is happening for Math and Gallery inspector too.
Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5
Steps to reproduce:

1.Open a page with VE
2.Add a text/change the format of a text

Observed Result:
The"Save Page" button remains disabled on the page


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 with chrome and FF
verified the fix on test2
Verified the fix on betalabs
Screenshot

Steps to reproduce:

1.Open a page with Mobile VE
2.Close the VE for it
3.Again reopen the page with VE
4.Go to the last and hit return twice

Observed Result:
The following error appears in the console:
Uncaught Error: ve.dm.Document.getNodeFromOffset(): offset 339 is out of bounds

See the screenshot attached

Test Environment:http://en.m.wikipedia.beta.wmflabs.org/
Page: http://en.m.wikipedia.beta.wmflabs.org/wiki/New_page_for_testing_the_special_characters_by_creating_a_new_page#editor/0

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

**Attached**: {F13638}
verified the fix on production
Verified the fix on test2
I can still reproduce this issue on 
http://en.m.wikipedia.beta.wmflabs.org/wiki/User:RYasmeen_%28WMF%29#editor/0
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
Steps to reproduce:

1.Open a page with VE
2.Add some references
3.Insert a reflist
4.Click on the "Save Page" button
5.Click on "Review your changes"


Observed Result:
There is no wikitext for the reflist , in the review changes panel it says:
Could not start the review because your revision matches the latest version of this page.

After saving the page no reflist is appearing on the page
An error is appearing on the read mode:



Cite error: There are <ref> tags on this page, but the references will not show without a {{Reflist}} template or a <references /> tag; see the help page. ().

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production in Chrome and FF
Verified the fix on test2
Verified the fix on Betalabs
Change 126817 merged by jenkins-bot:
Make inserting reference lists work again

https://gerrit.wikimedia.org/r/126817
Change 126817 had a related patch set uploaded by Catrope:
Make inserting reference lists work again

https://gerrit.wikimedia.org/r/126817
While trying to edit a new page the following error appears in the console:
Uncaught TypeError: Cannot call method 'isCollapsed' of null

Also there is no toolbar appearing over the page

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63945
Verified the fix on test2
Verified the fix on Betalabs
Change 126144 merged by jenkins-bot:
Don't call select on a fragment if it's null

https://gerrit.wikimedia.org/r/126144
Change 126144 had a related patch set uploaded by Trevor Parscal:
Don't call select on a fragment if it's null

https://gerrit.wikimedia.org/r/126144
While trying to save the edit on an existing page the following error is appearing:

Uncaught TypeError: Cannot call method 'select' of null
seen on beta labs as of 15 April in Firefox not in Chrome

on a page that begins with text such as "two words" open VE and click link without clicking any other item in the page

insert a link such as "http://www.example.com"

in Chrome this correctly creates a link like 

	
[http://www.example.com two] words


but in Firefox we get incorrectly instead 

	
http://www.example.com 	
  	
two words

--------------------------
**Version**: unspecified
**Severity**: major
Change 126835 merged by jenkins-bot:
Fix initial selection when focusing in Firefox

https://gerrit.wikimedia.org/r/126835
Change 126835 had a related patch set uploaded by Esanders:
Fix initial selection when focusing in Firefox

https://gerrit.wikimedia.org/r/126835
With gerrit 126169 this is now slightly better (initial selection is 1,1 but collapses to 0,0 if you click in), but still needs work because 0,0 is achievable. Badness.
After wmf21 deployment cannot load VE on en.wiki.GEtting the following error:

Uncaught TypeError: Object #<Object> has no method 'lookup' VM734:1505

--------------------------
**Version**: unspecified
**Severity**: normal
Looks like a caching issue.

The offending line is 25 of ve.ui.Toolbar.js

Fixed by Timo
Looks like Rummana and Trevor can reproduce it on their machine, but Ed and myself cannot.

And on their machine it also doesn't happen in Incognito mode, so looks like it is a caching bug.

-- 
[#wikimedia-operations]
 !log krinkle touched php-1.23wmf21/resources/oojs-ui/oojs-ui.js'
 !log krinkle touched php-1.23wmf21/resources/startup.js
 !log krinkle touched php-1.23wmf21/extensions/VisualEditor/lib/ve/lib/oojs-ui/oojs-ui.js
 !log krinkle touched php-1.23wmf21/extensions/VisualEditor/lib/ve/modules/ve/ui/ve.ui.Toolbar.js
Uncaught TypeError: Object #<Object> has no method 'lookup' VM1319:1505
OO.ui.Toolbar.setup VM1319:1505
ve.init.mw.Target.setUpToolbar VM1319:19180
ve.init.mw.ViewPageTarget.setUpToolbar VM1319:21943
(anonymous function)
oojs-ui was pulled through to MW core with a breaking change ( https://gerrit.wikimedia.org/r/#/c/121537/ ) before the update to VE extension.

It was correctly pulled through to ve core with changes: https://gerrit.wikimedia.org/r/#/c/120844/
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Page options>Categories section
3.Type in a category name which does not already exist

Observed Result:
The new category does not get added 

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**: {F13724}
Verified the fix in production:
https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/sandbox
verified the fix on mw.org
Verified the fix on test.wikipedia.org
This issue got fixed with: https://gerrit.wikimedia.org/r/124381
Verified the fix in Betalabs
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Template
3.Search for a template by typing in something on the search box for example: Cite
4.When the matching transclusion names appear in the list try to select the first name

Observed Result:

The first match does not get selected .


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=63547
https://bugzilla.wikimedia.org/show_bug.cgi?id=63554

**Attached**: {F13706}
Verified the fix on mw.org
Verified the fix on test.wikipedia.org
Verified the fix in Betalabs: http://en.wikipedia.beta.wmflabs.org/wiki/7thaprilchrome?veaction=edit
Change 124381 merged by jenkins-bot:
[BREAKING CHANGE] Death to initializeSelection

https://gerrit.wikimedia.org/r/124381
Change 124381 had a related patch set uploaded by Catrope:
[BREAKING CHANGE] Death to initializeSelection

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

Steps to reproduce:


1.Add a link
2.Apply format on it like Bold/Strikethrough
3.Now add a space right after that and add a text


Observed Result:
An error appears in the console  Uncaught TypeError: Cannot read property 'constructor' of undefined and the text gets added in a weird way: One letter appears before the link and some letters gets typed inside the link text

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/31stMarChrome?veaction=edit

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

**Attached**: {F13199}
Verified the fix in production
Verified the fix on mediawiki.org
Change 124488 merged by jenkins-bot:
Adjust loop counters in word break detection when removing item

https://gerrit.wikimedia.org/r/124488
Change 124488 had a related patch set uploaded by Catrope:
Adjust loop counters in word break detection when removing item

https://gerrit.wikimedia.org/r/124488
Verified the fix on Betalabs
Change 123373 merged by jenkins-bot:
Adjust loop counters in word break detection when removing item

https://gerrit.wikimedia.org/r/123373
Change 123373 had a related patch set uploaded by Esanders:
Adjust loop counters in word break detection when removing item

https://gerrit.wikimedia.org/r/123373
Screencast

If I select a few cells in a table at
https://pt.wikipedia.org/wiki/Quadrado_perfeito?oldid=38495158&veaction=edit
and then press DELETE, I get the error "Unbalanced set of replace operations found".

See the screencast.

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

**Attached**: {F13276}
Verified the fix in test2 and production.
This should now be fixed with the new table editing code that replaces this broken issue.
screenshot

There are wide varieties of type errors I get for undoing typing references in different way.I will try to document each cases in this same bug report:


Case 1:

Steps to reproduce:

1.Insert a reference with text for example : reference[1]
2.Press "Undo"

Error 1:
Uncaught TypeError: Cannot read property 'length' of undefined 

3.Place the cursor at the end of the text

Error 2:
Uncaught Error: ve.dm.Document.getNodeFromOffset(): offset 12 is out of bounds 


Case 2:

1.Insert two references with text , for example:
reference [1]
reference [2]

2.Now keep on pressing Undo untill the page gets empty

Errors:
Uncaught TypeError: Cannot read property 'length' of undefined VM484:296
Uncaught Error: Offset could not be translated to a DOM element and offset: 12 VM484:447
Uncaught Error: Invalid end offset: 21 VM484:252
Uncaught Error: Unbalanced input passed to document 

In both cases, after the Undo action , clicking on "Save Page" does not do anything.

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F13217}
Verified the fix in Betalabs: http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Reference_numbering&veaction=edit
Change 120874 merged by jenkins-bot:
Rename stray this.refGroup usage to this.group in MWReferenceModel

https://gerrit.wikimedia.org/r/120874
Change 120874 had a related patch set uploaded by Catrope:
Rename stray this.refGroup usage to this.group in MWReferenceModel

https://gerrit.wikimedia.org/r/120874
Created attachment 14904
screenshot 2

**Attached**: {F13218}
On http://en.m.wikipedia.beta.wmflabs.org/

Log in to edit
Settings to alpha to get VisualEditor
Attempt to edit any page

A spinner appears and spins forever.  The VE UI never appears.

--------------------------
**Version**: unspecified
**Severity**: major
Change 120842 merged by jenkins-bot:
Make generateCitationFeatures() not explode when citation code isn't loaded

https://gerrit.wikimedia.org/r/120842
Change 120842 had a related patch set uploaded by Catrope:
Make generateCitationFeatures() not explode when citation code isn't loaded

https://gerrit.wikimedia.org/r/120842
Looks like the citation code broke this, sorry. I'll fix it.
Looks like the problem might be in VisualEditor

TypeError: Expecting a function in instanceof check, but got undefined TypeError {stack: (...), message: "Expecting a function in instanceof check, but got undefined"} load.php?debug=true&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Clo…:9515
log load.php?debug=true&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Clo…:9515
handlePending load.php?debug=true&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Clo…:10492
markModuleReady load.php?debug=true&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Clo…:10632
nestedAddScript load.php?debug=true&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Clo…:10639
(anonymous function) load.php?debug=true&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Clo…:10644
script.onload.script.onreadystatechange load.php?debug=true&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2Clo…:105
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1798
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Add an image
3.Select the image

Observed Result:
The media settings icon is getting hidden by the  Image highlight box and hence not clickable

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/Slug?veaction=edit

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

**Attached**: {F12847}
Verified the fix in betalabs:http://en.wikipedia.beta.wmflabs.org/wiki/Slug?veaction=edit
https://gerrit.wikimedia.org/r/#/c/118757/
I am getting this error while trying to save a page on betalabs:
Uncaught TypeError: Cannot read property 'saveDialogSave' of undefined

However, if you cancel the dialog box and reload again, it shows that the new content actually got saved

--------------------------
**Version**: unspecified
**Severity**: normal
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 in betalabs.
Change 118021 merged by jenkins-bot:
Followup 4bd80b62: fix JS error on page save

https://gerrit.wikimedia.org/r/118021
Change 118021 had a related patch set uploaded by Jforrester:
Followup 4bd80b62: fix JS error on page save

https://gerrit.wikimedia.org/r/118021
Verified in the linked URL (I'm using Chrome, Win7, Vector), all I did was adding a few words at the top. I'll add that the edit did trigger the "corrupted edit, please check" warning, but I didn't verify what that caught, since the article is very large.

--------------------------
**Version**: unspecified
**Severity**: critical
**URL**: https://en.wikipedia.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandbox&diff=598527246&oldid=598527036
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53853
*** Bug 62499 has been marked as a duplicate of this bug. ***
Fixed with gerrit 117445 backport.
**letartean** wrote:

This happens also on fr.wikipedia : https://fr.wikipedia.org/w/index.php?title=%C3%89glise_de_J%C3%A9sus-Christ_des_saints_des_derniers_jours&diff=prev&oldid=101872119
This is clearly an unintentionnal removal of the upright parameter.
Screenshot

Tried to load VE in en.wiki getting the following error in the console and the label of insert button is missing:

Uncaught TypeError: Object #<VeInitMwViewPageTarget> has no method 'restoreEditSection

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

**Attached**: {F13187}
Kk.
(In reply to James Forrester from comment #1)
> Is this the bug that Roan fixed with the no-op deployment touch this morning?
Yes, I believe so.
Is this the bug that Roan fixed with the no-op deployment touch this morning?
Seen on for example  http://en.m.wikipedia.beta.wmflabs.org/wiki/Selenium_Edit_Test 

As logged-in user with 'alpha' mode set, attempt to edit a page on beta labs. 

VE never appears, Mobile user sees only a spinner. 

VE seems to work correctly for non-Mobile user.  

(Possibly related may be a recent change to Parsoid on beta labs https://bugzilla.wikimedia.org/show_bug.cgi?id=60694)

--------------------------
**Version**: unspecified
**Severity**: critical
Change 111919 merged by jenkins-bot:
Move paste rules to Target

https://gerrit.wikimedia.org/r/111919
Change 111912 merged by jenkins-bot:
Move paste rules to Target

https://gerrit.wikimedia.org/r/111912
Change 111919 had a related patch set uploaded by Jforrester:
Move paste rules to Target

https://gerrit.wikimedia.org/r/111919
Change 111912 had a related patch set uploaded by Jdlrobson:
Move paste rules to Target

https://gerrit.wikimedia.org/r/111912
Seems to be a problem in the VE codebase. Managed to debug it with Trevor..
Actually it was a different parsoid bug. See bug 60755
Please provide more detail. It does sound like the parsoid bug...
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1669
Screenshot

I cannot save any page on Betalabs with FireFox and Chrome.It shows an error Unknown error on the dialog box and in the console it shows:
TypeError: this.toolbar is null

For Chrome, it shows:
GET http://bits.beta.wmflabs.org/static-master/extensions/VectorBeta/less/images/unwatch-icon.svg 404 (Not Found) 

Also ,Edit button is not loading VE sometimes.

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

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

**Attached**: {F13034}
Not happening anymore though.Page is loading properly now on Betalabs.Also I am able to save the content on any page
(In reply to comment #0)
> http://bits.beta.wmflabs.org/static-master/extensions/VectorBeta/less/images/
> unwatch-icon.svg
> 404 (Not Found) 

Not sure if related at all; but recent change is http://git.wikimedia.org/commit/mediawiki%2Fcore.git/58f72c5f227b9a16ca9f489cef5171a508a059ee
Steps to reproduce:

1.Open a page with VE
2.Select an image
3.Go to Insert>Gallery

Observed Result:
An error appears in the console "Uncaught TypeError: Cannot read property 'body' of undefined"

After that the Media Settings option does not appear on any other image .Also the reference dialog option does not show up when you select a reference note.

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

--------------------------
**Version**: unspecified
**Severity**: normal
Change 110652 merged by jenkins-bot:
Don't throw JS errors when opening MWExtensionInspector on the wrong node type

https://gerrit.wikimedia.org/r/110652
Change 110652 had a related patch set uploaded by Jforrester:
Don't throw JS errors when opening MWExtensionInspector on the wrong node type

https://gerrit.wikimedia.org/r/110652
*** Bug 60699 has been marked as a duplicate of this bug. ***
Verified the fix in test2 and mw.org
Verified the fix in Betalabs:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=29th_January&veaction=edit
Change 109832 merged by jenkins-bot:
Don't throw JS errors when opening MWExtensionInspector on the wrong node type

https://gerrit.wikimedia.org/r/109832
Change 109832 had a related patch set uploaded by Catrope:
Don't throw JS errors when opening MWExtensionInspector on the wrong node type

https://gerrit.wikimedia.org/r/109832
There's no validation going on in MWExtensionInspector at all, so it's happy to try and inspect references or images or anything that's inspectable, even if it can't be inspected by the inspector you tried to open.
Created attachment 14386
Screenshot

**Attached**: {F13418}
Screenshot

Steps to reproduce:


1.Open a page with VE
2.Select a Text and press command+k

Observed Result:
Observe that no page suggestions are appearing on the link inspector regardless of whether it is a new page or an existing 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/w/index.php?title=User:RYasmeen_(WMF)&veaction=edit

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

**Attached**: {F13086}
Verified the fix in test2 and mw.org
Verified the fix in Betalabs:http://en.wikipedia.beta.wmflabs.org/wiki/Jan_27th
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
Screenshot of the error

Steps to reproduce:

1.Open a page with VE
2.Add a gallery from Insert>Gallery or just simply close the inspector without adding anything.
3.Click on the "Save Page" button

Observed Result:

The page cannot be saved.

An error appears in the console:
Uncaught Error: InvalidCharacterError: DOM Exception 5

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/w/index.php?title=Thedomtest&veaction=edit

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

**Attached**: {F12917}
Change 110826 merged by jenkins-bot:
Add tagName to ve.dm.MWGalleryNode

https://gerrit.wikimedia.org/r/110826
Change 110826 had a related patch set uploaded by Jforrester:
Add tagName to ve.dm.MWGalleryNode

https://gerrit.wikimedia.org/r/110826
Verified the fix in mw.org and test2
Verified the fix in betalabs.
Change 109759 merged by jenkins-bot:
Add tagName to ve.dm.MWGalleryNode

https://gerrit.wikimedia.org/r/109759
Change 109759 had a related patch set uploaded by Catrope:
Add .tagName to MWGalleryNode

https://gerrit.wikimedia.org/r/109759
**cmitasch** wrote:

I can confirm the behaviour. It does not work in Chrome but it is working with Firefox 26.0.
Comment to follow from Roan.

--------------------------
**Version**: unspecified
**Severity**: critical
Checked the cases mentioned above.All of them are working now on Betalabs.No JS error is appearing now after copy -paste of reference.
This patch may not have been merged into ve-mw yet. Please check commit history.
The following JS error appears if I copy a reference note with some text following it.
Uncaught Error: Unbalanced input passed to document
Change 109481 merged by jenkins-bot:
Fix balancing of data in cloneSliceFromRange

https://gerrit.wikimedia.org/r/109481
Change 109481 had a related patch set uploaded by Esanders:
Fix balancing of data in cloneSliceFromRange

https://gerrit.wikimedia.org/r/109481
Change 108720 merged by jenkins-bot:
Fix up result of selectNodes

https://gerrit.wikimedia.org/r/108720
Change 108720 had a related patch set uploaded by Esanders:
Fix up result of selectNodes to remove empty items

https://gerrit.wikimedia.org/r/108720
Change 108692 merged by jenkins-bot:
Fix exception thrown by findEndOfNode

https://gerrit.wikimedia.org/r/108692
Change 108692 had a related patch set uploaded by Esanders:
Fix exception thrown by findEndOfNode

https://gerrit.wikimedia.org/r/108692
Based on these findings, my expectation of what will and won't work is:

Probably broken:
* Copying a reference by itself, where that reference is immediately preceded by text in the same paragraph (foo|[1]|bar)
* Copying a reference plus some text before it (f|oo[1]|bar)
* Copying a reference plus some text after it, where there is no text immediately preceding that reference in the same paragraph (|[1]ba|r)

Probably works:
* Copying a reference plus some text after it, where that reference is immediately preceded by text in the same paragraph (foo|[1]ba|r)
* Copying a reference plus text before and after it (f|oo[1]ba|r)
* Copying a reference by itself, where there is no text immediately preceding that reference in the same paragraph (|[1]|bar)
I forgot to include how these things lead to the actual failure:

* cloneSliceFromRange returns a slice with an unclosed paragraph opening at the very beginning, as described above
* The tree build algorithm in ve.dm.Document doesn't actually care about the unclosed opening and builds the tree as if the mwReference was the first node. This means we get a mostly valid tree except that all the offsets are off by one because the paragraph opening element was ignored
* When we try to get the contents of the internalItem associated with the reference from this unbalanced slice, the range in the tree is one off from the range in the data array. And so instead of [ {type:'paragraph'}, 'F', 'o', 'o', {type:'/paragraph'} ] we get [ {type:'internalItem'}, {type:'paragraph'}, 'F', 'o', 'o' ] when calling .getFullData( itemNodeRange, true ) in ve.dm.MWReferenceNode.static.toDomElements on line 135 (it's actually written as .getFullData( new ve.Range( itemNodeRange.start, itemNodeRange.end ), true ) which is just WTF and should be simplified)
* This data with two openings and zero closings then gets fed to getDomSubtreeFromData(), which calls removeInternalNodes(), which spots an internalItem as the very first element and tries to find its end with findEndOfNode()
* findEndOfNode() can't find the internalItem closing because there are no closings, so it tries to throw an error, but that fails because dataElement is undefined and so accessing dataElement.type is itself an error
Attempt to invoke VE by clicking the Edit button on my near-empty user page http://en.wikipedia.beta.wmflabs.org/wiki/User:Cmcmahon, get error: 

Error loading data from server: internal_api_error_ErrorPageError: Exception Caught: &lt;editpage-notsupportedcontentformat-text&gt;. Would you like to retry?

Note: several hours ago a number of automated browser tests failed by timing out waiting for 10 seconds for the diff viewer to manifest in the browser.  There may have been a performance problem before this error appeared.

--------------------------
**Version**: unspecified
**Severity**: major
Synchronisation for betalabs has been broken for over a week due to bug 49846 – see http://en.wikipedia.beta.wmflabs.org/wiki/Special:Version which says "VisualEditor 0.1.0 (3e925e6) 20:50, 2 January 2014". Re-closing as that's a distinct issue.
*** Bug 59903 has been marked as a duplicate of this bug. ***
This is fixed on test2/mw.o but still broken on beta labs.  Perhaps it was a hotfix in prod, but master not updated yet?
Verified the fix in test 2 and mw.org.VE is now loading properly on wmf10.
Change 106628 merged by Ori.livneh:
Update VisualEditor for cherry pick I5cc44c5ef35 (bug 59867)

https://gerrit.wikimedia.org/r/106628
Change 106628 had a related patch set uploaded by Ori.livneh:
Update VisualEditor for cherry pick I5cc44c5ef35 (bug 59867)

https://gerrit.wikimedia.org/r/106628
Fix now being deployed.
Change 106627 merged by jenkins-bot:
Provide content format faux reqeust now that content format is validated

https://gerrit.wikimedia.org/r/106627
Change 106621 merged by jenkins-bot:
Provide content format faux reqeust now that content format is validated

https://gerrit.wikimedia.org/r/106621
Change 106627 had a related patch set uploaded by Jforrester:
Provide content format faux reqeust now that content format is validated

https://gerrit.wikimedia.org/r/106627
Asking here instead of in IRC:
What's the offending commit? When was it merged into master?
(grumble mid-air collision bz, really adding reedy now)
Adding reedy:

Reedy, if this isn't fixed very quickly, we'll need to revert :/

Rob: Can you get that reviewed and merged and tested on beta cluster ASAP?
Change 106621 had a related patch set uploaded by Krinkle:
Provide content format faux reqeust now that content format is validated

https://gerrit.wikimedia.org/r/106621
new patch
https://gerrit.wikimedia.org/r/#/c/106621/
Change 106619 abandoned by Robmoen:
Provide content format faux reqeust now that content format is validated

https://gerrit.wikimedia.org/r/106619
Change 106619 had a related patch set uploaded by Robmoen:
Provide content format faux reqeust now that content format is validated

https://gerrit.wikimedia.org/r/106619
Added Rob Moen and Greg Grossmeier and changed importance, this affects mediawiki.org also
This is happening on test2 environment now after 1.23wmf10 deployment
Confirming.
https://it.wikipedia.org/w/index.php?title=Utente%3AElitre_%28WMF%29%2FSandbox_VE&diff=63377772&oldid=63377716

I added the Citazione Necessaria template to my sandbox,
and added some text to its only parameter.

As a result I get an additional superscripted "Citazione necessaria" which is broken:
<sup data-ve-ignore="true" class="noprint"><span title="Il testo selezionato deve essere comprovato da una fonte affidabile. Modifica la pagina per aggiungere fonti." style="color:red;">[''<a href="/wiki/Wikipedia:Uso_delle_fonti" title="Wikipedia:Uso delle fonti">senza fonte</a>'']</span></sup>

(Not sure if bug 59154/bug 55855 are related.)

--------------------------
**Version**: unspecified
**Severity**: major
What about these:
https://en.wikipedia.org/w/index.php?title=Seattle%E2%80%93Tacoma_International_Airport&diff=592102043&oldid=592065880
https://en.wikipedia.org/w/index.php?title=Lega_Nord&diff=594074863&oldid=593959708
https://en.wikipedia.org/w/index.php?title=Swedish_Hockey_League&diff=591935813&oldid=589894884

It looks like the fix here was not complete... Did that get fixed at some point?
This was fixed by https://gerrit.wikimedia.org/r/#/c/107559/
(Copy/pasting isn't involved in the cases I reported at least, but thanks for assigning this.)
*** Bug 59902 has been marked as a duplicate of this bug. ***
I've seen this in users of Windows 7, Windows 8, Mac OS 10.8, and Linux.  Editors have encountered this in at least Chrome, Firefox, and Safari.  Systematic testing of browsers can be seen at https://en.wikipedia.org/w/index.php?title=User:Ceyockey/sandbox_spantest&action=history

Other examples include:
 
https://en.wikipedia.org/w/index.php?title=List_of_information_graphics_software&curid=2891117&diff=590578180&oldid=590577937

https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28Greece_season_4%29&curid=40567903&diff=590510331&oldid=590492954

https://en.wikipedia.org/w/index.php?title=Tour_de_Ski&curid=8516243&diff=589296570&oldid=589296376

https://en.wikipedia.org/w/index.php?title=Kamal_Haasan&curid=222346&diff=589232047&oldid=589174733

https://en.wikipedia.org/w/index.php?title=PTC_Therapeutics&curid=13883765&diff=589307581&oldid=589306439

https://office.wikimedia.org/w/index.php?title=User:Whatamidoing_(WMF)/Sandbox&diff=105448&oldid=105447
**mr.heat** wrote:

This obviously is the same error:
https://de.wikipedia.org/wiki/Nest_Labs?diff=126472789

Reported/discussed here:
https://www.mediawiki.org/wiki/Thread:VisualEditor/Feedback/HTML_output_from_template_leaked_into_wikitext

I tried to reproduce it but it did not happen.
The French template "etc" gets a similar error:
https://fr.wikipedia.org/w/index.php?title=Gremlin&diff=99848534&oldid=92711100

{{etc}}<abbr data-ve-ignore="true" class="abbr" title="et cetera" xml:lang="la" lang="la">etc.</abbr>
The French version of that template also gets that bug, while the English one probably works differently: https://en.wikipedia.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandbox&diff=589354249&oldid=583268893 .
Screenshot of problem in production.

As of recently, we have SVG versions of the external link icons in MediaWiki. These are embedded as base64 encoded data uris by CSSMin in ResourceLoader.

Locally, these are working fine for me. Comes out as:

 background-image: linear-gradient(transparent,transparent),url(data:image/svg+xml;base64,PD...

In production, however, they are broken.
E.g.: https://www.mediawiki.org/wiki/VisualEditor/Basic_example_worksheet#Links

 background-image: linear-gradient(transparent,transparent),url(data:application/xml;base64,PD...

I can consistently reproduce this in Chrome (latest stable). I eliminated other causes by verifying that it breaks locally if I change the mime type in the CSS manually, and visa versa by changing it to image/svg+xml in the browser console when looking at production.


Not sure if this supposed to work according to the spec, but fact is, Chrome (maybe other browsers as well) does not accept application/xml in data uris for background images.

--------------------------
**Version**: wmf-deployment
**Severity**: major

**Attached**: {F12090}
*** This bug has been marked as a duplicate of bug 59234 ***
https://github.com/wikimedia/mediawiki-core/blob/master/includes/libs/CSSMin.php#L118-L142
On MediaWiki.org (1.23wmf9), MW thinks that the appropriate MIME type for SVGs embedded in CSS as data: URIs is application/xml instead of image/svg+xml, causing them not to show up in any browser. It works for me locally.

--------------------------
**Version**: 1.23.0
**Severity**: major
**URL**: https://www.mediawiki.org/wiki/VisualEditor/Basic_example_worksheet#Links
(In reply to comment #33)
> I'll clone this ticket to cover the general issue.

Filed as bug 59744. I only CC'd Kevin. The rest of you can CC yourselves if you'd like.
Both https://www.mediawiki.org/w/index.php?title=Requests_for_comment/Custom_inter-namespace_tabs&action=edit and [[mw:Special:RecentChanges]] look good to me now. Thanks!

Marking this ticket as resolved/fixed. I'll clone this ticket to cover the general issue. Kevin: thanks as always for digging into this. :-)
(In reply to comment #29)
> (In reply to comment #23)
> > I'm seeing missing arrows next to "Templates used on this page:" below the
> > edit
> > window on mediawiki.org as well. Example URL:
> > <https://www.mediawiki.org/w/index.php?title=Requests_for_comment/
> > Custom_inter-namespace_tabs&action=edit>.
> > I'm not sure if this is already covered by the Gerrit changes linked above.
> 
> Ditto.
> 
> Also seeing it on the Beta Cluster, eg at
> http://en.wikipedia.beta.wmflabs.org/w/index.
> php?title=Dido_Sotiriou&action=edit
> 
> The Beta Cluster is already running with
> https://gerrit.wikimedia.org/r/#/c/105469/ though, ie: even the cherrypick to
> wmf9 (https://gerrit.wikimedia.org/r/#/c/105477/) won't fix it on mw.org most
> likely.
> 
> So, this issue isn't fixed with any of the already merged (to master)
> patches.

I think I mispoke here/wasn't looking at the right thing. I think this one is indeed fixed by the patches.

I think thanks to Reedy's lastest push, everything is back to normal/good. Anyone seeing any other inconsistencies/lack of images?
(In reply to comment #30)
> Change 105477 merged by jenkins-bot:
> Deoptimize SVG versions of enhanced recent changes collapse/show arrows
> 
> https://gerrit.wikimedia.org/r/105477

Fixed mediawiki.org for me
Change 105477 merged by jenkins-bot:
Deoptimize SVG versions of enhanced recent changes collapse/show arrows

https://gerrit.wikimedia.org/r/105477
(In reply to comment #23)
> I'm seeing missing arrows next to "Templates used on this page:" below the
> edit
> window on mediawiki.org as well. Example URL:
> <https://www.mediawiki.org/w/index.php?title=Requests_for_comment/
> Custom_inter-namespace_tabs&action=edit>.
> I'm not sure if this is already covered by the Gerrit changes linked above.

Ditto.

Also seeing it on the Beta Cluster, eg at http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Dido_Sotiriou&action=edit

The Beta Cluster is already running with https://gerrit.wikimedia.org/r/#/c/105469/ though, ie: even the cherrypick to wmf9 (https://gerrit.wikimedia.org/r/#/c/105477/) won't fix it on mw.org most likely.

So, this issue isn't fixed with any of the already merged (to master) patches.

(In reply to comment #16)
> Created attachment 14228 [details]
> Screenshot of missing arrows from [[mw:Special:RecentChanges]]
> 
> (In reply to comment #13)
> > I don't know what you are looking at on mw.org, but it certainly isn't fixed
> > for me or Mz ;)
> 
> I uploaded a screenshot of how [[mw:Special:RecentChanges]] looks to me at
> the
> moment. Perhaps cache?

I don't see that issue on the BetaCluster, but I can confirm on mw.org.

So, this one is indeed fixed with the patches merged to master.

**Attached**: {F12054}
(In reply to comment #16)
> Created attachment 14228 [details]
> Screenshot of missing arrows from [[mw:Special:RecentChanges]]

I can still reproduce MZMcBride's screenshot after enabling "Group changes by page in recent changes and watchlist" on https://www.mediawiki.org/w/index.php?title=Special:Preferences#mw-prefsection-rc

<span class="mw-collapsible-toggle mw-collapsible-arrow mw-enhancedchange…-enhancedchanges-arrow-space mw-collapsible-toggle-collapsed" tabindex="0"></span> is empty but should probably show a collapsible arrow (if I interpret the classes correctly here).

**Attached**: {F12054}
This seems to have been fixed in file 5.04; however, PHP uses a bundled,
patched copy of the library that was only updated from 5.03 to 5.11 in
12cf930a403d.

Running "git tag --contains 12cf930a403d" in php-src tells me that
affected versions of PHP were 5.3.10 and older, as well as 5.4.0.
Wikimedia runs 5.3.10 in production.

Here's a snippet of the diff:

--- file-5.03/magic/Magdir/sgml	2008-07-26 11:03:55.000000000 -0400
+++ file-5.04/magic/Magdir/sgml	2009-09-19 13:31:35.000000000 -0400
@@ -1,36 +1,59 @@
 #------------------------------------------------------------------------------
+# $File: sgml,v 1.24 2009/09/19 17:31:35 christos Exp $
 # Type:	SVG Vectorial Graphics
 # From:	Noel Torres <tecnico@ejerciciosresueltos.com>
 0	string		\<?xml\ version="
 >15	string		>\0
->>23	search/400	\<svg			SVG Scalable Vector Graphics image
+>>19	search/4096	\<svg			SVG Scalable Vector Graphics image
 !:mime	image/svg+xml

Note that the start offset of the search for "<svg" was dropped from 23 to 19, and the newer, shorter XML declaration was the following 22-character string:

<?xml version="1.0" ?>

So this problem could have been avoided by either adding a DOCTYPE or leaving one more whitespace character in the right place.
(In reply to comment #24 and comment #25)

Neither of these comments were helpful as a reply to comment 23. Thanks for adding Reedy to the relevant changeset, though.
(I hoper we aren't using yet another set of arrows icons for that)
the arrow fixed hasn't been merged and deployed in wmf9, i've tagged reedy on that changeset.
I'm seeing missing arrows next to "Templates used on this page:" below the edit window on mediawiki.org as well. Example URL: <https://www.mediawiki.org/w/index.php?title=Requests_for_comment/Custom_inter-namespace_tabs&action=edit>. I'm not sure if this is already covered by the Gerrit changes linked above.
(In reply to comment #21)

> https://gerrit.wikimedia.org/r/105477

This one is the backport to 1.23wmf9, which someone else will need to merge+deploy.
Change 105477 had a related patch set uploaded by Legoktm:
Deoptimize SVG versions of enhanced recent changes collapse/show arrows

https://gerrit.wikimedia.org/r/105477
Change 105469 merged by jenkins-bot:
Deoptimize SVG versions of enhanced recent changes collapse/show arrows

https://gerrit.wikimedia.org/r/105469
Done, sorry about the mess. Backport and deploy to taste.
Change 105469 had a related patch set uploaded by Bartosz Dziewoński:
Deoptimize SVG versions of enhanced recent changes collapse/show arrows

https://gerrit.wikimedia.org/r/105469
IIRC I was silly enough to optimize the recent changes arrows in a different commit, eh. Sorry about that, patch on the way.
Created attachment 14228
Screenshot of missing arrows from [[mw:Special:RecentChanges]]

(In reply to comment #13)
> I don't know what you are looking at on mw.org, but it certainly isn't fixed
> for me or Mz ;)

I uploaded a screenshot of how [[mw:Special:RecentChanges]] looks to me at the moment. Perhaps cache?

**Attached**: {F12054}
(In reply to comment #14)
> I'm looking at the main page on mw.o with FF26 on OSX10.9.1 and it looks fine
> to me.

Tried recent changes with enhanced recent changes on?
I'm looking at the main page on mw.o with FF26 on OSX10.9.1 and it looks fine to me.
(In reply to comment #12)
> Ori just reverted it via https://gerrit.wikimedia.org/r/#/c/105413/ and
> pushed
> it out to wmf9. Looks fixed on the Beta Cluster and mw.org to me.

I don't know what you are looking at on mw.org, but it certainly isn't fixed for me or Mz ;)
Ori just reverted it via https://gerrit.wikimedia.org/r/#/c/105413/ and pushed it out to wmf9. Looks fixed on the Beta Cluster and mw.org to me.

His commit message:
On my Mac, calling finfo_file on external-link-ltr-icon.svg gets the correct
MIME-type ("image/svg+xml"), but in production I get  "application/xml".
This is probably due to the version of fileinfo or libmagic that is deployed on
the cluster. Reverting for now.


Robla made the point that just upgrading libmagic isn't the right/full solution: we shouldn't break backwards compat here that quickly.
*** Bug 59452 has been marked as a duplicate of this bug. ***
(In reply to comment #8)
> (In reply to comment #6)
> > Bartosz: Can you get a patch for re-adding in the doctype on those svgs?
> 
> I didn't even remove doctypes from most of these files (they haven't had
> any).
> I'll leave shotgun debugging to someone who has access to production
> environment; if you need this fixed immediately, try reverting If05ee0e0.

That's what the Beta Cluster is for :).

But you're right, just first random file change I looked at removed the doctype, but the external link svg, which is not shown in that test case on Beta Cluster, didn't have doctype before either.

I'm confused now.

On en.wiki (production), the lock icon next to an external url is a base64 encoded image/png.

On en.betawiki, the lock icon is a base64 application/xml, that is in fact valid/renders if you load it directly. It just doesn't show on the page.

Both viewed with Iceweasel 24.2.
(In reply to comment #7)
Not sure anymore if that's the same problem. Filed as bug 59452 instead.
(In reply to comment #6)
> Bartosz: Can you get a patch for re-adding in the doctype on those svgs?

I didn't even remove doctypes from most of these files (they haven't had any). I'll leave shotgun debugging to someone who has access to production environment; if you need this fixed immediately, try reverting If05ee0e0.


(In reply to comment #7)
> From #mediawiki a few minutes ago, pasting as it mentions IE difference:
> <SVG^> Hey all. Is there already a bug report about the missing arrows in the
> recent changes at MediaWiki.org with Chrome and FF (IE shows them properly)?

Old IE uses the fallback PNG images, which show up correctly.
From #mediawiki a few minutes ago, pasting as it mentions IE difference:
<SVG^> Hey all. Is there already a bug report about the missing arrows in the recent changes at MediaWiki.org with Chrome and FF (IE shows them properly)?
Bartosz: Can you get a patch for re-adding in the doctype on those svgs? If you can get that merged today it'll be on Beta shortly after.

The problem is exhibited on Beta Cluster, see eg:
http://en.wikipedia.beta.wmflabs.org/wiki/User:Greg_%28WMF%29
(Quote from bug 59249 comment #1)
> https://github.com/wikimedia/mediawiki-core/blob/master/includes/libs/CSSMin.
> php#L118-L142

It probably works for us locally because it uses a different function than production, or maybe the underlying library has a different upstream version or configuration of an upstream C-library dependency.

(In reply to comment #4)
> Since this has worked before, a possible culprit is my commit optimizing the
> SVGs: If05ee0e0 – lots of things that are supposedly non-essential were
> removed
> from the SVGs' source code.

Yeah, let's find out if putting the doctype back makes it work for mimetype library Wikimedia uses in production.

Otherwise we'll have to abstract mime type detection to make sure that valid XML documents of which the root tag is "<svg>" are detected as SVG (instead of plain XML).
Since this has worked before, a possible culprit is my commit optimizing the SVGs: If05ee0e0 – lots of things that are supposedly non-essential were removed from the SVGs' source code.
*** Bug 59249 has been marked as a duplicate of this bug. ***
The empty gap is pretty confusing plus might create side effects (bug 59239); hence supporting blocking next deployment (bug 38865). CC'ing greg.
For example, this affects the little icons shown next to links; a blank space appears instead.
When loaded in alpha on beta labs I get 
Error: Unknown dependency: jquery.uls Error {} 

Given this is the second dependency related error I've now seen I'm a bit concerned about the speed at which dependencies are added to the mobile version of VisualEditor. Is there a way to better sandbox the mobile code? I find it hard to believe that ULS is actually needed for the stripped down mobile version.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 102368 merged by jenkins-bot:
Move additional module loading from mw.Target to mw.ViewPageTarget

https://gerrit.wikimedia.org/r/102368
Change 102368 had a related patch set uploaded by Jdlrobson:
Move additional module loading to viewPage vs general target

https://gerrit.wikimedia.org/r/102368
http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Something&veaction=edit

The error is :
ailed to load resource: the server responded with a status of 500 (Internal Server Error) http://en.wikipedia.beta.wmflabs.org/w/api.php

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix on betalabs:http://en.wikipedia.beta.wmflabs.org/
Change 99317 merged by jenkins-bot:
Followup ec3d1d67c: fix fatals because of removed run() methods

https://gerrit.wikimedia.org/r/99317
Change 99317 had a related patch set uploaded by Catrope:
Followup ec3d1d67c: fix fatals because of removed run() methods

https://gerrit.wikimedia.org/r/99317
Chad – Not sure if this is solely caused by CirrusSearch, but it'd be great to get that factored out.
Exception associated with the HTTP 500 in the Apache logs on beta:

Dec  5 03:02:04 10.4.0.187 apache2: PHP Fatal error:  Class CirrusSearchLinksUpdateJob contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Job::run) in /data/project/apache/common-local/php-master/extensions/CirrusSearch/includes/CirrusSearchLinksUpdateJob.php on line 22
**jhall** wrote:

Problem also successfully repros for me using Linux (Ubuntu) with Chrome v31 and Firefox v25.
I am still getting it:
http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Something&veaction=edit
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5
Cannot reproduce. 
Generic Labs bug 57968, maybe?
Steps to reproduce:

1.Edit a page
2.Click on "Save Page"

Observed Result:
Unknown Error shows up in the dialog box.
The error in the console is:
Failed to load resource: the server responded with a status of 500 (Internal
Server Error
Created attachment 13987
Screenshot of the error

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

1.Click on Switch to source editing from the down menu for an article on betalabs

Observed Result:
Nothing happens.It does not switch to source editing from VE

--------------------------
**Version**: unspecified
**Severity**: critical
(In reply to comment #9)
> Seeing something slightly odd after this fix was deployed to Betalabs - not
> sure this is Bad Thing, so not re-opening the bug at this point…
> 
> There are 2 pathways to switch from VE to wikitext, and they now navigate the
> user to different URLs (this didn't happen prior to the bug fix).
> 
> If you start in VE editing mode, and use the "Edit Source" tab to switch to
> wikitext, you end up at:
> 
> http://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:
> Oldjoe&action=edit
> 
> On other hand, if you start in VE editing mode and select "Switch to source
> editing" from the Page Settings drop-down, you end up at:
> 
> http://en.wikipedia.beta.wmflabs.org/wiki/User:Oldjoe?action=submit
> 
> Is this the intended behavior?

The change to the primary entry point isn't explicitly intended, but I don't think it's the end of the world to push people towards the canonical (and simpler) URLs.
verified in production
**jhall** wrote:

Seeing something slightly odd after this fix was deployed to Betalabs - not sure this is Bad Thing, so not re-opening the bug at this point…

There are 2 pathways to switch from VE to wikitext, and they now navigate the user to different URLs (this didn't happen prior to the bug fix).

If you start in VE editing mode, and use the "Edit Source" tab to switch to wikitext, you end up at:

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:Oldjoe&action=edit

On other hand, if you start in VE editing mode and select "Switch to source editing" from the Page Settings drop-down, you end up at:

http://en.wikipedia.beta.wmflabs.org/wiki/User:Oldjoe?action=submit

Is this the intended behavior?
Verified the fix on beta labs 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/New_page_on_latex
This should now be fixed.
Change 98989 merged by jenkins-bot:
Fix naked request for save dialog's summary in save

https://gerrit.wikimedia.org/r/98989
Change 98989 had a related patch set uploaded by Jforrester:
Fix naked request for save dialog's summary in save

https://gerrit.wikimedia.org/r/98989
Yes, it is still occurring.
Bug 57926 is now fixed - does this still occur?
Sorry Test Environment should be betalabs in my previous comment.
Test Environment: production
Browser: Chrome Version 26.0.1410.65 &       FF 25
OS: MAC OS X 10. 8. 5 
Example Pagehttp://en.wikipedia.beta.wmflabs.org/wiki/Groel?veaction=edit
- go to any article
- edit it with visual editor
- instead of text of the article in visual editor, text of another article appears

- reproducible for every article I have tried at http://en.wikipedia.beta.wmflabs.org/
- not reproducible at http://test2.wikipedia.org/

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57233
hopefully cleared parsoid cache using:


 deployment-parsoidcache3$ sudo varnishadm ban.url .
And it is fixed now!

Gabriel kindly answered all my newbie questions related to Parsoid architecture. Ended up confirming that Parsoid running on deployment-parsoid2 did query the production infrastructure despite a localsettings.js  claiming otherwise.

Roan showed up and noticed that /var/lib/parsoid/Parsoid points to the shared NFS directory (/data/project/apache/common-local/php-master/extensions/Parsoid/).  That one is autoupdated and did NOT contain the localsettings.js file

Roan copied the settings file, I restarted the server and now it seems to be serving the proper pages.

The root cause is https://gerrit.wikimedia.org/r/98014 from last Friday which I did not bother to verify :-(
On deployment-parsoid2 , I have edited /usr/bin/parsoid to enable some log, namely the launch command is something like:

 sudo -E -u parsoid nohup node \
   /var/lib/parsoid/Parsoid/js/api/server.js \
   >/data/project/logs/parsoid-stdout.log \
   2>/data/project/logs/parsoid-error.log &

/data/project being the shared project directory, that might gives some clue.
[13:41] <gwicke> parsoid is not using action=visualeditor
[13:42] <gwicke> I'd double-check that VE is actually using parsoidcache3
[13:42] <gwicke> and that the request goes to the right parsoid backend
The Parsoid does queries to the MediaWiki API to get some content to render. One of the request is logged in api.log as:

 format=json action=visualeditor page=Marching_band paction=parse

I used ApiSandbox to reproduce that query:

http://en.wikipedia.beta.wmflabs.org/wiki/Special:ApiSandbox#action=visualeditor&format=json&page=Marching_band&paction=parse

The response contains among other things:

 http://en.wikipedia.org/wiki/Special:Redirect/revision/51845
 <title>Marching_band</title>
 Describe the new page here.

 "basetimestamp": "20120103034343",
 "starttimestamp": "20131203212539",
 "oldid": 51845

The redirection to old id 51845 yields page https://en.wikipedia.org/w/index.php?oldid=51845 which is the 'Pérez Prado' article.
There is no more 404 errors but some articles still gives content that does not match the page being requested :/
I upgraded the varnish on parsoidcache instance while I was investigating.

Now it seems VE is querying the parsoid with some invalid URL and it popup a 404 error :-/   Nothing obvious in the logs though, maybe VE has a wgDebugLogGroup we should enable to get more logs.
The articles returned do not seem to originate from beta enwiki or production enwiki
I have updated Parsoid code on deployment-parsoid2 in /srv/deployment/parsoid/Parsoid

Forgot to run npm install to update the node modules, might be related :/
This very much looks like an artefact of the changes for bug 57233 - marking as such.
Screenshot attached

Steps to reproduce:

1.Click on the Edit button
2.Add any image/template/link in the article
3.Click the "Save Page" button

Observed Result:
Cannot Save the Article.

The following error is found in the developers tool:

Uncaught TypeError: Object #<VeDmInternalItemNode> has no method 'isCollapsed'
ve.dm.Transaction.newFromRemoval
ve.ui.MWReferenceDialog.teardown
OO.ui.Window.close
(anonymous function)
proxy load.php:10

--------------------------
**Version**: unspecified
**Severity**: blocker

**Attached**: {F12504}
*** This bug has been marked as a duplicate of bug 57683 ***
Test Environment: production
Browser: Chrome Version 26.0.1410.65 and FF 25
OS: MAC OS X 10. 8. 5 
Example Page:http://en.wikipedia.beta.wmflabs.org/wiki/Groel?veaction=edit
Steps to reproduce:

1.Click on the Edit page
2.Select a text or place the cursor at the end of any text
3.Click on More>Reference
4.Click on Insert reference
5.Click on Save Page

Observed Result:
No reference is getting added in the article.

--------------------------
**Version**: unspecified
**Severity**: blocker
Moved my comments to bug 59599 and bug 59600.
I think this just happened to me on the Danish Wikipedia?
I used my userpage as a sandbox https://da.wikipedia.org/w/index.php?title=Bruger:Elitre_(WMF)&action=history, and the edits in which I tried to add references do not show up in the history, although I managed to save them and also got the message that confirms this.

(For the record, I was trying to reproduce https://da.wikipedia.org/w/index.php?title=F-35_Lightning_II&diff=prev&oldid=7409486 and https://da.wikipedia.org/w/index.php?title=Enhedslisten&diff=prev&oldid=7414100 , where there might be a connection between adding a reference and getting a duplicated infobox).
verified the fix in production
Verified in betalabs.
http://en.wikipedia.beta.wmflabs.org/wiki/New_page_on_latex
Change 98587 merged by jenkins-bot:
Fix JS errors when inserting references

https://gerrit.wikimedia.org/r/98587
Change 98587 had a related patch set uploaded by Catrope:
Fix JS errors when inserting references

https://gerrit.wikimedia.org/r/98587
*** Bug 57785 has been marked as a duplicate of this bug. ***
(In reply to comment #2)
> Please note that, this is working fine in Live right now.
By Live, I meant production in :https://en.wikipedia.org/
Please note that, this is working fine in Live right now.
Test Environment: Betalabs
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5
Example Page:http://en.wikipedia.beta.wmflabs.org/wiki/User:RYasmeen_(WMF)?veaction=edit
Seen in Firefox on beta labs as of Nov 25 (Chrome behaves correctly):

Login and navigate to some page with text, e.g. as Selenium_user/User:Selenium_user

Without touching anything on the page, click the "Link" icon in the menu bar. 

Expected:  First word in the page is highlighted and link UI appears, referring to highlighted text. 

Actual:  Link icon shows being pressed, but no link UI appears.

--------------------------
**Version**: unspecified
**Severity**: blocker
Verified in production
Verified in Betalabs.
http://en.wikipedia.beta.wmflabs.org/wiki/New_page_on_latex
Change 98688 merged by jenkins-bot:
Use visibility: hidden; for the ui.Context and its popup

https://gerrit.wikimedia.org/r/98688
Change 98688 had a related patch set uploaded by Catrope:
Use visibility: hidden; for the ui.Context and its popup

https://gerrit.wikimedia.org/r/98688
Also partially fixed in gerrit 98598.
Change 98569 merged by jenkins-bot:
Use visibility: hidden; to hide inspectors

https://gerrit.wikimedia.org/r/98569
Change 98569 had a related patch set uploaded by Catrope:
Use visibility: hidden; to hide inspectors

https://gerrit.wikimedia.org/r/98569
Looks like transplantStyles isn't resolving in OO.ui.Frame.
*** Bug 57779 has been marked as a duplicate of this bug. ***
Also, after clicking on the "Link" icon, the "Save Page" button does not work anymore even if I close the editor and reopen and re-edit it.Related issue?
**jhall** wrote:

Now it seems as though the Link interface is completely broken in Firefox.  Following repro steps above, when I click the "Link" icon, nothing happens at all (Chrome stills seems to work fine).
Created attachment 13905
link is pressed, 'Starting' should be highlighted, link UI should appear but does not

**Attached**: {F12079}
As discovered today with the Wikidata weekly summaries run, MassMessage ignores the namespace if it is a interwiki link.

Example; {{#target:Wikidata:Status updates|www.wikidata.org}}

The message gets delivered to https://wikidata.org/wiki/Status_updates which then errors due to it being in NS_MAIN and not NS_PROJECT which was specified.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=58524
Seems to happen again? https://meta.wikimedia.org/w/index.php?title=VisualEditor/Newsletter/Wikis_with_VE&oldid=11801108
This went out to the rest of the sites with today's deployment and looks to be working fine: <https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&diff=prev&oldid=589970369>
(In reply to comment #22)
> (In reply to comment #21)
> > I've been using MassMessage the whole time. Just replace the namespaces with
> > 'Project:' (if this is not deployed within time).
> 
> Is the canonical namespace name safe to use?

Let's see: <https://meta.wikimedia.org/w/index.php?title=Special:Contributions/AnankeBot&dir=prev&offset=20121207114449&limit=39&target=AnankeBot>.
(In reply to comment #21)
> I've been using MassMessage the whole time. Just replace the namespaces with
> 'Project:' (if this is not deployed within time).

Is the canonical namespace name safe to use? If so, that's a handy workaround. :-)

(In reply to comment #20)

People continue to use EdwardsBot, both locally and globally. Bug 58962 is probably more pressing to get resolved, but this bug (bug 57464) is medium priority given the rather nasty side effect (failed deliveries). It can probably go out to Wikimedia wikis on Monday or Tuesday of this week. That'd be a question for Sam, Ori, or Aaron S., I imagine.

There's also bug 54859 about adding an API module for MassMessage. This would help for the Signpost in particular given its use of LivingBot, in my estimation.
(In reply to comment #20)
> Dan or Greg, is there any chance we can get this deployed this week?
> 
> Because of this bug, we're still dependent on EdwardsBot for global message
> delivery, and EdwardsBot is planned to be retired from global delivery in 2
> days. The sooner we can fully transition to MassMessage, the better :)

I've been using MassMessage the whole time. Just replace the namespaces with 'Project:' (if this is not deployed within time).
Dan or Greg, is there any chance we can get this deployed this week?

Because of this bug, we're still dependent on EdwardsBot for global message delivery, and EdwardsBot is planned to be retired from global delivery in 2 days. The sooner we can fully transition to MassMessage, the better :)
Change 101814 merged by jenkins-bot:
Store title as a job parameter

https://gerrit.wikimedia.org/r/101814
Change 101814 had a related patch set uploaded by Legoktm:
Store title as a job parameter

https://gerrit.wikimedia.org/r/101814
Change 101810 merged by jenkins-bot:
Add debug logging for bug 57464

https://gerrit.wikimedia.org/r/101810
Change 101810 had a related patch set uploaded by Legoktm:
Add debug logging for bug 57464

https://gerrit.wikimedia.org/r/101810
Change 101808 merged by jenkins-bot:
Add debug logging for bug 57464

https://gerrit.wikimedia.org/r/101808
Change 101808 had a related patch set uploaded by Legoktm:
Add debug logging for bug 57464

https://gerrit.wikimedia.org/r/101808
At [[Special:Log/massmessage]] I currently see:

---
08:38, 9 December 2013 Delivery of "[[m:Special:MyLanguage/Tech/News/2013/49|Tech News: 2013-49]]" to Village pump (technical) was skipped because target was in a namespace that cannot be posted in
---

This is pretty gross. "Village pump (technical)" should be "Wikipedia:Village pump (technical)". Not sure what's going on with "[[m:...]]"; that may be a separate bug.

Ori: any chance you could take a look here?
I'm not able to see where the namespace is being lost, so here are the steps the data goes through. Maybe someone else will spot it.

1. Picked up by MassMessageHooks::storeDataParserFunction as a string
2. MassMessageHooks::verifyPFData validates that it is a valid title (checks !is_null( Title::newFromText ) ), but returns the original string
3. MassMessage::getParserFunctionTargets unserializes the string.
4. MassMessage::normalizeTargets simply re-arranges the list of targets, not modifying the string.
5. Back to SpecialMassMessage::submit, which feeds the result from normalizeTargets to MassMessageSubmitJob.
6. the SubmitJob creates a Title object, and submits a group of MassMessageJobs.
7. On meta, in MassMessageJob::__construct, there is "$this->title = Title::newFromText( $this->title->getPrefixedText() );", which was the original fix for this bug. It *should* do nothing when being run on meta.
8. When the job is executed on the target wiki, that line is run again. Title::getPrefixedText should return the entire title (including interwiki) except for any fragments (url anchors). By re-creating the title, the namespace should be re-parsed as a real namespace instead of an interwiki prefix.

The issue:
If the namespace is not an interwiki prefix, it is re-parsed correctly as can be seen by the successful deliveries.

If the namespace is an interwiki prefix, it is still thought to be an interwiki prefix (I think), and the delivery fails since it is not interpreted as a namespace.

My hunch is that somewhere step 8 isn't working as I expect it would.
Not fixed apparently, see https://meta.wikimedia.org/w/index.php?title=User_talk:Guillom&oldid=6668167

Glancing at the list of wikis, the first thing I notice is that for all the wikis in the "did not work" list (except for one), they all have namespaces that are also interwiki prefixes on meta.

The lone exception is ttwiki, https://tt.wikipedia.org/wiki/%D0%9C%D0%B0%D1%85%D1%81%D1%83%D1%81:%D0%9A%D3%A9%D0%BD%D0%B4%D3%99%D0%BB%D0%B5%D0%BA/massmessage?uselang=en

The weird thing about that is that link is to the correct page. The link on the failed commons delivery is missing the namespace, see https://commons.wikimedia.org/wiki/Special:Log/massmessage
This was deployed at some point.
(In reply to comment #6)
> Kunal: Yeah, please prepare a backport to wmf5.

I've created a branch called '1.23wmf5' and cherry-picked the patch onto it.
Change 98709 merged by jenkins-bot:
Create a fresh Title object in the job

https://gerrit.wikimedia.org/r/98709
Change 98709 had a related patch set uploaded by Legoktm:
Create a fresh Title object in the job

https://gerrit.wikimedia.org/r/98709
Kunal: Yeah, please prepare a backport to wmf5. And when would you be available to help with the deploy this week? We might be able to get this in tomorrow.

(I assume the only bit that is needed to be backported is gerrit 97162.)
Thanks for the quick fix. This probably didn't get caught because we only deployed to test.wikipedia.org and test2.wikipedia.org, instead of a project such as Wikidata or Commons, which share an interwiki prefix and a namespace name. This probably points to an area where a unit test might make sense? (Or additional test inputs?) Maybe. In any case, this bug is no longer PATCH_TO_REVIEW. I'll leave it to someone else to figure out what to set it to.
Greg, Sam, would it be possible to get this backported and deployed next week? Global message delivery basically won't work because of this.
Change 97162 merged by jenkins-bot:
Create a fresh Title object in the job

https://gerrit.wikimedia.org/r/97162
I guess this might also affect Commons (https://meta.wikimedia.org/wiki/Distribution_list/Global_message_delivery ).

It looks like this issue prevents MM from being used for most of the usual global message deliveries to village pumps, so it's great that we already have a patch, and a timely review and deployment would be useful.
Change 97162 had a related patch set uploaded by Legoktm:
Create a fresh Title object in the job

https://gerrit.wikimedia.org/r/97162
Try to reuse a reference in VE in an article featuring references.

All you get is the list of number in brackets, which are the numbers of the references, and nothing else.

(Actually, if you test it in https://en.wikipedia.org/wiki/Alex_Timbers?veaction=edit , you will notice that it does provide the "ref name" for the first reference; but that's it).

It seems it does not matter which OS, browser or skin you are using.

--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://commons.wikimedia.org/wiki/File:VisualEditor_ref_dialog_box_showing_numbers_and_ref_names.png
Created attachment 14498
Screenshot of testing the fix

**Attached**: {F12146}
Verified the fix in test2
Fixed and back-ported.
Change 111232 merged by jenkins-bot:
Fix 'use existing reference' list rendering

https://gerrit.wikimedia.org/r/111232
Change 111229 merged by jenkins-bot:
Fix 'use existing reference' list rendering

https://gerrit.wikimedia.org/r/111229
(In reply to comment #11)

Thank you for your reply.
Change 111232 had a related patch set uploaded by Jforrester:
Fix 'use existing reference' list rendering

https://gerrit.wikimedia.org/r/111232
Change 111229 had a related patch set uploaded by Jforrester:
Fix 'use existing reference' list rendering

https://gerrit.wikimedia.org/r/111229
Change 111203 merged by jenkins-bot:
Fix 'use existing reference' list rendering

https://gerrit.wikimedia.org/r/111203
Change 111203 had a related patch set uploaded by Esanders:
Fix 'use existing reference' list rendering

https://gerrit.wikimedia.org/r/111203
Sorry, this bug got entirely missed.

For major regression bugs like this, if they've clearly missed out on immediate triage, please shout out-of-band (e.g. on IRC or the various Feedback pages) as otherwise it's likely to continue to get missed for weeks or even months, as in this case. :-(

Assigning. Ed, please fix urgently.
Nemesis, what you're seeing for the fourth reference is the ref name (<ref name="Couratier_Transvaal">).  This is displayed, and might be helpful if the ref name were both sensibly chosen (e.g., not just a number or random letter) and if it already existed for every ref that you wanted to re-use.
(In reply to comment #9)
> This is ABSURD.

Please discuss high-level team priorities or workflows e.g. on https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback - this specific bug report is only about this specific bug and its technical aspect. Thanks.
This is ABSURD. It's been two and half months of having something that *used to work* no longer work. And that something was very USEFUL - if you wanted to use a existing citation/reference to support text in more than one place in an article, you could do so easily. 

Why does it take the VE team MONTHS to fix something that gets broken? How difficult is this, really? Why don't regressions get TOP priority for fixing? 

(Just so there's no misunderstanding about what's broken:

a. In the "Insert" menu, select "Reference"
b. At the bottom left corner of the dialog box, click "Use an existing reference".

While you can still select any existing reference, what you CAN'T do is actually see what the references consist of (author, title, date, publication, etc.). Yes, occasionally some text does appear, but REALLY?

And yes, there is a workaround - first you should look at the References section in the article, and note the reference number you want, BEFORE you do a. and b. above. But REALLY - is this supposed to be user-friendly? Is this the sort of step-by-step procedure we want to put into a user manual?

So to repeat - it's ABSURD that someone can't easily (and quickly) fix a problem that simply involves DISPLAYING SOME TEXT. And if there is an underlying problem with VE or Parsoid that prevents DISPLAYING SOME TEXT, then perhaps someone would post a brief explanation here so that this wouldn't seem so ABSURD.
Actually, when test on my sandbox page, https://fr.wikipedia.org/wiki/Utilisateur:NemesisIII/Ch%C3%A2teau_Rothschild_%28Boulogne-Billancourt%29?veaction=edit, there is some text displayed for the 4th ref. Still, if these two words are indeed in the reference, they are sperarated by many other words. And why for this reference, and not for the others ? The 2nd and the 7th references are very similar but no words are displayed in the tool...
The screenshot at https://en.wikipedia.org/wiki/File:Use_existing_reference_bug_for_VE.jpg shows how inadquate the interface is.  Even if you search for a word that you know is in the ref, you may still be left with many unidentified ref numbers.  "Please blindly guess which one is the right one" is not a desirable interface.
**Wikifram** wrote:

This is not a duplicate, these are completely different issues, and this one isn't fixed in MediaWiki. This bug is not about autonumbering, this is about "use an existing reference", where you only get to see the numbers, not the contents of the ref, which is totally useless. Please don't merge unrelated bugs.
Also reported as bug 57420, fix pending. Sorry for the disruption.

*** This bug has been marked as a duplicate of bug 57420 ***
Hey Cainamarques, about this last comment, let's keep this conversation at https://en.wikipedia.org/wiki/User_talk:Cainamarques#Bug.3F . Thanks!
FORGET my last comment. I did not know I could not edit simple external hiperlinks (with only the url). At least I am assuming I cant...
Yeah, I was not paying attention Elitre. This bug happens to me as well. I did some testing and found something interesting. In the Alex Timbers article, I "named" more than one reference to see if the names would show up in the existing references list (as the first one did) and they do. But for whatever reason I can not edit those "named" references using VE. It only shows:

[1]

I can edit the first named reference and all the others perfectly. Is that a known bug?

Test page:
https://en.wikipedia.org/w/index.php?title=User:Cainamarques/sandbox&oldid=582669663
This makes the ""Use an existing reference" functionality almost *useless*. You can't see *any* information about the existing references - the author, title, url, etc., etc. I *could* modify the user guide to say "Remember the footnote number you want to use again, because if you don't, the dialog box that appears will be worthless", but that would be embarrassing. Also, hopefully, this regression will be fixed quickly. (I'd feel better if it were prioritized as at least "High" priority.)
Categories

Steps to reproduce:

-Click on the Edit button of a page
-Click on the Page Settings button
-Add some category to this page
-Click on "Apply Changes"
-Click on the "Save Page"

Observed Result:
The categories appear in wiki text format in the view mode of the page.

See the screenshot attached.

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

**Attached**: {F12703}
Verified in betalabs
Fixed in https://gerrit.wikimedia.org/r/93640
Thanks for reporting this. It looks like newly added categories are getting mangled this way because Parsoid was rolled back to a version that does not recognize the new mw:PageProp/Category type we're sending it. Gabriel and I are looking into the possibility of redeploying Parsoid with the UTF8 bug fixed later today.
VE is breaking text encoding on *all* edits on fr.wp. Looks like UTF-8 is being intepreted as ISO-8859-2 or something.

Example edits:
https://fr.wikipedia.org/w/index.php?title=Tulle&curid=51555&diff=98030422&oldid=98028576
https://fr.wikipedia.org/w/index.php?title=Herv%C3%A9_Jolly&diff=prev&oldid=98030048

--------------------------
**Version**: unspecified
**Severity**: blocker
**Wikifram** wrote:

Thank, Bartosz
Let's just add "VisualEditor" to the summary to make this easier to find.
Bugzilla is primarily a tool for developers and its primary classification is based on codebases (products and components).
**Wikifram** wrote:

(In reply to comment #9)
> Reverting. This was a bug with config, not with code, and so belongs in
> "Wikimedia". Also, it was a bug with Parsoid, not with VisualEditor.

This means that people looking for VE bugs won't find it though; this may make sense from a devs point of view, but not from an editor's point of view. They encountered severe problems when editing with VE (and not with wikitext editing), but can't find that bug when searching VisualEditor bugs. 

Take a look at the "search" box for Bugzilla; first is status, second is product;  how many people trying to find info on this or similar bugs will look for "Wikimedia"?
Reverting. This was a bug with config, not with code, and so belongs in "Wikimedia". Also, it was a bug with Parsoid, not with VisualEditor.
**Wikifram** wrote:

Why "Wikimedia"? It only happened to VE edits, so for the sake of being able to track bugs in VE editing (fixed and non-fixed, major and minor), I have moved this back to VisualEditor. Wikimedia is much too vague for this...
Not that it matters, but there is no Apache involved here. Moved it to General.
Relabelling and moving to the correct component.
Post mortem has been posted at https://wikitech.wikimedia.org/wiki/Incident_documentation/20131104-Parsoid
This is fixed now that the Parsoid update has been reverted.
(gwicke restored working version of the code. Awaiting a post-mortem :) )
*** Bug 56584 has been marked as a duplicate of this bug. ***
Happens on other wikis too, including sv and pl.
Tested on both the Italian and the English Wikipedia;
Reach the bottom of any page: the style drop down menu does not open (it does when you're at the top of the page); the link inspector does not present the list of options.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55465
Note that this is fixed and has been deployed to the cluster. Please re-open if it still occurs for you after a refresh.
Change 88226 merged by Robmoen:
The amazing mystery of scrollTop and onscroll

https://gerrit.wikimedia.org/r/88226
Change 88225 merged by Robmoen:
The amazing mystery of scrollTop and onscroll

https://gerrit.wikimedia.org/r/88225
*** Bug 55362 has been marked as a duplicate of this bug. ***
Change 88226 had a related patch set uploaded by Jforrester:
The amazing mystery of scrollTop and onscroll

https://gerrit.wikimedia.org/r/88226
Change 88225 had a related patch set uploaded by Jforrester:
The amazing mystery of scrollTop and onscroll

https://gerrit.wikimedia.org/r/88225
Change 88195 merged by jenkins-bot:
The amazing mystery of scrollTop and onscroll

https://gerrit.wikimedia.org/r/88195
Change 88195 had a related patch set uploaded by Trevor Parscal:
Bug 55343 - The amazing mystery of scrollTop and onscroll

https://gerrit.wikimedia.org/r/88195
(In reply to comment #6)
> Krinkle, do I need to file a different bug for the non-working wikilink menu
> part? Thanks.

Yes, let's keep that separate. Could be related, but different user end bugs.
Krinkle, do I need to file a different bug for the non-working wikilink menu part? Thanks.
Can't reproduce it in Chrome, but in Firefox.

Note that (this is difficult to see in the screenshots), the height decreases only when you close and re-open the More menu.

If you open the More menu on top of the page and scroll down, it stays that way and only when you resize the window does the menu grow/shrink (as it should).

But when you close/re-open the menu when scrolled down, it seems to belief the page is shorter than it really is and draw the menu too small (by a factor that relates to how far one scrolls down) until very soon it is completely collapsed.

For me the collapsed point is far from the bottom of the page (I scrolled down a few pixels each time, and after having scrolled a mere 100px it was already completely collapsed).
From bug 55357:

TeamGale reports:

"while I was getting more down to the page, the drop down menus were getting
"shorter" and sometimes disappear at the very end. I tried it to many pages to
see if it was happening everywhere and it does. I don't know exactly how to
describe it that's why I took screencaps from the page. All three are from the
same page, in different height. See how the drop down menu of "more" can be
seen entirely at the top of the page and how it gradually disappear as I get
closer to the bottom. It's really weird!! The same thing happens when I am
trying to add a wiki link in the article's text and to be honest, that's how I
notice the gradually disappearing."

The screenshot is at [[File:Drop Down Menus.jpg]]

I can reproduce this in Firefox 24 on Linux when using the vector skin, but not
when using Monobook. 

Trying to add a link after the end of the first paragraph I get no suggestions
when my window is not maximised. Even when it is maximised it has completely
disappeared by the end of the page. 

What seems to matter is where the view is, not where the cursor is.
*** Bug 55357 has been marked as a duplicate of this bug. ***
Created attachment 13447
Screenshot of the 0px-height menus

These 3 menus have a height of 0px.

I’ve attached a screenshot of these menus without height.

**Attached**: {F12608}
Same bug with « more » menu
load.php request for ve.base (when it crashes)

At this time, on most Wikipedias that have just been switched to 1.22wmf19, VisualEditor is fatally broken.

It cannot be consistently reproduced, but trying 3 or 4 times will hit the exception.

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

**Attached**: {F12689}
Fixed by touching the JS file in production.

And yeah, this is another artefact of 43805, I think. :-(
*or bug 43805
Is this a dupe of bug 51766 or bug 51766?
Contrary to what one might think, both scenarios do not automatically resolve themselves the next 5-minute window of the startup module.

The next time the startup module is generated, 5 minutes later, the max() timestamp of a module will still be the same.

Touching startup.js won't help either.

You'd have to artificially touch the individual module that got corrupted in cache and sync it and hope the same race condition won't happen again.
Created attachment 13436
load.php request for ve.core (when it does not crash)

**Attached**: {F12692}
Created attachment 13435
load.php request for ve.core (when it crashes)

**Attached**: {F12691}
Created attachment 13434
load.php request for ve.base (when it does not crash)

**Attached**: {F12690}
Splitting from bug 54322.

--------------------------
**Version**: unspecified
**Severity**: critical
(In reply to comment #3)
> Change 87442 merged by jenkins-bot:
> ve.Element: Fallback to body, window is not scrollable
> 
> https://gerrit.wikimedia.org/r/87442
This was just deployed.
Change 87466 merged by jenkins-bot:
ve.Element: Fallback to body, window is not scrollable

https://gerrit.wikimedia.org/r/87466
Change 87467 merged by jenkins-bot:
ve.Element: Fallback to body, window is not scrollable

https://gerrit.wikimedia.org/r/87467
Change 87467 had a related patch set uploaded by Jforrester:
ve.Element: Fallback to body, window is not scrollable

https://gerrit.wikimedia.org/r/87467
Change 87466 had a related patch set uploaded by Jforrester:
ve.Element: Fallback to body, window is not scrollable

https://gerrit.wikimedia.org/r/87466
Change 87442 merged by jenkins-bot:
ve.Element: Fallback to body, window is not scrollable

https://gerrit.wikimedia.org/r/87442
Change 87442 had a related patch set uploaded by Krinkle:
(DRAFT) ve.Element: Fallback to body, window is not scrollable

https://gerrit.wikimedia.org/r/87442
pawn character editing

seen on master branch (beta labs) as of 30 September. 

open a page on beta labs in VE

begin editing at default location or top-left beginning of page

pawn character appears upon entering text

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F12377}
Change 86685 merged by jenkins-bot:
Follow-up to 9b999622: don't slug paragraphs that contain just a text node

https://gerrit.wikimedia.org/r/86685
*** Bug 54785 has been marked as a duplicate of this bug. ***
Change 86685 had a related patch set uploaded by Catrope:
Follow-up to 9b999622: don't slug paragraphs that contain just a text node

https://gerrit.wikimedia.org/r/86685
**Author:** `Wikifram`

**Description:**
After the failure of VE (e.g. witness the opt-in at the three largest wikipedia versions), the WMF now comes with MW 1.22wmf19, which creates more errors than it solves for VE, as could be predicted by anyone remotely busy with VE. I have documented some problems I found with minimal testing, there are probably a lot more. The version doesn't do what the release notes claim (e.g. reflists can't be moved, not that they often need moving anyway; many templates can't be moved either), and doesn't solve the major problems that existed with the one thing that could somewhat be dragged, images. 

Multiplying known problems instead of solving them, when there are plenty of major problems which have turned away most of your user- and testbase, is simply stupid. 

No one is waiting for weekly updates (certainly not of this "quality"). Please, PLEASE, stop it; get back to the bug list, solve the 50 most urgent ones, ''test them thoroughly yourselves", and then come to us, present the improvements, and ''ask'' us whether we want to implement and test them.

--------------------------
**Version**: unspecified
**Severity**: major
**Wikifram** wrote:

Allright, thanks to both for the reply.
(In reply to comment #4)
> Is that an official policy or wishful thinking?

VE product manager James Forrester told to Tech Ambassadors at 
See also http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000416.html

"However, if there is community consensus that your wiki does not want it
yet or is not ready, it can of course be reversed to "opt-in" - just file a
Bugzilla request or contact your local community liaison."
(In reply to comment #4)
> MZMcBride, is that an official policy or wishful thinking? I can't an
> official statement that declares that the opt-in is now an automatic right of
> all Wikipedias if they want it.

How official would you like the statement to be? I've declared this both on Bugzilla and on-wiki (on the English Wikipedia).

Is there any Wikimedia wiki community having trouble getting VisualEditor switched from opt-out to opt-in?
**Wikifram** wrote:

MZMcBride, is that an official policy or wishful thinking? I can't an official statement that declares that the opt-in is now an automatic right of all Wikipedias if they want it.
**Wikifram** wrote:

While it is an improvement that the wikis can request an opt-in, I'm not interested in that. You (WMF) are pushing untested, deficient software to us, making things even worse when tempers are already running high; we don't have the means to stop your releases apparently (or if we did stop them, some people would again get very upset probably). I'll try to find a better location for this, but this is not about the policy, this is about the VE being one major bug that shouldn't be released at all until it is seriously improved.
I agree with Andre here.

Though I'll also point out that, while it's a little less than ideal, any Wikimedia wiki that currently has opt-out VisualEditor deployed can request that VisualEditor be switched to opt-in mode (similar to the setup on the German and English Wikipedias) by establishing a local community consensus. For further info, users should consult [[m:Requesting wiki configuration changes]].
Discussing deployment policies is nothing that should happen in a technical bugtracker (however once a discussion *has* taken place in a better suited place, the request for changing the configuration based on that consensus can be filed as a ticket in Bugzilla).
Please take this discussion to the talk page or to the mailing list instead to *discuss* this request first, as statements here seem to be rather subjective (which does not necessarily mean "wrong" though).
Thanks for your understanding.
See last line of this diff: https://fr.wikipedia.org/w/index.php?title=T%C3%A9l%C3%A9com_SudParis&diff=next&oldid=97023702 .

Steps to reproduce, as provided by user: Seudo.

1) Go to https://fr.wikipedia.org/wiki/Cumul_des_mandats_en_France - you don't need to save later
2) Click on Modifier 
3) Place the cursor after the words « exercice simultané de mandats » (5th line, I think)
4) Click "Plus->Référence"
5) Write something in the dialog, i.e. "toto."
6) Save the reference
7) Click at the left or at the right of the newly added reference
8) Watch pawns multiplyin' as you keep clicking.
Suedo adds that in his console Web he also got a Javascript error, TypeError: group.firstNodes[index2] is undefined (load.php:54) .

I was able to reproduce this as well, but only with FF (exactly like Seudo), only in the actual article - not in my sandbox - and only clicking at the left of the word. The user reports instead that this might happen at any point in the page.

My edits in the sandbox could not reproduce the issue but generated https://bugzilla.wikimedia.org/show_bug.cgi?id=54341 instead.

Thanks.

--------------------------
**Version**: unspecified
**Severity**: critical
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54976
(In reply to Elitre from comment #22)
> More examples from it.wp:
> https://it.wikipedia.org/w/index.
> php?title=Natale_Ciravolo&diff=67212907&oldid=67197341 ,
> https://it.wikipedia.org/w/index.php?title=Utente:Nnvu/
> Sandbox1&diff=prev&oldid=67108020 .

This is bug 67992 I think.
More examples from it.wp: https://it.wikipedia.org/w/index.php?title=Natale_Ciravolo&diff=67212907&oldid=67197341 , https://it.wikipedia.org/w/index.php?title=Utente:Nnvu/Sandbox1&diff=prev&oldid=67108020 .
I believe this is happening again at it.wp.
See https://it.wikipedia.org/w/index.php?title=AA.VV.&diff=prev&oldid=67188720 (snowmen) or https://it.wikipedia.org/w/index.php?title=Utente:Elitre_(WMF)/Pagina_delle_prove_VE&diff=next&oldid=67195802 (pawn).
What you need to reproduce: just create a base reference, add the template Cita, add something as its first parameter, then hit Space/type something else in the reference before saving.
Um, folks, this may be happening again... please see bug:61272...
*** Bug 54976 has been marked as a duplicate of this bug. ***
(In reply to comment #12)
> Change 87455 had a related patch set uploaded by Catrope:
> When cloning the InternalList, pass through properties that aren't rebuilt
> 
> https://gerrit.wikimedia.org/r/87455

I just deployed this change, and the article linked in comment 0 now works for me on frwiki.
Change 87459 merged by jenkins-bot:
When cloning the InternalList, pass through properties that aren't rebuilt

https://gerrit.wikimedia.org/r/87459
Change 87458 merged by jenkins-bot:
When cloning the InternalList, pass through properties that aren't rebuilt

https://gerrit.wikimedia.org/r/87458
Change 87455 merged by jenkins-bot:
When cloning the InternalList, pass through properties that aren't rebuilt

https://gerrit.wikimedia.org/r/87455
Change 87459 had a related patch set uploaded by Jforrester:
When cloning the InternalList, pass through properties that aren't rebuilt

https://gerrit.wikimedia.org/r/87459
Change 87458 had a related patch set uploaded by Jforrester:
When cloning the InternalList, pass through properties that aren't rebuilt

https://gerrit.wikimedia.org/r/87458
Change 87455 had a related patch set uploaded by Catrope:
When cloning the InternalList, pass through properties that aren't rebuilt

https://gerrit.wikimedia.org/r/87455
*** Bug 54917 has been marked as a duplicate of this bug. ***
I was able to reproduce this on that frwiki article just now. I get the same error about group.firstNodes[group2] being undefined. Investigating further.
Being able to add references without corrupting the article is a core requirement. Updating the severity to critical.
Same for me too, it appears literally impossible to add a reference without snowmen and a bogus reference tag (FF 24.0, Windows 7):

https://en.wikipedia.org/w/index.php?title=X_Window_System&diff=575630218&oldid=575623976
Could this please have a priority assigned? Other editors are finding it a blocker to editing with references:

This bug is really annoying! Every time I add a new reference I can't do anything after it because whatever I click on my keyboard the snowmen appear! Even clicking backspace to delete them multiplies them along with already existing text! Only way to get out of there is to cancel my edit and lose the work I've done! :/ Basically, VE can't be used almost at all at this point, since every addition to an article has to have a reference too! Is there any information about when this bug will get fixed? TeamGale 04:35, 3 October 2013 (UTC)
My edit above to [[OpenOffice.org]] was in Firefox 24.0, Ubuntu 12.04 distro version.
An instance of this from en.wp. David Gerard reports:

Dig this: https://en.wikipedia.org/w/index.php?title=OpenOffice.org&diff=575290819&oldid=575267859
What I was trying to do was add PladaoOffice and a reference link, which appeared to add correctly in the VE. Then I noticed there was a full stop after "SunShine Office", so I clicked on it to put the cursor there, and VE added a pile of "☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃", and more each time I clicked again. Note also that my carefully constructed reference is gone, leaving only "<ref name=":0" />", and it's added another spurious one of those higher up
Please replace the word "pawns" with "snowmen". Sorry for the confusion.
**seudeau** wrote:

That looks like 
https://bugzilla.wikimedia.org/show_bug.cgi?id=53642, which is quite old
though. 

I also tried to reproduced in a user-specific test page, but couldn't.
**seudeau** wrote:

%%%*** Bug 54708 has been marked as a duplicate of this bug. ***%%%
A last comment from the user,
<<[...] Sometimes the following error appears, "Javascript Error: Cannot open another window while another one is active". Sometimes the text of the page breaks down completely and the browser gets stuck.
Do not try to look at what's on line 54 of load.php, you'll give up quickly  :-)>>
For example, you can't copy/paste in the edit summary box.

--------------------------
**Version**: unspecified
**Severity**: major
Change 85784 merged by jenkins-bot:
Only listen for copy/paste on documentNode and pasteTarget

https://gerrit.wikimedia.org/r/85784
Change 85783 merged by jenkins-bot:
Only listen for copy/paste on documentNode and pasteTarget

https://gerrit.wikimedia.org/r/85783
Change 85784 had a related patch set uploaded by Catrope:
Only listen for copy/paste on documentNode and pasteTarget

https://gerrit.wikimedia.org/r/85784
Change 85783 had a related patch set uploaded by Catrope:
Only listen for copy/paste on documentNode and pasteTarget

https://gerrit.wikimedia.org/r/85783
Change 85204 merged by jenkins-bot:
Only listen for copy/paste on documentNode and pasteTarget

https://gerrit.wikimedia.org/r/85204
Change 85204 had a related patch set uploaded by Esanders:
Only listen for copy/paste on documentNode and pasteTarget

https://gerrit.wikimedia.org/r/85204
Marking as a regression as this is new behaviour in the latest release (version "false")
Pasting from an external source into the edit summary box works fine for me. 

However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE.

To reproduce:
1. Load any page in VisualEditor.
2. Do any of
 i. Press the browser back button to exit VE
 ii. Cancel the edit
 iii. make an edit and then save the page
3. Select any text anywhere on the page and copy it to the clipboard
4. Try to paste that text anywhere (search box, URL bar, text editor, etc)

Expected behaviour: Selected text is copied and pasted
Actual behaviour: Selected text is not copied and pasted
https://en.wikipedia.org/w/index.php?title=Matt_Chandler_%28pastor%29&curid=37214846&diff=573675359&oldid=571858677

For some reason, multiple different unnamed references all get name=":3" there.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54445
*** Bug 54445 has been marked as a duplicate of this bug. ***
James,
I think it can be confusing that the name and the number of a reference do not match, although the links work.
See https://en.wikipedia.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandbox&diff=575128343&oldid=575128003 (the reference #2 gets a ref name:3).
*** Bug 54654 has been marked as a duplicate of this bug. ***
Change 85781 merged by jenkins-bot:
Prevent naming collisions when generating unique reference names

https://gerrit.wikimedia.org/r/85781
Change 85780 merged by jenkins-bot:
Prevent naming collisions when generating unique reference names

https://gerrit.wikimedia.org/r/85780
Change 85781 had a related patch set uploaded by Catrope:
Prevent naming collisions when generating unique reference names

https://gerrit.wikimedia.org/r/85781
Change 85780 had a related patch set uploaded by Catrope:
Prevent naming collisions when generating unique reference names

https://gerrit.wikimedia.org/r/85780
Change 85144 merged by jenkins-bot:
Prevent naming collisions when generating unique reference names

https://gerrit.wikimedia.org/r/85144
Change 85144 had a related patch set uploaded by Catrope:
Failing test for <ref name=":3"> bug

https://gerrit.wikimedia.org/r/85144
Isolated test case: https://en.wikipedia.org/wiki/User:Ed_g2s/Sandbox4

Diagnosis:

The automatically generated names are based on the number of distinct references in the page up to that point, indexed at zero. The first unnamed <ref> tag is the 4th distinct reference on the page (it's preceded by two :1s, a :3 and a :0), so its autogenerated name is :3. However, there so happens to already be a literal <ref name=":3"> on the page, so we get a naming collision and the whole thing goes to hell.

In practice, this situation can only arise after multiple iterations of duplicating unnamed references with VE (which adds <ref name=":n"> tags to the source), then removing or reordering references so the ref tags are aligned exactly right for this bug to occur.
VisualEditor seems to take particular pleasure in abusing circumflexes.

Issue 1: VE duplicates the first character entered after a circumflexed letter at the end of a line.

* Steps to reproduce: In VE, enter the text êtt (actually enter the characters individually, don't copy/paste) at the end of a line.
* Expected result: "êtt" is entered.
* Actual result: "êtt<newline>t" is entered.

Issue 2: At the beginning of a line, VE turns a circumflexed letter into a pawn character when removing text entered after the circumflexed letter.

* Steps to reproduce: In VE, enter the text êtt at the beginning of a line, then delete the last 't'.
* Expected result: "êt"
* Actual result: "♙t"

There's also some wonky behavior when dealing with circumflexed letters in the middle of a line, but I'm assuming that the descriptions above will be enough to help you investigate VE's blatant circumflexphobia.

--------------------------
**Version**: unspecified
**Severity**: normal
Marking as a duplicate of bug 53680 which I believe is indeed the issue.

*** This bug has been marked as a duplicate of bug 53680 ***
This is a dupe of bug 53747, bug 53680 or both.
Also, circumflexes that are entered in VE are completely stripped on save. Instead, characters are jumping around to its location.
Since approx. August 30-31 VisualEditor breaks when Polish-language diacritics (ążśźęćńółĄŻŚŹĘĆŃÓŁ) are input. The characters themselves disappear and text around them gets mangled and moved around.

They're all input using AltGr (right Alt) + diacritic-less version of the characters, with the exception of "x" mapping to "ź" (so, respectively, azsxecnol).

I have been unable to replicate the issue myself, but it's definitely happening.

pl.wp thread: https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#VisualEditor_a_polskie_diakrytyki

This is repeatedly breaking page text on the Polish Wikipedia, so I'm marking the bug "highest critical".

--------------------------
**Version**: unspecified
**Severity**: critical
**URL**: https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#VisualEditor_a_polskie_diakrytyki
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53680
It seems like it does actually fix the issue (for me at least). Thanks.

So that means editing will have been completely broken for only three weeks straight by the time this gets deployed :/
Marking this as "FIXED" on the expectation that it's fixed - please re-open if you find that it is still occurring.
Ok, the patch is merged, and due to go live on mediawiki.org by 13 September 2013:

https://gerrit.wikimedia.org/r/#/c/82858/

Please let us know whether it fixes the bug!
I'm optimistic that the following patch will fix this bug:

https://gerrit.wikimedia.org/r/#/c/82858/

If someone can test this hypothesis, great; if not, then I will hopefully be able to do so later today.
Is there any progress on this? Because today's the point when I'd suggest reverting the deployment to last known good version if nobody is going to fix this.
I've tested this on master in Firefox under Ubuntu -- I managed to replicate the behavior not just in polish, but also Spanish diacritics but only when these are "added on". Trying to add diacritic to an existing character produced a pawn and then some odd duplication of characters.

That did not happen when I typed in either Hebrew or Arabic in master.

Another thing I found is that there seems to be a difference between an already-combined diacritic (like ñ which is native to the Spanish keyboard) and an "added" diacritic. When I typed the native ñ nothing broke, it added it properly and the behavior was correct. 

And finally, the typing broke and the pawn appeared only when I tried to add diacritic to a latin letter. 

When I tried to add "niqqud" to Hebrew letters, though, like pressing ש and left-Alt+a to produce שְ the behavior was as expected (no pawn, no problem)
Bug 53680 shows this also happens on en.wp and fr.wp and is independent of keyboard layout.
https://pl.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Opinie&oldid=37428181#.C4.99 is a pretty good explanation, and makes clear it's not browser (or OS) dependent.
Actually, I sort of have reproduced it now. I used Opera 12, but some users at pl.wp reported it happening on Chrome – it's probably not browser-dependent.

You'll probably need to set your system keyboard to "Polish (programmer's)" or similarly named one. (It's the same as standard US layout, but includes the AltGr diacritics. A "Polish (typist's)" layout exists on some systems, but nobody ever uses it, so forget it.)

1.
Try inputting some text with diacritics, such as the "Pójdź, kińże tę chmurność w głąb flaszy!" sentence above (copying and pasting text with diacritics doesn't cause issues, you need to type it). (Strings of one character such as "ąąąą" tend to work correctly for some reason.)

2.
Depending on your luck, it might look okay, or you might get parts of the sentence duplicated in the next paragraph. Regardless of that, try backspacing a little now. The cursor will likely be moved to someplace in the next paragraph and unrelated characters will be removed.

3.
Try previewing the changes. The text will differ from the one shown in editing view.
Examples of edits apparently exhibiting this issue:

* https://pl.wikipedia.org/w/index.php?title=Rondo&curid=122034&diff=37421631&oldid=35999089 - "Największe rondo" -> "Najwi kszerondo"

* https://pl.wikipedia.org/w/index.php?title=Euronews&diff=prev&oldid=37394282 - "dostpna" should be "dostępna", "Midzyrnodowym" should be "Międzynarodowym", etc.

* https://pl.wikipedia.org/w/index.php?title=1967&diff=next&oldid=37422197 - "ki rapers" should probably be "Amerykański raper" (both occurences - this happened on two consecutive edits)

Results of a user trying to type in "Pójdź, kińże tę chmurność w głąb flaszy!" when reproducing this bug:
* https://www.mediawiki.org/w/index.php?title=User:G%C5%BCdacz&oldid=775661
* https://www.mediawiki.org/w/index.php?title=User:G%C5%BCdacz&oldid=775666
I haven't worked out this out fully yet, but it seems that linking or annotating newly added text that contains accented or non-Latin characters frequently causes those characters to disappear. Re-adding them in the same word almost always results in their turning into pawns when, anywhere else on the page, the link dialog is subsequently opened or a link is inserted.

This happens everywhere on a page including body text, tables and image captions.

--------------------------
**Version**: unspecified
**Severity**: critical
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53747
*** Bug 54047 has been marked as a duplicate of this bug. ***
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!
(In reply to comment #3)
> Same as bug 53747?

Yes. I don't want to just merge them though as they're assigned to different people.
Same as bug 53747?
K7L comments:
"I am seeing the same problems if I try to edit ordinary text such as the article intro. Pressing <save> or even <backspace> makes accented characters in newly-edited text vanish. This editor is not usable for non-English text on this browser [firefox]."

This needs to be fixed urgently.
Now also reported on the French Wikipedia:
[[:fr:Route 2 (Ontario)]] and its revision history, the distance chart is a table and Unicode descriptive text added with VisualEditor didn't save properly.[https://fr.wikipedia.org/w/index.php?title=Route_2_%28Ontario%29&diff=96342109&oldid=96342028] The damage was fixed using the standard MW wiki source editor but is still in history. Try inserting « La route 2 va à Montréal (Québec) » (or something/anything that isn't US ASCII) into a table cell and watch it fail to display correctly or fail to save.


The fr.wp reported was using an unspecified version of firefox on Vector in Ubuntu. I use Firefox 23 on monobook in Xubuntu.

Raising this to critical as being able to use all characters in a language is essential.
When inserting any template immediately before any word that is linked or has bold or italic markup, that word is deleted but continues to be displayed in the editing surface. The deletion can only be seen in review changes or upon saving.

To reproduce:
1. Open any page in VE.
2. Place the cursor immediately before a word (i.e. with no white space between the cursor and word) that is one or more of:
   * A link
   * Bold text
   * Italic text
   * plain text that you have just added one of the above to
3. Insert any template at the cursor position
4. Observe the word remains as expected
5. Review changes, and observe the word has been deleted.

Examples: https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox2&diff=570195482&oldid=570194023

On en.wp PamD encountered this bug when inserting a maintenance template at the head of an article that started with a bold word.

--------------------------
**Version**: unspecified
**Severity**: critical
This is the same Parsoid bug that affected both places where we implicitly assumed that the 'about' id is always present (without realizing/checking that it could be absent for VE-inserted transclusions).
*** This bug has been marked as a duplicate of bug 53434 ***
HTML

<p><span typeof="mw:Transclusion" data-mw="{&quot;target&quot;:{&quot;href&quot;:&quot;Template:Inline&quot;,&quot;wt&quot;:&quot;Inline&quot;},&quot;params&quot;:{&quot;1&quot;:{&quot;wt&quot;:&quot;Foo&quot;}}}"></span><b>bar</b>quux</p>

Expected wikitext

{{Inline|Foo}}'''bar'''quux

Actual wikitext

{{Inline|Foo}}quux

:(
This does not require pre-existing formatted or linked text.  The bug also appears if you enter the template first and then add bold word(s) immediately afterwards (no space between the template and the text), starting from an empty page or in a new paragraph.  

For example, using VisualEditor with the intention of producing this, in this order:

{{unreferenced}}'''Hello world''' from Wikipedia.

actually results in this:

{{unreferenced}} from Wikipedia.

If you add a space or hit return after the template, then it works as expected.
VE link insertion dialog when attempting to add a section link

Since the latest update it is impossible to create links to specific sections of a page in VisualEditor: As soon as you enter the # character the link insertion dialog gives an "Invalid title" error. See screenshot attached and bug 50881 comment 11.

I've reported this separately to bug 50881 as that is an enhancement to give proper handling of section links, but this is a regression that blocks all use of links to sections.

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

**Attached**: {F11887}
Change 112898 merged by jenkins-bot:
Include fragments in normalizedTitle

https://gerrit.wikimedia.org/r/112898
Change 112898 had a related patch set uploaded by Esanders:
Include fragments in normalizedTitle

https://gerrit.wikimedia.org/r/112898
(In reply to comment #10)
> Unless I'm missing something obvious, I can't make this work anymore on it.wp
> or Mediawiki. It will just ignore the #name_of_the_section if I add it to an
> existing wikilink and therefore, it will not recognize the link as edited and
> the Save button will stay greyed out.

Split that issue into bug 61221.
Unless I'm missing something obvious, I can't make this work anymore on it.wp or Mediawiki. It will just ignore the #name_of_the_section if I add it to an existing wikilink and therefore, it will not recognize the link as edited and the Save button will stay greyed out.
… and now deployed.
Change 80507 merged by Catrope:
Modify regex to allow section links as valid titles

https://gerrit.wikimedia.org/r/80507
Change 80505 merged by Catrope:
Modify regex to allow section links as valid titles

https://gerrit.wikimedia.org/r/80505
Change 80507 had a related patch set uploaded by Jforrester:
Modify regex to allow section links as valid titles

https://gerrit.wikimedia.org/r/80507
Change 80505 had a related patch set uploaded by Jforrester:
Modify regex to allow section links as valid titles

https://gerrit.wikimedia.org/r/80505
This is now fixed in master; we'll cherry-pick it and push live this afternoon. Sorry for the problem.
Change 80417 merged by jenkins-bot:
Modify regex to allow section links as valid titles

https://gerrit.wikimedia.org/r/80417
Change 80417 had a related patch set uploaded by Esanders:
Modify regex to allow section links as valid titles

https://gerrit.wikimedia.org/r/80417
Ah, good that someone already reported. Confirmed in mediawiki.org.
Steps to reproduce:
1. Go to http://en.wikipedia.org/wiki/Post_and_core
2. Edit it with VE
3. Make some minor edit, by example, add a space after "is a type"
4. Review your changes (or save)

Results:
The {{Interventions infobox|(...)}} gets removed.

--------------------------
**Version**: unspecified
**Severity**: major
Moving to date we likely fixed this with the changes to DM.
I can't reproduce it anymore either, so I'm closing it.
* "I can't reproduce" ... the issue. :)
I can't reproduce but the infobox invocation has some garbage in it.

{{Interventions infobox |
  Name        = Post and core |
  Image       = |sesuiatu
  Caption     = |sasa
  ICD10       = |sasas
  ICD9        = |sasasasa
  MeshID      = D011176 |
  OPS301      = |sasas
  OtherCodes  = |sasa
}}
Roan, thoughts? Selser issue?
[error] PHP Strict Standards:  Only variables should be passed by reference in /srv/phase3/extensions/VisualEditor/ApiVisualEditor.php on line 255, referer: http://server/wiki/index.php/Sandbox?veaction=edit

--------------------------
**Version**: unspecified
**Severity**: trivial
Now fixed in master. Sorry for the slip-up.
Change 77362 merged by jenkins-bot:
Fix notice caused by not passing the WebRequest object by reference

https://gerrit.wikimedia.org/r/77362
Change 77362 had a related patch set uploaded by Catrope:
Fix notice caused by not passing the WebRequest object by reference

https://gerrit.wikimedia.org/r/77362
<<When I was trying to add a link to Classic XI, (didn't know it didn't exist) it repeatedly took the word "Classic" and continually tried to make the link go to Classical music. [...] --buffbills7701 19:42, 1 August 2013 (UTC)>>

I tested this as well with Vector on both Chrome and FF, on it.wiki with the word Lettera (which is an existing page), it keeps insisting that I must link to Letteratura instead. I tried a workaround and was able to get Lettere, but it ain't the same thing.
Thanks!

--------------------------
**Version**: unspecified
**Severity**: critical
Fixed and will be deployed tonight.
Change 77264 merged by jenkins-bot:
Don't override link target input value while typing

https://gerrit.wikimedia.org/r/77264
Change 77264 had a related patch set uploaded by Trevor Parscal:
Don't override link target input value while typing

https://gerrit.wikimedia.org/r/77264
I did not know this was a competition, so more from me as well! :p
The "workaround" is what I mentioned earlier, but it won't always work.
With it I managed to get "Lettere": it autocompleted to Letteratura, then I put the "e" after the first "r" and cut the rest. But, it did not work to get to "Lettera", which was my intended outcome. 
This also happens if I am interested in, say, "Letteratura tedesca": it won't appear in the drop down list, and I am not even allowed to write it. The only way to get there is writing "letteraturatedesca" instead, and adding the space later. This makes sense to VE! Thanks.
I was 25 seconds too slow reporting Bug 52421, but I did include steps to reproduce:
1.Load a page in VE
2.Press ctrl+k to enter a link
3.Try to enter a link to [[Portable Network Graphics]], [[Classic (album)]] or
[[Thing (assembly)]].

I've also found a workaround - continue typing the link you want after it's suggestion, then select and delete what it inserted that you don't want.
*** Bug 52421 has been marked as a duplicate of this bug. ***
VisualEditor.php attempts to register a hook handler that was removed (summary credit goes to Ori)

stack: http://paste.tstarling.com/p/GuTJEM.html

Tim says:

> var_dump($wgHooks['BeforeWelcomeCreation']);
array(2) {
  [0]=>
  string(42) "VisualEditorHooks::onBeforeWelcomeCreation"
  [1]=>
  string(44) "GettingStartedHooks::onBeforeWelcomeCreation"
}

> print is_callable($wgHooks['BeforeWelcomeCreation'][0]);

> print is_callable($wgHooks['BeforeWelcomeCreation'][1]);
1

--------------------------
**Version**: unspecified
**Severity**: normal
I removed the BeforeWelcomeCreation handler in I8be6198a6 but not the statement in VisualEditor.php that registered it.

1.22wmf11 had not yet been updated to I8be6198a6, so it didn't need to be fixed. 1.22wmf12 did need a fix, but there was a merged change separating the deployed commit and my fix: change I1cd9e2bea. I didn't know if it was safe to deploy and no one from the VE team was around, so I created a cut a 'bug/52368' branch based on the deployed commit, cherry picked the fix on top, and synced that.

My apologies to the VisualEditor team and to the users that were affected.
Ia4e2a7854b3a2a5cbbe4da
Screenshot

Since the VE update tonight the save dialog is half out of the screen on FF 23/Win7, but sometimes only.

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

**Attached**: {F11781}
*** Bug 52328 has been marked as a duplicate of this bug. ***
This is fixed and being pushed live right now.
Change 76935 merged by jenkins-bot:
ve.ui.Toolbar: Emit position event on toolbar instead of surface

https://gerrit.wikimedia.org/r/76935
*** Bug 52346 has been marked as a duplicate of this bug. ***
Whatamidoing's link is to the Polish Wikipedia:
[[pl:Wikipedia:VisualEditor/Opinie#b.C5.82.C4.99dnie_wy.C5.9Bwietlaj.C4.85ce_si.C4.99_okno_opisu_zmian]]
I have a report of this sort of problem with a misplaced save dialog box appearing in the lower left corner.  The editor is running Linux Mint 14 and Firefox 18.0.2.  See  http://i40.tinypic.com/2eojvh1.jpg and http://i41.tinypic.com/30wqpnb.jpg for his screenshots.

The original problem description can be found at Wikipedia:VisualEditor/Opinie#b.C5.82.C4.99dnie_wy.C5.9Bwietlaj.C4.85ce_si.C4.99_okno_opisu_zmian
Basically it attaches to whichever toolbar is positioned last. So if you click on a link, and then open the save dialog, it pops up there. If you then scroll down (which updates position of platform toolbar), it moves to that one.
Change 76935 had a related patch set uploaded by Krinkle:
ve.ui.Toolbar: Emit position event on toolbar instead of surface

https://gerrit.wikimedia.org/r/76935
Renamed.

Removing the link to bug 49969 - the save dialog isn't (yet) an actual dialog, so that would have no effect.

Adding a link to bug 52326 which is possibly caused by the same
There is a lot of discussion about this at https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Save_page_box_drops.2C_button_invisible_without_scrolling_..._but_fixes_itself_given_time including two screenshots: [[File:VE save form off screen.png]] and [[File:VE misplaced save box.jpg]]

From my testing it seems that if an element is selected (picture, link, template) when you click save then the dialog aligns itself to the top right of that element, regardless of whether there is space on screen for it, with scroll bars if there isn't sufficient vertical space in the window to show the whole dialog. If you close the dialog, deselect the element then open the save box again it appears in the same place, only based on what that element is in the view now. If you close and select a different element then save, it relates to that element. If you have not selected any elements during your edit it appears overthe save button.

Steps to reproduce:
1. Edit a page in VE
2. Make a change to the page (doesn't matter what)
3. Click on an element (link, image, template) near the lower left edge of the window.
4. Click the save button in the top right.
(In reply to comment #7)
> I'm sorry if we were dismissive earlier. When I said "VE doesn't work the way
> you think it does", what I meant to say was "despite the confusing way these
> variables are named, they mean something slightly different, such that one of
> them is unused if the other one is set a certain way".

I wasn't annoyed with you (and you weren't the person quoted in comment 6). You're wonderful and I adore you.
(In reply to comment #6)
> I'm fairly annoyed that I was told that VisualEditor "doesn't work the way
> you
> think it does" this morning and my patch sets were roundly and soundly
> ignored
> (in favor of Gerrit change #76516), only to have the exact changes
> implemented a few hours later after this bug appeared.
Your patchsets weren't ignored, we worked off them. At the time we honestly believed that this was unnecessary, and the code that uses them is written in a way that leads the reader to believe that it is unnecessary: if wmgVisualEditorDefault is false, wmgVisualEditorDisableForAnons is unused.

However, caching threw a wrench in all of this. Two wrongs made a right, if you will.

I'm sorry if we were dismissive earlier. When I said "VE doesn't work the way you think it does", what I meant to say was "despite the confusing way these variables are named, they mean something slightly different, such that one of them is unused if the other one is set a certain way".
For the record, if my patch set from Gerrit changeset 76199 and Gerrit changeset 76468 had been merged and deployed, this bug never would have happened.

I'm fairly annoyed that I was told that VisualEditor "doesn't work the way you think it does" this morning and my patch sets were roundly and soundly ignored (in favor of Gerrit changeset 76516), only to have the exact changes implemented a few hours later after this bug appeared.
(In reply to comment #4)
> Roan's putting this in place now.
Done. This bug should stop happening in the next ~10 minutes.
(In reply to comment #0)
> My suspicion is that logged-in users are hitting certain pages, the pages are
> being cached, and then anons are receiving these cached pages (with the VE
> init
> JS loaded).

We don't mix user preference cache between logged-in users and logged-out users, this is definitely not what's happening.


What's happening is that a while ago the 'visualeditor-enable' preference was enabled by default on de.wikipedia.org. Though it was disabled for anonymous users by other means, that preference was there and as such is cached inside the anonymous user cache that visited pages while VE was enabled by default on de.wikipedia.org.

The 'other' means to disable for anons have been removed now that the preference is disabled again on de.wikipedia (it is now an opt-in for logged-in users). However this other means is not cached inside the page but globally from the startup module.

So people visiting the pages generated while VE was enabled by default are now getting VE since there is no 'disableForAnons' flag in place.

Roan's putting this in place now.
Change 76552 merged by jenkins-bot:
Explicitly disable VE for anons on dewiki

https://gerrit.wikimedia.org/r/76552
Change 76552 had a related patch set uploaded by Catrope:
Explicitly disable VE for anons on dewiki

https://gerrit.wikimedia.org/r/76552
This appears to be a caching issue, yes
**Author:** `matthiasbecker1967`

**Description:**
According to http://de.wikipedia.org/wiki/Wikipedia_Diskussion:Umfragen/VisualEditor_Opt-in the German Wikipedia community demands to postpone enablement of the VE for IPs until the VE is a robust and mostly bug free feature and to revert VE for registered users back to "opt-in".

--------------------------
**Version**: unspecified
**Severity**: critical
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49998
https://bugzilla.wikimedia.org/show_bug.cgi?id=52232
**nrp** wrote:

(In reply to comment #16)
> (In reply to comment #15)
> > So De Wikipedia holds a quick poll and their deployment is changed to opt-in,
> > but on En Wikipedia, despite weeks of complaints, we are still stuck with
> > opt-out? How does that work?
> 
> If you can hold a coordinated vote on the English Wikipedia and get over 400
> participants to agree to switch to opt-in, I imagine you can get the same
> result. :-)

I think a quick look at the feedback and other related pages would show a consensus for a switch to opt-in, but in any event there is now an RFC: http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Default_State_RFC
(In reply to comment #15)
> So De Wikipedia holds a quick poll and their deployment is changed to opt-in,
> but on En Wikipedia, despite weeks of complaints, we are still stuck with
> opt-out? How does that work?

If you can hold a coordinated vote on the English Wikipedia and get over 400 participants to agree to switch to opt-in, I imagine you can get the same result. :-)
**nrp** wrote:

So De Wikipedia holds a quick poll and their deployment is changed to opt-in, but on En Wikipedia, despite weeks of complaints, we are still stuck with opt-out? How does that work?
Closing this bug now as the issue in c13 should be resolved by bug 52232. The intention of this bug report is done.
It seems that some IPs can use VE, see e.g. 
http://de.wikipedia.org/w/index.php?title=Medien_%28Land%29&curid=132736&diff=121014468&oldid=120989155
(tagged as Visual editor), see also the talk on the village pump
https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#VE_f.C3.BCr_IP_funktioniert.3F
Change 76468 abandoned by MZMcBride:
Explicitly disable VisualEditor by default on dewiki

Reason:
I feel like a Wikipedia user who finally makes his first edit only to have it reverted. ;-)

https://gerrit.wikimedia.org/r/76468
(In reply to comment #7)
> (In reply to comment #6)
> >... VisualEditor will be temporarily switched back into opt-in mode on
> > the German Wikipedia. We don’t intend to otherwise alter the near-term
> > VisualEditor deployment schedule
> 
> Does that mean opt-in for everyone or just registered users?
Opt-in for everyone, that is to say it's off unless you turn it on in your preferences. In practice, anonymous users won't be able to opt in unless they create an account, because anons can't change their preferences.
This is now done.
Change 76516 merged by jenkins-bot:
Switch VisualEditor back to alpha (opt-in) mode on dewiki

https://gerrit.wikimedia.org/r/76516
Change 76516 had a related patch set uploaded by Jforrester:
Switch VisualEditor back to alpha (opt-in) mode on dewiki

https://gerrit.wikimedia.org/r/76516
**jsalsman** wrote:

(In reply to comment #6)
>... VisualEditor will be temporarily switched back into opt-in mode on
> the German Wikipedia. We don’t intend to otherwise alter the near-term
> VisualEditor deployment schedule

Does that mean opt-in for everyone or just registered users?
Change 76468 had a related patch set uploaded by MZMcBride:
Explicitly disabled VisualEditor by default on dewiki

https://gerrit.wikimedia.org/r/76468
Change 76199 had a related patch set uploaded by MZMcBride:
Enable anonymous use of VisualEditor on es/fr/he/it/pl/ru/sv

https://gerrit.wikimedia.org/r/76199
VisualEditor's configuration variables are a bit confusing to me, but it seems like the German Wikipedia would like to reverse part of this change: <https://gerrit.wikimedia.org/r/#/c/75543/4/wmf-config/InitialiseSettings.php,unified>.

wmgVisualEditorDefault would be set to false for dewiki.

wmgVisualEditorDisableForAnons would be left as true for dewiki.

Is this correct?
From bug 49998 comment 8:

---
In the quick poll (see #7) the results at the moment are as following:

1) enabeling VE as default for all users: 21 votes
2) VE as default for logged-in users: 6 votes
3) VE to be opt-in only until all bugs are fixed: 430 votes (!)
4) enabeling VE under another link name (suggestion was "Visual Editor (beta)"
instead of "Bearbeiten" ("edit")): 31 votes

According to this large majority of users who oppose defaulting VE by tomorrow,
I hereby ask you to put VE back to opt-in for logged-in users until the most
important bugs are fixed. Thank you.
---
From bug 49998 comment 7:

---
the German wikipedia just started a quick poll over the weekend to at least
postpone this activation for anonymous users on monday:

https://de.wikipedia.org/wiki/Wikipedia:Umfragen/VisualEditor_Opt-in

the poll has currently also a option for the previous state where VE was Opt-in
for users instead of Opt-out if this is still possible.

It would be appreciated to take the outcome on monday into account and postpone
this activation for dewiki if desired.
---
--------------------------
**Version**: unspecified
**Severity**: major
Now fixed.
Change 76220 merged by jenkins-bot:
Don't compare annotations directly with ve.compare()

https://gerrit.wikimedia.org/r/76220
Change 76220 had a related patch set uploaded by Jforrester:
Don't compare annotations directly with ve.compare()

https://gerrit.wikimedia.org/r/76220
(In reply to comment #4)
> https://www.mediawiki.org/w/index.php?title=Extension:MassMessage/
> Design&oldid=745378&veaction=edit
> 
> When I go to this URL in Google Chrome/OS X/Version 27.0.1453.116, I get the
> following error in my JavaScript console:
> 
> Uncaught RangeError: Maximum call stack size exceeded
> oo.compare
> oo.compare
[…]

This is now masked by some significant performance improvements we made (so it "works"), but we think it's still an issue; keeping open.
Change 75636 merged by jenkins-bot:
Put <nowiki> edting in experimental for now

https://gerrit.wikimedia.org/r/75636
Change 75636 had a related patch set uploaded by Jforrester:
Put <nowiki> edting in experimental for now

https://gerrit.wikimedia.org/r/75636
[Sorry, somehow it was created without a description.]

On the latest master I cannot edit a page that has <nowiki> in it. VisualEditor appears to be loading with the "progress bar", but doesn't go to actual editing mode.

Versions:
VisualEditor 393807462e9d04ec5e437cb50ef1d03e5644e9be
Parsoid be8a7dea49bd70692ef574a1bb7c7a70584d77e3
core e617dc6c8f2ce1d867ddadcd4bc3de098a84ff07
Apologies if this is a duplicate; I haven't found a report about this.

If you add a new reference with VisualEditor, you can't immediately reuse it with the reference editor; it doesn't show up in the list. You need to save the page and re-open the reference editor for that reference to show.

--------------------------
**Version**: unspecified
**Severity**: normal
This is still the case for references added inside a table though?
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 52000 - Reusing new reference groups

https://gerrit.wikimedia.org/r/81964
So bug reports are taking 2 weeks to be assessed and assigned? That sounds like bad news. Glad to see it's now "highest", thanks.  I'm amazed it took so long to be reported as a bug, and suspect it's because the experience of adding refs has been so dreadful that people haven't picked up on this specific aspect to report as a distinctive bug. Good luck.
(In reply to comment #2)
> I can think of possible two reasons why this bug has not been given high
> priority:

You forgot option 3: We hadn't got to this bug report yet (aka, "AGF"). :-)

Now marked appropriately.
I can think of possible two reasons why this bug has not been given high priority:

(1) Those unfamiliar with creating or substantially expanding Wikipedia articles don't think that this is a big deal. They are wrong - it IS a big deal. Not been able to cite the same source two or more times in an article, which is exceptionally common, causes all the problems noted by Pam, above.

or (2) VE's fundamental architecture prevents it from adding footnotes created during an editing session to the list of footnotes that existed prior to that session, and if this were listed as a high-priority bug, that design mistake might be much more obvious.

I really, really hope that the answer is not (2), because if so, that's a deal-breaker. The lack of such functionality is certainly, in and of itself, reason to NOW recommend that anyone writing a new article *not* do so in VE. (And, no, it's not acceptable to do everything but the footnotes in VE, then do footnotes with the wikitext editor - users absolutely should be footnoting their text additions with citations, *as they go along*, if only for efficiency.)
I'd urge this to be a higher priority: how do we expect people to create good new articles, even a well-cited stub, if they can't use the same reference for more than one point? They get offered a "reuse a reference" button, but it doesn't work: seriously bad news. The confused editor then has several choices: (a) don't give the extra reference(s) they think are appropriate, dumbing down the article; (b) re-input the reference each time they want to use it; (c) stop editing in VE and go into Edit Source (if they're lucky enough to be an established editor who knows about it and has learned how to use it ... not for newbies according to current ideas); (d) curse and swear and givve up trying to create their article and probably abandon editing Wikipedia altogether.
Currently, the "insert reference" dialog is a bit confusing and buggy, and it takes two or more steps to actually type the content of a reference (most common case).

We should initialize the dialog with a micro-VE surface that immediately enables the user to type reference content. The selection of an existing reference can be pushed down into a separate section or tab.

(Per discussion w/ James)

--------------------------
**Version**: unspecified
**Severity**: normal
This was done and deployed last week.
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
Change 74191 had a related patch set uploaded by Trevor Parscal:
Reference dialog commingling

https://gerrit.wikimedia.org/r/74191
James and I agreed to make this a "stretch blocker" for the IP release. (That means it's a blocker for now, unless other issues around content corruption or the basic edit surfacing operation become more critical.) The reason is that citations are such a crucial part of the new editing experience that we'd really like to make some basic improvements to the dialog ASAP, ahead of additional refactoring work around supporting citation templates etc.
data-mw.i seems to be dropped on edit in latest VE, which causes a loss of round-trip information for spaces etc.

--------------------------
**Version**: unspecified
**Severity**: major
Change 180240 merged by jenkins-bot:
Remove workaround for Visual Editor bug (T53150).

[[https://gerrit.wikimedia.org/r/180240]]
Change 180240 had a related patch set uploaded (by Cscott):
Remove workaround for Visual Editor bug (T53150).

[[https://gerrit.wikimedia.org/r/180240]]

#patch-for-review
We've not seen this recur; it was probably caused by mis-cached code. Closing, but please re-open if it does happen again.
**wicke** wrote:

%%%*** Bug 51175 has been marked as a duplicate of this bug. ***%%%
(In reply to comment #16)
> (In reply to comment #15)
> > I'm assuming that this is not yet deployed, as a new report was added to
> > 51161:
> > 
> It is deployed.
> 
> > Normally this single-transclusion content should be covered by the Parsoid
> > workaround. Did anything change in the VE handling recently that could have
> > re-added the "i" property with a faulty value?
> That sounds unlikely. When the user adds a new parameter, that parameter
> won't
> have an i value, but that seems reasonable to me.

That infobox already existed. The 'i' property is per transclusion, not per parameter.
(In reply to comment #15)
> I'm assuming that this is not yet deployed, as a new report was added to
> 51161:
> 
It is deployed.

> Normally this single-transclusion content should be covered by the Parsoid
> workaround. Did anything change in the VE handling recently that could have
> re-added the "i" property with a faulty value?
That sounds unlikely. When the user adds a new parameter, that parameter won't have an i value, but that seems reasonable to me.

I'll try to reproduce this later and see what's being sent back to Parsoid.
I'm assuming that this is not yet deployed, as a new report was added to 51161:

---------------------------------------------------
This is what happened:
http://en.wikipedia.org/w/index.php?title=Scarborough_railway_station&diff=next&oldid=557856562

This is what the user intended:
http://en.wikipedia.org/w/index.php?title=Scarborough_railway_station&diff=564074475&oldid=557856562

If removal of newlines really is necessary, please insert a space instead. If
that is not possible, please remove the spaces from both sides of each equals.
An arrangement like 

|name = Scarborough|symbol = rail|code = SCA|image_name =
ScarboroughRailwayStation.jpg|caption = The entrance to the station

gives the impression of associating a parameter name with the value immediately
preceding. An arrangement like

|name=Scarborough |symbol=rail |code=SCA
|image_name=ScarboroughRailwayStation.jpg |caption=The entrance to the station

would associate a parameter name with the value immediately following.
-------------------------------------------------


Normally this single-transclusion content should be covered by the Parsoid workaround. Did anything change in the VE handling recently that could have re-added the "i" property with a faulty value?
*** Bug 51161 has been marked as a duplicate of this bug. ***
Change 73372 merged by jenkins-bot:
Preserve unused Parsoid template properties

https://gerrit.wikimedia.org/r/73372
Change 73372 had a related patch set uploaded by Catrope:
Preserve unused Parsoid template properties

https://gerrit.wikimedia.org/r/73372
The Parsoid workaround above is now deployed. If the index went missing in VE, it assumes that a single-transclusion target was not swapped out and reinserts the lost index in that case. This should avoid corruptions in the common single-template case.

It will do nothing for multi-transclusion content (table start / row etc), and will also fail if the template was swapped out for another one. The latter case should be rare.
Change 73187 merged by jenkins-bot:
Workaround for VE bug 51150

https://gerrit.wikimedia.org/r/73187
Change 73187 had a related patch set uploaded by GWicke:
Workaround for VE bug 51150

https://gerrit.wikimedia.org/r/73187
Example on http://www.mediawiki.org/wiki/User:GWicke/TestDataMW?veaction=edit:

Original data-mw:
data-mw='{"target":{"wt":"echo","href":"../Template:Echo"},"params":{"1":{"wt":"foo"}},"i":0}'

data-mw through VE without edit:
data-mw="{&quot;target&quot;:{&quot;wt&quot;:&quot;echo&quot;,&quot;href&quot;:&quot;../Template:Echo&quot;},&quot;params&quot;:{&quot;1&quot;:{&quot;wt&quot;:&quot;foo&quot;}},&quot;i&quot;:0}"

data-mw through VE after changing 'foo' to 'bar':
data-mw="{&quot;target&quot;:{&quot;wt&quot;:&quot;echo&quot;,&quot;href&quot;:&quot;../Template:Echo&quot;},&quot;params&quot;:{&quot;1&quot;:{&quot;wt&quot;:&quot;bar&quot;}}}"

Note that the "i" member is gone.
Aha. Gotcha.
(In reply to comment #4)
> https://en.wikipedia.org/w/index.php?title=Christchurch,
> _Dorset&diff=prev&oldid=563716751
> appears to be a pre-deployment occurrence.

This is post-Parsoid deployment.
It is either data-mw.i or data-mw.parts[<n>].i for templates. It is not new, but so far we have not used that information that heavily, so the fact that you drop the i probably fell under the radar. We use it to associate the public entry with private round-trip information such as the order of parameters and (crucially for this bug) whitespace.

echo -e '{{echo|a   = foo\n|b   = c}}| node parse 
<body><p about="#mwt1" typeof="mw:Transclusion" data-mw='{"target":{"wt":"echo","href":"./Template:Echo"},"params":{"a":{"wt":"foo"},"b":{"wt":"c"}},"i":0}' data-parsoid='{"dsr":[0,27,null,null],"src":"{{echo|a   = foo\n|b   = c}}","pi":[[{"k":"a","spc":["","   "," ","\n"]},{"k":"b","spc":["","   "," ",""]}]]}'>{{{1}}}</p>
</body>
https://en.wikipedia.org/w/index.php?title=Christchurch,_Dorset&diff=prev&oldid=563716751 appears to be a pre-deployment occurrence.
*** Bug 51161 has been marked as a duplicate of this bug. ***
I can't reproduce this, even if I edit the template. VE preserves unmodified data-mw attributes always.

Also, what is data-mw.i ? Is it new?
This then causes diffs like http://en.wikipedia.org/w/index.php?title=Bj%C3%B6rk&diff=563745216&oldid=563123196
This is a tracking bug only for blocker-level issues before the planned release of the VisualEditor beta to IP users on English Wikipedia. Please only add blocker-level issues (e.g. content corruption); ultimately, what qualifies as "blocker" is at the discretion of James Forrester, VisualEditor PM.

--------------------------
**Version**: unspecified
**Severity**: blocker
[adding the #tracking project to tasks blocking (now deprecated) T4007 as part of T93366]
The aspects of bug 50747 that were wanted have now been done; bug 51152 has not, but was a soft-blocker rather than a hard-blocker.
It is possible to have a tooltip that will tell you what a reference is when you hover over the number in edit mode, as it currently does in viewing? It is inconvenient to editors to have to go into the references mode to view the source while editing.

(Request from En Wikipedia)

--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://www.mediawiki.org/wiki/VisualEditor/Design/Reference_Dialog
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50110
Change 119913 merged by jenkins-bot:
Ultra-mega-hyper-citation editing on crack

https://gerrit.wikimedia.org/r/119913
Change 119913 had a related patch set uploaded by Jforrester:
Ultra-mega-hyper-citation editing on crack

https://gerrit.wikimedia.org/r/119913
Yes. Hopefully this will be PTR later this week.
This has been highest priority for four months now... 
Does that still reflect reality?
The bug as was written is the highest priority enhancement in VisualEditor and we've been working on it since October.

The change in title and comment 3 reflect a further ambition for this area which will be addressed once this bug is fixed, and should be split off at some point.
JamesF: This has been highest priority since 2013-11-08. 
Any news or updates here?
*** Bug 51188 has been marked as a duplicate of this bug. ***
When cite web is used, webpage title, and access date should be filled
automatically for 1 click web citations.
*** Bug 56708 has been marked as a duplicate of this bug. ***
*** Bug 56772 has been marked as a duplicate of this bug. ***
screenshot

As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot.

Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21.

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F11031}
Merged and will hopefully go out soon.
Change 72069 merged by jenkins-bot:
mw.ViewPageTarget.init: Move edit section to top init

https://gerrit.wikimedia.org/r/72069
Please consider fixing bug 50540 and maybe bug 50405, too.

They are directly dependent of this change. Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth.

Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.
Change 72069 had a related patch set uploaded by Krinkle:
mw.ViewPageTarget.init: Move edit section to top init.

https://gerrit.wikimedia.org/r/72069
Bizarrely, the mouseover "edit source" links appear briefly when mousing over "edit" links while VE is loading a page into edit mode.
Bug 48429#c35 - basically, visual section editing is a seriously hard problem, and isn't on the agenda any time soon.
Well, if that's the case (I haven't heard about it, but I believe you) presumably the link should be renamed to "edit source" to be consistent with the naming of the tabs. Otherwise, I expect quite a bit of confusion.
I'd call this NOTABUG, since James has declared that visual section-editing won't be funded for the foreseeable future. So we now don't have an interface that claims functionality there aren't even plans to implement.
Screenshot of problem

This causing:

* The label fallback (parameter name + ucfirst) not working.
* It is still available from the "Add parameter" dropdown.
* The user can actually add it again, causing a logic error.

I can currently consistently reproduce this on https://en.wikipedia.org/wiki/Taal%2C_Batangas?veaction=edit when editing the "Population Consensus of Taal" information box.

See screenshot:
- "title" is both in the sidebar and in the selectable cloud
- "title" isn't transformed into "Title" (the templatedata has no .label for this one)

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

**Attached**: {F11920}
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
The Edit tab for VisualEditor is sometimes not correctly initialized. Loading about 50 random pages, on one of them I will not have the "Edit source" tab, and the "Edit" tab will point to the wikitext editor instead of VisualEditor.

Chrome/Ubuntu, logged-in. Console shows the following error when this occurs:

Exception thrown by skins.vector.js: Object [object Object] has no method 'collapsibleTabs'

--------------------------
**Version**: unspecified
**Severity**: normal
No longer able to repro this either so closing as fixed; will reopen if I see it reappear.
(In reply to comment #5)
> I still saw it a couple days ago. I'll try with a clean (standard prefs) test
> account later today.

Did a spot-test of 100 on Firefox and another 50 in Safari, and also didn't have any issues.
I still saw it a couple days ago. I'll try with a clean (standard prefs) test account later today.
(Though it didn't recur for me just now on a spot-test of 100 Special:Randoms.)
(In reply to comment #2)
> The collapsibleTabs thing was bug 50504, and it's supposed to be fixed now.

Yes, but apparently that fix of Roan's didn't fix this issue.
The collapsibleTabs thing was bug 50504, and it's supposed to be fixed now.
FYI Timo/Roan, still getting this, but no longer getting the collapsibleTabs error on the console. :P
It might be nice to show a quick intro message for first-time user, could be implemented via GuidedTour. We may want to distinguish between new vs. experienced users.

Part of the goal of the message would be to help users understand the difference between editing in wikitext and VisualEditor, and to explain that wikitext cannot be entered in VisualEditor. We're seeing a fair number of users enter wikitext in VisualEditor, and adding a first-time explanation might help reduce this issue as we roll out VisualEditor to more wikis.

(Feel free to close this WONTFIX if we decide this issue is not significant in scale enough or the message would be too prominent. But having a first-time use message come up is not that unusual for a major feature change.)

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T51820}
{T89074}
**swalling** wrote:

Okay, since VE implemented this in their own dialog system, instead of us doing it in GuidedTours, I'm going to go ahead and close this.
(In reply to comment #11)
> GuidedTour support for VE is shaping up, so we're about ready to start
> building this. But before we embark on this tour you've suggested, I just
> wanted to confirm you're still thinking it's necessary in light of
> https://gerrit.wikimedia.org/r/#/c/73569/ and bug 49820?

I think we still want a GuidedTour to highlight that the user is now in VisualEditor and not the wikitext editor; a very brief one-time message of "hey, you're in VisualEditor now - here is the user guide" or similar should suffice.
James - please weigh in. My take is that we still need a first-use tour. We're changing the function of the "Edit" link, and just giving the user the wikitext warning isn't quite sufficient in informing them about a change of this magnitude. I don't think we'll need it indefinitely, but while VE is in Beta, doing this as part of the wider language rollout will save us and the community some additional transition pain, I think.
**swalling** wrote:

(In reply to comment #9)
> Let's strike the idea of a distinction between new and experienced users for
> now. Philippe and James make the good point that we can't really tell for
> sure
> whether a user is new, especially when editing as an IP, so in the interest
> of
> simplicity and consistency, I suggest we show the same message to everyone
> for
> a while. We can then later either turn it off completely, or show it only to
> a
> subset.

GuidedTour support for VE is shaping up, so we're about ready to start building this. But before we embark on this tour you've suggested, I just wanted to confirm you're still thinking it's necessary in light of https://gerrit.wikimedia.org/r/#/c/73569/ and bug 49820?
**weskaggs** wrote:

I've had quite a bit of experience with things like this working on the GIMP project, and would like to try to convey a bit of "wisdom" that we learned the hard way.

First, there are severe limits on the amount of information a new user, unfamiliar with the interface, can learn from a guided tour.  A tour can give some increased sense of familiarity, but it can't give an ability to do specific tasks.  Above all, a tour can't substitute for simplicity and discoverability.

Second, a guided tour should never be forced on anybody.  It can be offered if that can be done unobtrusively, but should never be required.

Third, if a guided tour exists, it should be available on demand, and able to be repeated as often as desired.  Ideally there should be some sort of "help" menu in the interface, offering the tour as one of the entries.

Fourth, if you make a guided tour, you should consider making a video version and putting it on Youtube.  That might seem like a bizarre idea, but many users are very comfortable with that format.

Also I agree that there is a strong need to show a warning to users who try to enter wiki-markup directly (with a link to an extended explanation).
Let's strike the idea of a distinction between new and experienced users for now. Philippe and James make the good point that we can't really tell for sure whether a user is new, especially when editing as an IP, so in the interest of simplicity and consistency, I suggest we show the same message to everyone for a while. We can then later either turn it off completely, or show it only to a subset.
We'll probably set this up so it launches when they visit a VE-eligible article, unless they have a hidden preference that shows it has launched before.  The role isSinglePage plays is ensuring no cookie is stored tracking their tour progress.  So even if they navigate away without closing the tour, it won't show again.
**swalling** wrote:

(In reply to comment #6)
> I'd suggest:
> 
> If user account was created before July 1, 2013, display the following
> message
> exactly once:
> 
> -
> You are using the VisualEditor, a new rich-text editing interface for
> {{SITENAME}} (currently in beta). <B>Please be aware that wiki syntax (e.g.
> "[[link to another page]]") will not work in this editing mode.</B> To use
> the
> old editing interface, click the 'Edit source' tab or section link.
> -
> 
> For extra points, the "exactly once" could be managed via a "Do not show this
> message again" checkbox. But it shouldn't be handled as a notice that comes
> up
> every single time -- it should definitely be dismissible.
> 
> The reason I'd like to finalize the language soon is to give us enough time
> to
> get translations.

I think this is reasonable.  

Regarding showing a tour only once: I don't think we have to add an explicit checkbox to show it exactly once. Currently the default behavior is...

If a user completes the tour or clicks the X to close we never show it again. So in this case, as a single step tour, clicking the "Okay" button or X would end the tour and it would never repeat. That is stored as a hidden preference, so it works across sessions, but not across wikis.

If we really want to tie it to a single page, there is also an isSinglePage variable we can set for the tour, which means no matter what it will only appear on that one page.
I'd suggest:

If user account was created before July 1, 2013, display the following message exactly once:

-
You are using the VisualEditor, a new rich-text editing interface for {{SITENAME}} (currently in beta). <B>Please be aware that wiki syntax (e.g. "[[link to another page]]") will not work in this editing mode.</B> To use the old editing interface, click the 'Edit source' tab or section link.
-

For extra points, the "exactly once" could be managed via a "Do not show this message again" checkbox. But it shouldn't be handled as a notice that comes up every single time -- it should definitely be dismissible.

The reason I'd like to finalize the language soon is to give us enough time to get translations.
(In reply to comment #2)
> (In reply to comment #1)
> > Adding Steven in case his team wants to help/weigh in.
> 
> TL;DR: 
> 
> Unless VE team wants to own it, I think E3 can handle any tours of basic
> editing functionality (with and without VE). What we have is 1/2 way toward
> the changes Erik requested. 

Awesome; very happy for E3 to lead on this. We'll support as needed, of course.

> We are working on adding better VE support in GuidedTour currently, and I've
> added Matt Flaschen since he's tackling that. We are shooting for feature
> parity with our previous guided tour of editing for the first time delivered
> to GettingStarted editors, with the exception being that there is no Preview
> step to point to in VE. 
> 
> Also, soon we hope to test delivering a guided tour to all newly-registered
> editors, outside the GettingStarted funnel. (Docs:
> https://meta.wikimedia.org/wiki/Research:Guided_tours). Whether we run that
> test on a wiki like Spanish or French instead of English depends on l10n of
> the "first edit" tour and whether VE support is ready. S Page is helping
> out with this test, so I've added him as well. 
> 
> If we're interested in pointing out the difference between VE and wikitext to
> users right away, we could easily build that in as step for the guided tours
> delivered via GettingStarted and the general "first edit" tour we're
> planning. Currently with the tour that's in production, we just point to the
> Edit button and section edit buttons. 
> 
> I'm open to changing that, but I do think we should be cautious about
> throwing too much complexity at first time editors too soon, by pointing out
> the multiple methods of editing. I added Pau for his input.

Yeah, I'm not convinced I know what we'd want to do.

Maybe just a simple "you're using VisualEditor" on first load for experienced users?

Maybe a set of "add a {reference,template} by clicking here" ones too? Maybe not?

What do you advise?
If it's semi-experienced users who are entering the wikitext, that could be improved with a tour specific to them (and/or VE documentation).

If it's new users (they are less likely to know wikitext, though) making this mistake, maybe the comparison is necessary.
(In reply to comment #2)
> If we're interested in pointing out the difference between VE and wikitext to
> users right away, we could easily build that in as step for the guided tours
> delivered via GettingStarted and the general "first edit" tour we're
> planning.

I don't think that (comparing VE and wikitext) needs to be in the first tour.  It's discoverable in the UI in a consistent way, plus people on-wiki will point to and explain the difference when necessary.
**swalling** wrote:

(In reply to comment #1)
> Adding Steven in case his team wants to help/weigh in.

TL;DR: 

Unless VE team wants to own it, I think E3 can handle any tours of basic editing functionality (with and without VE). What we have is 1/2 way toward the changes Erik requested. 

Full details: 

We are working on adding better VE support in GuidedTour currently, and I've added Matt Flaschen since he's tackling that. We are shooting for feature parity with our previous guided tour of editing for the first time delivered to GettingStarted editors, with the exception being that there is no Preview step to point to in VE. 

Also, soon we hope to test delivering a guided tour to all newly-registered editors, outside the GettingStarted funnel. (Docs: https://meta.wikimedia.org/wiki/Research:Guided_tours). Whether we run that test on a wiki like Spanish or French instead of English depends on l10n of the "first edit" tour and whether VE support is ready. S Page is helping out with this test, so I've added him as well. 

If we're interested in pointing out the difference between VE and wikitext to users right away, we could easily build that in as step for the guided tours delivered via GettingStarted and the general "first edit" tour we're planning. Currently with the tour that's in production, we just point to the Edit button and section edit buttons. 

I'm open to changing that, but I do think we should be cautious about throwing too much complexity at first time editors too soon, by pointing out the multiple methods of editing. I added Pau for his input.
Adding Steven in case his team wants to help/weigh in.
After save of page using VisualEditor on beta, and clicking on Edit again (I am on the current page, as the content has been updated), I don't get the latest revision, but the revision I had before (the content switches back to the old version), and getting a warning that I'm not editing the latest version

--------------------------
**Version**: unspecified
**Severity**: blocker
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50716
This is now deployed and appears to be working as expected in production, according to my testing. Marking as fixed. Please re-open if you find otherwise.
Change 72070 merged by jenkins-bot:
mw.ViewPageTarget: Fix incorrect retention of the wrong oldid

https://gerrit.wikimedia.org/r/72070
*** Bug 50596 has been marked as a duplicate of this bug. ***
Bug 47420 is the same thing that was reopened.  One of these two should be merged as a duplicate of the other.
Change 72070 had a related patch set uploaded by Krinkle:
mw.ViewPageTarget: Only pass oldid if we have to and clear/update it on save

https://gerrit.wikimedia.org/r/72070
Actually, though we are indeed initialising for the version the user is reading instead of the latest version (separate bug) we do update `this.oldid` in mw.ViewPageTarget#onSave based on the data we got from the API.

However the API isn't returning that data, there is no "data.newrevid" returned by ApiVisualEditor.
Which makes me wonder, why are we using that in the first place. Don't we always want to be editing the latest version (except when url has oldid=) even if the latest version is more recent than the version the user is reading (either because the page is cached or because an edit was made while the user was viewing the page).
Figured out the cause:

This revision id for the page is initialised in ve.init.mw.Target from wgCurRevisionId but then never updated.
(In reply to comment #8)
> If there's any likely timescale for the fixing of this bug, it might be
> useful to comment there: is "soon" likely to be hours, days, or weeks?!

Days. :-) Don't want to promise "tomorrow" if we don't manage to fix it by then, but certainly as soon as we can get it written, tested and deployed.
(In reply to comment #7)
> (In reply to comment #6)
> > Pending a full solution, is there any way that the pink error box can be
> > amended to include something like: "Please click the "Cancel" button, then
> > Refresh/Reload the page and try again. Apologies for this temporary problem -
> > we are working on it."
> > 
> > It's irritating for an experienced editor who has found the work-round, but
> > must be desperately confusing for a new editor who has just made an edit, had
> > an afterthought, and gets that message.
> 
> The message displayed is editable by any English Wikipedia sysop; this
> doesn't
> need any code changes to alter the text, or remove the bright pinkness, but
> you
> should discuss it with the community:
> https://en.wikipedia.org/wiki/MediaWiki:Editingold
> 
> We're hoping to get this regression fixed soon; sorry for the inconvenience.

OK, have raised a suggestion at [[MediaWiki_talk:Editingold#VE_problem]]. If there's any likely timescale for the fixing of this bug, it might be useful to comment there: is "soon" likely to be hours, days, or weeks?!
(In reply to comment #6)
> Pending a full solution, is there any way that the pink error box can be
> amended to include something like: "Please click the "Cancel" button, then
> Refresh/Reload the page and try again. Apologies for this temporary problem -
> we are working on it."
> 
> It's irritating for an experienced editor who has found the work-round, but
> must be desperately confusing for a new editor who has just made an edit, had
> an afterthought, and gets that message.

The message displayed is editable by any English Wikipedia sysop; this doesn't need any code changes to alter the text, or remove the bright pinkness, but you should discuss it with the community: https://en.wikipedia.org/wiki/MediaWiki:Editingold

We're hoping to get this regression fixed soon; sorry for the inconvenience.
Pending a full solution, is there any way that the pink error box can be amended to include something like: "Please click the "Cancel" button, then Refresh/Reload the page and try again. Apologies for this temporary problem - we are working on it."

It's irritating for an experienced editor who has found the work-round, but must be desperately confusing for a new editor who has just made an edit, had an afterthought, and gets that message.
*** Bug 50555 has been marked as a duplicate of this bug. ***
Comment on attachment 12694
Screen recording of the bug

This is how the problem materialize for me, as you see, it jumps back to the previous revision on edit, and then complains it's not the latest revision.
Screen recording of the bug

**Attached**: {F11340}
The url is http://en.wikipedia.beta.wmflabs.org/wiki/User:AzaToth/Test2?veaction=edit

Following is a timeline:

http://i.imgur.com/VmbT33s.png
http://i.imgur.com/FVWEf4r.png
http://i.imgur.com/ieTdi36.png
http://i.imgur.com/DP0eDLs.png
http://i.imgur.com/fNRbqeP.png
What url do you go to initially?
After saving and reading the page, what do you see. The version from before you edited or after, and what does the url look like?

When going into edit mode after saving, what does the url look like?
An attempt to save an article in the visual editor after a period of inactivity results in the "Invalid token" error message and saving fails. At this point, the user is completely stuck and their entire work is lost. 

Loss of session data can also occur in the regular source code edit window, but is easily rectified by repeated saving; this doesn't work in the visual editor. 

I would classify this as user-hostile behavior.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50402
This is now fixed in master, which will be deployed within the hour.
Change 73446 merged by jenkins-bot:
mw.ViewPageTarget: Refetch token if session expired

https://gerrit.wikimedia.org/r/73446
Please note that the reporter of Bug 51302 also points out that the session expiry clock already starts ticking once an article is opened for *reading*, i.e. potentially much earlier than when the visual editor is started on the article.
I just encountered this problem.  I would call this bug a blocker as it is effectively 'dataloss' in bmo keyword terminology!
*** Bug 51302 has been marked as a duplicate of this bug. ***
Change 73446 had a related patch set uploaded by Krinkle:
(DRAFT) mw.ViewPageTarget: Refetch token if session expired

https://gerrit.wikimedia.org/r/73446
Change 73203 merged by jenkins-bot:
mw.ViewPageTarget: Improve error message for badtoken error

https://gerrit.wikimedia.org/r/73203
Change 73189 merged by jenkins-bot:
api: Split save action into separate API module

https://gerrit.wikimedia.org/r/73189
Change 73203 had a related patch set uploaded by Krinkle:
mw.ViewPageTarget: Improve error message for badtoken error

https://gerrit.wikimedia.org/r/73203
Change 73189 had a related patch set uploaded by Krinkle:
API: Split save action into separate API module

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

See the screenshot; I imagine the reference is being treated as existing within the template, rather than within the template within the page - it hunts for <references\>, can't find a tag in the template itself, and freaks the heck out.

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

**Attached**: {F11303}
I'm forking this off into bug 51337.
Change 73614 had a related patch set uploaded by Esanders:
Use new class to detect Cite errors inside templates

https://gerrit.wikimedia.org/r/73614
Should probably leave this open to track improvements.
Also: https://gerrit.wikimedia.org/r/73096
These are now hidden by the above commit, which we're deploying in the next few minutes.
Change 73092 merged by jenkins-bot:
Hide ref errors inside MW transclusions

https://gerrit.wikimedia.org/r/73092
Change 73092 had a related patch set uploaded by Esanders:
Hide ref errors inside MW transclusions

https://gerrit.wikimedia.org/r/73092
The short-term fix is to just strip this comment from the returned HTML that the PHP parser gives us.

When we switch over to using Parsoid for this, we'll need that to run in context, somehow, so the references are correctly numbered and that we know to update the relevant reference lists.
The references list one is still there; did Trevor's change break it?

--------------------------
**Version**: unspecified
**Severity**: critical
Fixed with new pull.
http://en.wikipedia.org/w/index.php?title=User%3AEdgepedia%2FVE%2FGNoSR&diff=561873747&oldid=561873385

Removes non-breaking space.

--------------------------
**Version**: unspecified
**Severity**: major
We cannot reproduce this on several different browsers/computers; it's most likely cause by a browser plug-in that the user has installed. Marking as "WORKSFORME" but if you can work out with the user what they have that is breaking VisualEditor it'd be good to know.
Chrome Version 27.0.1453.116 on Windows 7 Home Premium.
Will inquire.
Do you know which browser was used for this edit?
Odd. I can't reproduce this locally or on the article.
Log in to beta labs: 

No navigation arrows exist in FF or Chrome

Special:Preferences shows no tabs

No links to VE exists even when Preferences are set

In regular editor, no controls appear

A number of pages e.g. user page show error Uncaught ReferenceError: mw is not defined load.php:1

--------------------------
**Version**: unspecified
**Severity**: critical
Ah it seems the cached load.php got cleared finally.   I got AFT and VisualEdit working properly now :-]
AFT, VisualEditor are now working when passing ?debug=true to the URL (which bypass resourceloader cache).

I have no idea how to clear the resource loader cache though :(
Changes above reverts the two patches mentionned in bug 45918.
Related URL: https://gerrit.wikimedia.org/r/70806 (Gerrit Change Ie373d1f407788a8e2456c3d8a34cc79ac9ed8bb6)
Related URL: https://gerrit.wikimedia.org/r/70805 (Gerrit Change I02ed22e324435e362cabdfc67e69c224ad9e2550)
In the exception.log I also got a bunch of:


2013-06-26 22:39:51 deployment-jobrunner08 aawiki: [ff75b05a] [no req]   Exception from line 32 of /data/project/apache/common-local/php-master/extensions/MwEmbedSupport/MwEmbedResourceManager.php: MwEmbedResourceManager::register not given readable path: extensions/TimedMediaHandler/MwEmbedModules/EmbedPlayer


It seems the issue is caused by https://gerrit.wikimedia.org/r/#/c/69479/ "Register resources with absolute path"  which is intended to fix bug 45918 "MwEmbedSupport doesn't work with non standard layouts"
exception 'MWException' with message 'ResourceLoaderFileModule::readScriptFiles: script file not found: "/usr/local/apache/common-local/php-master/er/extensions/MwEmbedSupport/MwEmbedModules/MediaWikiSupport/MediaWikiSupport.loader.js"' in /data/project/apache/common-local/php-master/includes/resourceloader/ResourceLoaderFileModule.php:574
not a blocker, sorry, mw.o is a workaround
This also breaks Wikilove on beta. 

In about 24 hours I will be giving a training session at WMF for 50 people about browser test automation that I had intended to do with Wikilove on beta labs.  

While I could move the demo to mw.o instead, that would be less than ideal.
I made a grammar fix (one word), and did not check the differences before saving. Mistake! :) 

http://en.wikipedia.org/w/index.php?title=Abdullah_of_Saudi_Arabia&diff=prev&oldid=561571041

It looks like all it did was sanitize the templates, which isn't the worst thing on earth, but it's hard to verify that was all that happened (especially for a non-expert). 

No recommended fix, exactly, but perhaps something to consider.

--------------------------
**Version**: unspecified
**Severity**: normal
Yeah, this is a quite bad problem to have. Thankfully, we believe that the majority of these issues have now been fixed (since that edit of yours) - so I'm going to mark this as fixed. There are no-doubt other issues we've yet to spot, but we've fixed this one. :-) Sorry for the inconvenience!
For deployment purposes, we will want VisualEditor to be enabled for all logged-in users but not anonymous ones; to do this, we'll probably just fail in VisualEditor.hooks.php#onBeforePageDisplay() if they're anonymous, according to Roan.

--------------------------
**Version**: unspecified
**Severity**: trivial
We achieved this. Obviously. :-)
Screenshot

See screenshot.

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

**Attached**: {F11809}
Change 70851 merged by jenkins-bot:
Make local overlays local to surface and remove insane z-indexes

https://gerrit.wikimedia.org/r/70851
Change 70851 had a related patch set uploaded by Robmoen:
Make local overlays local to surface and remove insane z-indexes

https://gerrit.wikimedia.org/r/70851
Appears to be now fixed; marking as resolved. Thanks, Rob! :)
Rob's working on re-doing our z-indexes and inheritance right now.
(Firefox 21.0, Windows 7)
Screenshot

I am unable to click ob the icon to open the image/caption dialog, see screenshot. Instead a cross to move the image is shown.

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

**Attached**: {F11665}
Fixed and will be going out in a few minutes.
Change 70859 merged by jenkins-bot:
Local Overlay Stacks

https://gerrit.wikimedia.org/r/70859
Change 70859 had a related patch set uploaded by Jforrester:
Local Overlay Stacks

https://gerrit.wikimedia.org/r/70859
Also in Safari 6 for me.
I confirm this in Firefox 21 on enwp.
When using the control/command+k shortcut, and manually typing the text of the desired page to be linked, duplicate links are produced.  See http://en.wikipedia.org/w/index.php?title=User:PEarley_%28WMF%29/sandbox&diff=prev&oldid=561424914

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #5)
> Great! Thanks for the quick response, James and team!

Our pleasure; sorry it happened in the first place.
Great! Thanks for the quick response, James and team!
Fixed and being deployed right now.
Related URL: https://gerrit.wikimedia.org/r/70623 (Gerrit Change I8c68468a95cddbc7efb222cf3a1f9868b2949285)
*** Bug 50188 has been marked as a duplicate of this bug. ***
Confirmed - happens whenever you use the link inspector on a non-selection (slug or otherwise). Ed?
When doing a simple test edit on https://en.wikipedia.org/wiki/Chloroplast?veaction=edit and then previewing the diff, several transclusions of the form {{expand section|..}} show up with dirty diffs. This is very likely a DOM corruption in the VE that disables selective serialization.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/wiki/Chloroplast?veaction=edit
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50070
I don't see the Dub Jones issue any more, so that appears to be fixed.

There was also an independent Parsoid issue that resulted in incomplete DSR on transclusions, which is now also fixed. 

If you don't see this issue any more then this bug can be closed as fixed.
(In reply to comment #7)
> Another case:
> https://en.wikipedia.org/w/index.
> php?title=Dub_Jones_%28American_football%29&curid=5240085&diff=561834911&oldi
> d=561833425
WFM when I tried to reproduce at http://en.wikipedia.org/wiki/User:Catrope/Dub_Jones?veaction=edit . VE's sanity check says the DOM is clean. I believe these failures are due to cached content or some sort of bug in Parsoid/selser.
Another case:
https://en.wikipedia.org/w/index.php?title=Dub_Jones_%28American_football%29&curid=5240085&diff=561834911&oldid=561833425
Another example where an unmodified template was dirtied:

https://en.wikipedia.org/w/index.php?title=User%3AEdgepedia%2FVE%2FGNoSR&diff=561782383&oldid=561781680

Since our DOM diff is so simple I have a lot of faith in it. Did you diff the template DOM fragment after making an unrelated change?
(In reply to comment #4)
> At least one {{expand section|..}} transclusion still dirty-diffs.
> 
> This will soon not show up as a diff any more because we improved our native
> serialization, but it seems that the VE still dirties the transclusion, which
> needs to be fixed.
It doesn't seem to be dirtied by VE directly. On [[Chloroplast]], I get a clean diff if I don't make any changes, but a dirty diff if I make any change at all. This leads me to suspect a selser / DOMDiffer bug.

Will try to produce a minimal test case and investigate from there.
At least one {{expand section|..}} transclusion still dirty-diffs.

This will soon not show up as a diff any more because we improved our native serialization, but it seems that the VE still dirties the transclusion, which needs to be fixed.
*** This bug has been marked as a duplicate of bug 50070 ***
The nowiki escaping in Schuylar_Oordt is Parsoid bug 50144. It would normally be hidden with selective serialization.
Some more examples from https://en.wikipedia.org/w/index.php?namespace=&tagfilter=visualeditor&title=Special%3ARecentChanges:

https://en.wikipedia.org/w/index.php?title=Eugenio_Fojo&curid=33949576&diff=561434486&oldid=561304103
https://en.wikipedia.org/w/index.php?title=Schuylar_Oordt&curid=37614262&diff=561438828&oldid=561406705
https://en.wikipedia.org/w/index.php?title=Dina_bint_%27Abdu%27l-Hamid&diff=561398396&oldid=561397974

I added a single letter ("therafter" --> "thereafter"). VisualEditor duplicated the categories and the default sort.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50385
https://bugzilla.wikimedia.org/show_bug.cgi?id=50332
https://bugzilla.wikimedia.org/show_bug.cgi?id=54169
The Parsoid fix is deployed. The P-wrapping portion is verified fixed on our test case [[Tim_Gartrell]].

The VE newline migration should be tracked in a different bug. Closing this bug as fixed.
Change 73113 merged by jenkins-bot:
Bug 50120: Avoid paragraph wrapping for DOM fragments with blocks

https://gerrit.wikimedia.org/r/73113
Change 73113 had a related patch set uploaded by GWicke:
Bug 50120: Avoid paragraph wrapping for DOM fragments with blocks

https://gerrit.wikimedia.org/r/73113
Subbu, Gabriel and I figured this out on IRC, and Subbu and Gabriel are working on a fix. Summary for the benefit of those following this bug:

* On the first parse (either upon first VE load after the cache is purged, or upon the first edit after the purge), Parsoid parses the PERSONDATA template from scratch (because there is no cached content to reuse) and does so correctly. The output is something like <span>\n</span><table>...</table><link>
* On the second parse, (first or second edit after cache purge), Parsoid reuses the template expansion from the first parse. It notices that the first (span) and last (link) nodes are both inline, and so it assumes the entire template is inline and wraps it in a <p>
* The browser receives this HTML and is unhappy about the <table> inside the <p>, so it moves both the <table> and the <link> out of the <p>, leaving <p><span>\n</span></p><table>...</table><link>. Because the table is not a sibling of the span, VE doesn't recognize the table (or the link) as part of the template. Due to a separate bug in VE, the newline after the link is moved and ends up between the table and the link.
* VE sends this corrupted HTML back to Parsoid, which freaks out and duplicates the table as well as a bunch of categories.
* After the page is edited again (possibly by the user saving the corrupted VE output, possibly some other way), the third parse occurs, and Parsoid again tries to reuse the previous parse's expansion of the template. However, because of the <p> interruption, it only sees the span and doesn't see the table or the link. The table and the link disappear from the output in this and all subsequent parses, masking the bug. The user doesn't notice because the table has style="display:none;"
https://en.wikipedia.org/w/index.php?title=Tim_Gartrell&curid=1659124&diff=563696826&oldid=563696785
*** Bug 50554 has been marked as a duplicate of this bug. ***
See also: bug 50554, bug 50385.
Another case:
https://en.wikipedia.org/w/index.php?title=Frederick_Calvert,_6th_Baron_Baltimore&curid=884173&diff=563705563&oldid=563705411

Also updated the subject and moved to VE.
That's really strange. The template is one unit in the VE data model, so if <link> tags are placed in the middle of it that must be a bug in the data model -> HTML conversion, not in the data model itself.
(In reply to comment #15)
> So, there may also be a Parsoid issue here about how such templates are
> parsed.

As long as the content (including ws-only spans) is properly encapsulated that should not be relevant for this corruption.

I have seen VE move categories to random places in the DOM before. Apparently that bug is still alive. And hard to reproduce, sadly.
Possibly related: bug 50332.
And, I misspoke. The spans from the template before/after the table are not really "empty" -- they have whitespace.  And, the more interesting thing is that these spans do not get the display:none; css style but the table gets it from the style on the table ==> the spans are technically visible (with whitespace ignored in the browser) in VE, but the table is not.

So, there may also be a Parsoid issue here about how such templates are parsed.
This may be a VE bug (unconfirmed).  Here is what I did.

I parsed mw:Jayaprakash Narayan on my local parsoid install and saved the HTML.
I then added a <link rel="mw:WikiLink/Category" href="Category:foobar"> (a new category essentially mimicking editor behavior), but I added it between the empty span that marks the opening of the Persondata tmeplate and the <table> that is part of the template.  This effectively splits the template and duplicates the rest of the template.

If you look at the diff in https://en.wikipedia.org/w/index.php?title=Jayaprakash_Narayan&diff=563627722&oldid=563627392, all the categories are between the end of the template and the table. The above experiment yielded something similar, except in the diff, all categories are moved up.

So, it does seem that when a user adds categories, new/old categories are being moved/inserted between the empty span and the table breaking the atomic encapsulated template into two.

Also note that this only seems to affect Persondata template 
* in original wikitext, default sort template immediately follows the persondata template.
* it has an empty span before/after the table
* it has display:none set on it which means it doesn't show up in the editor.

Not sure if cursor position affects where categories are inserted.  Can VE folks verify this hypothesis?
Couple more:
https://en.wikipedia.org/w/index.php?title=Peter_Biddle&diff=563624872&oldid=563623995
https://en.wikipedia.org/w/index.php?title=Jayaprakash_Narayan&diff=563627722&oldid=563627392

Based on inspection of recent diffs, I'd call this the single most prevalent and most problematic content corruption issue at this point.
Note the additional table screw-up in that one. We may need some cross-browser hammering on those revs to see if it's a browser-specific issue.
Another one:
https://en.wikipedia.org/w/index.php?title=Rick_DePiro&curid=29139774&diff=563628155&oldid=560712931
Nope, still occurring.
https://en.wikipedia.org/w/index.php?title=Ma_Huateng&curid=6152047&diff=563628488&oldid=555028382
https://en.wikipedia.org/w/index.php?title=Mat_Devine&curid=28997812&diff=563130933&oldid=563130533 looks like a VE bug to me. I can't reproduce it any more (similar to the case in bug 50853), so I am guessing that something in last night's VE deploy fixed this.

Closing as fixed, please reopen if this still happens.
This may be related to bug 50853 which gabriel is going to be investigating to day.
Is this a Parsoid DSR issue? Content getting repeated in this way (especially, the substituted template) is hard to see occurring in VisualEditor.
This is still occurring. Most recent example from a few minutes ago:

https://en.wikipedia.org/w/index.php?title=Mat_Devine&curid=28997812&diff=563130933&oldid=563130533
We believe that this is now fixed (due to fixes in Parsoid). Please re-open if it recurs.
https://en.wikipedia.org/w/index.php?title=Miloslav_Ransdorf&curid=1478506&diff=561858255&oldid=561857291 to boot.
Roan, thoughts?
https://en.wikipedia.org/w/index.php?title=Richard_Ned_Lebow&diff=561410319&oldid=561410032
Perhaps related to:

| PLACE OF BIRTH    =[Alexandria], [[Egypt]]
Self-explanatory; Firefox 21.0, Windows 7.

--------------------------
**Version**: unspecified
**Severity**: major
Fixed and will be going out in a few minutes.
Patched in: https://gerrit.wikimedia.org/r/#/c/70559/
Not sure if this is something that's been nixed and nobody has told me, but: tracking bug for adding cite template support to the VE's referencing setup. They're pretty universally useful.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50768
Change 119913 merged by jenkins-bot:
Ultra-mega-hyper-citation editing on crack

https://gerrit.wikimedia.org/r/119913
Change 119913 had a related patch set uploaded by Jforrester:
Ultra-mega-hyper-citation editing on crack

https://gerrit.wikimedia.org/r/119913
*** Bug 51185 has been marked as a duplicate of this bug. ***
(In reply to comment #2)
> For clarification: I'll assume that this is about what you put _inside_ the
> <ref> tags and not about templates that add the <ref> tags themselves.

Correct.
For clarification: I'll assume that this is about what you put _inside_ the <ref> tags and not about templates that add the <ref> tags themselves.
*** Bug 51683 has been marked as a duplicate of this bug. ***
Screenshot

See screenshot. Kiiinda worrying - if this is something a group of people > me is seeing it may be a blocker.

--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://en.wikipedia.org/wiki/Joe_Flacco?veaction=edit

**Attached**: {F11445}
Related URL: https://gerrit.wikimedia.org/r/70119 (Gerrit Change I29e210aba9a6265d8364ff8ae49408cb4c2428b9)
Confirmed by a second user.
--------------------------
**Version**: unspecified
**Severity**: normal
Written and about to be deployed.
Change 70106 merged by jenkins-bot:
mw.ViewPageTarget: Add sanity check for DOM roundtrip

https://gerrit.wikimedia.org/r/70106
Related URL: https://gerrit.wikimedia.org/r/70106 (Gerrit Change I04f71fe8e00c6257fbc953cc9de3323e24709b0f)
They get stripped out when rendered back to HTML.

e.g.

<ref>Foo<!--bar--></ref>

->

<ref>Foo</ref>

--------------------------
**Version**: unspecified
**Severity**: normal
Related URL: https://gerrit.wikimedia.org/r/70060 (Gerrit Change I3bbea49132ef4a720a147ba9b170c39a0c00f711)
Moved from #48830.

Merlijn van Deen 2013-06-23 11:20:36 UTC
----------------------------------------
https://www.mediawiki.org/w/index.php?title=Git%2FConversion%2Fpywikipedia&diff=714194&oldid=713893
The only real edit is at the bottom.

Krinkle 2013-06-23 11:25:31 UTC
-------------------------------
This is due to the merging of the 2 <b> tags. Currently it fails compare custom
attributes like "style" when attempting to merge equal annotation sequences.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48830
We have a work around for this - gerrit 69852 - now in production in VisualEditor, but the underlying cause is bug 48194. I've manually fixed the changes VE made - sorry about that: https://www.mediawiki.org/w/index.php?title=Git/Conversion/pywikipedia&diff=715751&oldid=715067
This doesn't work; not quite sure why/how. Should be fixed.

--------------------------
**Version**: unspecified
**Severity**: major
Fix merged and will hopefully go out soon.
Change 72069 merged by jenkins-bot:
mw.ViewPageTarget.init: Move edit section to top init

https://gerrit.wikimedia.org/r/72069
Change 72069 had a related patch set uploaded by Jforrester:
mw.ViewPageTarget.init: Move edit section to top init.

https://gerrit.wikimedia.org/r/72069
Gah, bad breakage related to making VE more lightweight - sorry about that. Gerrit 72069 fixes this, according to my local testing - we'll try to get this out today.
My testing shows that ctrl+click works only in VE-enabled namespaces but middle click works everywhere in Firefox 22. 

In Konqueror 4.8.5 (which is apparently not enabled for VE) both ctrl+click and middle click both work only in VE-enabled namespaces.
I'm not sure how the fix was implemented, but it seems to have started occurring again - this time only in namespaces in which the VE isn't active.
Related URL: https://gerrit.wikimedia.org/r/70773 (Gerrit Change I5245ab19ae16b79d2c562c05b94649a58e04a4fd)
Fixed in gerrit 70735 which is now merged and will get pushed later today.
Raising importance, this is quite annoying. It's just been reported on [[WP:VPT]] for the second time today.
*** Bug 50221 has been marked as a duplicate of this bug. ***
**pinkampersand.wikimedia** wrote:

I should note that I've been having this bug (well, with ctrl-click on my laptop, but think that's the same thing), and I don't have VE enabled. However, this bug's several days old, and I'm pretty sure this has only been happening to me within the past hour. Chrome on a ChromeOS netbook.
Some back-of-the-envelope work by users indicates that firefox (logged in) and chromium (logged out) on linux have this problem; firefox and IE on Windows (not logged in) do not.
Steps to reproduce:
1. Insert the cursor immediately after the first letter of a link
2. Hit delete/backspace
3. Type a new character
4. The new character isn't part of the link, so select the entire word and click the link button
5. Re-enter the link article
6. Save your changes

Expected result:
If you started with "[[Porcupine]]", you should end up with "[[porcupine]]".

Actual result:
If you started with "[[Porcupine]]", you end up with "[[porcupine|p]][[Porcupine|orcupine]]".

This is just a common use case demonstrating a more general bug. Namely, if you create a new link that subsumes an existing link, the existing link is preserved within the new link instead of being replaced.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50098
(In reply to comment #5)
> Change 70633 merged by jenkins-bot:
> Fix comparison of MW internal links
> 
> https://gerrit.wikimedia.org/r/70633

And with that change, this bug is fixed; closing. It will be deployed this afternoon.
Change 70633 merged by jenkins-bot:
Fix comparison of MW internal links

https://gerrit.wikimedia.org/r/70633
Related URL: https://gerrit.wikimedia.org/r/70633 (Gerrit Change I5fb5bfc69c344ca4ce4803d7b6116074648a8d7e)
There are two issues here.

First off, we should change getComparableObject() for MWInternalLinkAnnotation to normalize the title and possibly tweak other things to the point where links to the same title are comparable, even if they have different capitalizations or space-vs-underscore variants of that title. That will be both more semantically correct and serve as a workaround for this bug.

Secondly, because we want to stop merging comparable but different annotations in the converter, we need Parsoid to correctly process at least things like <a href="Porcupine">p</a><a href="Porcupine">orcupine</a> (adjacent <a>s with the same href) and possibly <a href="porcupine">p</a><a href="Porcupine">orcupine</a> as well (adjacent <a>s with different hrefs that normalize to the same title).
Similar but different. This case should definitely be fixed in VE, not Parsoid.
Ed, is this due to the DM stuff around adjacent annotations?
http://en.wikipedia.beta.wmflabs.org/wiki/Special:Version shows that the version of VisualEditor on beta labs is from May 28.  The version of Parsoid on beta labs shows no date. 

It would be convenient to have VE/Parsoid available on beta labs as well as on test2wiki and mediawiki.org

--------------------------
**Version**: unspecified
**Severity**: critical
**Whiteboard**: rmqa-2013
Change 317923 merged by Dzahn:
contint: remove python-requests

[[https://gerrit.wikimedia.org/r/317923]]
Change 317923 had a related patch set uploaded (by Hashar):
contint: remove python-requests

[[https://gerrit.wikimedia.org/r/317923]]
Change 311161 merged by Dzahn:
contint: drop now unused sudo rule

[[https://gerrit.wikimedia.org/r/311161]]
Change 311161 had a related patch set uploaded (by Hashar):
contint: drop now unused sudo rule

[[https://gerrit.wikimedia.org/r/311161]]
Change 309275 merged by Giuseppe Lavagetto:
ci::master: drop mwext-sync leftover

[[https://gerrit.wikimedia.org/r/309275]]
Change 309272 merged by jenkins-bot:
Remove VE script to sync the Gerrit repo

[[https://gerrit.wikimedia.org/r/309272]]
This is confirmed to have been fixed when we have upgraded to Gerrit 2.12.

The workaround script and Jenkins job have been removed end of July, the recent changes I have sent above are merely for clean up.
Change 309275 had a related patch set uploaded (by Hashar):
ci::master: drop mwext-sync leftover

[[https://gerrit.wikimedia.org/r/309275]]
Change 309272 had a related patch set uploaded (by Hashar):
Remove VE script to sync the Gerrit repo

[[https://gerrit.wikimedia.org/r/309272]]
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVcJQJLzaH8PnNb4D6OE} [2016-09-08T10:03:29Z] <hashar> Delete Jenkins job https://integration.wikimedia.org/ci/job/mwext-VisualEditor-sync-gerrit/ that has been left behind. It is no more needed. T51846 T86659
{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVcJP0y9pirJUPGy-5YX} [2016-09-08T10:02:05Z] <hashar> Delete mwext-VisualEditor-sync-gerrit job, already got removed by ostriches in 139d17c8f1c4bcf2bb761e13a6501e4d85684066 . The issue in Gerrit (T51846) has been fixed. Poke T86659 , one less job on slaves.
Fixed in https://gerrit-review.googlesource.com/#/c/69891/

Upgrading to gerrit 2.12 which will happen soon will fix the problem.
Upstream bug is https://code.google.com/p/gerrit/issues/detail?id=2393
Same issue with `Cards` and `mediawiki/extensions/Cards` at T125182
After much madness, this is now fixed. I had to write a bunch of shell slave scripts to let us properly push the VE update change to mediawiki/extensions.git and self merge them.

The job is:

 https://integration.wikimedia.org/ci/job/mwext-VisualEditor-sync-gerrit/

It managed to merge an update a few minutes ago:

 https://gerrit.wikimedia.org/r/#/c/109113/


I guess the issue is fixed now. Sorry for the long time it took to get this fixed.
Change 108837 merged by jenkins-bot:
mwext-VisualEditor-sync-gerrit on master branch only

https://gerrit.wikimedia.org/r/108837
Change 108837 had a related patch set uploaded by Hashar:
mwext-VisualEditor-sync-gerrit on master branch only

https://gerrit.wikimedia.org/r/108837
Change 108810 merged by jenkins-bot:
trigger mwext-VisualEditor-sync-gerrit on postmerge

https://gerrit.wikimedia.org/r/108810
Change 108810 had a related patch set uploaded by Hashar:
trigger mwext-VisualEditor-sync-gerrit on postmerge

https://gerrit.wikimedia.org/r/108810
The Gerrit replication got fixed last week.  The bot was not able to connect because Gerrit cache accounts credential indefinitely (lowered to 7 days by Chad with https://gerrit.wikimedia.org/r/#/c/108715/ ).

I did a few tweaks to adjust the shell script and granted jenkins-bot the ability to CR+2 and V+2 on mediawiki/extensions.git .

The first change that self merged is https://gerrit.wikimedia.org/r/#/c/108732/

Gotta add triggers in Zuul.
When jenkins-bot push to Gerrit, Gerrit fetch the email address of the user from the LDAP directory and compare it to the Commiter field of each commit being pushed.

Gerrit points to LDAP server virt1000 which is no more replicated from virt1.  Hence the jenkins-bot record known to virt1000 is still lacking the email field and thus Gerrit thinks jenkins-bot has no email.


This is thus blocked until the virt1 -> virt1000 LDAP replication is fixed.
Still failing :(

https://integration.wikimedia.org/ci/job/mwext-VisualEditor-sync-gerrit/9/console
I've manually updated the database until LDAP gets back in sync. You *should* be able to push now.
Gerrit still believe that jenkins-bot user does not have any email address despite the address being shown in virt0 LDAP.

The suspect is that the LDAP replication to virt1000 is broken and that is the server Gerrit is using as a primary.

Whenever Gerrit learns about jenkins-bot user, the script I wrote should be able to push its change.


The last build I triggered ( https://integration.wikimedia.org/ci/job/mwext-VisualEditor-sync-gerrit/8/console ) yields:

7:14:47 remote: ERROR:  In commit c414977bcdbcbdf6331d9fe2e627bc0768695966
17:14:47 remote: ERROR:  committer email address jenkins-bot@wikimedia.org
17:14:47 remote: ERROR:  does not match your user account.
17:14:47 remote: ERROR:
17:14:47 remote: ERROR:  You have not registered any email addresses.
I have added a couple Jenkins slave scripts in integration/jenkins.git 

 bin/gerrit-sync-ve.sh
 bin/gerrit-sync-ve-push.sh

That would update the VisualEditor on a local copy of mediawiki/extensions.git

Then had to get a jenkins-bot@wikimedia.org email address registered and assigned to the jenkins-bot Gerrit user.


The job mwext-VisualEditor-sync-gerrit still needs to be triggered by Zuul on postmerge.  That is an easy change though. Will do whenever I am sure the job is working properly.
Change 107862 merged by jenkins-bot:
mwext-VisualEditor-sync-gerrit

https://gerrit.wikimedia.org/r/107862
Change 107862 had a related patch set uploaded by Hashar:
mwext-VisualEditor-sync-gerrit

https://gerrit.wikimedia.org/r/107862
Change 107853 merged by Andrew Bogott:
contint: invoke gerrit-sync-ve-push.sh as jenkins

https://gerrit.wikimedia.org/r/107853
Change 107853 had a related patch set uploaded by Hashar:
contint: invoke gerrit-sync-ve-push.sh as jenkins

https://gerrit.wikimedia.org/r/107853
Change 107841 merged by jenkins-bot:
Script to sync VisualEditor in mediawiki/extensions.git

https://gerrit.wikimedia.org/r/107841
Change 107841 had a related patch set uploaded by Hashar:
Script to sync VisualEditor in mediawiki/extensions.git

https://gerrit.wikimedia.org/r/107841
Change 107575 abandoned by Hashar:
beta: pull VisualEditor individually

Reason:
Per Chad, will use a Jenkins job to update mediawiki/extensions.git

https://gerrit.wikimedia.org/r/107575
Change 107574 abandoned by Hashar:
unregister VisualEditor (replication broken in Gerrit)

Reason:
Per Chad, will use a Jenkins job to update mediawiki/extensions.git

https://gerrit.wikimedia.org/r/107574
The patches above:

1) unregister VisualEditor from mediawiki/extensions.git since it is broken anyway
2) make the wmf-beta-autoupdater script to use git pull to refresh the repository
Change 107575 had a related patch set uploaded by Hashar:
beta: pull VisualEditor individually

https://gerrit.wikimedia.org/r/107575
Change 107574 had a related patch set uploaded by Hashar:
unregister VisualEditor (replication broken in Gerrit)

https://gerrit.wikimedia.org/r/107574
(In reply to comment #29)
> (In reply to comment #28)
> > We need to do this as a post-merge job in Jenkins for updating the meta-repo.
> > The Beta config should be able to remain as-is.
> 
> I am not sure we could do a post-merge job since Zuul does not support
> triggering a job according to a project wildcard such as
> mediawiki/extensions/*
> 

We don't need to for all repos. Just VisualEditor since it's broken. So we'd adjust the VE zuul/jenkins config to update mediawiki/extensions.git after VE merges.

> 
> I thought we could adapt the 6 minutes wmf-beta-autoupdater.py script, make
> it
> fetch the list of extensions generated at:
> https://gerrit.wikimedia.org/mediawiki-extensions.txt  then do a git
> submodule
> add on all of them and then update them all.

Ew. I'd rather keep everything else as it is, keep the workaround to one place (the VE zuul/jenkins config) until the upstream fix takes place. No need to change our infrastructure.
(In reply to comment #28)
> We need to do this as a post-merge job in Jenkins for updating the meta-repo.
> The Beta config should be able to remain as-is.

I am not sure we could do a post-merge job since Zuul does not support triggering a job according to a project wildcard such as mediawiki/extensions/*


I thought we could adapt the 6 minutes wmf-beta-autoupdater.py script, make it fetch the list of extensions generated at: https://gerrit.wikimedia.org/mediawiki-extensions.txt  then do a git submodule add on all of them and then update them all.
We need to do this as a post-merge job in Jenkins for updating the meta-repo. The Beta config should be able to remain as-is.
Assigning to self and moving to CI
The root cause is that there are two Gerrit projects being named VisualEditor and there is a bug in Gerrit that get it confused about that and break the automatic update of mediawiki/extensions.git

To restore automatic update, we would need to register the extensions locally by iterating over `gerrit ls-projects -p mediawiki/extensions/` and then use git `submodule update --init` as we did previously.
Re-opening rather than having a fork in bug 59758.
*** Bug 59758 has been marked as a duplicate of this bug. ***
happened again, see bug 59758
(In reply to comment #21)
> Does anybody plan to investigate on this ticket? 
> Or is this "working for us" right now? 
> 
> Wondering if this should still be open, and what's the way forward.

The problem was that there was more than one git repos on gerrit called "VisualEditor" (namely, mediawiki/extensions/VisualEditor.git and VisualEditor.git with its subsidiaries VisualEditor/core.git, VisualEditor/plugins/<foo>.git etc.). We created the other repos to move the code out of MW and make VE properly stand-alone and shippable, but thought we have split the code, we hadn't yet moved the core of VE into the new repo).

As a quick hack, Chad deleted the extra repos, which seems to have fixed everything, which means the issue is fixed (and has a known cause), but this isn't sustainable in the longer term as we will likely want to actually do the repo split some time soon (though we could work around the restriction on repo names)…

Marking as "FIXED", but it's more like "AVOIDED AT SOME COST".
Does anybody plan to investigate on this ticket? 
Or is this "working for us" right now? 

Wondering if this should still be open, and what's the way forward.
VisualEditor is finally working. I hope. I pray.
I'm beginning to think this thing is totally broken and a waste of time to use.
Sorry DataTypes was dirty in my local copy. That caused git to not update the remaining extensions.  It chokes currently on:


Cloning into 'ValueFormatters'...
remote: Counting objects: 4, done
remote: Finding sources: 100% (4/4)
remote: Getting sizes: 100% (3/3)
remote: Total 4 (delta 0), reused 4 (delta 0)
Unpacking objects: 100% (4/4), done.
Submodule path 'ValueFormatters': checked out 'b466dde64555d82fcefcdd0b1fe838de2e3acada'
fatal: Needed a single revision
Unable to find current revision in submodule path 'ValueParsers'
*** Bug 51635 has been marked as a duplicate of this bug. ***
*** Bug 48893 has been marked as a duplicate of this bug. ***
Change 73736 merged by Hashar:
update VisualEditor to latest master

https://gerrit.wikimedia.org/r/73736
Change 73736 had a related patch set uploaded by Hashar:
update VisualEditor to latest master

https://gerrit.wikimedia.org/r/73736
I hate life.
Got broken again a couple hours ago:

*   ac6c10d - (origin/master, origin/HEAD) Merge "Bind listener to key...
|\  
| * 31104d5 - Bind listener to keyup to capture arrows & better ma...
* |   877463e - (HEAD) Merge "Add hooks and classes, initially to s...

which shows HEAD not pointing to the same commit as origin/HEAD :(
Worked around (decreasing priority), but keeping this open as it might bite us again (as bug 49906 is still open).
I fixed it before.

Now I've fixed it once again.

This is annoying.
Setting Importance etc since today is "D Day" for Visual Editor on ENWiki. Would be great to have betalabs running up to date VE on the day we roll out to a large audience :)
VisualEditor is lagged out again:

$ cd extensions
$ git remote update
$ git rebase
$ git submodule update --init VisualEditor
Submodule path 'VisualEditor': checked out '46c3d48ba7779254581bfad017c0804588a1983d'
$

Then looking at HEAD (that is the checked out version above) and origin/master:

$ git log --oneline HEAD..origin/master
c331c19 Merge "Minor performance optimization and cleanup in FocusableNode"
daa83d2 Minor performance optimization and cleanup in FocusableNode
a08da9f Make node resizing happen inside onAttributeChange
f8d7314 Merge "Simplify ve.ce.ResizableNode by removing code for 'transition' which is not used anyway"
87667bd Merge "Make toolbar look correct with non-standard browser font size settings"
b0b832a Make toolbar look correct with non-standard browser font size settings
59e7a7b Simplify ve.ce.ResizableNode by removing code for 'transition' which is not used anyway
$



$ git rev-parse origin/master
c331c1980ec37a4d6926f138fd1e81879d5db299
$ git rev-parse HEAD
46c3d48ba7779254581bfad017c0804588a1983d
$
http://en.wikipedia.beta.wmflabs.org/wiki/Special:Version

VisualEditor (Version 0.1.0)	(4b74101)
19:00, 20 June 2013

:-)
I have no idea what went wrong :/

Filled bug 49906 to monitor such issues.

Thank you Chad!
Fixed.

gerrit> select * from submodule_subscriptions where submodule_project_name like '%VisualEditor%';
 submodule_project_name | submodule_branch_name | super_project_project_name | super_project_branch_name | submodule_path
 -----------------------+-----------------------+----------------------------+---------------------------+---------------
 VisualEditor           | refs/heads/master     | mediawiki/extensions       | refs/heads/master         | VisualEditor
(1 row; 2 ms)

gerrit> update submodule_subscriptions set submodule_project_name = 'mediawiki/extensions/VisualEditor' where submodule_path = 'VisualEditor';
UPDATE 1; 2 ms

gerrit> select * from submodule_subscriptions where submodule_project_name like '%VisualEditor%';
 submodule_project_name            | submodule_branch_name | super_project_project_name | super_project_branch_name | submodule_path
 ----------------------------------+-----------------------+----------------------------+---------------------------+---------------
 mediawiki/extensions/VisualEditor | refs/heads/master     | mediawiki/extensions       | refs/heads/master         | VisualEditor
(1 row; 1 ms)

Was the extension at one point pointing to the wrong repository? Will file a bug upstream, since I guess this should've updated itself when the submodule changed.
Actually moving this bug under 'git/gerrit'.
On beta, origin/master points to 5add8cc4c0ea5b305525c30d8af5261406e5d355 which mean VisualEditor remote is not being fetched when running 'git pull && git submodule update --init'.
The mediawiki/extensions.git is not updating VisualEditor extension:


$ git submodule update --init VisualEditor
remote: Counting objects: 3887, done
remote: Finding sources: 100% (5930/5930)
remote: Getting sizes: 100% (1370/1370)
remote: Compressing objects:  21% (288/1370)
remote: Total 5930 (delta 3846), reused 5495 (delta 3829)
Receiving objects: 100% (5930/5930), 2.95 MiB | 622 KiB/s, done.
Resolving deltas: 100% (4091/4091), completed with 275 local objects.
From https://gerrit.wikimedia.org/r/p/mediawiki/extensions/VisualEditor
   65602e1..ed1c06e  master     -> origin/master
Submodule path 'VisualEditor': checked out '5add8cc4c0ea5b305525c30d8af5261406e5d355'


$ cd VisualEditor
$ git rev-parse HEAD origin/master
5add8cc4c0ea5b305525c30d8af5261406e5d355
ed1c06ee6b36851ba1f6e3a68d0584da4c20be46

HEAD should points to the same as origin/master.


Parsoid is updated though:

$ git rev-parse HEAD origin/master
bf8d3dff339e5b3e10f0667850d0114f49db131c
bf8d3dff339e5b3e10f0667850d0114f49db131c


Moving the bug under Wikimedia > Git/Gerrit . Will poke Chad / Sam about it.
In this edit: https://fr.wikipedia.org/w/index.php?diff=94100781 VisualEditor seems to have emptied a reference (the one containing "Maxime Pargaud" as author of the cited reference).

--------------------------
**Version**: unspecified
**Severity**: normal
This is now fixed (Parsoid selser issue); sorry!
VisualEditor kissed a girl and liked it. Oh boy, do our products grow up fast.

Oh wait, it ate a reference? Bad bad editor. Discipline... Slacker!
See https://en.wikipedia.org/wiki/User:Mdennis_%28WMF%29/sandbox for the result of four different attempts to insert images. Each one resulted in something like https://en.wikipedia.org/w/index.php?title=User%3AMdennis_%28WMF%29%2Fsandbox&diff=560491469&oldid=560491343

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed. Sorry about this.
https://en.wikipedia.org/w/index.php?title=McIntosh_%28apple%29&diff=560394609&oldid=560264020

--------------------------
**Version**: unspecified
**Severity**: normal
I'm going to speculatively mark this as fixed; we haven't seen any further issues with this and there's no steps to repeat - even when we undertake edit conflicts it still doesn't occur.

Please re-open if you find that it does recur - and if so, any information about how to get it to trigger would be great, of course.
(In reply to comment #1)
> https://en.wikipedia.org/wiki/Wikipedia:
> Village_pump_(technical)#VisualEditor_-_A.2FB_test_launch_on_18_June
> 
> indicates that this might be caused by edit conflicts

I can't replicate this, although of course it is difficult to realistically replicate edit conflicts.
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#VisualEditor_-_A.2FB_test_launch_on_18_June

indicates that this might be caused by edit conflicts
Have a page with a <references /> block but no <ref>s and you get:

| Uncaught TypeError: Cannot call method 'connect' of null 

This is bad.

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed with gerrit 67924, which is now merged into master and will go out with wmf8 from Thursday.
https://en.wikipedia.org/w/index.php?title=Vidin&diff=559844598&oldid=559844102 shows several dirty diff issues, including spurious template bars, space changes, and corrupt links.

However, this bug is specifically about the HTML comments that are dropped, "the name of a location map as per http://en.wikipedia.org/wiki/Template:Location_map" and "the position of the pushpin label: left, right, top, bottom, none".  These comments often have important messages to other editors, so they can not be stripped.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49603
https://bugzilla.wikimedia.org/show_bug.cgi?id=49655
verified in betalabs and test2 - HTML comments are preserved for both cases  - generally and, specifically, in transclusions.
verified in betalabs - HTML comments are preserved both - generally and, specifically, in transclusions.
That's a separate bug, will raise as such.
Not sure if it's the same thing, but I just did this today http://it.wikipedia.org/w/index.php?title=Google&diff=59622535&oldid=59377529 and it discarded commented text which, as noted above, should be there for a reason :)
This is now fixed; as an example, see https://en.wikipedia.org/w/index.php?title=Bleak_House&diff=560362551&oldid=560338958 as an edit made with VisualEditor that leaves the comments in the templates as they were.
Can't reproduce in master. The comment appears in the template dialog and can be edited. With experimental code disabled the template is completely untouched.
(In reply to comment #3)
> See also bug 49655 and this (where Ssastry discusses it): 
> Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox

The place for "see also" bugs is the "see also" section at the top right of the bug - have put it there. :-) Bug 42124 is not relevant.
[[Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox]]

See also bug 42124.
See also bug 49655 and this (where Ssastry discusses it): 
Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox
Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?). Ed, can you confirm at your end if this is a DM issue or a Parsoid one?

I was able to edit around an HTML comment without altering it inline (as expected) in https://www.mediawiki.org/w/index.php?title=VisualEditor:TestComments&diff=712245&oldid=712244 - but changes to the HTML comment in the second template fail to be detected as a change (?). Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?) merged with the following transclusion.
At the time of this discussion by VE developers, 
[[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE.

Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: 
[[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. 

If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. 

If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? 

Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.
Adding a file/media fails with wrong wikicode.

This wikicode is created, see URL:

[[undefined|link=https://commons.wikimedia.org/wiki/File:CV.03326.jpg|right|framed|424x275px]]

--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://test.wikipedia.org/w/index.php?title=User:Raymond/image&diff=174461&oldid=174460
*** Bug 50021 has been marked as a duplicate of this bug. ***
(In reply to comment #10)
> What about commend 5 and comment 6?

Sorry, yes; created as bug 49849.
What about commend 5 and comment 6?
This is partially fixed in gerrit 69581 which we will deploy this afternoon.

However, the link issue is still not fixed, thus (in the example in comment 0) we will now get:

[[File:CV.03326.jpg|link=https://commons.wikimedia.org/wiki/File:CV.03326.jpg|right|framed|424x275px]]

… instead of:

[[File:CV.03326.jpg|right|framed|424x275px]]

… which is bad, but nothing like as terrible as it was. Forking that off to a new bug, bug 49844, and marking this as fixed.
From bug 49829 comment 0:

| This is the DOM returned by the VE after inserting a new thumbnail:
| <figure typeof="mw:Image/Frame" class=" mw-halign-right">
| <a rel="mw:thumb" href="http://commons.wikimedia.org/wiki/File:Apples.jpg">
| <img src="http://upload.wikimedia.org/wikipedia/commons/thumb/e/ee/Apples.jpg/
|   100px-Apples.jpg" width="100" height="150" resource="undefined"></a></figure>
| 
| Note the 'undefined' in the resource attribute. The resource is the image
| target, so we notice that the link and the image named 'undefined' differ and
| serialize as
| [[undefined|link=http://commons.wikimedia.org/wiki/File:Apples.jpg|thumb]].
*** Bug 49829 has been marked as a duplicate of this bug. ***
**winne2i** wrote:

The same on plwiki: https://pl.wikipedia.org/w/index.php?diff=36790309
("prawo" means "right" in polish, "ramka" means "frame")
(In reply to comment #3)
> I get the same type of error:
> <http://pt.wikipedia.org/w/index.
> php?title=PLoS_ONE&diff=36119075&oldid=34872658>

On this example there is also something else: I think the code "direita,right" should be just "direita" or "right".
*** Bug 49795 has been marked as a duplicate of this bug. ***
I get the same type of error: <http://pt.wikipedia.org/w/index.php?title=PLoS_ONE&diff=36119075&oldid=34872658>
For additional examples, if that will be helpful, see:
http://en.wikipedia.org/w/index.php?title=User%3AMdennis_%28WMF%29&diff=560023092&oldid=541758155

http://en.wikipedia.org/w/index.php?title=Keshi_%28demon%29&diff=559979773&oldid=559978871
Roan, do we get the typeof:/etc. wrong at our end, or is this a Parsoid issue?
--------------------------
**Version**: unspecified
**Severity**: normal
Merged and we'll get this out on Monday so we can test it.
Related URL: https://gerrit.wikimedia.org/r/68712 (Gerrit Change Iddb9eb9c64b55b25445ddf9e474d312b685978a6)
(In reply to comment #1)
> All events in Edit_5563071 appear to have the same value for
> event_pageViewSessionId (2147483647).

It was simply overflowing its column type (int). I set it to 'bigint' and it's fine now.

It's odd that we haven't run into this before! It's because we ordinarily convert timestamps to byte strings, like the rest of MediaWiki. This is the first time we've tried to save timestamps as integers. The int type is good for values between +/- 2,147,483,647, which has been adequate for all other use cases.

> When fixing, we will want to bump the event_version value.

Well, since this did not require a deployment, I instead moved all existing rows in the 'Edit' table to 'z_Edit_5563071'. Any events that go into the current 'Edit_5563071' will be fine.
All events in Edit_5563071 appear to have the same value for event_pageViewSessionId (2147483647).

When fixing, we will want to bump the event_version value.
--------------------------
**Version**: unspecified
**Severity**: normal
Merged and we'll get this out on Monday so we can test it.
Related URL: https://gerrit.wikimedia.org/r/68712 (Gerrit Change Iddb9eb9c64b55b25445ddf9e474d312b685978a6)
Related URL: https://gerrit.wikimedia.org/r/68712 (Gerrit Change Iddb9eb9c64b55b25445ddf9e474d312b685978a6)
Coordination card on Trello: https://trello.com/c/xCkMEAY0

Reminder: anonymous editors are excluded from logging (we'll instrument the edit funnel for anons in July in preparation for the global launch).
Needs also https://meta.wikimedia.org/wiki/Schema:Edit to be updated first, of course. :-)
I have edited the page w:cs:Banolo Blahnik and after saving HTML code was left at the page. See this revision: https://cs.wikipedia.org/w/index.php?title=Manolo_Blahnik&oldid=10415532

--------------------------
**Version**: unspecified
**Severity**: critical
*** Bug 50049 has been marked as a duplicate of this bug. ***
Yes, <https://bugzilla.wikimedia.org/show_bug.cgi?id=49701>. It is apparently fixed.
Did you open a new bug? If so could you please link it? I have someone with a similar issue.
Ah, sorry, I missed the tag. I think you should; this is certainly something different than what was happening here.
It has the VisualEditor tag and was reported in the feedback page <http://pt.wikipedia.org/w/index.php?title=Wikip%C3%A9dia%3AEditor_Visual%2FComent%C3%A1rios&diff=36129760&oldid=36054006>. Should I open a new bug?
It's not, this bug had different symptoms, and that edit doesn't even seem to have been made using VE.
Not sure if this is related: <https://pt.wikipedia.org/w/index.php?title=CMM_-_Canal_Meninos_e_Meninas&diff=36129698&oldid=36129686>, but that edit was made today.
To update, this bug was in an overly-keen Operations cacheing server configuration change which broke the caches' responses completely (and corrupted every response to not be what we want).

Sorry everyone for the disruption; we've now found (and killed) this problem, and re-enabled VisualEditor as before.
It looks like an update to the libraries Parsoid depends on might have caused this issue. It would have been visible in the diff, but since the user is not seeing that by default any more few noticed.

Parsoid is rolled back, so this issue should be fixed.
**ignatus31oct** wrote:

(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb):

http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653

I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled.

When I entered enough and pushed "Save", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed "Save page", but after a time I've seen.........
Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for. I'm going to go round and notify people now :)
Related URL: https://gerrit.wikimedia.org/r/68667 (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa)
Related URL: https://gerrit.wikimedia.org/r/68667 (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa)
A note; I've just spoken to James F; a fix to this is highest-priority. I'm deeply sorry about this (and think I speak for James and the VE team on that front, too).
(In reply to comment #3)
> Issue started ~ 11:37 UTC today per
> https://en.wikipedia.org/w/index.
> php?namespace=&tagfilter=visualeditor&title=Special%3ARecentChanges

If that's really accurate *maybe* this has some relevance (posting here in case someone who knows more can do something with it):

Jun 14 11:34:59 cerium puppet-agent[22506]: (/Stage[main]/Role::Cache::Parsoid/Varnish::Instance[parsoid-frontend]/Exec[load-new-vcl-file-frontend]) Triggered 'refresh' from 2 events
...
Jun 14 11:34:59 cerium puppet-agent[22506]: (/Stage[main]/Role::Cache::Parsoid/Varnish::Instance[parsoid-backend]/Exec[load-new-vcl-file]) Triggered 'refresh' from 2 events
Yes, first time I tried the new VisualEditor. My user page is live and I still left the HTML as an example. Tried a few more times to blank page with VE, it is real ugly. HTML leaks on HTML leaks on HTML leaks with each new save, http://www.mediawiki.org/w/index.php?title=User%3AHutchy68&diff=711244&oldid=711236
This is occurring fairly widely and I have a lot of reports. Moving it up to highest priority (because frankly something being broken that is already deployed > anything we might /want/ deployed).
Issue started ~ 11:37 UTC today per https://en.wikipedia.org/w/index.php?namespace=&tagfilter=visualeditor&title=Special%3ARecentChanges
More of this:

https://de.wikipedia.org/w/index.php?title=Oper_K%C3%B6ln&curid=2386780&diff=119548868&oldid=118354900

https://test.wikipedia.org/w/index.php?title=User:Raymond/image&diff=174443&oldid=174442
*** Bug 49573 has been marked as a duplicate of this bug. ***
Should be user interface language.

--------------------------
**Version**: unspecified
**Severity**: major
This is resolved in the latest version

I3bcf924a3e179cb65f19e833277a39dfd3dad8bd
This is to restore the pre-December save workflow (Save dialog triggered, with Show Changes within it).

The "Review and Save" button in the toolbar will be replaced with "Save..." which takes you straight to the Save dialog (with the existing save box, minor edit, watch and disclaimer/legal)

Inside the Save dialog there should also be a "Review changes" button that triggers the wikitext diff as a dismissible dialog; whilst we're here, remove the Parsoid "Something looks wrong" button entirely, and replace the "Looks good to me" button with a normal close one.

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed and will go out with wmf7 from next Thursday.
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://pl.wikipedia.org/w/index.php?title=Ukryta_sie%C4%87&diff=36500666&oldid=36500549
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50720
I believe this is now fixed.
Can't reproduce in master.
1. Create a page that has a heading at the very beginning
2. Open it in VE
3. Put the cursor at the beginning of the heading and press Enter
4. An empty heading appears above
5. Use arrow keys or mouse to move the cursor into this empty heading
6. See an error in the console
7. Type into the heading
8. See one error per key press in the console

In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly.

--------------------------
**Version**: unspecified
**Severity**: normal
This is not an issue anymore.
1. Create a link using the link inspector button
2. Note that autocomplete feature doesn't appear
3. Hit save and note that link is stored as an external link "[Foo Foo]"

Using the keyboard shortcut, however, works fine (Ctrl+K)

--------------------------
**Version**: unspecified
**Severity**: normal
Merged into master; will go out with wmf5.
Related URL: https://gerrit.wikimedia.org/r/63850 (Gerrit Change Icda3305e422bedaf0d490b8fbe51f55b8c8e79e8)
Looks like the format for providing toolbar options was changed, so the MW override isn't working. As a result we're rendering a link button instead of an mwLink. Ctrl+K works because the mwLink is still registered with the command registry (should commands work without the button being rendered?)
1. Go to a page with a bullet or a numbered list. Edit with VisualEditor.

2. Place the cursor at the end of an item of the list. Press enter to create a new item. A new item has been created and the cursor is at the beginning, ready to receive input.

3. Type something.

EXPECTED

You are typing in the new line.


ACTUAL OUTCOME 

A pawn appears at the end of the previous line and there you can also find the text you are typing. If you press Enter again the mess continues to grow. There is no way to clean the scene of the crime. The only way is to jump to "Edit source".

This happens at least at mediawiki.org with Firefox 22.0a2 (2013-05-07).

--------------------------
**Version**: unspecified
**Severity**: major
Solid like a rock! 

https://www.mediawiki.org/w/index.php?title=User%3AQgil%2FSandbox&diff=710845&oldid=710844

Thank you very much. The bug I filed has been fixed. Resolving accordingly.
@Quim: Are you still able to reproduce this problem? I can't.
I'm getting similar behaviour on en.wp if you use the slug at the beginning of the article, then change your mind and try to delete the text you've inserted. General behaviour with slug lines?
Problems in IndentationAction that Ed it working on right now.

--------------------------
**Version**: unspecified
**Severity**: major
Code is merged into wmf4.
Related URL: https://gerrit.wikimedia.org/r/63485 (Gerrit Change I5ce0c385214f30c5e5c66b5b5b755c9937267cd0)
*** Bug 48069 has been marked as a duplicate of this bug. ***
Problem here was with surface fragments and translate range in the data model. The ranges were getting out of sync, so after (un)indenting the first item, and subsequent ones would fail.
Fixed by https://gerrit.wikimedia.org/r/#/c/63394/
--------------------------
**Version**: unspecified
**Severity**: critical
verified for any page in http://en.wikipedia.beta.wmflabs.org/
using Chrome Version 26.0.1410.65 MAC OS X 10.8.5
Fixed in https://gerrit.wikimedia.org/r/63413. Will close after it gets merged.
Related URL: https://gerrit.wikimedia.org/r/63413 (Gerrit Change I8d7aeffc8166487806e3489b054f508c5e9418ff)
By stepping back through the commit log I've isolated it down to this commit by Inez: https://gerrit.wikimedia.org/r/#/c/63223/1

Assigning the bug to him.
1. Hitting return inside a list item cases the paragraph to split, not the listitem (that's what shift-return should do)
2. Unlisting the two line list item created in 1. causes the second line to completely disappear
3. Listing two paragraphs only lists the first one, and adds an extra paragraph between them
* Create a page starting with a list ('* list' is sufficient)
* Enter some text into the slugged paragraph above the list, then delete it with backspaces
* The paragraph now doubles in height, inspecting the DOM you see a <br> has appeared from nowhere:
  <p><br><span slug></span></p>

Also this paragraph gets sent to Parsoid resulting in an extra line break.

Removing the text by using undo doesn't result in this bug.

--------------------------
**Version**: unspecified
**Severity**: normal
This is fixed with my refactor to handleDelete method.
Deeming that this is now fixed.
(In reply to comment #1)
> We are not placing slugs around lists anymore so this bug can't be
> reproduced, however I know what was root cause of it (native handling of 
> deletion) and I'm working on it now.

Is this bug still valid? I can't reproduce now, using a thumb image (rather than a list) to create the block item.
We are not placing slugs around lists anymore so this bug can't be reproduced, however I know what was root cause of it (native handling of deletion) and I'm working on it now.
Lately, I've been noticing random pawn characters at the end of paragraphs all over English Wikipedia. The source of these pawns was a mystery to me until I tried using the Visual Editor today. As soon as I started typing in the editor, it inserted a pawn at the end of the line I was editing.

The pawn in question is the white pawn, typically the first piece to move in a game of chess. This makes me wonder if perhaps the visual editor has become sentient and is trying to initiate a friendly game with the editor. Unfortunately, playing chess on Wikipedia was banned in 2006 as a violation of WP:NOT,[1] so it's probably a good idea if we eliminate this sort of behavior.

Actual character: ♙
Unicode value: 2659
UTF-8 value: E2 99 99
Browser: Firefox

1. https://en.wikipedia.org/wiki/Wikipedia:Miscellany_for_deletion/Wikipedia:Chess_championship

--------------------------
**Version**: unspecified
**Severity**: critical
verified for any page https://test2.wikipedia.org/

using chrome Version 26.0.1410.65 and firefox 25.
Confirming that this is fixed in master and wmf4; deployed in the normal deployment train.
(In reply to comment #4)
> Pawn insertion from May 3:
> https://en.wikipedia.org/w/index.
> php?title=Rubik%27s_360&diff=553360286&oldid=540708795

These kind of issues are precisely why there's a mandatory pre-save diff for users to read and agree it's fine. If there's a pawn inserted into the article, you're not meant to press save!
(In reply to comment #1)
> Steps to reproduce:
> 1. Log in and turn on the visual editor.
> 2. Go to a random article like "Sundance Meadows Airport"
> 3. Click the Edit tab
> 4. After the cursor appears on the page, type a character
> 
> You will then see a white pawn at the end of the line of text you are
> editing.

Thanks; have updated the bug report accordingly.

> Interestingly, it only seems to happen on articles that insert the cursor
> into a blank line at the top of the article. I'm not sure what determines
> that behavior, but it seems to be the behavior for the vast majority of
> en.wiki articles.

That is bug 47790. It's not really a blank line in the document; it's the "potential" place to insert some new content, until you click into it and insert some, at which point it's whatever you type in. But it's not really very obvious to users what it is.

> The only article I haven't been able to reproduce the bug at so far
> is Lalage:
> https://en.wikipedia.org/wiki/Lalage

A block-level slug only appears if the page starts with a template or other kind of generated content; any page that starts with one will get one (hence the pervasiveness). The alternative is not giving users the ability to insert content before a template if it happened to be at the start of a document, which would be even more confusing.
Can't reproduce this is master. It may have already been fixed, pending release?
**fran** wrote:

Pawn ahoy: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/VisualEditor.git;a=blob;f=modules/ve/ce/ve.ce.Surface.js;h=7ad07c54370cb585ca264f78872fee0c83bd77a5;hb=HEAD#l1009

"git blame" says this section was worked on by Christian Williams, so maybe he'll know what's going on?
Pawn insertion from May 3:
https://en.wikipedia.org/w/index.php?title=Rubik%27s_360&diff=553360286&oldid=540708795
Confirmed in Safari and Chrome as well.
I also can't reproduce the bug in my user sandbox:
https://en.wikipedia.org/wiki/User:Kaldari/sandbox
Steps to reproduce:
1. Log in and turn on the visual editor.
2. Go to a random article like "Sundance Meadows Airport"
3. Click the Edit tab
4. After the cursor appears on the page, type a character

You will then see a white pawn at the end of the line of text you are editing.

Interestingly, it only seems to happen on articles that insert the cursor into a blank line at the top of the article. I'm not sure what determines that behavior, but it seems to be the behavior for the vast majority of en.wiki articles. The only article I haven't been able to reproduce the bug at so far is Lalage:
https://en.wikipedia.org/wiki/Lalage
Go to http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services
Put the cursor somewhere in the text.
Type "Enter" 2 times.
Type "Up".
Click Bullet List
Type Enter
Type Up
Type Delete

Wild pawn appears.

--------------------------
**Version**: unspecified
**Severity**: normal
Merged into master; will be deployed from Monday.
(In reply to comment #3)
> Related URL: https://gerrit.wikimedia.org/r/63102 (Gerrit Change
> If22d9b904b8861e24d56944d791545635b2e4254)

Merged.
Related URL: https://gerrit.wikimedia.org/r/63102 (Gerrit Change If22d9b904b8861e24d56944d791545635b2e4254)
I can reproduce in Firefox and Chrome if you forwards-delete or insert characters. It appears that this is because when you clear out the <li> (return at the end of the list) it doesn't check that the <ul> is empty, so you get a node inside the <ul>.

Note that in casual testing this 'worked', because backspace deletes the pawn and <ul> together. Bother.
Same when entering text instead of Delete
Go to http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services
Put the cursor somewhere in the text.
Type "Enter" 2 times.
Type "Up".
Type "Delete".
Click Bullet List
Type q
Type Left
Type Enter
Type Up
Type Delete

Wild pawn appears.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #3)
> James, do you mean the pawn does not appear for you?
> I tried just now on wikipedia.org, the pawn appears.
> Please note that the correct instructions are those in Comment 1.
> 
> Ubuntu 2012.10, Firefox 20.0

I didn't say it doesn't appear in production, I said it doesn't appear in master; had I been unable to reproduce, I would have said. :-)

I think this is fixed through changes made in master but not deployed, but bug 47795 appears to have broken itself; I'll close this and mark that as re-opened.
James, do you mean the pawn does not appear for you?
I tried just now on wikipedia.org, the pawn appears.
Please note that the correct instructions are those in Comment 1.

Ubuntu 2012.10, Firefox 20.0
I can reproduce bug 47795 in master in Firefox, but not the pawn issue; all works in Chrome, as normal.
Sorry, ignore the first Delete step above.

Steps should read:

Type "Enter" 2 times.
Type "Up".
Click Bullet List
Type q
Type Left
Type Enter
Type Up
Type Delete
1. Open http://en.wikipedia.org/wiki/Enterprise_content_management
2. Add a space and remove it
3. Press "Review and Save"
4. Wait forever.

The text stays greyed out and nothing changes. Changes can't be saved.
Same for any article I tried.

Ubuntu 2012.10, Firefox 20.0

--------------------------
**Version**: unspecified
**Severity**: blocker
*** This bug has been marked as a duplicate of bug 48181 ***
Bug is gone indeed.
Can't reproduce in Chrome or FF. I see other bugs (which I think have been filed elsewhere) but nothing that stops me from reviewing.
Ed, marking this as immediate for when you wake.
Error: toDomElements() failed to return an array when converting element of type alienBlock @ http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cicons-raster%7Cext.visualEditor.viewPageTarget.icons-raster%7Crangy%7Cunicodejs.wordbreak&skin=vector&version=20130506T190432Z&*:130
Uncaught Error: toDomElements() failed to return an array when converting element of type alienBlock load.php:4092
> ve.dm.Converter.getDomElementsFromDataElement load.php:4092
> ve.dm.Converter.getDomSubtreeFromData load.php:4629
> ve.dm.Converter.getDomFromData load.php:4444
> ve.init.mw.ViewPageTarget.swapSaveDialog load.php:101
> ve.init.mw.ViewPageTarget.showSaveDialog load.php:99
> ve.init.mw.ViewPageTarget.onToolbarSaveButtonClick load.php:87
> proxy load.php:10
> ve.EventEmitter.emit load.php:11
> ve.ui.ButtonWidget.onClick load.php:8696
> proxy load.php:10
> jQuery.event.dispatch load.php:45
> elemData.handle.eventHandle
(In reply to comment #0)
> 1. Open http://en.wikipedia.org/wiki/Enterprise_content_management
> 2. Add a space and remove it
> 3. Press "Review and Save"
> 4. Wait forever.
> 
> The text stays greyed out and nothing changes. Changes can't be saved.
> Same for any article I tried.
> 
> Ubuntu 2012.10, Firefox 20.0

Confirmed on Firefox 20, Mac OS X.
What does the console error log say?
Multiple list items don't indent properly.

Steps to duplicate the bug:

Write a couple of lines. Mark all the lines and click the "list" button - producing bullet-list. 

If the indent button is clicked when the cursor is on a single list item, that item will be indented. However, if you mark a couple of list items and indent them at once, the indentation is jumbled: some of the items are indented and some double-indented (and the item above the selection seems to be indented as well)

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 48390 ***
I am entirely not sure if I am in the right direction here, but I figured I'd share my intuition --

I am thinking this is some bug with the definition of child-nodes vs same-level nodes, which results in indentation as if some of the nodes selected are parents.

There was a change in ve.ce.BranchNode.js and ve.ce.ContentBranchNode.js regarding child nodes -- could this have caused it?


+ve.ce.BranchNode.prototype.onModelUpdate = function ( transaction ) {
+       this.emit( 'childUpdate', transaction );

And there are a couple of other changes in the ve.ce.BranchNode.prototype.onSplice method. Perhaps something went wrong with the definition of what is a child and what is a same-level node, which then jumbles up the hierarchy of the list?

(I do hope I am in the right direction here, I thought I'd share my thoughts)
Broken in master for Firefox but not in wmf3 - presumably we changed something in the last week that did this?
*that* was an amusing bug to find.

Tested on mediawiki.org.

Steps:

1. Write text in an ordered list item
2. Select some of the text
3. Hit "end"

Expected:

Cursor at end of line

Actual:

Cursor at end of line, text gone

I would *suspect* this is an easy bug, unmark it if it's not.

Found bug on Firefox 23 alpha 1

--------------------------
**Version**: unspecified
**Severity**: normal
*** Bug 48288 has been marked as a duplicate of this bug. ***
https://gerrit.wikimedia.org/r/63223 (Gerrit Change I7a8d6c474ecca5af02b72b6453c900ed61acea58) | change APPROVED and MERGED [by jenkins-bot]
Related URL: https://gerrit.wikimedia.org/r/63223 (Gerrit Change I7a8d6c474ecca5af02b72b6453c900ed61acea58)
*** Bug 48039 has been marked as a duplicate of this bug. ***
Whoops. :-)
See Parsoid bug 47998.

--------------------------
**Version**: unspecified
**Severity**: critical
As far as we can tell, this isn't reproducible in live, so I'm marking as INVALID; happy to re-open if we see this happen in the wild.
Argh, a mess - Roan, could you investigate?
Steps to reproduce problem:
1. Edit https://www.mediawiki.org/wiki/Git/Commit_message_guidelines in VisualEditor
2. Add some text
3. "Review and save"
4. "Something is wrong"
5. "Report problem"

Expected behaviour:
Make an http request somewhere and report back in the UI.

Actual behaviour:
No http request is made and UI is unresponsive.

console:
> Uncaught TypeError: Converting circular structure to JSON
> at:
> > mw.Target.prototype.reportProblem = function(message) {
> > var ...., report = { title: .., oldid: .., .. };
> > $.post(mw.config.get('wgVisualEditorConfig').reportProblemURL, {'data': JSON.stringify(report)}, function() {

debug:

var objs = [];
JSON.stringify(a, function (k, v) {
  var i;
  if (v === Object(v)) {
    i = objs.indexOf(v);
    if (i !== -1) {
      console.log('dupe at #' + i, v);
    }
    objs.push(v);
  }
  return v;
});
dupe at #66 
<p data-parsoid=​"{"dsr":​[0,139,0,0]​}​">​
"The "
<b data-parsoid=​"{"tsr":​[4,7]​,"dsr":​[4,24,3,3]​}​">​commit message​</b>​
" play an important role in revision control systems. They are the first thing other people will see of your commit."
</p>​

--------------------------
**Version**: unspecified
**Severity**: critical
Fixed in master.
Ah, because native DOM element objects have all kinds of "convenience" pointers like "firstChild", "children", "nextSibling", "paretNode", "ownerDocument", which all have the same as well, so its like a circular reference nightmare.
Related URL: https://gerrit.wikimedia.org/r/62811 (Gerrit Change Id807ccc6ff31d063be815ed4988cb35684adb76a)
This is caused by the linear data now contain DOM elements in alien nodes (and other nodes that store original HTML). We will need to pre-process the data before serialising. We already do this in the unit tests so shouldn't be too difficult.
@Ed: I suspect the circular reference is coming from inside the data model. Can you look into this?

See ve.init.mw.Target.js, method #reportProblem.
Currently we don't alert users that they're outing their IP when they save. This is a Bad Thing(tm).

--------------------------
**Version**: unspecified
**Severity**: critical
I see - wan't looking at main namespace.
Merged and will go out with wmf4.
(In reply to comment #4)
> mediawiki.org? I don't see it there.

Compare https://www.mediawiki.org/w/index.php?title=MediaWiki_1.21&action=edit with https://www.mediawiki.org/wiki/MediaWiki_1.21?veaction=edit in an isolated browser (e.g. Chrome Incognito).
mediawiki.org? I don't see it there.
(In reply to comment #2)
> Currently the extension doesn't let anon editors use it at all (
> $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've
> put in a fix for when we do.

Except for mediawikiwiki, where it's forced on for everyone, logged in or out, regardless of preference. :-)
Currently the extension doesn't let anon editors use it at all ( $skin->getUser()->getOption( 'visualeditor-enable' ) is required ), but I've put in a fix for when we do.
Related URL: https://gerrit.wikimedia.org/r/62143 (Gerrit Change Ib5c3284c646ebcc0a8cad0b02de559d7820e05a0)
1. Edit a page with an unordered list.

2. Delete all the text on the last line.

3. Press the <delete key>. The bullet should be erased.  Instead, it will
remain and the cursor will move to the end of the previous line.

4. down-arrow

5. down-arrow off of the empty line.

Turd appears in the empty line.

Very many arrow-key actions will produce the turd.

Firefox 20.0, linux.

--------------------------
**Version**: unspecified
**Severity**: normal
Actually those are two separated issues. One is about turds appearing and the other one is about bullet not being erased. So in my previous comment I referred to the first issue, and second issue is something that I'm working on now (as a part of broader refactoring to handle deletion operations).
I believe that this is fixed in master: https://gerrit.wikimedia.org/r/#/c/61055/
jQuery have WONTFIX'ed this bug (13821) so we'll have to work around.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
http://bugs.jquery.com/ticket/13821
(In reply to comment #5)
> (In reply to comment #0)
> > jQuery have WONTFIX'ed this bug (13821) so we'll have to work around.
> 
> Any link? http://bugs.jquery.com/report/13821 returns error.

http://bugs.jquery.com/ticket/13821 (in the see also field).
Another place we had to work around:
https://gerrit.wikimedia.org/r/#/c/62028/
(In reply to comment #0)
> jQuery have WONTFIX'ed this bug (13821) so we'll have to work around.

Any link? http://bugs.jquery.com/report/13821 returns error.
*** Bug 47860 has been marked as a duplicate of this bug. ***
Ed's code is merged and will be going out with the regular deployment train on Monday.
Related URL: https://gerrit.wikimedia.org/r/61180 (Gerrit Change I3df8f49b170c31da9610129d53cf8cb65dd5d5f8)
*** Bug 47712 has been marked as a duplicate of this bug. ***
This has reappeared (in live on hewiki and others) - if the page on load has bold annotation on some text, pressing the "bold" button doesn't remove bold but adds a second bold annotation (which can be removed, but not in a way that stops the text being bold).

--------------------------
**Version**: unspecified
**Severity**: major
Merged and deployed.
Roan fixing now.
Related URL: https://gerrit.wikimedia.org/r/60948 (Gerrit Change I77f00e63c8732420063b0453fede7f453083c913)
Make a selection that includes the first character, and press the access key for creating a link (Ctrl+K?). You'll get a JS error.

--------------------------
**Version**: unspecified
**Severity**: normal
Mysteriously works upon updating to the current HEAD.
I wanted to check this out, and I noticed that this fails (I reproduced the error) in Chrome and Firefox 20.x in Windows, but it works perfectly (no crash on first character) in my Firefox 20.x in Ubuntu.

Also, if it helps, here's the error I'm getting on Firebug:

Error: Error in Rangy Position module: Cannot get position for range [WrappedRange(<P>[4][<a href="sdjfh" titl]:0, <P>[4][<a href="sdjfh" titl]:0)]
https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cicons-raster%7Cext.visualEditor.viewPageTarget.icons-raster%7Crangy%7Cunicodejs.wordbreak&skin=vector&version=20130505T030747Z&*
Line 224

It seems it has something to do with the wordbreaks (??). Can there be a difference in wordbreaks that are used at the beginning of a document/paragraph between Linux and Windows? (Like ther'es a difference in endofline chars and whitespaces) ?

Not sure if it helps, but here's for sharing.
As the title says. The bug seems to be in postHTML:

array(
        'postData' => array( 'content' => $html ),
        'timeout' => $wgVisualEditorParsoidTimeout,
        'oldid' => $parserParams['oldid']
)


should be:

array(
        'postData' => array( 'content' => $html, 
                             'oldid' =>  $parserParams['oldid']),
        'timeout' => $wgVisualEditorParsoidTimeout
)

--------------------------
**Version**: unspecified
**Severity**: normal
*** Bug 47498 has been marked as a duplicate of this bug. ***
Merged; to go out in next push as a critical priority.
Related URL: https://gerrit.wikimedia.org/r/60082 (Gerrit Change Ib1b7079a7fd3357903e5a14795ed0d2f2bdc5d16)
Verified that this fixes the problem and lets Parsoid actually use selective serialization. Current production code does not use selective serialization for this reason.
This would explain a great deal. :-)
The link tool showing "undefined" in step 5 of the bug report

1. Hit an article on English Wikipedia and click "Edit" to invoke Visual Editor. I used http://en.wikipedia.org/wiki/Savage%2C_Montana.

2. Double-click any word to highlight it. I used the first word of the "History" section, "Savage".

3. Click the Link Tool icon, and the tool pops up.

4. Choose any article title in the dropdown (I chose "Savage Land") and press Enter.

5. The dropdown closes, and in the tool's text input, instead of saying "Savage Land," it says "undefined." (See screenshot to be uploaded.)

6. Now click outside the tool -- somewhere else on the article. The tool becomes completely blank (see second screenshot) and article text disappears.

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

**Attached**: {F10425}
Now fixed by gerrit 60907 - thanks Trevor!
Seemingly not fixed at all - still broken in master/production with same behaviour as before.
Now merged and going out tomorrow.
Related URL: https://gerrit.wikimedia.org/r/60781 (Gerrit Change I286a28002c1691e58bbd7de04ed08cceb8b3bb07)
*** Bug 47546 has been marked as a duplicate of this bug. ***
Same for me.

In addition to Dan's step 6, i note that after step 6 I see: "TypeError: 'undefined' is not an object (evaluating 'dataElement.attributes.title')"
Confirmed in Chrome/Mac, Firefox/Mac and Firefox/Linux. Looks like a general critical issue.
This is in Chrome 25.0.1364.172 on Ubuntu Linux.
Created attachment 12146
The link tool going completely blank, and the article text behind it disappearing, as in step 6 of the bug report.

**Attached**: {F10426}
Master is failing jenkins tests right now due to some JSDuck failures.

Examples: https://gerrit.wikimedia.org/49364 , https://gerrit.wikimedia.org/r/57922

--------------------------
**Version**: wmf-deployment
**Severity**: blocker
Original patch has been resubmitted by Roan with https://gerrit.wikimedia.org/r/#/c/58134/ . That new version passed the JSDuck job \O/
Changed merged by Jenkins, so that definitely fixed the issue :-]
(In reply to comment #3)
> Maybe the V+2 and submit rights should be taken away from human users for
> core?
> We did this in VisualEditor a few months ago.

+10, best idea ever
Maybe the V+2 and submit rights should be taken away from human users for core? We did this in VisualEditor a few months ago.
Most probably caused by https://gerrit.wikimedia.org/r/#/c/56637/ that has been force merged.

Revert is https://gerrit.wikimedia.org/r/#/c/58131/
Related URL: https://gerrit.wikimedia.org/r/58131 (Gerrit Change I2d945b7ffb7cfbcc5024a1c3bdcf0c9506b0cf76)
In preparation for making the VisualEditor the "default" editor, we should have the existing integration switched over for users so that they can see, test and feedback on the final UX for triggering edits in the run-up to switch-over.

--------------------------
**Version**: unspecified
**Severity**: trivial
Now merged.
See https://gerrit.wikimedia.org/r/59557 , https://gerrit.wikimedia.org/r/59558
Aaron Schulz wrote:

I noticed that https://gerrit.wikimedia.org/r/#/c/33971/ passed the tests but after it was merged, the new tests started failing for everything. The commit to revert it also failed so I override Jenkins and merged anyway, and the failures went away for new commits. This indicates that something broken is going, possibly Jenkins running tests just against master rather than master + the patch, which would explain this problem.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 117045 merged by jenkins-bot:
Parsoid: uses ZUUL_COMMIT as a git refspec to build

https://gerrit.wikimedia.org/r/117045
Change 117045 had a related patch set uploaded by Hashar:
Parsoid: uses ZUUL_COMMIT as a git refspec to build

https://gerrit.wikimedia.org/r/117045
I have verified the jobs triggered over the past few days. Seems to work fine now :-)  The root cause was using ZUUL_BRANCH as a branch specifier instead of ZUUL_COMMIT.
hashar@gallium:~$ ./checkbug46723.py mediawiki-core-phpunit-api --filter 2013-04-16*
Found 0 mismatches in 29 log files.
hashar@gallium:~$ ./checkbug46723.py mediawiki-core-phpunit-misc --filter 2013-04-16*
Found 0 mismatches in 29 log files.
$

Seems it got fixed :-]  Will verify again during the week, but so far that looks good.
Will monitor over the next few days. Lowering priority for now.
https://gerrit.wikimedia.org/r/#/c/58865/ has been deployed.

I am now manually updating the jobs which are not under JJB:

analytics-libanon
analytics-udp-filters
analytics-webstatscollector
analytics-wikistats
mwext-PoolCounter-pep8
mwext-VisualEditor-docgen
operations-debs-python-voluptuous-debbuild
parsoid-parse-tool-check
parsoid-roundtrip-test-check
parsoid-runTests
test-mediawiki-merge
https://gerrit.wikimedia.org/r/58865 (Gerrit Change Iafebfffe480886fc8956e56517291b1b3b1fc0cc) | change APPROVED and MERGED [by Hashar]
*** Bug 47208 has been marked as a duplicate of this bug. ***
(In reply to comment #13)
> Related URL: https://gerrit.wikimedia.org/r/58865 (Gerrit Change
> Iafebfffe480886fc8956e56517291b1b3b1fc0cc)

Why is this comment duplicated?
I have updated mediawiki-core-whitespaces job to use ZUUL_COMMIT as a refspec specifier. The job is non voting so that is not going to do any harm.

The experimental change is https://gerrit.wikimedia.org/r/58865
Related URL: https://gerrit.wikimedia.org/r/58865 (Gerrit Change Iafebfffe480886fc8956e56517291b1b3b1fc0cc)
Related URL: https://gerrit.wikimedia.org/r/58865 (Gerrit Change Iafebfffe480886fc8956e56517291b1b3b1fc0cc)
The branch specifier in the git plugin is set to ZUUL_BRANCH which is 'master'. 

In the git plugin (at git-plugin/src/main/java/hudson/plugins/git/util/DefaultBuildChooser.java ), the getCandidateRevisions() will recognize whether the branch looks like a sha1 (if it matches /[0-9a-f]{6,40}/) and in such a case will create a detached branch using that commit.

Seems the Jenkins job macro should then use ZUUL_COMMIT as a branch specifier.
ZUUL_COMMIT=76cb37f0c69dcd69884fc6e66681e77c8045a08e

but it fetched origin/master instead :-(
Created attachment 12084
Console output for https://integration.wikimedia.org/ci/job/mediawiki-core-phpunit-parser/5386/console

**Attached**: {F10684}
We are lacking the git plugin verbose mode in production due to a bug. It is corrected with https://gerrit.wikimedia.org/r/58489  . That will help find out what the plugin is doing internally.
I have traced the issue as far as mediawiki-core-lint build #19 from made on November 22nd 2012).


MISMATCH in /var/lib/jenkins/jobs/mediawiki-core-lint/builds/19/log
Pipeline: gate
Zuulcommit: 76606b66b006ac0e62087e6d00b1e4bdd56fff09
Checkedout: 232e34733fc68739ba96cccc31d3ff88f9484a23
Extract for the two builds referenced somewhere above:

Verifying /var/lib/jenkins/jobs/mediawiki-core-phpunit-misc/builds/5222/log
Zuulcommit: 8cc0b601aa2db6db09ac0e4d70847293d75875aa
Checkedout: 8cc0b601aa2db6db09ac0e4d70847293d75875aa
Verifying /var/lib/jenkins/jobs/mediawiki-core-phpunit-misc/builds/5223/log
Zuulcommit: 7dd3356a51951f8cdfe463552b5e5aae272e8e60
Checkedout: 4c69569db71d149feff6c4b10ea7a493425d67fd (MISMATCH)


We can see that build 5223 did not used the proper commit :-]


I suspect git plugin does not fetch the proper references / can't find it. That result internally in an unknown sha1 and then git plugin fallback to master or something else.

I will try to reproduce the issue in labs with git plugin set to verbose. That needs to start Jenkins with -Dhudson.plugins.git.GitSCM.verbose=true
Created attachment 12066
output of checkbug46723.py

The result script output highlight that some builds are not testing what they should be testing because they check out a parent commit.  By looking at the Jenkins Git plugin source code, it seems that whenever the reference is not parseable (aka: git rev-parse $ZUUL_REF), the plugin fallback to use master or some parent commit.

I need to improve the script to find out if that happens in a specific pipeline or for some specific refs.

**Attached**: {F10683}
Created attachment 12065
python script parsing build logs to find Zuul commit vs Git plugin checkout

**Attached**: {F10682}
build #5223 


Workspace did get wiped:
 02:46:53 Wiping out workspace first.

It check out the revision:
 02:46:56 Checking out Revision 4c69569db71d149feff6c4b10ea7a493425d67fd (origin/master)

That is the master revision NOT the change. The commit should have been
7dd3356a51951f8cdfe463552b5e5aae272e8e60

----

The related merge job
https://integration.wikimedia.org/ci/job/mediawiki-core-merge/11333/console

02:44:17 Commencing build of Revision 7dd3356a51951f8cdfe463552b5e5aae272e8e60 (origin/master)
02:44:17 Checking out Revision 7dd3356a51951f8cdfe463552b5e5aae272e8e60 (origin/master)

----

The ZUUL_REF has probably not been resolved properly and the git plugin fallback to master.

There is also the possibility that the mediawiki-core-phpunit-misc job was using ZUUL_COMMIT as a refspec instead of ZUUL_REF. That might prevent the plugin from fetching the revision.   The job history is no more accessible due to an unexpected upgrade (see bug 47040).
From bug 47031 : https://gerrit.wikimedia.org/r/#/c/57436/ has been merged although it is faulty.

The unit tests ran on patchset upload did catch the issue:

https://integration.wikimedia.org/ci/job/mediawiki-core-phpunit-misc/5222/console : FAILURE

But the gating run after CR+2 did not catch it:

https://integration.wikimedia.org/ci/job/mediawiki-core-phpunit-misc/5223/console : SUCCESS


The root cause is that despite the ZUUL_REF points to the proper merge commit, the Jenkins Git plugin seems to use the current origin/master to build.
Related URL: https://gerrit.wikimedia.org/r/58283 (Gerrit Change I4b3fadccaae9c35964a0c47d63b22c4f35148a24)
0. Open a document with links already in it.
1. Click on a MediaWiki link, then click the icon to open the inspector.
2. Click anywhere else in the document to lose focus.
3. You're link has now been removed :(

Note that this doesn't happen if you have just created a link, or if you have edited a link, so I assume this is functionality for letting people abandon the creation of a link.

The only way to remove a link should be with the delete icon in the inspector, or clear formatting.

This doesn't appear to affect external links.

--------------------------
**Version**: unspecified
**Severity**: normal
*** Bug 46505 has been marked as a duplicate of this bug. ***
Code now merged.
https://gerrit.wikimedia.org/r/53488
The re-write of the node API that dm provide up to the rest of VE is necessary for most of the added support that VE is aiming to provide this year.

[Mostly done now.]

--------------------------
**Version**: unspecified
**Severity**: critical
… which is now merged. Hurrah.
Done in gerrit 50025 and related changes.
**Author:** `phil`

**Description:**
visual editor after deleting lines 3 and 4 - note that 4 is still visible and the gap inbetween 2 and 4 is marked as 'cannot be edited'

I had text
1
2
3
4

selecting the last 2 lines ( 3 and 4 ) and deleting and saving, on looking at the page again '4' is visible and there is a gap that is marked as 'cannot be edited'

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

**Attached**: {F10499}
Looks like this is similar to bug 44701. The linear model is correct, but is incorrectly serialized or parsed.
This is now fixed given the Parsoid update. Sorry for the delay.
**orbit** wrote:

Looks like this is similar to bug 44701. The linear model is correct, but is incorrectly serialized or parsed.
**phil** wrote:

Safari on Mac

used the trackpad on my Mac to select the text

Look at page
http://en.wikipedia.org/wiki/User:PhilK10/sandbox/lines
**orbit** wrote:

What browser did this happen with? How did you make the selection (mouse vs. keyboard)? Can you link to the revision?
**Author:** `phil`

**Description:**
error message on save after changing bullet format

Blank page
Add some text e.g. 'test' and make it a numbered bullet
Save the page
Edit the page
Remove the text 'test'
Click on the '1' and click the numbered bullet control to remove it
Save page
"Error loading data from server: Unsuccessful request: Error contacting the Parsoid server."

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

**Attached**: {F10836}
This is now fixed given the Parsoid update. Sorry for the delay.
Can reproduce (not as a Parsoid error, which is just a "this is not working", but as a null diff.)

This is a Parsoid bug; holding back for new Parsoid release to live to re-check before assigning.
We've decided to take a different tack which means this kind of special-casing won't be needed. Hopefully. :-) Consequently marking as invalid.
Is this going to work also for languages other than English (e.g. Portuguese)?
That issue is tracked as T52896.
That's covered in specific tasks. Please don't open dead tasks from two years ago with drive-by comments; it's unhelpful and doesn't get anything done except wasting time diverting the conversation from the actual tasks.
I'm not clear as to why this is shown as "Closed, Resolved". VE still won't edit citations/footnotes where the body of the citation is in the References section (that is, within the reflist template), as demonstrated by the first two citations here: http://en.wikipedia.org/wiki/Pope_Francis#Name

If this is a WONT FIX, it would be helpful to so state. And if so, I'll just note that decisions not to (ever) have VE be able to handle existing, widespread Wikipedia functionality, even where that is an "ugly hack", are one of the exact reasons that cause experienced editors to not want to use the VisualEditor.
Fixed in master and very soon in production.
Related URL: https://gerrit.wikimedia.org/r/70031 (Gerrit Change I1551ddaa3d52c4827c7dcac2a02e31859769890a)
(In reply to comment #1)
> VisualEditor must be able to handle grouped footnotes ( as discussed here:
> http://en.wikipedia.org/wiki/Help:Footnotes#Grouping_footnotes ) - at least,
> not breaking these.

I agree. In fact, you and I have discussed this several times, and each time I've told you that we're working on it, and that we won't go "live" for the beta without it. :-)

> It also must be able to handle articles where the text
> for
> footnote is placed in the References section rather than in the body of the
> article - see, for example,
> http://en.wikipedia.org/wiki/Pope_Francis#References .

Ugly hacks for wikitext like this are one of the exact reasons that cause us to want everyone to use the VisualEditor.
VisualEditor must be able to handle grouped footnotes ( as discussed here: http://en.wikipedia.org/wiki/Help:Footnotes#Grouping_footnotes ) - at least, not breaking these. It also must be able to handle articles where the text for footnote is placed in the References section rather than in the body of the article - see, for example, http://en.wikipedia.org/wiki/Pope_Francis#References .
IE11 on Windows 7 
See the two screenshots to compare - VE in betalabs and in test2. 
Production VE looks like test2 VE.{F24999}

{F25001}
>>! In T85247#947266, @Se4598 wrote:
> reopening: what's invalid here? (tasktitle had been changed to reflect incompatibility)

(Now abandoned) Tools not designed to work with VE don't work with VE.
Thought that  since it's by design - not an issue/bug.
reopening: what's invalid here? (tasktitle had been changed to reflect incompatibility)
Yes, unchecking 'Fixed header'  makes VE be back to normal. Should be there some warning to VE users?
another report: https://www.mediawiki.org/wiki/Topic:S4opda1x12kcc54w
Looks okay to me. You have the "Fixed header" [[ http://en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences#mw-prefsection-betafeatures | beta feature ]] enabled, I guess VE isn't compatible with it. (You also have "Compact personal bar", but that isn't problematic AFAIK.)
Actually, I see VE is broken in Chrome too - so the issue is not specific to IE.
When I do Wikipedia editing workshops with VisualEditor, participants repeatedly suggest adding a right-click context menu.

Something like that exists in Google Docs, and it's surprisingly useful. For MediaWiki It can include similar functions - formatting, styling, linking, commenting, suggesting edits, etc.
We have intentionally designed VisualEditor to not use right menus because they can't ever work on touch devices, because of user complexity, and because of their lack of find-ability. Even if these would start out purely as secondary UX controls, it would lead us down the road to Word's bloat.
According to Antoine when he runs the tests using the following extensions together:

- JsonConfig
- Mantle
- MobileApp
- MobileFrontend
- WikiGrok
- ZeroBanner
- ZeroPortal

This yields two failures:

ResourcesTest::testMissingDependencies
The module 'ext.visualEditor.mobileViewTarget' required by
'mobile.editor.ve' must exist
Failed asserting that an array contains 'ext.visualEditor.mobileViewTarget'.

ResourcesTest::testUnsatisfiableDependencies
Undefined index: ext.visualEditor.mobileViewTarget
Change 181403 merged by jenkins-bot:
Don't add VisualEditor related modules if VE isn't installed

[[https://gerrit.wikimedia.org/r/181403]]
Change 181403 had a related patch set uploaded (by Florianschmidtwelzow):
Don't add VisualEditor related modules if VE isn't installed

[[https://gerrit.wikimedia.org/r/181403]]

#patch-for-review
https://edit-reportcard.wmflabs.org is a very rough beginning in the analysis of data related to the use of VisualEditor in the main wikipedias. The VisualEditor team needs help improving this space, so it provides metrics that help the team understand problematic areas, trends, impact of new features...

At this point there is basically no documentation. T84926 and T84927 are very basic starts. Can you dig in these metrics and the raw data associated, and understand what is being shown there?

Also, these graphs are created using [[ https://www.mediawiki.org/wiki/Analytics/Limn | Limn ]]. Have a look at the documentation in order to understand how it works. Bonus point if you install it locally and play with it a bit. 

If you have any questions about Limn you can ask in the [[ https://lists.wikimedia.org/mailman/listinfo/analytics | analytics mailing list ]]. In any case, considering your background it is a good idea to subscribe to this list.
https://wikitech.wikimedia.org/wiki/Analytics/Dashboards is the documentation specifically about dasboards.
Great, I'm on it.
If, for example, we want to give a link from VisualEditor in the Afrikaans Wikipedia to the VE user guide in mediawiki.org, we can only link to the source page in English. It would be more convenient to link directly to Afrikaans, but Special:MyLanguage only works if the user defined the language in the preferences of the same wiki, and [[VisualEditor/User guide//af]] will appear like a non-existent page if there is no translation.

I can think of several options to fix this:
* Make a non-existent sub-page redirect to the fallback language.
* Make Special:MyLanguage work across wikis somehow.
* Global cross-wiki language options (this would be Very Useful for a lot of other things).
@amire80 Do you have more information that can be used by Nemo and Niklas for this?
> Make Special:MyLanguage work across wikis somehow.

Do you mean, redirecting the user to another wiki?
This bug is vague. You can already link to [[mw:Special:MyLanguage/Page/af]] with the following caveats:
* Set interface language in target wiki (if available) overrides the subpage request
* It falls back directly to English.

I think there is a task for the fallback thing already.
The undo link in the page history leads to the source editor and not VisualEditor. It should lead to the VisualEditor for people who prefer to use it.

It's probably not a high priority at this point, but if the VisualEditor is supposed to replace the source editor, this issue should be handled at some point.
Change 323357 restored by Esanders:
[WIP] Undo support

[[https://gerrit.wikimedia.org/r/323357]]
Change 323357 abandoned by Alex Monk:
[WIP] Undo support

[[https://gerrit.wikimedia.org/r/323357]]
This is higher priority with the new source mode.
Change 323357 had a related patch set uploaded (by Alex Monk):
[WIP] Undo support

[[https://gerrit.wikimedia.org/r/323357]]
I just hit this problem in my pet project, which has SET with VE enabled by default to everyone. Indeed, this problem is more annoying in this context because then editors who preferred VE or who didn't even use the wikitext editor are left with two problems after clicking Undo:

# They are now facing a wikitext UI.
# Their preference has now changed to wikitext, which means that all future edits will be presented on wikitext unless they find out how to bring VE back.
I just hit this problem in my pet project, which has SET with VE enabled by default to everyone. Indeed, this problem is more annoying in this context because then editors who preferred VE or who didn't even use the wikitext editor are left with two problems after clicking Undo:

# They are now facing a wikitext UI.
# Their preference has now chanded to wikitext, which means that all future edits will be presented on wikitext unless they find out how to bring VE back.
I just hit this problem in my pet project, which has SET with VE enabled by default to everyone. Indeed, this problem is more annoying in this context because then editors who preferred VE or who didn't even use the wikitext editor are left with two problems after clicking Undo:

# They are now facing a wikitext UI.
# Their preference has now chanced to wikitext, which means that all future edits will be presented on wikitext unless they find out how to bring VE back.
For some reasons I thought this was already fixed? It's particularly annoying/confusing on SET wikis.
> the VisualEditor is supposed to replace the source editor

Thunders and lightnings!
When you press an undo button, not only do we set the revision text to the previous revision, but we also set up the standard revert summary as the default summary, and show the diff they're about to cause, and show a warning. I'm wondering what a similar experience in VE would look like.
Suggest that specifically the undo link should lead to the editing interface selected in the user preferences or, in the absence of preference, to the default editor.
https://gdash.wikimedia.org/dashboards/ve/ seems to be missing data since the end of November.
I installed VisualEditor on MediaWiki 1.24.0. It works well now, I can edit and save pages.

But when I tried to add Template Data to my old template page, it cannot be formate as a table. VisualEidtor cannot use template data when editing pages.

My template data:

```
<templatedata>
{
    "description": "插入注意文本框，突出显示注意内容",
    "params": {
        "1": {
            "label": "注意内容",
            "description": "注意文本框的内容",
            "required": true,
            "type": "string",
            "aliases": [ "注意内容" ]
        }
    }
}
</templatedata>
```

Template page: http://xuexiii.org/w/%E6%A8%A1%E6%9D%BF:%E6%B3%A8%E6%84%8F

You can see template data is displayed as plain text. But in English Wikipedia, it should become a table.
@Jdforrester-WMF Thanks!
http://xuexiii.org/w/%E7%89%B9%E6%AE%8A:%E7%89%88%E6%9C%AC shows that you don't have the #TemplateData extension installed. If you install that (and then make an edit to any templates with TemplateData blocks on them so they can be re-parsed) it should work.
Steps to reproduce:

1.  Open VisualEditor on MediaWiki.org.
2.  Click on "Leave feedback" in the help menu.
3.  Choose to leave feedback onwiki.  Type something and submit your feedback.

Result:

The feedback is posted as a ==Regular section heading== with normal, signed ~~~~ comments to a feedback page that is using LiquidThreads.  It either needs to post correctly within LiquidThreads or it needs to post to a different page.
>>! In T78120#836065, @TTO wrote:
> I don't think it is fair to merge this. Realistically, that LQT task is never going to get resolved. VE needs to either work around this, or stop using a LQT-based feedback page (which is a WMF config issue).

I disagree; the standard feedback form provided by Platform is what all feature teams are meant to use. The problem that it's particularly poor and needs fixing in various ways is something the Editing team have been (slowly) helping to improve. However, there are wider issues that are beyond our team and need specialists to fix. When all the LQT pages get converted to Flow, of course, the issue becomes the parallel {T59989}.
I don't think it is fair to merge this. Realistically, that LQT task is never going to get resolved. VE needs to either work around this, or stop using a LQT-based feedback page (which is a WMF config issue).
Can we create consistency between the naming convention of the (sub)projects related to Visual Editor and Wikitext editor to make them more easily findable and have better parity?
We're not going to merge all the 20+ editing-related projects together.
Umbrella projects having a distinct color seems sane.  Upstream seems to do this I think.
> the wikitext editor in Flow, which is dealt with inside MediaWiki-extensions-Flow
> the VisualEditor issues specific to the Flow integration, which are, well, not currently filed anywhere, but I guess would go in VisualEditor and MediaWiki-extensions-Flow together.

The VE integration is not actively being worked on, though we still want to use it later, of course.

We basically use the standard scheme (MediaWiki-extensions-ExtensionName).  We also have a team board ( #Collaboration-Team ), but if you file it in the extension component you don't need to worry about the team board (we may add that project later, though).

Are there any action items for #Collaboration-Team ?  If not, we'll remove our projects from this task.
There's also:
* **Mobile Web**
** the wikitext editor in Mobile Web, which is dealt with inside #MobileFrontend-General-or-Unknown (no specific project for editor issues)
** VisualEditor issues specific to the Mobile Web integration, which are dealt with in #VisualEditor-MediaWiki-Mobile
* **Apps**
** the wikitext editor in the iOS mobile app, which is dealt with in #Wikipedia-App-iOS-App (but not really, because they haven't migrated to Phabricator yet)
** the wikitext editor in the Android mobile app, which is dealt with in #Wikipedia-App-Android-App (but not really, again)
* **Flow**
** the wikitext editor in Flow, which is dealt with inside #MediaWiki-extensions-Flow
** the VisualEditor issues specific to the Flow integration, which are, well, not currently filed anywhere, but I guess would go in #VisualEditor and #MediaWiki-extensions-Flow together.
* the wikitext editor in **LiquidThreads**, which is dealt with inside #MediaWiki-extensions-LiquidThreads
* the **code editor**, which is dealt with in #MediaWiki-extensions-CodeEditor

… and probably some others I'm forgetting.
No, not really. Core's wikitext editing must stay under MediaWiki- and VisualEditor (and WikiEditor) must be separate.
thanks for clarifying @matamarex, you kind of hit on what I'm saying. Is there any way we can make the phab project names for these more clearly show those relationships you just outlined?
We have three distinct editors and three corresponding projects.

* The **VisualEditor** is #VisualEditor, this is an umbrella project that includes all tasks from all of the subprojects like #VisualEditor-EditingTools. You should never file tasks in subprojects only or they may get lost (until we have project inheritance or whatever in Phabricator).
* The **WikiEditor extension**, which is #MediaWiki-Extensions-WikiEditor. This is what most people know as //the// wikitext editor and implements all of the fancy buttons around the wikitext editing area.
* The **built-in** MediaWiki editor, which you never see unless you're the kind of person who still uses MonoBook and hates new things. It doesn't have a dedicated project, but any issues can be filed under #MediaWiki-Page-editing (this project also covers things like editing pages suddenly being broken or something).

I'm not sure what this task is about.
I've added what I know and can find to the task, but others may be present and hard to find, due to the issue in this task (Catch-22)
What are the "subprojects related to Wikitext editor"?
Or basically: Which existing projects are we discussing here?
>>! In [[https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/35 | mingle]] on 2013-10-30 at 23:57:09, @MarkTraceur wrote:

https://gerrit.wikimedia.org/r/88987
>>! In [[https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/35 | mingle]] on 2013-10-11 at 18:06:37, @MarkTraceur wrote:

https://gerrit.wikimedia.org/r/88987
OOUI's svgo-optimized SVG files are not compatible with rsvg's broken SVG parsing. 

svgo emits SVG like `<path d="M-1-2 …">` or `<path d="M.3.5 …">` which rsvg is unable to parse (this is valid path data fragment that represents a points (-1; -2) and (0.3; 0.5), and the SVG 1.1 spec even explicitly discusses this syntax). The same issue affects ImageMagick when compiled with rsvg support.

This means that some of OOUI's and VisualEditor's icons will not appear correctly e.g. when uploaded to Commons, and blocks {T76473} since we're unable to rasterize the SVGs to PNG.

This can be worked around using some search-and-replace, but this leaves some questions:

* Can this be fixed in rsvg? Gotta file a bug, even if it'll probably be ignored, and even if not no one is going to upgrade their copy.
* //Where// do we apply the workaround? To the files in git? During build process? In MediaWiki's RL module from T76473?
* Should we maintain the workaround ourselves somewhere, or maybe it could be upstreamed to svgo? (As a command-line option for people who want rsvg compatibility at the cost of a few bytes, like us?)
The patch is included in rsvg 2.40.6. https://git.gnome.org/browse/librsvg/log/
Haha, I just learned that we have //just// deployed a rsvg patch to fix this on Wikimedia wikis last week: https://gerrit.wikimedia.org/r/#/c/173639/ (80dd6ad665610979af294aeff4db417599363250). rsvg upstream bug is https://bugzilla.gnome.org/show_bug.cgi?id=620923, patch is https://git.gnome.org/browse/librsvg/commit/?id=5ba4343bccc7e1765f38f87490b3d6a3a500fde1.

So let's forget applying to fix to existing files or bothering svgo people, and just keep the one in ResourceLoaderImage patch for third-parties who don't have the most recent rsvg.
The workaround goes like this: https://github.com/trevorparscal/colorize/pull/1/files – in the simplest form, we insert some spaces and zeroes to create path data that is readable to rsvg.

This has already been implemented in [[ https://gerrit.wikimedia.org/r/#/c/165922/ | ResourceLoaderImageModule for icons ]] for T76473 (see `ResourceLoaderImage::massageSvgPathdata()`).

I think we should keep the workaround there (for potential third-party users) **and** apply the fix to SVG files in our repos, for the benefit of people wishing to have copies of the files on Commons. It costs us little and isn't just theoretical, but has already been complained about: https://lists.wikimedia.org/pipermail/wikitech-l/2014-November/079532.html
wikibugs fails to link Phab task in some IRC notifications, dunno why. From #-visualeditor (times in CEST or something):

```
[20:38]	<wikibugs> OOjs-UI: MediaWiki, Apex: Provide default margins for buttons and other widgets
...
[20:41]	<wikibugs> OOjs-UI: ComboBoxWidget: Provide a getMenu method
```

The tasks it should have linked are T76643 and T76646.
Fixed by https://gerrit.wikimedia.org/r/#/c/181523/
Ctrl + F on http://bots.wmflabs.org/~wm-bot/db/%23mediawiki.htm gives 27 usages

Some are probably ok (aliases and such), but some plainly need updating

[22:10:20] <Reedy> !bug
[22:10:20] <wm-bot> https://bugzilla.wikimedia.org/

Another being vebug giving "Submit a new ticket on Bugzilla for the VisualEditor: https://bugzilla.wikimedia.org/enter_bug.cgi?product=VisualEditor"
Pretty sure I cleaned up most of those I could find.  Please ping me if more are found.
note, you can use !bug replace <new text>
The media type "basic", described using the message Visualeditor-dialog-media-type-none does not explain the real meaning of how the image will be inserted.

It will be clearer to call it something like "Inline", and possibly to change the icon as well.
Change 176919 abandoned by Jforrester:
Change Basic image type to "Inline"

Reason:
See comments on the task.

[[https://gerrit.wikimedia.org/r/176919]]
No. "Inline" is absolutely not what this sets. MediaWiki's Multimedia support is terrible, but lying to users to confuse them more is a terrible idea.
Change 176919 had a related patch set uploaded (by Amire80):
Change Basic image type to "Inline"

[[https://gerrit.wikimedia.org/r/176919]]

#patch-for-review
```
2) ResourcesTest::testUnsatisfiableDependencies
The module 'mobile.editor.ve' must not have target 'desktop' because its dependency 'ext.visualEditor.mobileViewTarget' does not have it
```
Change 178731 merged by jenkins-bot:
Don't load mobile.editor.ve module in desktop target

[[https://gerrit.wikimedia.org/r/178731]]
Change 178731 had a related patch set uploaded (by Jdlrobson):
Don't load RL module for VE in supported mode

[[https://gerrit.wikimedia.org/r/178731]]

#patch-for-review
This is so we can manage tasks as being definitely fixed, not just that it worked in test.

Descriptions: "Project for tasks verified by QA as being fixed in phase<N>."

Access as normal; icon as normal.
>>! In T76104#818733, @Aklapper wrote:
> I've updated to yellow color and tag icon + added a link to the deployment train to project descriptions.

Thank you!
I've updated to yellow color and tag icon + added a link to the deployment train to project descriptions.

>>! In T76104#801982, @Jdforrester-WMF wrote:
> The old #verified tag is not fit for purpose and should be marked as inactive.

If the Wikidata team has agreed on that and also plan to use the new Verified-in-PhaseX tags instead, I'm happy to archive it.
>>! In T76104#789665, @Se4598 wrote:
> Is it intentional that this are "normal" projects and not of (visual) type "Tag" as per https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Guidelines?

Yes, but I'm sure QA don't particularly care. There is an on-going project to ensure that tasks marked as resolved are actually proven to be resolved in practice, which is what these are for…

>>! In T76104#801766, @Aklapper wrote:
> The project descriptions of those three projects should link to https://wikitech.wikimedia.org/wiki/Deployments ( https://www.mediawiki.org/wiki/MediaWiki_1.25/Roadmap unfortunately isn't a stable URL) . 

The link can be changed as the current MediaWiki version requests; https://wikitech.wikimedia.org/wiki/Deployments is significantly less stable as an information resource.

> These projects should be tag style. 

Sure.

> These projects might also create slight confusion towards the already existing, generic "verified" tag

The old #verified tag is not fit for purpose and should be marked as inactive.

> (at least I want the descriptions to refer to each other and explain the differences in usage).

I see no value in using it.

> For future reference, I appreciate waiting a little bit longer for further feedback on such ideas, if we're not in some urgent hurry. Thanks. :)

There was an urgent hurry. The complete absence of a viable "verified" status in Phabricator made it impossible for QA to do their jobs of marking tasks as confirmed-fixed. Phabricator might have been in its first few days, but we are still shipping live code every week, and can't wait for a few days to restart our work.
>>! In T76104#801791, @Qgil wrote:
> I guess "Visible To: All Users" is simply a consequence of lack of awareness

Yeah, chatted with James and that's fixed now
I guess "Visible To: All Users" is simply a consequence of lack of awareness of  https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Default_policy. I have started to insist on View Public in proposals from new project creators.
Also, why are these projects set as "Visible To: All Users" instead of "Public"?
Please always provide reasons, as explained on https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Policy

Currently going to e.g. https://phabricator.wikimedia.org/T75378 and not being logged in I see two restricted projects (VisualEditor-Tables being the other one).
...and I also appreciate pointers where the practice to use these new tags is documented on-wiki, as that should also **definitely** be part of the project descriptions.
The project descriptions of those three projects should link to https://wikitech.wikimedia.org/wiki/Deployments ( https://www.mediawiki.org/wiki/MediaWiki_1.25/Roadmap unfortunately isn't a stable URL) . 
These projects should be tag style. 
These projects might also create slight confusion towards the already existing, generic "verified" tag (at least I want the descriptions to refer to each other and explain the differences in usage).

If there's no opposition I am going to go ahead tomorrow or so.

For future reference, I appreciate waiting a little bit longer for further feedback on such ideas, if we're not in some urgent hurry. Thanks. :)
>>! In T76104#789703, @Qgil wrote:
> They look indeed like better suited for tags.

I agree (especially if QA don't care).
>>! In T76104#789656, @Jdforrester-WMF wrote:
>[...]
>> And just curious, where can I learn about Phase0, 1, 2?
> 
> wikitech.wikimedia.org/wiki/Deployments and a few dozen other places.

Based on that I assume this means the specific wiki sets/groups and so I updated the descriptions of the projects to reflect that. Please correct me if I'm wrong at this.

I'm also confused of the usage of these different terms (group/set and phase), so it would for me initially clearer if they were named Verified-in-Group2 as group seems to be the normally used term for this.
They look indeed like better suited for tags.
>>! In T76104#789665, @Se4598 wrote:
> Is it intentional that this are "normal" projects and not of (visual) type "Tag" as per https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Guidelines?

Yes, but I'm sure QA don't particularly care. There is an on-going project to ensure that tasks marked as resolved are actually proven to be resolved in practice, which is what these are for…
Is it intentional that this are "normal" projects and not of (visual) type "Tag" as per https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Guidelines?
>>! In T76104#789646, @Qgil wrote:
> Just checking, are you in sync with QA?

Yes; this was at @RYasmeen's request.

> And just curious, where can I learn about Phase0, 1, 2?

wikitech.wikimedia.org/wiki/Deployments and a few dozen other places.
You provided less than a minute for consensus.  :)

Just checking, are you in sync with QA? And just curious, where can I learn about Phase0, 1, 2?
Done:

#Verified-in-Phase0
#Verified-in-Phase1
#Verified-in-Phase2
MediaWiki version is 1.25wmf9

VisualEditor 1.25wmf9 is installed and enabled:
```
require_once "$IP/extensions/Parsoid/Parsoid.php";
require_once "$IP/extensions/VisualEditor/VisualEditor.php";

$wgDefaultUserOptions['visualeditor-enable'] = 1;
$wgHiddenPrefs[] = 'visualeditor-enable';
//$wgDefaultUserOptions['visualeditor-enable-experimental'] = 1;
$wgVisualEditorParsoidHTTPProxy = false;
$wgVisualEditorParsoidURL = 'http://[my.nodejs.host]:80';
$wgVisualEditorParsoidPrefix = 'myWiki';
//$wgSessionsInObjectCache = true;
$wgVisualEditorParsoidForwardCookies = false;
$wgVisualEditorNamespaces = array_merge( $wgContentNamespaces, array( NS_USER ) );
```

If I curl Parsoid for the Main Page (from the same host where MediaWiki is installed) I can see page parsed and a log on Parsoid
```
curl http://[my.nodejs.host]/myWiki/Main_Page?oldid=1
```

If I click on Edit {F16470} the page is refreshed (?title=Main_Page&veaction=edit), but I can't see the VisualEditor editing area. Moreover, nothing is logged on Parsoid (like if the request has never be done).
If I click on Edit source the standard editor is displayed.
Aha. That means you didn't checkout the actual code for VisualEditor itself, just the MediaWiki extension that embeds it. You need to do `git submodule update --init `. See https://www.mediawiki.org/wiki/Extension:VisualEditor#Download.
Maybe I found something:

```
/*
exception 'MWException' with message 'ResourceLoaderFileModule::readScriptFiles: script file not found: ".../extensions/VisualEditor/lib/ve/src/ve.track.js"' in .../includes/resourceloader/ResourceLoaderFileModule.php:843
Stack trace:
#0 .../includes/resourceloader/ResourceLoaderFileModule.php(362): ResourceLoaderFileModule->readScriptFiles(Array)
#1 .../includes/resourceloader/ResourceLoader.php(901): ResourceLoaderFileModule->getScript(Object(ResourceLoaderContext))
#2 .../includes/resourceloader/ResourceLoader.php(647): ResourceLoader->makeModuleResponse(Object(ResourceLoaderContext), Array, Array)
#3 .../load.php(45): ResourceLoader->respond(Object(ResourceLoaderContext))
#4 {main}
*/
/*
exception 'MWException' with message 'ResourceLoaderFileModule::readScriptFiles: script file not found: ".../extensions/VisualEditor/lib/ve/src/ve.js"' in .../includes/resourceloader/ResourceLoaderFileModule.php:843
Stack trace:
#0 .../includes/resourceloader/ResourceLoaderFileModule.php(362): ResourceLoaderFileModule->readScriptFiles(Array)
#1 .../includes/resourceloader/ResourceLoader.php(901): ResourceLoaderFileModule->getScript(Object(ResourceLoaderContext))
#2 .../includes/resourceloader/ResourceLoader.php(647): ResourceLoader->makeModuleResponse(Object(ResourceLoaderContext), Array, Array)
#3 .../load.php(45): ResourceLoader->respond(Object(ResourceLoaderContext))
#4 {main}
*/
```
The folder .../extensions/VisualEditor/lib/ve is empty, maybe something went wrong while downloading with git.
What if any output is there on your browser's console log?
On frwiki, we have false positives on a filter that tags edits that remove all categories.

Filter: https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Filtre_antiabus/14
Example of false positive: https://fr.wikipedia.org/w/index.php?title=Bertrand_Chameroy&diff=prev&oldid=109458887 (it should not have the tag "suppression des catégories")
Details of the AbuseFilter log event: https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Journal_du_filtre_antiabus/1204633

I am sure that this is not an error in the filter itself, because in the details of the AbuseFilter log event, the diff shows that categories are indeed removed. But this diff does not match the real diff, where categories are unchanged.

Expected behavior: the content of the 'new_text' variable of AbuseFilter should always match the new page text.

I found 4 such false positives for this filter in the last two months. In all cases, modification also has the 'VisualEditor' tag, so this could be related.

Other cases:
https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Journal_du_filtre_antiabus/1200961
https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Journal_du_filtre_antiabus/1190456
https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Journal_du_filtre_antiabus/1164028
Edit any page in beta labs, e.g. http://en.wikipedia.beta.wmflabs.org/wiki/Cite_VisualEditor_Test?vehidebetadialog=true&veaction=edit

Click Cite and fill in the textareas

Click Insert

Cite inspector should disappear but does not. 

Also note that the appearance of the Cite inspector is exceptionally small, in both Firefox and Chrome
The issue is not reproducible anymore.
When I put in the template "Infobox road" onto a subpage of my user page, and added some parameters, the links they made were red.

Screenshot link:

[[https://en.wikipedia.org/wiki/File:Philroc-VEBug.png|The screenshot (red links circled)]]

More info:

[[https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Newly_made_links_are_red_until_page_is_saved|The bug at Wikipedia]]

I hope somebody gets to this soon.

Thanks!
Right, it was T95247
I can replicate the issue. I think it's separate - the reason those links get marked red is because their CE elements get a blank href element set somehow. Do you want to open a separate bug or shall I?
I don't know, but I'm seeing red links in Citoid.  It's in the initial
display, not when you go back to look at it later.  I suspect that this is
a separate bug, though.  (Steps to reproduce:  Add a ref to books.google.com;
Insert; look at the red ISBN link.)
Has this been fixed as T94315?
This has re-appeared.  You can read the editor's report at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=651892335#Weird_bug_with_VE
And feel free to reopen if you do still run into these issues
Please try again. I think we fixed these issues already.
Updating [[ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2014_4#Newly_made_links_are_red_until_page_is_saved | feedback page ]] link. This bug looks like a regression to me.
Wittylama reported something similar today: <<See this edit https://en.wikipedia.org/w/index.php?title=National_Library_of_Australia&diff=636455550&oldid=636107184 - where I replace a raw link with the "main" template. Before saving, the Visual editor shows the link as a redlink and adds an extra line of whitespace above and below the new template. However, when I actually save the edit the link goes blue and the whitespace disappears. So, the saved result is exactly what I wanted to happen, but the visual editor 'preview' made it look like there were going to be two mistakes.>>
I imported https://www.mediawiki.org/wiki/VisualEditor/Feedback into Flow with the LQT importer (plus some small changes for https://gerrit.wikimedia.org/r/#/c/172925/ that are probably not relevant to this bug).

The import crashed (bug 73638), but a lot of stuff was already imported by then.  However, when I visit it, I get:

"Fatal error: Maximum function nesting level of '200' reached, aborting"

The stack is https://phabricator.wikimedia.org/P98 .

It seems that the nesting level of a topic may influence the nesting level of the function stack, and cause it to go over the limit.

--------------------------
**Version**: unspecified
**Severity**: normal
This error comes from xdebug.max_nesting_level.

XDebug is not enabled in production, so we shouldn't have to worry about this.

I confirmed it can be worked around locally by raising the limit or switching to HHVM.
I hit this when testing https://gerrit.wikimedia.org/r/#/c/172925/ against https://www.mediawiki.org/wiki/VisualEditor/Feedback .

So far I haven't retested against master, since the import is pretty slow.  I suspect it will be present there.

Command was:

mwscript extensions/Flow/maintenance/convertLqt.php --wiki=wiki User_talk:VE_Feedback_1 --allowunknownusernames 1 --remoteapi=https://www.mediawiki.org/w/api.php --srcpage=VisualEditor/Feedback --verbose 

Log is https://phabricator.wikimedia.org/P97 .

--------------------------
**Version**: unspecified
**Severity**: normal
Change 174830 had a related patch set uploaded by EBernhardson:
Bug: UID generator counter overflow

https://gerrit.wikimedia.org/r/174830
Screenshot of Read mode after editing

Steps to reproduce bug:

1. Edit a page
2. Insert some text or a table
3. Click "Save page" in the toolbar
4. Click "Review your changes" in the dialog
5. Click "Return to save form"
6. Click "Resume editing" in the dialog
7. Click "Read" tab from the MediaWiki navigation


Expected:

Original page re-appears.

Actual:

* The modified state from the editor persists.
* Even the highlighting is still there (e.g. can highlight different cells in the table  we just inserted).
* The "Edit" tab in the MW nav is now broken (clicking it does nothing, no exception thrown).

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

**Attached**: {F15110}
*** This bug has been marked as a duplicate of bug 73589 ***
switch edit mode fails in Chrome

This manifests in several ways, see the browser test failures at
Chrome: https://integration.wikimedia.org/ci/view/BrowserTests/view/-All/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/
Firefox: https://integration.wikimedia.org/ci/view/BrowserTests/view/-All/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox-sauce/

The common case for Chrome and Firefox:

As a logged-in user with access to VisualEditor, edit any page. 
Attempt to switch from the wikitext editor to VE using the dropdown controls. 
Nothing happens, VE does not show up.  See screen shot. 

The Firefox-only issue: 

Attempt to edit a new page by supplying a bogus URL, e.g. http://en.m.wikipedia.beta.wmflabs.org/wiki/Foobarbaz

Clicking the edit icon does nothing.

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F15094}
I can edit new pages on Firefox so I think this has been fixed. Please reopen if you can still duplicate it.
**gerritadmin** wrote:

Change 174384 abandoned by Florianschmidtwelzow:
Don't try to set cursor on hidden elements

Reason:
Function reverted in: I672d04c16f9348f7e08c4f64b339b307276d2a5a

https://gerrit.wikimedia.org/r/174384
I captured the other issue in bug 73646
If there are two problems here there should be 2 bugs..
okay,just to keep note, this bug is now in test2 as well after today's deployment since it was regression from wmf9.I will test the fix in test2 once it is merged and backported.
Unhappily no, this patch adresses the Firefox problem. For now, I haven't had the time to look into it, why VE doesn't work :/
Ah got it, so this patch is going to fix for all pages in all browsers?
Jon is talking about the Firefox only problem :) The VE problem is right, it doesn't work on all pages :(
Nope, this is not a browser/page specific issue,was happening for me in all pages even in iOS safari.Once you switch to edit source mode the "Edit" button will no longer work from that point on.And then for a new page, it always opens the Edit Source mode first, so thats why its always reproducible for a new page too.
This seems to be specific for new pages in Firefox.
**gerritadmin** wrote:

Change 174384 had a related patch set uploaded by Florianschmidtwelzow:
Don't try to set cursor on hidden elements

https://gerrit.wikimedia.org/r/174384
For the second (FF only):
[10:11:21.144] "[Exception... "Failure"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: http://bits.beta.wmflabs.org/en.wikipedia.beta.wmflabs.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=minerva&version=20141030T090804Z :: EditorOverlay<._loadContent/< :: line 17"  data: no]" [object XPCWrappedNative_NoHelper]

Caused by: I2a3eab234338bae6258abcde99144bdd2464805f

VE: confirmed :/
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/LKgERdDV
Caption without background

Betalabs only in Chrome, FF, and Safari. test2 is fine.


VE - Insert Media and enter Caption - save the page. The Media caption is displayed with white background. 
See the attached screenshot.

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

**Attached**: {F15369}
This is how Beta Labs is configured, irritatingly.
Edit a page on beta labs e.g. http://en.wikipedia.beta.wmflabs.org/wiki/Links_VisualEditor_Test?vehidebetadialog=true&veaction=edit

Click the Links inspector

Note that the "Done" button is enabled

Quickly paste (do not type by hand) an external link e.g. http://www.example.com in the link field

Note that upon pasting "http://www.example.com", VE takes some time before displaying the "External link/New page" overlay. 

If the user clicks "Done" after pasting text in the link field but before the "External link/New page" overlay appears, VE creates a local link [[foo]] instead of the desired external link [http://www.example.com foo]

--------------------------
**Version**: unspecified
**Severity**: normal
Re-checked in betalabs - there is no noticeable delay in displaying "External link/New page" overlay(some performance improvements were made).
Safari cut and paste formatted text-white spaces issue

Steps to reproduce: 

Safari only - test2, Betalabs.

1. In VE type some text - e.g. underlined text. Apply underlined format to 'underlined'.

2. Highlight 'underlined text' and copy/paste it somewhere else on the page. 

It will be displayed as: underlinedtext. Underlined formatting will be gone and a white space between words is lost. 

This is affecting many options in formatted text - see the attached screenshot.

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

**Attached**: {F15096}
This was verified in betalabs.  It is sort of a  test case for the bug fix for 71718.
*** This bug has been marked as a duplicate of bug 71718 ***
Syntax fix: bug 71718
Duplicate of [[bug 71718]], I think.
Saw lots of bugs reported and fixed about the jumping of focus when using the toolbar.  Now seeing the problem in MSIE for many uses of the toolbar.  Would like a clue about fixing it.

--------------------------
**Version**: unspecified
**Severity**: normal
Related bug/fix? T66041
Some examples when a page scrolls up in IE11 

- Using Backspace button 

- changing existing Page title, Heading, and sub-headings to other format
Pasting anything besides plain text into MSIE fails.  Tried this with Word in FF and Chrome (see bug #73292) and had at least some success.

--------------------------
**Version**: unspecified
**Severity**: normal
Closing this for now since it has been solved elsewhere.  At least *some* pasting works.
Also bug 65714 comment 2.
When the categories suggested in the drop down are long enough, a scroll bar appears.  Clicking on this scroll bar causes the drop down to close.


It would be nice if you could use the scrollbar like others -- to scroll up and down the list.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 65774 ***
Change 172933 had a related patch set uploaded by Catrope:
Don't close PopupToolGroups when the scroll bar is clicked

https://gerrit.wikimedia.org/r/172933
Merging into bug 65774.

*** This bug has been marked as a duplicate of bug 65774 ***
Change 172723 had a related patch set uploaded by Alex Monk:
MenuWidget: Don't close menu when you click the scroll bar

https://gerrit.wikimedia.org/r/172723
Okay, I was just lucky and the last category would fit always without a scroll bar, unless I changed the window height. This feels like a duplicate bug though...
I've reproduced this on https://www.mediawiki.org/wiki/Project:Sandbox?veaction=edit using Chrome and Firefox on Windows and Linux.

What steps are you trying?  Maybe I need to provide more information?
Can't reproduce...
Enviornment-test2, beta

1> Select language and click done, when the language inspector opens.
2>type some text ,on the CE.
//the text has language style
3>now place the cursor to the start of the line and type in some more text.
// also has the language  style
4> after typing the additional text insert a space. Then delete that space.
Notice the cursor moves to the start of the line and also the language annotation from the recently typed text has been removed. Whereas the previously typed text still retains the annotation style.

See screencast.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows XP
The issue was checked - does not exist anymore.
Confirmed. 

The scenario for the issue is actually simpler. 

1. Select language and click done, when the language inspector opens.
2. type some text ,on the CE.
3. then add text to the beginning of the line - just start typing something and after some text click delete as if you were to correct something - all entered text  from your cursor to the beginning of the line will be deleted.
Also found in FF 33.1.
http://youtu.be/qzzJDdPJGQY
User added the words "La mui" to https://fr.wikipedia.org/wiki/Audiomachine#Utilisations_de_leurs_musiques . Then proceeded to edit elsewhere in the page. When he went back to those words, he found out he couldn't remove them at all (see screencast at https://www.youtube.com/watch?v=IMlMZt1FMvY : all his actions seem to affect the header below). When he reviews his changes, that content is actually not there.

Windows 7, Firefox Aurora 35.0a2 (2014-11-05), Vector.

--------------------------
**Version**: unspecified
**Severity**: normal
Could not reproduce. Sometime when a user session has been open for long and/or editing has taken long time(many edits) - UI becomes somewhat irresponsive. 
However, no specific and reproducible details have been reported yet.
(In reply to Ed Sanders from comment #1)
> Can't reproduce this.
I am the user to which it happened. I actually don't know how it happened, I did nothing special as far as I can remember. Elitre has suggested it may be because of my PC (I have sometimes other bugs that happen only to me). However the same bug or an extremely similar one also happened to me last year (in November 2013) but with my old PC with Firefox and Windows 7.
Can't reproduce this.
In wikitext editor, you can separate cells with a double bar "||" on the same line :

|Cell 1 || Cell 2 || Cell 3

(same thing for headers, except two exclamation marks "!!" are used).

When adding a new cell with VE, the result will look like
|Cell 1 || Cell 2 || Cell 3
|Cell 4

rather than |Cell 1 || Cell 2 || Cell 3 || Cell 4 .

While this still works, it makes the table less understandable and usable for those who do not use VE.

--------------------------
**Version**: unspecified
**Severity**: normal
Merging into bug 63356; ideally we'd want Parsoid to use inline or per-line syntax per precedent in the context, which sounds messy.

*** This bug has been marked as a duplicate of bug 63356 ***
Annotation on top of a link produces inefficient wikitext ([[asd|''asd'']]).

1. Type text, for example "asd".
2. Select it.
3. Press Ctrl+K to create a link, accept "asd" as link target.
4. Press Ctrl+I to italicize.

Result: [[asd|''asd'']].

Compare with:

1. Type text, for example "asd".
2. Select it.
3. Press Ctrl+I to italicize.
4. Press Ctrl+K to create a link, accept "asd" as link target.

Result: ''[[asd]]''.

I would expect both ways to produce the same wikitext, ''[[asd]]''.

--------------------------
**Version**: unspecified
**Severity**: normal
Yeah, merging with bug 50098.

*** This bug has been marked as a duplicate of bug 50098 ***
bug 50098 ?
Inserting new internal link inserts text, but doesn't linkify it.

1. Place cursor on empty paragraph
2. Open the link inspector (Ctrl+K)
3. Type in title of a page and press Enter

A new link to that page should appear. Instead, only the text typed is inserted, without the link annotation.

--------------------------
**Version**: unspecified
**Severity**: normal
Seems that you need to complete the dialog before page title suggestions appear, so just press Enter really quickly after typing.
https://www.mediawiki.org/w/index.php?title=Google_Code-in_2014&diff=1255073&oldid=1255066

Newly added "Bug" template was added as {{Template:Bug|…}} rather than just {{Bug|…}}. As far as I know I did nothing special to cause that.

--------------------------
**Version**: unspecified
**Severity**: normal
Verified on www.mediawiki.org - the Bug template added as {{Bug|73179}}.
Should've been fixed by Roan in Gerrit change 172319.
They broke and were disabled, but we should get them back.

--------------------------
**Version**: unspecified
**Severity**: normal
Looks like this was fixed at some point.
flow_tree_revision

Parsoid is running happily. I can edit pages using VisualEditor without issue.

I can visit a Flow page and add a new topic or comment. However, upon saving I don’t actually see the content of the comment. Topic titles do show up.

I’m not a DB guru, but upon inspecting the flow-specific database tables I noticed some weird syntax in the fields. Maybe it’s my editor (Sequel Pro) or an encoding issue.

I turned on MW debugging and I see this message:

Warning: DOMDocument::saveHTML() expects exactly 0 parameters, 1 given in /var/www/html/w/extensions/Flow/includes/Parsoid/Utils.php on line 273

1.25wmf5, PHP 5.3.3, most recent head/master build of Flow, most recent build of Parsoid.

--------------------------
**Version**: master
**Severity**: normal

**Attached**: {F15052}
While this is incredibly specific to my situation, I would like to point out that PHP 5.3.3 is still the standard version provided with RHEL-6. Which isn't the latest version, but still supported by Redhat.

Again, I realize this extension is a WMF-focused endeavor, but it's too cool to not be used elsewhere. :)

I'm off to argue with my linux sysadmins on updating PHP. Wish me luck!
https://www.mediawiki.org/wiki/Extension:Flow now documents Flow's php 5.3.6+ requirement. I'm proposing WONTFIX, although patches welcome.
I just tested on a system with 5.6.1 - Flow works as intended.
Erik is right.  Core requires 5.3.3, so we have the option of keeping support for that or documenting requiring 5.3.6.  The former may be doable if it's not much work, but core will probably bump above that soon anyway.
Actually i didn't read close enough, you are on 5.3.3.  I'm almost certain the problem is that, and we will have to update Flow's minimum requirements to 5.3.6.
The problem with DOMDocument::saveHTML is most likely our issue, it looks like that argument was added in php 5.3.6

Which version of php are you on?  I think we advertise support of 5.3.3, but we might need to bump that.
Sorry, I should have checked your screenshots first.  I see it's MySQL.  The weird characters are the binary UUID values.  Basically, consider the ID an arbitrary blob of bits (it does appear in the UI, serialized, in some places, e.g. in Topic URLs).

I'm not sure why it's not working, though.
What database engine are you using (MySQL, PostegreSQL, etc.)?
Created attachment 17047
mystery comments

**Attached**: {F15054}
Created attachment 17046
flow_revision

**Attached**: {F15053}
As a logged in user with VE available, edit any page in beta labs e.g. http://en.m.wikipedia.beta.wmflabs.org/wiki/Cyrion_and_Candidus#/editor/0

Page is white and shows spinner, editor never appears.

--------------------------
**Version**: unspecified
**Severity**: major
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/z22jBbGj
*** This bug has been marked as a duplicate of bug 73038 ***
Safari blurs text

1. Open a page in Safari VE Read mode - the text is displayed normally.

2. Switch to Edit  - the beginning of the page displays a blurred text.
Clicking in the text does not make it clearer. 

See the attached screenshots.

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

**Attached**: {F15010}
Now seems fine?
Created attachment 17040
Safari Read mode - text s clear

**Attached**: {F15011}
Created attachment 17039
Safari Read mode - text is clear

//attachment Safari Read mode.png ignored as obsolete//
Created attachment 17038
Safari displays clear text in Read mode

//attachment Safari Read mode.png ignored as obsolete//
**gerritadmin** wrote:

Change 171531 merged by jenkins-bot:
[BrowserTest] Fixed failing language screenshot browser tests

https://gerrit.wikimedia.org/r/171531
**gerritadmin** wrote:

Change 171531 had a related patch set uploaded by Vikassy:
Fixed failing browser tests

https://gerrit.wikimedia.org/r/171531
Vikas, can you take a look?

Amir, if Vikas does not have the time to fix this, we could work on it during our regular pairing sessions.
1. Safari - open any page and make sure that a page has enough content to have a vertical scrollbar. 

2. Insert a table at the bottom of the page.

Start typing in a table cell - the page scrolls up with each typed character.

--------------------------
**Version**: unspecified
**Severity**: normal
This was resolved some time ago.
text collisions

line height should be increased to not have text and controls run together.

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

**Attached**: {F14807}
on en.wiki:

go to article bonshō, click edit beta.
...and in general, steps to reproduce (which site is this about?) are welcome.
Local per-wiki templates need to be fixed locally…
icon not showing in VE

the featured article template added a significant amount of blank headspace to articles and doesn't draw the icon, so it is easy to accidently delete.

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

**Attached**: {F14803}
*** This bug has been marked as a duplicate of bug 49806 ***
See https://www.mediawiki.org/w/index.php?title=User:Elitre_(WMF)/sandbox&diff=prev&oldid=1249997 .

References at the words "this" were created by copy/pasting the contents of the reference at the word "complex".

Notice:
1) The spaces between the elements get removed (Bug 71718?)
2) The wikilink gets changed;
3) If you selected until after the "citation needed" template only, this wouldn't appear when pasting (Bug 49396?).

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to Elitre from comment #0)
> See
> https://www.mediawiki.org/w/index.php?title=User:Elitre_(WMF)/
> sandbox&diff=prev&oldid=1249997 .
> 
> References at the words "this" were created by copy/pasting the contents of
> the reference at the word "complex".
> 
> Notice:
> 1) The spaces between the elements get removed (Bug 71718?)

Looks like.

> 2) The wikilink gets changed;

This is bug 70743.

> 3) If you selected until after the "citation needed" template only, this
> wouldn't appear when pasting (Bug 49396?).

That bit works for me?

Merging with bug 71718.

*** This bug has been marked as a duplicate of bug 71718 ***
Steps to reproduce:

1.Insert a table
2.Add any focusable node inside content cell like template/image/math function
3.Place the cursor at the end of the table

Observed Result:
The page scrolls down to the end of it

--------------------------
**Version**: unspecified
**Severity**: normal
Oh *that* outside of the table. Yeah - you're not supposed to put your cursor there...

*** This bug has been marked as a duplicate of bug 71560 ***
Created attachment 17002
video capture

Still happening for me , See the video capture

**Attached**: {F15093}
Works for me in Chrome & FF
**Author:** `lhug`

**Description:**
Intention:
Trying to edit a page with linked files on a private wiki. Mainly to test if the Visual Editor functions are usable.

Steps to Reproduce:
1. Open page with a linked file
2. click "edit"
3. wait and see

Actual Results:  
The linked file simply disappears and is not visible to the editor. after saving, it is accessible again. Trying to insert media showed no local media.

Expected Results:  
Picture is editable of course, and at least a list of media to add.

Reproducible: Always

Using vector as skin. Changing skin did not resolve the issue. Wiki is running on a CentOS with self certified SSL. 
Accessing files that are on the commons is possible, and these are viewable by the editor. Copying the Link properties to other media links does not help, they are still invisible to the editor. Normal Text is editable and media are accessible there. Tried Workarounds found on several pages:

Changing permissions to all-read-true and/or all-read-edit-true did not resolve the issue. (in fact, if I do that, many pictures are not viewable - they are still there and linked, but show broken image)
Granting the ImageSearch read permissions did not help.
granting localhost, 127.0.0.1, our url and our IP read permissions did not help.
2 API-Queries returned expected results (https://dpaste.de/0Adz for ?action=query&prop=imageinfo&iiprop=url|size&iiurlwidth=220&titles=File:Logo.jpg&format=json and ?action=query&prop=imageinfo&iiprop=url|size&titles=File:Logo.jpg&format=json

Locally (on a Ubuntu machine) the pictures are being shown, yet the local media repo is empty to the VE.

We are running parsoid as a service run by root, the log file reports API request failed when trying to edit a page with pictures in it.

The used versions are MediaWiki 1.23.5, VE Snapshot 1.23, nodejs 0.10.30, Parsoid snapshot 1.23

--------------------------
**Version**: unspecified
**Severity**: normal
This bug could not be reproduced and is now three years old, so I'm closing.
**lhug** wrote:

Parsoid Log w. debug

This is the Parsoid log with debugging info when opening a page with a picture in it. Since I have no idea what exactly is happening in that parsoid service, or when it happens, maybe someone else can tell me what to do with this.

The fails API-request is easily notable

**Attached**: {F14960}
**lhug** wrote:

A direct call of the api query the VE starts shows definite parsing errors.
https://dpaste.de/8AhK is the result of the API-Query on the live system.

https://dpaste.de/DKwm is the result of the same page on the local system.

Notice the imagelinks in the first link are still in [[]].
VisualEditor build documentation via Grunt [1] and publish via Jenkins.
One of the benefits of this is you can use a jsduckcatconfig that pulls in documentation from core.

We should do the same.

[1] https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FVisualEditor/f35d577acb57319241ea992a95cb045298662cd8/Gruntfile.js

--------------------------
**Version**: unspecified
**Severity**: normal
Change 174851 merged by jenkins-bot:
Run jsduck through grunt

[[https://gerrit.wikimedia.org/r/174851]]
Change 174851 had a related patch set uploaded by Bmansurov:
Run jsduck through grunt

https://gerrit.wikimedia.org/r/174851
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/w96Isqis
screenshot in desktop browser

Steps to reproduce:

1.Open the wikitext editor for any page in en.m.wikipedia.org 
2.Make some edit
3.Click on "Next"

Observed Result:

There is no preview bar appearing at the top of the page indicating it's a preview as it does in iOS safari for iPhone.


See the screenshots attached

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

**Attached**: {F14824}
Duplicate of T76624
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/C7zx3kLC
Created attachment 16947
screenshot from iPhone

**Attached**: {F14825}
Newly filed bugs with empty description are not accounced on IRC. Bug 72705 wasn't pushed to #mediawiki-visualeditor when I filed it.

--------------------------
**Version**: unspecified
**Severity**: normal
Yeah, Bugzilla doesn't send messages to wikibugs-l, so pywikibugs cannot report anything. See #64836.

*** This bug has been marked as a duplicate of bug 64836 ***
* CtaDrawer down icon is not centered
* Switcher in VisualEditor/Wikitext editor
* Notification icon tiny mw-ui-icon-notification isn't sized correctly – font-size: 1.3em
* Clicking the notification icon doesn't hide it while the notifications are loading
* #page-actions .mw-ui-icon:before (the page actions) margin needs to be lowered
Animation of the watchstar is broken
* Toggleable (?) elements (Contents, section headings) don't have cursor: pointer
* Watch star in page actions moves slightly to the left every time you click it
* Provide SVG versions of all icons which currently only use SVGS
The watchstar in the search results is tiny
.mw-ui-icon-arrow-up isn't positioned hard-right when Contents is open

--------------------------
**Version**: unspecified
**Severity**: normal
I split this into various bugs to be more actionable
Also:
* face icon (logged in vor not logged in) in Special:MobileDiff repeats itself
Also 
* close icon in image overlay repeats itself
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/Vh51EzgU
Example: https://www.mediawiki.org/w/index.php?title=Project%3ASandbox&diff=1242918&oldid=1242833

Summary input: "Test". The summary was not saved.

--------------------------
**Version**: unspecified
**Severity**: normal
No, sry for delay.
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 169953 merged by jenkins-bot:
Save summary in VisualEditor

https://gerrit.wikimedia.org/r/169953
Change 169952 merged by MaxSem:
Save summary in VisualEditor

https://gerrit.wikimedia.org/r/169952
Change 169953 had a related patch set uploaded by MaxSem:
Save summary in VisualEditor

https://gerrit.wikimedia.org/r/169953
Change 169952 had a related patch set uploaded by MaxSem:
Save summary in VisualEditor

https://gerrit.wikimedia.org/r/169952
Maybe LD this patch in the next SWAT? The latest wmf branch was created today (without this patch), so Wikipedias will get thid patch in 14 days, which is a long time :/

The edit summary is an important feature to summarize an edit, it's bad, that a users summary message will not be saved and a reviewer maybe think the user doesn't submitted a summary.
Change 169778 merged by jenkins-bot:
Save summary in VisualEditor

https://gerrit.wikimedia.org/r/169778
Change 169778 had a related patch set uploaded by Bmansurov:
Save summary in VisualEditor

https://gerrit.wikimedia.org/r/169778
Hmm :/ I tested it again: https://m.mediawiki.org/wiki/Special:MobileDiff/1245793

Used Chrome desktop and stable mode. Clicked the lead section edit, write down some test text and click save. In the "Summary" field i insert "Test submit" and clicked save. The edit is saved, but not the summary :(
I'm not able to reproduce. My summary has been saved correctly:
https://www.mediawiki.org/w/index.php?title=Project%3ASandbox&diff=1245788&oldid=1245681

also this: https://www.mediawiki.org/w/index.php?title=Project%3ASandbox&diff=1245791&oldid=1245788

Can you give me instructions how to reproduce this?
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/9UaadG2M
I notice VisualEditor has lots of Grunt magic. If I'm not mistaken the Gruntfile on each merge [1].

Can a similar job be setup on mobile and could I grab one of either Krinkle and Antoine to see what else Mobile can do to get the most out of this Gruntfile?

[1] https://integration.wikimedia.org/ci/job/oojs-ui-npm/1740/console

--------------------------
**Version**: wmf-deployment
**Severity**: normal
Fixed by @Jdlrobson who added the necessary npm  / package.json entries and crafted the Jenkins jobs.
Change 174696 had a related patch set uploaded by Krinkle:
Add mwext-MobileFrontend-npm job

https://gerrit.wikimedia.org/r/174696
The Gruntfile is created. Is there anything else we need to do? I'm not sure what you mean by "once its working" does this mean working locally or working in some other form?
Creation of Gruntfile is to be done by MF maintainers. Once it's working, let me know and I'll create/enable the job. Or alternatively, submit a patch to integration-config (should be a 2-3 line change) that I'll merge/deploy.
Email I sent to Yuvi:

tl;dr: grrrit-wm is broken right now, it's not relying messages, and
when we try and attempt to kill it with qdel, it goes into some error
state and keeps connecting/quitting.

huh (PiRSquared) thinks he broke it when quieting it in another channel,
it was down for a while before I came online. He asked if he could
upgrade the irc node module it was using, so I said sure since he
already had access...that didn't work, so he reverted it, but it's still
not working.

I logged into gerrit-to-redis, and based on the log messages it appears
to be working fine (I also restarted it just in case, and it was working
fine after the restart)

So yeah...halp?

<http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-dev/20141026.txt> is
our log trying to figure stuff out.

---

Second email:

To stop spam, we moved the config.yaml to "config_moved-cuz-bug" so it
would stop joining. It also finally died from qstat.

At this point I'm not going to touch it until you or someone else has
time to debug it...

--------------------------
**Version**: unspecified
**Severity**: normal
I think this should be fixed now in https://github.com/martynsmith/node-irc/pull/187
Leaving this open as the actual bot still needs fixing...
**gerritadmin** wrote:

Change 168927 merged by jenkins-bot:
Bug 72523: Remove #wikimedia-growth

https://gerrit.wikimedia.org/r/168927
**gerritadmin** wrote:

Change 168927 had a related patch set uploaded by Legoktm:
Bug 72523: Remove #wikimedia-growth

https://gerrit.wikimedia.org/r/168927
Thanks, Merlijn!
I can't get the patch in from tools and the patch uploader has memory issues, so here's the patch:

commit 419e36d490f14d623633e79cf54dc46bb15dbd94
Author: Merlijn van Deen <valhallasw@gmail.com>
Date:   Sun Oct 26 20:23:16 2014 +0000

    Bug 72523: Remove #wikimedia-growth

diff --git a/config.yaml b/config.yaml
index 01797e0..adb052d 100644
--- a/config.yaml
+++ b/config.yaml
@@ -126,10 +126,6 @@ channels:
         "mediawiki/extensions/ValueView",
         "mediawiki/extensions/Capiunto"
         }
-    "#wikimedia-growth": {
-        "mediawiki/extensions/GuidedTour",
-        "mediawiki/extensions/GettingStarted"
-        }
     "#wikimedia-multimedia": {
         "mediawiki/extensions/CommonsMetadata.*",
         "mediawiki/extensions/MultimediaViewer.*",
I reverted the config.yaml move and the bot is now connected to freenode and seems stable. The stream seems broken, though.
video capture

Steps to reproduce:

1.Open a page with VE
2.click on link inspector icon 

Observed Result:
Link inspector opens with an animation from top

See the video capture attached

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

**Attached**: {F14920}
This is no longer happening.
There's an animation?
Can't reproduce.
VisualEditor team is using a grunt file. Flow have also moved to one of these.

One of the benefits of the Gruntfile is Jenkins will run `grunt test` on every commit meaning we can get Jenkins automating quite a few things for us.

MobileFrontend should also use it.

One of the benefits of this will be jscs running on every Jenkins build (currently this only runs in a pre commit hook)

--------------------------
**Version**: unspecified
**Severity**: normal
Change: https://gerrit.wikimedia.org/r/#/c/168656/

Merged.
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/ecXDbChX
It seems like nowiki-tags show up at edits done at nowiki with VisualEditor.

The first of the two examples (https://no.wikipedia.org/w/index.php?title=Cologne_Business_School&diff=13473599&oldid=13473538) could be a copy-paste. If so it is an user error and the same as in Bug 68928 VisualEditor: Copy/pasting causes <nowiki> and <em> tags to appear.

The second edit seems to be different (https://no.wikipedia.org/w/index.php?title=Bergen&diff=prev&oldid=13467156) and I'm not sure what has happened here. Perhaps it is Bug 49820 - VisualEditor: When user types in '[[' in the page or another DOM input widget, pop up a reminder that they're using VisualEditor. If this is the case the user has clicked through a warning (has it failed?) and still saved.

There is a thread at nowiki about this, https://no.wikipedia.org/wiki/Wikipedia:Torget#Tomme_nowiki-tagger ("Empty nowiki-tags")

--------------------------
**Version**: unspecified
**Severity**: normal
@Elitre is correct that the two bugs look like they are due to pasting wikitext into a place where wikitext doesn't work. Given the changes since then, this is unlikely to be as much of an issue, but we really can't stop users from doing the wrong thing in all occasions.
This should perhaps be a feature request as it seems to be about additional warning messages.
Allow me to underline the irony of a nowiki at no.wiki :D

I don't think the first case is related to that bug - that simply looks like wikicode copy/pasted in a VE instance, that's why the nowiki tags are generated.

The second case looks more like a confused attempt to edit a wikilink, similar to [[bug 70286]].

As for wikitext warnings, those do exist, but I don't know if they're currently working (I filed a bug about that today) or if they're supposed to work when you copy/paste (not type) wikicode. I'd argue this should be possibile, since this is not the first time we see copy/pasting confusion.
Screenshot

Steps to reproduce:

1.Open a page with mobile VE using desktop Safari
2.Edit something on the page, click on the back button at the top left corner and observe the alignment of "Ok" and "Cancel" button in the confirmation dialog for abandoning edit
3.Click cancel and now click on the button to switch to the edit source mode from the Settings menu

4.Observe the alignment of "Ok" and "Cancel" button in the confirmation dialog for switching to edit source mode

Observed Result:
The buttons are misaligned as seen in the screenshot attached

Environment:
Betalabs, test2 and production

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

**Attached**: {F14709}
Going with the latter for now.
These are native confirm dialogs, so this bug is upstream or invalid...
While some templates are easy to use in VE, this is not. At first VE doesnt load automatically its parameters, at second you need to enter hyperling to its values, but VE doesnt offer tools for that.

Its often used template which gives information, about subjects with the same title.

https://cs.wikipedia.org/wiki/%C5%A0ablona:Mo%C5%BEn%C3%A1_hled%C3%A1te

--------------------------
**Version**: unspecified
**Severity**: normal
That's tracked as bug 52581.
(In reply to Alex Monk from comment #4)
> How would VE grab a list of parameters without there being TemplateData...?

Thats a question for you. I am not a specialist, I dont know.
How would VE grab a list of parameters without there being TemplateData...?
Andre: I dont think so.

Elitre: I thought VE grabs it even there is no TD.
I don't think so. It seems to me this template lacks TemplateData information (https://www.mediawiki.org/wiki/Help:TemplateData ). That's easier to add now (see my announcement at https://cs.wikipedia.org/wiki/Diskuse_k_Wikipedii:VisualEditor/TemplateData ).
At the moment, you need to use wikimarkup inside templates' fields, so you can use double square brackets to make links.
If you need further help, please feel free to reach me at your wiki.
(In reply to Juan de Vojníkov from comment #0)
> At first VE doesnt load automatically its parameters

Is that bug 69734?
This may only be happening to links inside templates or refs.  

Steps to reproduce:

1.  Click on https://en.wikipedia.org/wiki/HOSxP?veaction=edit

2.  Watch the URL in the infobox turn red.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 72251 ***
File: https://github.com/wikimedia/mediawiki-extensions-EventLogging/blob/master/modules/ext.eventLogging.subscriber.js


The ext.eventLogging.subscriber.js has not worked since past April. Visual Editor editor was using it to submit its events to EL. 

While VE is removing usage of this class (as it really not needed on their case) we should either fix it or remove other usages of it. Sounds like its only usage on the codebase (besides Visual Editor's) is to report usage of deprecated javascript functions.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 167326 merged by jenkins-bot:
Fix off-by-one error in mw.track subscriber

https://gerrit.wikimedia.org/r/167326
(In reply to Roan Kattouw from comment #1)
> Specifically, what's broken is the way that it tries to derive the schema
> from the topic name. The things that are broken about it are:
> 
> * It ends up trying to load schema..foo (double dot)
My patch fixes this.

> * It documents that the topic must start with 'event.', and tries to strip
> that (leaving the dot), but none of the callers actually pass 'event.'
This seems to be deliberate, because it only listens for events that start with 'event'. My patch changes this to 'event.' so we don't capture random other stuff.

> * If the schema is not found (which due to the bugs above is virtually
> always the case), it fails silently with no warning logged anywhere
> 
This doesn't seem to be true: ResourceLoader does log an error about not being able to find a module called schema..foo

> It's been suggested that subscriber.js (and mw.track(), which it
> facilitates) just needs to be put out of its misery. VisualEditor is using
> it, but there's no good reason for that and I'm porting it to call
> EventLogging directly. However, a few things in MediaWiki are using
> mw.track(), and some of them would benefit from deferred loading (they may
> call mw.track() very early, before EventLogging has been loaded), so those
> would have to be looked at.

Right now Dan is suggesting we just keep it around.
Change 167326 had a related patch set uploaded by Catrope:
Fix off-by-one error in mw.track subscriber

https://gerrit.wikimedia.org/r/167326
Specifically, what's broken is the way that it tries to derive the schema from the topic name. The things that are broken about it are:

* It ends up trying to load schema..foo (double dot)
* It documents that the topic must start with 'event.', and tries to strip that (leaving the dot), but none of the callers actually pass 'event.'
* If the schema is not found (which due to the bugs above is virtually always the case), it fails silently with no warning logged anywhere

It's been suggested that subscriber.js (and mw.track(), which it facilitates) just needs to be put out of its misery. VisualEditor is using it, but there's no good reason for that and I'm porting it to call EventLogging directly. However, a few things in MediaWiki are using mw.track(), and some of them would benefit from deferred loading (they may call mw.track() very early, before EventLogging has been loaded), so those would have to be looked at.
VE has a variety of schemas[1] that are not correctly feeding into the EL databases. They need assistance in figuring out what's happening.

Dario suspects that the events are failing validation.

[1] https://meta.wikimedia.org/w/index.php?title=Special%3ASearch&profile=advanced&search=VisualEditor&fulltext=Search&ns470=1&profile=advanced

--------------------------
**Version**: unspecified
**Severity**: normal
Edit team has a dashboard that is fed data from the DB, so everything seems ok from our point of view: http://edit-reportcard.wmflabs.org/
Roan.. can you clarify a bit your last comment? me no comprendo.
(In reply to Roan Kattouw from comment #2)
> Turns out EventLogging's mw.track subscriber is broken, and VisualEditor was
> using it for no good reason. I'll port VE to use EL directly, but there are
> other uses of mw.track and those are probably broken too:
> 
> resources/lib/jquery/jquery.migrate.js:65:mw.track( "jquery.migrate", key ||
> "unknown" );
> resources/src/mediawiki/mediawiki.js:567:mw.track( 'mw.deprecate', key );
> resources/src/mediawiki/mediawiki.js:572:mw.track( 'mw.deprecate', key );

ACTUALLY... the WikimediaEvents extension includes subscribers for both ve.* events and for these two. So they DO end up in EventLogging, just not via EventLogging's subscriber. It looks like nothing is just EventLogging's subscriber, which only subscribes to things starting with 'event.*'

The schemas used by WikimediaEvents are:
ve.* --> Schema:TimingData
jquery.migrate --> Schema:JQMigrateUsage
mw.deprecate --> Schema:DeprecatedUsage
Turns out EventLogging's mw.track subscriber is broken, and VisualEditor was using it for no good reason. I'll port VE to use EL directly, but there are other uses of mw.track and those are probably broken too:

resources/lib/jquery/jquery.migrate.js:65:mw.track( "jquery.migrate", key || "unknown" );
resources/src/mediawiki/mediawiki.js:567:mw.track( 'mw.deprecate', key );
resources/src/mediawiki/mediawiki.js:572:mw.track( 'mw.deprecate', key );
No new events are coming in for schemas like VisualEditor%:

zsub vanadium.eqiad.wmnet:8600 | grep '"schema": "VisualEditor'

But at least two of the events used to validate at some point at the end of 2013, beginning of 2014:

mysql:research@analytics-store.eqiad.wmnet [log]> select min(timestamp), max(timestamp) from VisualEditorDOMSaved_6063754;
+----------------+----------------+
| min(timestamp) | max(timestamp) |
+----------------+----------------+
| 20131016202600 | 20131121114538 |
+----------------+----------------+
1 row in set (0.00 sec)

mysql:research@analytics-store.eqiad.wmnet [log]> select min(timestamp), max(timestamp) from VisualEditorDOMRetrieved_5961496;
+----------------+----------------+
| min(timestamp) | max(timestamp) |
+----------------+----------------+
| 20131010222635 | 20140128212543 |
+----------------+----------------+
1 row in set (0.00 sec)

The most likely explanation is that the events are no longer emitted, as we don't see them in the raw stream.  So, in short, look around 20131121114538 and 20140128212543 to see what changed in your instrumentation.  We're setting up a meeting to discuss further, but feel free to comment here too.
1. Go to https://www.mediawiki.org/w/index.php?title=Manual:Coding_conventions/Ruby&redirect=no&veaction=edit (revision: https://www.mediawiki.org/w/index.php?title=Manual:Coding_conventions/Ruby&oldid=1226556 )

2. Put the caret at the end of the second paragraph after "staff".

3. Move the caret forward with the keyboard using the "right arrow" key repeatedly

Expected: The caret must move forward through the three footnote numbers.

Observed: The caret moves to the first reference and then back before it.

This is similar to bug T73550.

--------------------------
**Version**: unspecified
**Severity**: normal
Works for me now. Wish we could confirm when we'd fixed this. :-(
screenshot

Environment- test2, beta

1> Add a new category say- Japan.
2> select the category to delete it. Notice the context menu appears out of position.

see screenshot.

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

**Attached**: {F15006}
*** This bug has been marked as a duplicate of bug 72052 ***
Environment- test2

1> In VE enter external link e.g- http://lowes.com . Save the page. Takes you to Read mode.
2> Select Edit tab again and Edit the external link to google.com. Save the page.
3> In the Read mode click on the external link to open the page. Navigates to google page. Now click on the back browser button. You would expect this to navigate you to the most recently saved page in VE , but click on the link and it opens lowes page . 
4> Now click on Edit tab and it would show google.com as the link.


Page in VE with lowes.com ->edit and saved the page with google.com -> google.com(current page)
                                                                            
                                                                                                                                                  
                                                                                                                                                                                                                                                                                            
Hit the back button.

Page in VE with lowes.com(takes me here)  -> edit and saved the page with google.com (should have navigated here)-> google.com

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows XP
Re-checked it in test2 and betalabs - seems to be working fine.
(In reply to Ritu Swain from comment #2)
> (In reply to James Forrester from comment #1)
> > I can't reproduce this; can you confirm it's still an issue? (Test
> > environment: Beta Labs, Chrome 38, Mac OS X 10.10)
> 
> I cannot reproduce it anymore in test2 or beta.

OK, marking as FIXED though I know not how.
(In reply to James Forrester from comment #1)
> I can't reproduce this; can you confirm it's still an issue? (Test
> environment: Beta Labs, Chrome 38, Mac OS X 10.10)

I cannot reproduce it anymore in test2 or beta.
I can't reproduce this; can you confirm it's still an issue? (Test environment: Beta Labs, Chrome 38, Mac OS X 10.10)
Environment- test2, beta

In the Reference dialog and Media Settings Caption dialog, before even  I could scroll down the Annotations menu list and select the Language tool or Clear styling,  the pull-down closes, making it difficult to  apply them to existing content.


Environment-test2 only

Similarly, in the Transclusion dialog -> Add a Template field, when you start typing and the suggestion list is shown, before you could scroll the list, it closes, making it unusable.

--------------------------
**Version**: unspecified
**Severity**: minor
**OS**: Windows XP
Merging into bug 65774.

*** This bug has been marked as a duplicate of bug 65774 ***
This bug has been observed for a while on fr.wp and thus unofficially reported time ago, but now User:Drongou has kindly provided instructions to replicate it, so:

1) Copy/paste something between square brackets, say [[2013]]
2) Place the cursor before the 3 and type 4, so that it becomes [[20143]]
3) Type a space, so it now looks like [[2014 3]]
4) Remove the 3 and save.
 
The result will be <nowiki>[[2014 ]]</nowiki>.
Confirmed at least on Safari 7.1, Mac OS-X 10.9 .

--------------------------
**Version**: unspecified
**Severity**: normal
This is already covered in bug 52037 – it's really messy, yeah.

*** This bug has been marked as a duplicate of bug 52037 ***
Switcher icon not visible

In EditorOverlay the icon for the editor switcher (VE or Source) isn't visible (see attachment). You can still click/tap on the position and you can switch, but nobody know, that the switcher is there.

Reported first on https://www.mediawiki.org/wiki/Thread:Extension_talk:MobileFrontend/visualeditor_abandoned

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F15397}
Working now :)
**gerritadmin** wrote:

Change 164584 merged by jenkins-bot:
Use less function to embed editor images

https://gerrit.wikimedia.org/r/164584
**gerritadmin** wrote:

Change 164587 merged by jenkins-bot:
Use less function to embed editor images

https://gerrit.wikimedia.org/r/164587
**gerritadmin** wrote:

Change 164543 merged by jenkins-bot:
Use less function to embed editor images

https://gerrit.wikimedia.org/r/164543
**gerritadmin** wrote:

Change 164587 had a related patch set uploaded by Florianschmidtwelzow:
Use less function to embed editor images

https://gerrit.wikimedia.org/r/164587
**gerritadmin** wrote:

Change 164584 had a related patch set uploaded by Florianschmidtwelzow:
Use less function to embed editor images

https://gerrit.wikimedia.org/r/164584
**gerritadmin** wrote:

Change 164543 had a related patch set uploaded by Florianschmidtwelzow:
Use less function to embed editor images

https://gerrit.wikimedia.org/r/164543
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/799d4SR5
The author of this revision https://fr.wikipedia.org/w/index.php?title=La_Grange_au_Lac&diff=107837547&oldid=107804115 realizes that the wikicode he copy/pasted was not valid. The question is, does VE really need 5 nowiki tags to inform us? Can there be a good way of warning the user, maybe one which at the same time allows unexperienced editors to avoid saving and fix that mess?

--------------------------
**Version**: unspecified
**Severity**: normal
Yes, T73426.
>>! In T73422#754038, @Elitre wrote:
> I'll file a bug against Parsoid, thanks.

Any ticket ID handy?
It could also be a warning just like those for "Comments", with a different icon and/or color. This plus a warning on save, indicating the line, suggesting to "switch to source editing" and correct it directly in the code ?
But this won't be efficient if the user doesn't know the wikicode.
I'll file a bug against Parsoid, thanks.
Could we expose the specific issue, like, telling at which line it is and highlighting it? I realize pointing at code is not a great idea in a visual editor.
Maybe we could have an additional warning on save, like we do for suspected page corruption?
There is already a warning that appears in the top right corner. Maybe that warning could be made better?

The number of nowiki tags there is a bit excessive; that's a bug in Parsoid.
See https://de.wikipedia.org/wiki/Benutzer:Elitre_(WMF)/sandbox?veaction=edit .
Place your cursor after the last period of any section, and start typing. 
The first letter of your word will get added to the beginning of the following line.
Hit Backspace; now the whole word appears there.
Verified also on en.wp on the Chess article.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51932
Please reopen if you manage to reproduce this issue again.
Is this still occuring? I can't reproduce the issue...
Screenshot

Steps to reproduce:

1.Insert 3 citation notes next to a text
2.Now select the 3rd one
3.Select the second one and edit it
4.Select the first one and edit it
5.Again select the 3rd one to edit it


Observed Result:
"TypeError: this.$documentNode is undefined" appears in the console.

See the screenshot attached.

This happens in Firefox only.

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

**Attached**: {F14758}
The error is not displayed anymore.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Cite>Basic 
3.Open the drop down box for "Use this group"


Observed Result:
The drop down box appears very small 

See the screenshot attached

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

**Attached**: {F14754}
Sorry ,it is a duplicate, I could not find this bug in BZ, so reported it.
Sorry ,it is a duplicate, I could not find this bug in BZ, so reported it.

*** This bug has been marked as a duplicate of bug 71178 ***
Most of the language jobs fail with the same errors. This is example for cs[1]. The parent job is [2].

...
00:18:18.444 Failing Scenarios:
00:18:18.444 cucumber features/language_screenshot.feature:42 # Scenario: VisualEditor_Page_Settings
00:18:18.444 cucumber features/language_screenshot.feature:142 # Scenario: VisualEditor_cancel_save
...

1: https://integration.wikimedia.org/ci/job/browsertests-VisualEditor-language-screenshot-linux-firefox/LANGUAGE_SCREENSHOT_CODE=cs,label=contintLabsSlave%20&&%20UbuntuPrecise/5/console
2: https://integration.wikimedia.org/ci/job/browsertests-VisualEditor-language-screenshot-linux-firefox/

--------------------------
**Version**: wmf-deployment
**Severity**: normal
Looks like the problem is fixed by the above commit. Please reopen the bug if something is still failing.
Change 163185 merged by jenkins-bot:
[BrowserTest] Fixed failing language screenshot scenarios

https://gerrit.wikimedia.org/r/163185
Change 163185 had a related patch set uploaded by Jforrester:
[BrowserTest] Fixed failing language screenshot scenarios

https://gerrit.wikimedia.org/r/163185
Change 162879 merged by jenkins-bot:
[BrowserTest] Disable screenshots for broken scenarios

https://gerrit.wikimedia.org/r/162879
Change 162879 had a related patch set uploaded by Zfilipin:
[BrowserTest] Disable screenshots for broken scenarios

https://gerrit.wikimedia.org/r/162879
Some features of WikiEditor probably aren't going to be developed much in the future. One such feature that I noticed is "Side by side preview". (I might actually be wrong, and this feature may be in development.)

If these features will no be developed further, the messages for them should be removed, because currently translators' time is wasted on them.

--------------------------
**Version**: unspecified
**Severity**: normal
All messages of modules that aren't actually in use (either at WMF or externally) have been removed.

Publish and side-by-side preview have remained.
The following patch removes previewDialog, since it probably isn't used anywhere anyways.
https://gerrit.wikimedia.org/r/#/c/176512/
>>! In T73287#795508, @TheDJ wrote:
> side by side (aka preview), is a mode where you can switch between 3 tabs (source, preview, diff) that have live preview features
Now //THAT// sounds like something Wikisource, Wikibooks, & the like could really use.. and even build upon -- //but I know better than to get my hopes up by now though//.

If the consensus is better to trim it out, then I'd be OK with that too. 

> previewDialog, even I don't know about ...(probably because it's disabled for everyone, incl fresh installs).
If we follow the existing premise, its safe to say its going to do the same thing as 'preview' does using tabs hinged to the basic WikiEditor but with a MediaViewer-ish type of floating window/interface instead. //yawn// I see no point in pursuing something like that.
side by side (aka preview), is a mode where you can switch between 3 tabs (source, preview, diff) that have live preview features

Publish gives you a dialog that basically replaces the summary and copyright disclaimer that is below the edit screen.

Both have some users outside of Wikimedia, I know from bugreports that have been filed over the past few years.

previewDialog, even I don't know about ...(probably because it's disabled for everyone, incl fresh installs).
Most of the "original" modules like 'toc', 'highlight' & 'templateEditor' are already gone. Not sure what "Side-by-side preview" is; I've never come across anything like that. But if you go by a current mock-up of features...
```
lang=php, name=mock $wgWikiEditorFeatures, lines=4, counterexample

// Each module may be configured individually to be globally on/off or user preference based
$GLOBALS['wgWikiEditorFeatures'] = array( 

	/* Textarea / i-frame compatible (OK to deploy) */

	// Enhanced toolbar
	'toolbar' => array( 'global' => false, 'user' => true ),
	// Provides interactive tools using dialogs
	'dialogs' => array( 'global' => false, 'user' => true ),
	// Hide signature button from main namespace
	'hidesig' => array( 'global' => true, 'user' => false ), 

	/* Textarea / i-frame compatible, but still experimental and unstable (do not deploy!) */

	// Adds a tab for previewing in-line
	'preview' => array( 'global' => false, 'user' => true ),
	// Adds a button for previewing in a dialog
	'previewDialog' => array( 'global' => false, 'user' => false ),
	//  Adds a button and dialog for step-by-step publishing
	'publish' => array( 'global' => false, 'user' => true ),

); 
```
... the only thing I can guess that might be is the in-line (or live?) preview module. I've never seen 'publish' at work or heard anything about it either. And of course, hideSig is still in effect though it hasn't "worked" for months now.

That said, I can go along with removing the "abandoned" feature bits - unless somebody knows better. The focus is on developing VisualEditor as far as I can tell anyway. I just hope they keep something like WikiEditor around for the non-Wikipedia types of projects.
Most of the "original" modules like 'toc', 'highlight' & 'templateEditor' are already gone. Not sure what "Side-by-side preview" is; I've never come across anything like that. But if you go by a current mock-up of features...
```
lang=php, name=mock $wgEditorFeatures, lines=4, counterexample

// Each module may be configured individually to be globally on/off or user preference based
$GLOBALS['wgWikiEditorFeatures'] = array( 

	/* Textarea / i-frame compatible (OK to deploy) */

	// Enhanced toolbar
	'toolbar' => array( 'global' => false, 'user' => true ),
	// Provides interactive tools using dialogs
	'dialogs' => array( 'global' => false, 'user' => true ),
	// Hide signature button from main namespace
	'hidesig' => array( 'global' => true, 'user' => false ), 

	/* Textarea / i-frame compatible, but still experimental and unstable (do not deploy!) */

	// Adds a tab for previewing in-line
	'preview' => array( 'global' => false, 'user' => true ),
	// Adds a button for previewing in a dialog
	'previewDialog' => array( 'global' => false, 'user' => false ),
	//  Adds a button and dialog for step-by-step publishing
	'publish' => array( 'global' => false, 'user' => true ),

); 
```
... the only thing I can guess that might be is the in-line (or live?) preview module. I've never seen 'publish' at work or heard anything about it either. And of course, hideSig is still in effect though it hasn't "worked" for months now.

That said, I can go along with removing the "abandoned" feature bits - unless somebody knows better. The focus is on developing VisualEditor as far as I can tell anyway. I just hope they keep something like WikiEditor around for the non-Wikipedia types of projects.
Intention:
I tried to insert a template using VisualEditor when editing or creating pages on dewiki.

Steps to Reproduce:
1. Enable Visual Editor in the Beta preferences
2. Open a random page on dewiki and edit it.
3. Click ‘Einfügen’ → ‘Vorlage’ (= ‘Insert’ → ‘Template’).

Actual Results:  
A pop-up opens, but does not load (title: ‘Laden …’ = ‘Loading …’). The pop-up cannot be closed (hitting ‘Abbrechen’ = ‘Cancel’ does not work), so the previous changes are lost.

Expected Results:  
Instead the template editor should open normally.

Reproducible: Always

Using vector with Firefox 32.0 on Kubuntu 14.04.

JS error (Firefox web console):
TypeError: queue is undefined ve.dm.MWTransclusionModel.js:136

--------------------------
**Version**: unspecified
**Severity**: normal
You're welcome. On de.wp you can find me at https://de.wikipedia.org/wiki/Wikipedia:Technik/Text/Edit/VisualEditor/Beta2013-07 . Please let us know of any further issues, or just leave your thoughts about your experience with VE. Thank you.
Hmm, strange.  The problem does not occur with a blanked common.js, though the user scripts did not report an error.  Anyway, thanks for the assistance; I’ll have another look at the user scripts.
I can't reproduce with the same browser but in Windows 8.
Robin, can you please try to add a template in incognito mode to https://de.wikipedia.org/wiki/Benutzer:Elitre_(WMF)/sandbox?veaction=edit and tell us what happens? Thanks.
Created attachment 16552
Screenshot of the stuck template pop-up with Firefox 32.0 on Kubuntu 14.04

**Attached**: {F14915}
Citations broken display

Environment- Test2, beta, production

1> Cite Basic -> Select to insert any citation(book/journal/news/website)
2> In the resulting modal, just click insert button.
3> Notice the citation appears broken momentarily and then gets added to the Reference editor.

See screenshot.

--------------------------
**Version**: unspecified
**Severity**: minor
**OS**: Windows XP

**Attached**: {F14809}
Done.
Please close this issue, i cannot reproduce it anymore.
The article [[iOS]] in the English Wikipedia has {{lowercasetitle}}, which is a wrapper for {{displaytitle}}.

It works correctly for display, but isn't shown in the Advanced settings dialog.

--------------------------
**Version**: unspecified
**Severity**: normal
I'm guessing this is because the displaytitle is transcluded in?
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Open the citation dialog for an existing citation
3.Place the cursor on any field that has an input in it.

Observed Result:
The citation dialog opens with a weird animation and the first textbox appears much larger


See the screenshot attached.

Environment:Betalabs, test2 and production

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

**Attached**: {F14782}
This seems to now be fixed?
New Section tab in Beta

Environment-Production, Test2, beta

1> Go to Advanced Settings and enable the “Show a tab on this page to add a new section” and apply changes.
2> Save the page.Switch back and forth between the Edit beta and Read tab, notice the new section/Add topic tab is not added to the Toolbar. It gets added only after clicking on Edit Source tab and then Edit beta tab.
3>Now  go back to Advanced Settings.Change the “Show a tab on this page to add a new section”  to No and apply changes.
4>Save the page.
5> Go back to the editor and notice the new section tab is still visible . And it is only when you click on the Edit source tab, that the New Section tab goes away from the Toolbar.

--------------------------
**Version**: unspecified
**Severity**: minor
**OS**: Windows XP

**Attached**: {F14727}
*** This bug has been marked as a duplicate of bug 20177 ***
Created attachment 16470
Add Topic in Test2

**Attached**: {F14728}
References list

Environment- Test2, beta

1> Have at least 2 citations on the page.
2> Select Basic  -> Use an Existing Reference. The selected citation to re-use gets inserted on the page.
3> Now while the  re-used citation is still highlighted. Select “Basic” again and type in a name  in the “Use this group” input box.
4> Apply changes.
5> In the editor that citation gets replaced by the group name. Now delete all the citations from the page.
6> Select Insert -> References list. And click on the arrow in the “Use this Group” drop-down. Notice the group name assigned in step#3 is still visible in the suggestion list drop-down.

Same thing happens when you try to access the “Use this group” in the basic citation.
See screenshots.

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

**Attached**: {F14722}
(In reply to Rummana Yasmeen from comment #2)
> Hey Ritu, this is intentional, because even if user deletes the citations
> that belongs to a specific group, user might want to use that group later
> and add other citations to that in that edit session.So, instead of making
> user to do the same step again , we are keeping the group name for that
> session, however if you save your edit after step 6 , you will no longer see
> that group name.

yes, i saw that too. But was assuming that the suggestions would get updated too when the page has no citations. got it now.
Hey Ritu, this is intentional, because even if user deletes the citations that belongs to a specific group, user might want to use that group later and add other citations to that in that edit session.So, instead of making user to do the same step again , we are keeping the group name for that session, however if you save your edit after step 6 , you will no longer see that group name.
Created attachment 16468
Basic Citation

**Attached**: {F14723}
I added a description to my new category https://en.wikipedia.org/wiki/Category:Conspiracy_theories_in_popular_culture using VisualEditor.

After I saved the category page, my new description was not visible. I had to reload the page, and then it was displayed.

--------------------------
**Version**: unspecified
**Severity**: normal
Merging this with bug 56289.

*** This bug has been marked as a duplicate of bug 56289 ***
## Steps

1. Select an image node.
   https://www.mediawiki.org/wiki/VisualEditor:Basic_example_worksheet#Media_files
2. Resize a one of the small ones to be bigger. It'll fetch a large thumbnail momentarily.
3. Drag and drop the image to a different position in the surrounding paragraph.

## Unexpected behaviour

The original image resource is re-used after a drag/drop, but now upscaled by the browser, thus pixelated. And no new thumb is fetched, either.

--------------------------
**Version**: unspecified
**Severity**: normal
It seems like it's been fixed - when resized(enlarged) images are dragged&dropped - they do not get reversed to the original resolution(and, therefore,  pixelated). 

Or it could be that only specific images displayed the issue.
Span tag as seen in Firefox

https://en.wikipedia.org/wiki/Everyone_Poops?veaction=edit produces an ugly span tag above the infobox.  

The infobox is not displaying correctly at all in Safari, but in both Firefox and Safari it shows a long, large, bold-face span tag.  This appears to be caused by the <ref> tags.  See https://en.wikipedia.org/w/index.php?oldid=625300040 for a single-parameter infobox that causes the mess.

These span tags are not saved, so they don't corrupt the wikitext.

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

**Attached**: {F15303}
This is just a buggy template / template use.

The wikitext on https://en.wikipedia.org/w/index.php?oldid=625300040 leads to the following template expansion for the infobox:

...
<span class="Z3988"
          title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Everyone+Poops<ref name="bnn">{{cite web|url=http://search.barnesandnoble.com/Everyone-Poops/Taro-Gomi/e/9780916291457|title=Everyone Poops, My Body Science Series, Taro Gomi, Book|accessdate=2008-02-14|year=2009|publisher=[[Barnes & Noble]]}}</ref>"></span
...

See how the span has a title attribute that has a ref tag and transclusion. But even that brokenness is okay .. the real problem is the use of double quotes for the name attribute of the <ref> tag that is embedded in the title attribute.

So, the wikitext is effectively something like this:

<span title="....name="bnn"..."</span>

That is broken because of the use of double quotes which terminates the title attribute early. This is one of those edge-case differences between PHP parser and Parsoid. If the name="bnn" is replaced with name='bnn', this will work.

This is a wontfix on the Parsoid end since there is a wikitext edit that will handle this strange edge case.

Please reopen if there is something to do on the Parsoid end.
Looks like a Parsoid issue?
Also reported here:  https://www.mediawiki.org/wiki/Thread:VisualEditor/Feedback/Infobox_on_en.wikipedia%27s_The_Little_Prince
Created attachment 16456
Infobox as seen in Safari.  Note that the content of the box does not display in Safari.  It's blank for half a screen, and then the article text begins.

**Attached**: {F15304}
If "clear styling" is going to clear links, too, then it should say, "Clear styling and links".  

(I'd rather that it didn't clear links, because, when I copy a link from another page, I want a way to get rid of character formatting and colors without killing the links, too.)

--------------------------
**Version**: unspecified
**Severity**: enhancement
*** This bug has been marked as a duplicate of bug 51757 ***
This is related to bug 61072 and bug 50240.

Please consider marking all links to disambiguation pages in a different color, not just in the link inspector tool itself, but in the regular text that editors see when typing in VisualEditor.  This will help editors realize that there is something different (and probably wrong) with links that were previously added to the page.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This is (effectively) a duplicate of bug 7936 (which is only asking for Special:AllPages, but we'd also change it in the content display). It's nothing particularly specific to VisualEditor; VE just follows MW's lead here.

*** This bug has been marked as a duplicate of bug 7936 ***
BD2412 has specifically requested that this be available to everyone, not just for himself/people using a script.
They already are! (Or rather can be.) I implemented a way to color them in 066283dde745fcc372ffab8d753962858813d032 (the links on the editing surface now have a .mw-disambig class that can be styled with user/site CSS). I also did the same functionality in the MW parser (8cc16d021410f49fa12a2f35c97cdac51adf4380, this is not rolled out yet).

I'm not sure if we want to actually color them. Colors can be distracting/confusing, especially if it's not clear what they mean. MediaWiki has been providing a .mw-redirect CSS class in parser output for years and it was never styled in any way, as far as I know. (Some special pages mark redirects with italics, though.)

For the record, such coloring functionality has sometimes been implemented by gadgets. pl.wp has a opt-in gadget to color redirects green and disambigs maroon and add a form to the page to selectively correct the links; ru.wp has some tool enabled for everyone that gives disambigs pink background with red outline (or had, last time I checked). I am not aware of any such thing on the English Wikipedia (but I'd be love to learn about it if it exists).
Language dialog box, as it's not meant to be

While testing on Meta, the language inspector did not open correctly.  It had some odd box drawing and no buttons.  See the screenshot.

(This is not the problem described in bug 70731.  This oddly drawn box was the correct size.)

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

**Attached**: {F15132}
This appears to now be fixed for me – testing in Firefox, Chrome and Safari.
User:Mike Christie made ten small (often single-character) edits to [[w:en:2002 Pacific typhoon season]] recently.  Edits #1 and #3 produced a generic error of "Something went wrong", and it appeared the save had failed.  

In both cases, the save worked.  The diffs are https://en.wikipedia.org/w/index.php?title=2002_Pacific_typhoon_season&diff=624878218&oldid=624550518 and https://en.wikipedia.org/w/index.php?title=2002_Pacific_typhoon_season&diff=next&oldid=624881675  None of the other, similar edits made to the article (including one in between these two) produced any errors. 

Mike usually edits in Chrome on Windows 7.  I've seen the same behavior with a generic "There was an error" message in Firefox on Mac OS 10.8.5, so it's probably affecting everything.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53093
>>! In T72705#976450, @Kabhi2104 wrote:
> {F28605} Uploaded provision.log here too for future reference and this is the link of new paste https://phabricator.wikimedia.org/P216 

Further discussion moved to {T86787}
{F28605} Uploaded provision.log here too for future reference and this is the link of new paste https://phabricator.wikimedia.org/P216
>>! In T72705#975760, @Kabhi2104 wrote:
> I am facing the same problem in ubuntu 14.04.
> When i run vagrant up i get  **" VirtualBox VM is already running. "**
> While running 127.0.0.1:8080  says  **webpage not available**
> http://imgur.com/R5ZDXCJ  regarding roles in **vagrant list-roles**
> I get full bunch of red errors while running **vagrant provision** Here: http://imgur.com/yWohm04

Adding a "me too" to a closed ticket probably isn't the best way to get good support. ;)

The errors shown from your puppet provisioning run in the screen capture don't show enough to indicate where things went wrong, just that you had a cascading dependency failure. Based solely on past experience I would guess that there was an apt-get failure that ended up blocking Puppet from doing anything else.

To get a real trace of the problem, you could run `PUPPET_DEBUG=1 vagrant reload --provision | tee provision.log` and then upload provision.log as a paste here and open a new ticket referencing it. The command given will restart the virtual machine and then force a Puppet run. The `PUPPET_DEBUG=1` environment var will tell Puppet to output more information on what it is doing at each stage of the run and `| tee provision.log` will make a copy of all the information sent to the screen in a log file that will be easier to cut-n-paste into [[https://phabricator.wikimedia.org/paste/create/|a new pastebin issue]].
I am facing the same problem in ubuntu 14.04.
When i run vagrant up i get  **" VirtualBox VM is already running. "**
While running 127.0.0.1:8080  says  **webpage not available**
http://imgur.com/R5ZDXCJ  regarding roles in **vagrant list-roles**
I get full bunch of red errors while running **vagrant provision** Here: http://imgur.com/yWohm04
Thanks for reporting this and writing it up.  I just ran into this. :(
(In reply to Bryan Davis from comment #4)
> Was the vagrant/mediawiki clone new too or potentially very old?

My vagrant/mediawiki clone was so old... (insert joke here).

Documented:

https://www.mediawiki.org/w/index.php?title=MediaWiki-Vagrant&diff=1151216&oldid=1139643
(In reply to Bryan Davis from comment #4)
> $ cd vagrant/mediawiki
> $ git pull

Wait, mediawiki (core?) does not get updated automatically!? Trying this now, will report in a few hours (when the machine is up).
Was the vagrant/mediawiki clone new too or potentially very old? At least some of these errors look like your vagrant/mediawiki/skins/Vector directory is from before the changes were merged that made Vector a separate repository. The fix for that is given in <https://bugzilla.wikimedia.org/show_bug.cgi?id=70114#c1> :

$ cd vagrant/mediawiki
$ git pull
$ cd skins
$ rm -rf Vector  # might not be a dir here to delete now but worth trying
$ vagrant provision
Surprisingly, mediawiki is available at http://127.0.0.1:8080/wiki/Main_Page
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Media
3.Enter something in the search box to search for images


Observed Result:

Nothing happens. "No Results" found message stays in the dialog instead

Environment:Betalabs

See the screenshot attached

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

**Attached**: {F14832}
Yeah may be..Working for me now as well
Works for me… Search blip?
Field description popup for template:Bugzilla on mediawiki.org

See attachment. A lot of wasted empty space, and a scrollbar :) Possibly related to other reports, or a dupe.

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

**Attached**: {F14777}
My patch for bug 70423 seems to fix this.

*** This bug has been marked as a duplicate of bug 70423 ***
Same for the Special Characters dialog.
References list trying to impress us

See screenshot (which was taken in IE), I tried with other browsers and it looked the same there.

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

**Attached**: {F14773}
*** This bug has been marked as a duplicate of bug 70016 ***
Screenshot

Steps to reproduce:


1.Open a page with VE
2.Keep it open for a while (~10-15 mins)
3.After coming back to this page, open a link inspector or a comment box 

Observed Result:
They open with no UI, see the screenshot attached.


Environment:Betalabs

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

**Attached**: {F14719}
screenshot

Environment- test2, beta

1> open a page in VE, insert some text. Open the language inspector and click on link icon.
2> Now click anywhere on the Editor and type in some more text, the language inspector closes but the link icon stays selected.See screenshot.

--------------------------
**Version**: unspecified
**Severity**: minor
**OS**: Windows XP

**Attached**: {F14676}
(In reply to etonkovidova from comment #1)
> Checked in test2 on Chrome - cannot confirm.

Not reproducible. close the issue.
Checked in test2 on Chrome - cannot confirm.
*** This bug has been marked as a duplicate of bug 63229 ***
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Media

Observed Result:
The following errors are appearing in the console:


TypeError: boundingRect is undefined

TypeError: surfaceRect is undefined

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

**Attached**: {F15082}
Yes, working fine now
This was fixed by https://gerrit.wikimedia.org/r/#/c/158519/ but not pulled through. Sorry! It's pulled through now.
screenshot1

1> open a blank page in VE, open the Language inspector. 
2> Now click anywhere in the Editor, the inspector stays open but the language style text drop-down selection turns blank. After that any selection you make, it continues to stay blank. And if you type in any text, a pawn gets inserted beside the text. See screenshots.

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

**Attached**: {F15074}
Per submitter.
Not reproducible.
Apologies.. here are the steps-

1> open a blank page in VE, open the Language inspector and select a text style from the drop-down,for ex- select Heading.
2> Now click anywhere in the Editor, the inspector  closes, but the text style drop-down selection turns blank. After that any selection you make, it continues to stay blank. And if you type in any text, a pawn gets inserted beside the text. See screenshots.

Delete the text and the pawn character and reapeat steps #1 and 2, JS console error is "Uncaught Error: Offset could not be translated to a DOM element and offset: 3".
After deleting the text and pawn characters as mentioned in the steps above when i  repeat the steps #1 and #2, i get this console error 

Uncaught Error: Offset could not be translated to a DOM element and offset: 3
Environment-test2
Created attachment 16388
screenshot2

**Attached**: {F15075}
<!-- comments are not recommended for users: it is hidden!  -->

Comments aren't recommended for new editors (and for 99% of the times for advanced users too), as must comments should be written in talk page.

It is not just a non useful feature, it is a harmful feature, as people get confused between reference and comments and it leads to "too many icons" problem. Please remove comment button from toolbar completely, or at least change it to opt-in/out feature.  (Only the toolbar icon, as the option to show and edit already written comments is important)

Side benefit: less code to maintain and less bugs ;)

--------------------------
**Version**: unspecified
**Severity**: major
James, comments are great to VIEW & EDIT, but there is no reason to ADD comments in VE. Please consider removing the button, as new editors don't understand what is "comment" (they use it instead of citation).
(In reply to Eran Roz from comment #0)
> <!-- comments are not recommended for users: it is hidden!  -->
> 
> Comments aren't recommended for new editors (and for 99% of the times for
> advanced users too), as must comments should be written in talk page.

The principal use of HTML comments in articles is to warn new editors to not do something that seems "obvious" but there is talk-page consensus to not do. This was a very widely-requested pain point from experienced editors who felt now showing the comments was very damaging to new users' expereience. Hiding comments which are there for new users seems like the wrong way around…

Long term, this will hopefully be replaced by a proper in-editor discussion system, but until that's done, this will have to do.
**Author:** `gryllida`

**Description:**
I'd like to enable a new beta feature on a wiki, but I wouldn't like the users to enable it thoughtlessly, as it currently breaks a lot of things. For this reason, I'd like to be able to append a 'do NOT use this! only for developers' note to such beta feature in the beta tab.

--------------------------
**Version**: unspecified
**Severity**: enhancement
(In reply to Gryllida from comment #4)
> James Forrester, I expected you to be most familiar with the context here --
> installation of visualeditor at non-Wikipedias as a sort-of-pre-beta
> feature, while people script visualeditor to suit the project needs.

This is the very first time you've suggested it, so no, I'm not remotely familiar with your idea. :-)
**gryllida** wrote:

James Forrester, I expected you to be most familiar with the context here -- installation of visualeditor at non-Wikipedias as a sort-of-pre-beta feature, while people script visualeditor to suit the project needs.

If it's put as a beta feature, a lot of people will enable it and make edits that break things or at least don't provide the relevant features (for wikipedias, this is the common use of <ref> tag, for instance; for its sisters, it's a need in other toolbar buttons and often lack of need in <ref> tag in the first place).
If there are severe issues that would "break a lot of things" it's not ready to be a Beta Feature and for WMF servers we wouldn't let it go live. Consequently I don't see a valid use case and am marking as WONTFIX.
Editing the MediaWiki messages isn't good enough?
Hmm. Does that sound like a common usecase, or rather like something that you could hack up yourself if really wanted? I don't know...
VisualEditor editor is full of bugs. Since his implementation i have disabled it for me, because, as experimented user i just like to edit clean code.
So, i noticed folowing bugs
when you edit a part of a wikilink (termination) visual editor leaves old wikilink as adrress and only add new edited variant as label. For example if you want to correct digit of an wikilinked year - your action will just add a correct label but wikilink will be the same, old.
I first noticed this on rowiki when anonymous users edited wikipedia. One fresh example can be this https://ro.wikipedia.org/w/index.php?title=Gustar_%28festival%29&diff=8812463&oldid=8805982
Now i tested myself this "phenomenon" on test2wiki and i obtained the same result
https://test2.wikipedia.org/w/index.php?title=Edit_page_for_firefox&diff=104063&oldid=104062

Other bug: when you try to remove title of a section from a page (for merging 2 sections), visual editor removes only caption but it keeps the real section heading (====) and adds between equal sign an "<nowiki/>". The result will be ==<nowiki/>== and section will exist further without title. Test edit: https://test2.wikipedia.org/w/index.php?title=New_page_for_bugzilla&diff=104066&oldid=104065

Also there exists some problems when copying of tables in a page edited via VisualEditor. VisualEditor adds again some <nowiki> </nowiki> tags, and in some cases adds magic words like __INDEX__ and __NEWSECTIONLINK__
Example (real edit on rowiki): https://ro.wikipedia.org/w/index.php?title=Kiesza&diff=next&oldid=8808818

--------------------------
**Version**: unspecified
**Severity**: major
I noticed again a bug related to <nowiki/>

Some user tried several times to add image and each time image (code) was put betweeen <nowiki/> tags
Diffs:
https://ro.wikipedia.org/w/index.php?title=The_Pirate_Bay&diff=8969441&oldid=8969436
https://ro.wikipedia.org/w/index.php?title=The_Pirate_Bay&diff=8969445&oldid=8969444
https://ro.wikipedia.org/w/index.php?title=The_Pirate_Bay&diff=8969449&oldid=8969448
Again noticed bug related to <nowiki/>

Some user tried several times to add image and each time image (code) was put betweeen <nowiki/> tags
Diffs:
https://ro.wikipedia.org/w/index.php?title=The_Pirate_Bay&diff=8969441&oldid=8969436
https://ro.wikipedia.org/w/index.php?title=The_Pirate_Bay&diff=8969445&oldid=8969444
https://ro.wikipedia.org/w/index.php?title=The_Pirate_Bay&diff=8969449&oldid=8969448
Thanks for posting this.

The first problem is "working as designed", but the design is seriously being discussed because of exactly this problem.  This item is best described as a duplicate of multiple other bug reports.  See bug 48789 for a list of most open link-related bugs.

The second problem is bug 50100.  Also, this is what you'd expect from a word processor (like Microsoft Word):  if you type "My Title" and set bold formatting or a large font size on those words, and then you remove all the letters on that line, and start typing again, then you do expect the font size and bold formatting to be retained.  This report is a duplicate.

On the third one (the table in ro.wp's [[Kiesza]]), it appears that the editor copied the wikitext code out of en.wp's article, and pasted it directly into VisualEditor.  VisualEditor then assumes that you wanted this pasted text to display (i.e., as if you were writing a help page telling someone what wikitext to type, so you really wanted the wikitext on the page).  Magic words can be set in VisualEditor by going to the Page options menu, choosing "Advanced settings", and clicking the buttons to turn on those magic words.  This report should be closed as "working as designed".

I'm going to mark the whole thing as "Resolved", but without trying to specify it as a duplicate, because I don't know if Bugzilla can handle multiple duplicate numbers.  If you have other questions, then please feel free to follow up at those other open bugs.
Please file only one specific problem per report and stick to the topic (general complaints about perceived quality of software can go to wikis, mailing lists, blogs). https://www.mediawiki.org/wiki/How_to_report_a_bug might come handy. Thanks.
Sometimes users set the format of a line to be a == Section heading ==, but never put anything in it.  In that case, the section heading formatting should be removed.  There's no good reason to have == == or === === by itself on a line.

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

**Description:**
On http://en.wikipedia.beta.wmflabs.org/wiki/Cite_VisualEditor_Test?veaction=edit, when you click on the "Page Options" icon, the pop-up page options dialog appears to be too narrow.  Characters are missing.

OS X 10.9.4.
Safari 7.0.6
Firefox 32.0

visual editor version: https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FVisualEditor.git/bfbe8cbbebe0a461d0ee68c0491b901507636fe2

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Mac OS X 10.9
**Platform**: Macintosh
Yeah, this is a painful issue; merging with bug 57366.

*** This bug has been marked as a duplicate of bug 57366 ***
**josephsieh** wrote:

Screen shot

**Attached**: {F14703}
Steps taken:

1.  Open a redirect to edit.

2.  Add a template:  {{R from other languages}}

3.  Discover that I can't save.  The green 'save' button is still gray and non-functional.

4.  Mash the keyboard to add some text to the page.  

5.  Still can't save.  Give up and cancel the edit.


This happened in Firefox on my Mac; when I closed the page and tried again, it worked correctly.

--------------------------
**Version**: unspecified
**Severity**: normal
Sounds like the editor had crashed by the time you added the template… Can't reproduce now, however. :-(
Created attachment 16345
Screenshot showing the template that I just added (highlighted in blue) and the still-gray 'Save' button

**Attached**: {F14679}
"No results found" overlaps with the results that were found

Steps to reproduce:

1.  Open VisualEditor and Insert > Media

2.  Search for File:Alf Cooke's Packaging Factory - Hunslet Road - geograph.org.uk - 483165.jpg 

3.  Nothing happens:  "No results found".

4.  Spend a few moments grumbling about the stupidity of a search tool that cannot find a file even when you give it the complete and exact file name.

5.  Spend a few moments groaning because there's no way to add this image unless the search tool can find it, even when you know the exact file name.

6.  Hey!  Search finally found the image!  Why does VisualEditor still say "No results found" on top of the results?

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

**Attached**: {F14693}
*** This bug has been marked as a duplicate of bug 67438 ***
To reproduce:

1. Write text. Make it bold.
2. Put the caret in the middle of the bold text.
3. Insert a special character.

Actual: The inserted character is not bold.

Expected: The inserted character is bold like the surrounding text.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 60476 ***
Change 157703 had a related patch set uploaded by Esanders:
Annotate inserted special characters

https://gerrit.wikimedia.org/r/157703
Sometimes you want to re-use an image (or otherwise need to know its name).  Some file names are too long to display in the tab.  It would be nice if something in the media dialog box exposed the name of the file, so that it could be copied.

--------------------------
**Version**: unspecified
**Severity**: enhancement
If VisualEditor is used to introduce a link (Ctrl-K) and the list of suggested link targets is long enough to require a scroll bar, this scroll bar cannot be used: clicking on it immediately closes the target list.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows 7
Merging into bug 65774.

*** This bug has been marked as a duplicate of bug 65774 ***
Just noticed that the (non-functional) scroll bar is only shown if the target list is displayed too far down on the screen. Otherwise, the list just contains 10 items and no scroll bar. To test on mediawiki.org: start a new empty link with Ctrl-K and type R.
(Notice that using the mouse wheel works as intended, at least in the categories' case, so assuming it's the same bug we'll need to edit its title.)
I don't have examples for the link tool, but can confirm in the categories' one.
Screenshot

The highlight that appears after inserting a reference in a slug is pretty weird.


See the screenshot attached

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

**Attached**: {F14232}
That bug is T89192, this particular issue was fixed with staging.
Breaks even worse at the moment, appears to corrupt the document CE node.
Breaks even worse at the moment.
It seems that if you insert a reference into a slug, the selection ends up as |<p>, <ref>, </ref>, </p>| rather than <p>, |<ref>, </ref>|, </p>

We should see how this behaves in Ed's "Stage slugs" code, though, because that's the future.
This edit was actually saved, but it seemed like it wouldn't be at the time:  https://en.wikipedia.org/w/index.php?title=Integrated_circuit&diff=622517186&oldid=622152913


The report was this:

Error saving to server: Empty server response

Hangs when editing "Integrated circuit" page - section SSI, MSI and LSI - tried to remove redirect wikilinks to SSI, MSI and LSI (keywords). Chrome 36.0.1985.143 m, Win7 64bit Kozuch (talk) 21:08, 23 August 2014 (UTC)

Hi, I see my edit was saved, but probably was later than what my patience allowed me to wait for :). I was looking at page history before cancelling the edit save, but it was not there, probably shower up later. VE interaction definitely ended up deadly though (hung on the "saving" dialog and when I canceled it the above error just was quickly show and then dialog closed by itself.

--------------------------
**Version**: unspecified
**Severity**: normal
This bug could not be reproduced and is now three years old, and was probably a random transient issue, so I'm closing.
http://bits.beta.wmflabs.org is entirely down with 503.  E.g.:

http://bits.beta.wmflabs.org/en.wikipedia.beta.wmflabs.org/load.php?debug=true&lang=en&modules=ext.visualEditor.viewPageTarget.noscript&only=styles&skin=vector&*

--------------------------
**Version**: unspecified
**Severity**: normal
Still working for me.  If you still get a 503, please re-open, and add the URL and error text you get.
**physik** wrote:

It worked fine this morning but now I'm getting 503 again.
It's somehow hard to decide when a Temporarily bug has been fixed.
The link works for me now, so it seems fixed.  If it is still broken when you test, please re-open.
**physik** wrote:

The link seems to be still broken (503).
**gerritadmin** wrote:

Change 155806 merged by BBlack:
declare hhvm_appservers lvs service ip for labs, too

https://gerrit.wikimedia.org/r/155806
**gerritadmin** wrote:

Change 155806 had a related patch set uploaded by Ori.livneh:
declare hhvm_appservers lvs service ip for labs, too

https://gerrit.wikimedia.org/r/155806
Currently language selector adds <span lang=".." dir="..."> which is good for multiple words. However, sometimes longer text such as [few] paragraphs, lists etc should be makred as different language, and in this case it should wrap it with div.

Example: https://he.wikipedia.org/wiki/%D7%A9%D7%9E%D7%A2%D7%95%D7%9F_%D7%90%D7%95%D7%9C%D7%9E%D7%9F?veaction=edit&uselang=en - the second title is "Books" and since all the books are in English, the whole list should be wrapped with <div lang="en" dir="ltr">.

--------------------------
**Version**: unspecified
**Severity**: normal
Merging with bug 60187; this will require a major amount of work to provide a block-level editing concept more widely, of which this is the most obvious (but not sole) user.

*** This bug has been marked as a duplicate of bug 60187 ***
bogus "no results" found in Media interface

Seen if Firefox, less so in Chrome

On any page in beta labs e.g. http://en.wikipedia.beta.wmflabs.org/wiki/Media_Interface_VisualEditor_Test?veaction=edit 

Click Insert/Media.  Message "no results found" appears.

Search for media that returns results.  "no results found" message persists. See screen shot. 

In Chrome, "no results found" flickers but ultimately disappears when media thumbs are displayed.

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

**Attached**: {F14384}
(In reply to Chris McMahon from comment #1)
> Also note that search results for Media in Firefox are different than in
> Chrome, and Firefox seems to be less correct.

Search results is a Cirrus problem. :-) But yeah.
*** This bug has been marked as a duplicate of bug 67438 ***
Also note that search results for Media in Firefox are different than in Chrome, and Firefox seems to be less correct.
I have not been able to reproduce this at en.wikipedia.beta, and I didn't want to edit live category pages for testing.

In Firefox, I added a line of text.  VisualEditor added a level 1 section headign after it:

= <span dir="auto">Category:Medical and health organizations</span> =

You can see the diff here:  https://en.wikipedia.org/w/index.php?diff=621943590&oldid=615616525

--------------------------
**Version**: unspecified
**Severity**: normal
Inclined to mark it as resolved since it seems to be fixed.

Instead of 
```<h1><a href="#Category:Medical_and_health_organizations" class="mw-headline-anchor" aria-hidden="true" title="Link to this section">§</a>
<span class="mw-headline" id="Category:Medical_and_health_organizations">
<span dir="auto">Category:Medical and health organizations</span></span></h1>```

when testing  span dir="auto" is not added anymore: 

```<h1><a href="#Category:Medical_and_health_organizations" class="mw-headline-anchor" aria-hidden="true" title="Link to this section">§</a>
<span class="mw-headline" id="Category:Medical_and_health_organizations">
Category:Medical and health organizations</a></span></h1>```
<h1>
<a href="#Some_page_titile" class="mw-headline-anchor" aria-hidden="true" title="Link to this section">§</a>
<span class="mw-headline" id="Some_page_titile">Some page titile</span></h1>
We fixed this a while ago, I think.
Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Change the type of the image to "Frame"
4.Click on "Apply Changes"
5.Reopen the media settings dialog for that image

Observe that the "Make full size" button is now active
Click on that.
The Custom tab does not get enabled, even though the size has just been customized by making it full size.

Environment:Betalabs
Browser:Chrome

--------------------------
**Version**: unspecified
**Severity**: normal
Correct MediaWiki behaviour.
Currently, in the template adding dialog there is just one search box and a lot of empty space.

A user needs to know the name of the template to insert.

A template could be suggested in a more proactive way. One idea can be to simply show the currently available templates by category, starting from the top and let the user drill down (in enwiki the top is https://en.wikipedia.org/wiki/Category:Wikipedia_templates ; the top category should probably be defined in a wg variable). This will require each project to maintain their templates neatly categorized, but this should be done anyway ;)

Another possibility is to let the projects define lists of commonly used templates, or to show a list of the most frequently transcluded ones.

[And see also the trivial bug 69692.]

--------------------------
**Version**: unspecified
**Severity**: enhancement
I think this is bug 53590.

*** This bug has been marked as a duplicate of bug 53590 ***
The Hebrew Wikipedia, as well as a few others, have a gadget for canned edit summaries:
https://he.wikipedia.org/wiki/MediaWiki:Gadget-Summarieslist.js

If the forceeditsummary user preference is enabled and the user uses this gadget to insert a summary, the warning about an empty edit summary is issued, even though it shouldn't.

I suspect that the problem is in the VE code.
As far as I can see, this preference is checked in
modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.js on line 867
and the summary values are not what I expect them to be.

(See also Bug 52085.)

--------------------------
**Version**: unspecified
**Severity**: normal
Hmm. That is actually a very good point. Talked with @trevorparscal and you have us both convinced.

Let's file a separate task for this (filed T86868), I'll adapt your patch ({F14710} from T71749#745592) for other InputWidgets.
Sync of the value to the DOM can be done in lazy way on the getValue() (so timer polling isn't really needed...)

What is the correct policy to handle DOM value not equal to the OOUI widgets? Don't know but here are some possible options
* Trigger change event - this is what I suggested above. This is WYSIWYG - you see X in DOM, X would be the value in the widget.
* Raise exception - If you fear the above is too dangerous, and this moves the responsibility to the script writter but let him know
* log.warning(...) - If OOUI lost DOM synchronization too often to raise exceptions. If this is the case then OOUI is probably broken.
Documented how/where? I'd be happy to if you come up with a sensible way to do it. :) (This isn't really a supported use-case for OOUI, but it's useful and people are going to do it anyway, so documenting something would make sense.)

Just to be clear, when you modify `.value` from JavaScript (or use jQuery's `.val()`, etc.), there's literally no way for VisualEditor or any other script to pick up the changes in real-time (which we need for things like validation of the inputted values), unless you trigger a 'change' event or something like that (well, short of polling for changes every 100 ms or so, but let's not do that please). That's just how this works, whether we like it or not.
Documented how/where? I'd be happy to if you come up with a sensible way to do it. :) (This isn't really a supported use-case for OOUI, but it's useful and people are going to do it anyway, so documenting something would make sense.)

Just to be clear, when you modify `.value` from JavaScript (or use jQuery's `.val()`, etc.), there's literally no way for VisualEditor or any other script to pick up the changes, unless you trigger a 'change' event or something like that (well, short of polling for changes every 100 ms or so, but let's not do that please). That's just how this works, whether we like it or not.
Per Bartosz.
At least it should be documented properly.
Usually  the UI should be consistent with the DOM.
I think this should be closed as invalid. Like Trevor said above, the script should call `.trigger( 'change' )` on the <input/> node.

We could change #getValue to actually get the .value of the <input/> every time (like in the proposed patch), rather than relying on the cached one, but any scripts interacting with input fields //must trigger the 'change' event anyway//; there's more machinery that often depends on this – in this particular case, the script that limits the length of edit summary to 255 bytes.

It is a bit weird that OOUI widgets rely on events only to update their internal state, but that's intentional per Trevor's design and I think the design is sensible. It can result in the state of the widget becoming inconsistent with the state of the DOM node when other scripts modify it without triggering events, but on the other hand it ensures that the state of the widget itself is //internally// consistent.
Isn't this an OOjs UI thing?
There are actually several reasons for the setTimeout, but the real problem here is that getValue compensating for not noticing the value changed previously causes other issues.

The OO.ui.TextInputWidget has a "change" event, which is depended on by other systems. If we just make getValue compensate for not noticing the value changed previously, then systems depending the aggregated change event will behave incorrectly. The best way to handle this is to either trigger the event or come up with a way to access the input. We could, for instance, leave references to widgets in the elements using jQuery.data().
This is onEdit function  (with setTimeout) that protect against browsers mishaps if I understand correctly.

BTW - don't scar to change getValue, as it is used only in ~35 places in the code ;)
The problem is that we really should be caching the value; it's done to protect the behavior against a lot of event triggering and browser mishaps that otherwise would make interaction with inputs pretty horrible.

We can't have ooui deal with the jQuery element directly; if you notice, htere's also a SetTimeout() method inside 'setValue' -- that's on purpose to make sure that if the user types quickly we don't emit crazy amount of events. Changing ooui to deal with the jQuery element's value directly will remove a lot of its intended functionality.
@Trevor Parscal, I already fixed it with triggering input event. However it should be fixed in oojs-ui itself for later cases.
The browser should not emit event in this case (see RFC: http://www.w3.org/TR/html401/interact/scripts.html#adef-onchange), and even if the spec was the other way - oojs-ui can't blame browsers...
The problem is actually to do with the fact that the browser isn't emitting events when it should. OOjs UI is listening for the change event.

Just use:

$input.val( newValue ).trigger( 'change' );
Created attachment 16237
Fix for oojs-ui

Attaching a proposed patch for oojs-ui.

**Attached**: {F14710}
Fixed by triggering manually input event.

However oojs-ui should use the widget value to get must up to date value (e.g protype.getValue( return this.widget.val(); ), and not to be based on some cached variable.
If it does something smart with the value it can be check that if this.value !=this.widget.val()  then it should trigger the function for updating this.value, before actually return the widget value.
Got it.

The issue was a mixup between dealing directly with the textarea object through jQuery (which updates .val()) and dealing with VE's OOUI elements (which update through .setValue() )

I've created a fix to the gadget, but I don't have the permissions to edit it. I've asked Eran to take a look and implement the fix.
This gets a bit weirder for me. It seems that with the gadget that summaries aren't saved at all, even if I type something manually in the textbox, and this behavior is inconsistent:

If I add automatic summaries from the buttons and save, the summary isn't saved.
If I add automatic summaries from the buttons and then add a text, they are saved as a summary. 
If I add a summary by hand, it isn't saved.

I'm not sure what would cause this to happen; the gadget fills in automatic text by adding into the textbox.val() which should make this work.
In particular we've had a community request to display a citation summary when focusing citation nodes.

We could list template values in order until we run out of room, but this may not lead to desirable results, for example the first parameter in {{Cite web}} is URL.

A more complex solution would be to come up with a format for defining how to generate the summary of a template and store it in template data, either as a value on the column (summary order):

Field     Desc  Summary order
url       ...   null
publisher ...   2
title     ...   1
date      ...   3
month     ...   null

A simplified version of this would just flag one field as being used in the summary.

etc.

Or as a string concatenation message somewhere:

"{{{title}}}, {{{publisher}}} - {{{date}}}"

--------------------------
**Version**: unspecified
**Severity**: normal
Clearly I was protecting against typos in the bug number :)
I'm going crazy...

*** This bug has been marked as a duplicate of bug 69474 ***
Is this the same thing as bug 69474? (You filed that one too, and the bug numbers are confusingly similar. :D)
Steps to reproduce:

1.  Type some text:  "Foo bar baz bat"

2.  Select the last word, because you want to create a wikilink before you finish typing the sentence.

3.  Type Command-K to create a link.  

4.  Make a link.  Click "Done".

5.  Finish typing the sentence.

6.  Oops, where did [[bat]] go?


Results:

When you exit the link inspector, the linked text remains highlighted, and typing results in it being overwritten by your next character.  

Expectation:  after I've made a link, de-select the link and put the cursor at the end of the word, so I can keep writing.

--------------------------
**Version**: unspecified
**Severity**: enhancement
We've intentionally chosen this behaviour after a huge amount of user and product research.
screenshot of the problem

Confirmed this on Safari 7, mac, Vector and Firefox 31, Windows 7, Monobook

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

**Attached**: {F14614}
Merging into bug 57366 (FIXED).

*** This bug has been marked as a duplicate of bug 57366 ***
I guess this became a problem when the cancel button was removed.
The clipping is correct, but we aren't repositioning for the edge of the screen, like we do with link inspectors (context popups).
Also Firefox 30 on a Mac.  I suspect that it's everywhere.  This problem has been present for at least a few weeks.
It is customary for big templates with a lot of parameters, such as infoboxes, to have each parameter written on a separate line in the wiki source code.

If I am not mistaken, VE inserts all templates in one long line.

As long as source code editing is common, VE should insert templates according to the above community practice.

How to know whether to insert one line or multiple lines? Either do it with multiple lines if there are more than x parameters, say 4, or have a parameter in template data that suggests multiline insertion.

**See Also**:
* {T52584}
It seems that VE users still get [[https://fi.wikipedia.org/wiki/Keskustelu_k%C3%A4ytt%C3%A4j%C3%A4st%C3%A4:Kuriuss#Infolaatikot | yelled at]] for this (or perhaps that was rather a manifestation of T52584, because in the offending edits - [[https://fi.wikipedia.org/w/index.php?title=Resedakasvit&diff=prev&oldid=14486819 |example]] - the parameters were already present).
What I started with was a link to a disambiguation page:

  Foo bar [[CML]] baz bat.


What I wanted was a link to a real article, so I repointed the link:

  Foo bar [[chronic myelogenous leukemia|CML]] baz bat.


Hmm, that initialism doesn't appear to be expanded anywhere on the page.  Okay, what we need is:

  Foo bar [[chronic myelogenous leukemia]] baz bat.


So I copied the long name out of the link tool's field, and pasted it into the middle.  It produced:

  Foo bar [[chronic myelogenous leukemia|CM]]chronic myelogenous leukemia[[chronic myelogenous leukemia|L]] baz bat.

None of this would have been so difficult if we could edit labels in the link tool, in a separate box.

--------------------------
**Version**: unspecified
**Severity**: normal
This is because of bug 48720. Grumble.

*** This bug has been marked as a duplicate of bug 48720 ***
The step in firsteditve that appears when you start editing the document in VisualEditor no longer points to the "Save page" button due to an incompatible change to the VE HTML DOM.

It still shows up, but it's no longer attached.

--------------------------
**Version**: master
**Severity**: normal
Change 155234 abandoned by Phuedx:
Point to the "Save page" button

Reason:
Abandoned in favour of I81fdc4f2fa41c86a6481cf478c154b5d6c99d41d.

https://gerrit.wikimedia.org/r/155234
**swalling** wrote:

Fixed in https://gerrit.wikimedia.org/r/#/c/155280/
Change 155234 had a related patch set uploaded by Phuedx:
Point to the "Save page" button

https://gerrit.wikimedia.org/r/155234
When I open the VisualEditor on mobile in stable on enwiki using Chrome on desktop (OSX), I get the following JS error:
Discontiguous selection is not supported. 

I loaded it with ?debug=true here's what I see in the console:
Discontiguous selection is not supported. rangy-core-1.3.js:2842
(anonymous function) rangy-core-1.3.js:2842
(anonymous function) rangy-core-1.3.js:2852
(anonymous function) rangy-core-1.3.js:327
init rangy-core-1.3.js:249
loadHandler rangy-core-1.3.js:365

Incidentally, I'm also seeing this in the console with ?debug=true (however I do not see this without ?debug=true):
Uncaught Error: Module not found: loggingSchemas/MobileWebClickTracking load.php?debug=true&lang=en&modules=mobile.head&only=scripts&skin=minerva&version=20140815T031511Z&*:53
mw.mobileFrontend.require load.php?debug=true&lang=en&modules=mobile.head&only=scripts&skin=minerva&version=20140815T031511Z&*:53
(anonymous function) load.php?debug=true&lang=en&modules=mobile.languages&only=scripts&skin=minerva&version=20140815T101…:67
(anonymous function)

Not sure if the click tracking thing is related, a separate bug, or just a result of something going wonky with load order as a result of ?debug=true - if it seems like a separate issue, I'm happy to file another bug but figured it'd be worth mentioning here for now.

--------------------------
**Version**: unspecified
**Severity**: normal
Duplicate of bug 68493 which is now fixed.

*** This bug has been marked as a duplicate of bug 68493 ***
Not sure if this is still a relevant bug. Guessing VE folks will know.
**jgonera** wrote:

This ("Discontiguous selection is not supported") is not a mobile bug. It happens on desktop too.
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/nqeGVbpJ
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/7MTSGUCb
Usually, DEFAULTSORT contents need only a little re-arranging or capitalization changes.  If the name is long or unfamiliar, it may be difficult to type it to make these relatively minor changes.  It would be nice to pre-fill the box with the page title.

But if VisualEditor simply fills in the box whenever you open the Page settings menu, then we'll get a lot of errors (because people won't notice that it needs to be updated).

Possible solution:  Add a button next to the DEFAULTSORT item to insert the current page title as text that the editor can then change as needed.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This is the same as bug 50002 (and needs a huge amount of design thought).

*** This bug has been marked as a duplicate of bug 50002 ***
Steps to repro:

1. In production/stable, enter VE edit mode and scroll down to a section that's below the fold.
2. Tap on a wikilink
3. Use the "remove" button to remove the link & tap done.

Expected: I am taken back to the section I was on.

Actual: I'm taken back to the top of the page.

Observed on iPad 2 & mobile site on desktop Chrome.

--------------------------
**Version**: unspecified
**Severity**: normal
**jgonera** wrote:

Can't reproduce anymore on latest master. Other bugfixes might have fixed this too. Reopen if it's still happening.
**jgonera** wrote:

I suspect this might be related to bug 66697.
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/JUXz2uL6
**Author:** `ryan.wold`

**Description:**
When disabling an Editor's .target.surface (by calling .disable()), the text is no longer editable, which is great.  However, the text in the disabled Editor cannot be copied and pasted.  It does not appear to make it to the clipboard. 

Desired behavior is that the text can be be copied even when the editor is disabled.  Or perhaps there could be a setting/option around that.



We traced this to ve.dm.Surface.prototype.changeInternal, where it returns immediately if the surface is disabled.

if ( !this.enabled ) {
  return;
}

I found this here: https://doc.wikimedia.org/VisualEditor/master/source/ve.dm.Surface.html#ve-dm-Surface-method-changeInternal


I'm using OSX Mavericks and Google Chrome Version 36.0.1985.125.

Thanks!

- Ryan Wold
  ryan.wold@neo.com

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Mac OS X 10.9
**Platform**: Macintosh
**ryan.wold** wrote:



%%%*** This bug has been marked as a duplicate of bug 69515 ***%%%
From John Broughton:

"This is what tabbing through Cite templates (in the mini-editors) looks like: type, tab, tab, tab, type, tab, tab, tab, type, ... You have to tab three times to get from one field to the next. That's because tabbing always includes both the “Field description” and “Remove field” icons. There isn't any reason to include these icons in tabbing; tabbing should bypass these icons."

--------------------------
**Version**: unspecified
**Severity**: minor
*** This bug has been marked as a duplicate of bug 68768 ***
(In reply to James Forrester from comment #2)
> Using a <button> rather than a <div> in OOUI for buttoned elements takes us
> into really horrible issues more widely, though…

Can you elaborate, because I don't see why that would be ? We have gotten them pretty down even in mediawiki.ui
(In reply to WhatamIdoing from comment #0)
> From John Broughton:

[…]

> There isn't any reason to include these icons in tabbing

The reason is "accessibility". That's a pretty strong sine qua non for how we build things.

(In reply to Derk-Jan Hartman from comment #1)
> Using an actual button might fix 'excessive' tabbing here, since browsers
> sometimes have different default tab behavior for buttons vs. fields, a
> behavior overridden if you need to force button behaviors on a div/a.

Using a <button> rather than a <div> in OOUI for buttoned elements takes us into really horrible issues more widely, though…
Also shift tab behaves differently (this is due to presence of icon only in focus state. WAI-ARIA has some further thoughts on how bot build fields like this, but I think it might be a bit too much effort right now.)

Using an actual button might fix 'excessive' tabbing here, since browsers sometimes have different default tab behavior for buttons vs. fields, a behavior overridden if you need to force button behaviors on a div/a.
What happens when you try to make a link.  (Notice that the box is too small; that will be a separate bug in a moment.)

I can only make this happen in Safari, not Firefox, but I believe that the user reporting this was using Firefox.

Steps to reproduce:

1.  Open VisualEditor and Insert > Media.

2.  Pick and image and add a caption.

3.  Select a word and press Command-K to make an internal link. 

4.  Notice that you get no search results to help you find the correct page for your link.

5.  Click inside the box.  Now you have search results.

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

**Attached**: {F14163}
I think it is the firefox which is different from Chrome and Safari, not sure which one is correct though!And not just for a link inside image, for a link in CE too,in Chrome and Safari, you will not get any list of link target suggestions unless you click inside the box.
Experience in Safari:

1.  Open VisualEditor and Insert > Media.

2.  Pick and image and add a caption.

3.  Select a word and press Command-K to make an internal link. 

4.  Notice that you get no search results to help you find the correct page for your link.

5.  Click inside the box.  Now you have search results.


Experience in Firefox:

1.  Open VisualEditor and Insert > Media.

2.  Pick and image and add a caption.

3.  Select a word and press Command-K to make an internal link. 

4.  Notice that you are immediately given a long list of search results, even if you don't want them.


Since they don't behave the same, then one of these two browsers isn't working as designed.
I don't see a bug here? This seems to be working as expected. Have I missed something?
See https://en.wikipedia.org/wiki/File:Cite_dialog_with_large_boxes_for_fields.png

This is intermittent and may be relate to zooming in/large text size.  The fields go back to normal size when you click inside them.  Seen in both Firefox and Safari on Macs.

Today, I'm getting pretty consistent results by opening https://en.wikipedia.org/w/index.php?title=User:Whatamidoing_(WMF)/sandbox&veaction=edit in Safari and selecting the infobox.  Opening it (double-clicking) the first time works as expected.  Cancelling it (escape key) and opening it again produces larger than necessary fields.

--------------------------
**Version**: unspecified
**Severity**: minor
Tried in Safari on Mac with the link provided - cannot reproduce. Also, checked if transclusion boxes will scale up/down with the selected zoom rate - all look fine.
Of a non-existent category has been added on a page, there is no indication in the Categories dialog that it is a red link.

--------------------------
**Version**: unspecified
**Severity**: enhancement
*** This bug has been marked as a duplicate of bug 65517 ***
VisualEditor should display categories in the page's footer, just like they will display when the page is saved.  Clicking on the footer could open the Categories editing tool.

--------------------------
**Version**: unspecified
**Severity**: enhancement
*** This bug has been marked as a duplicate of bug 50239 ***
Article URL: https://ru.wikipedia.org/wiki/%D0%A2%D0%B0%D0%B1%D0%BB%D0%B8%D1%86,_%D0%91%D0%BE%D0%B3%D1%83%D1%81%D0%BB%D0%B0%D0%B2

The infobox is shown correctly while reading the article, but broken when editing in VisualEditor. HTML code is shown above the page.

--------------------------
**Version**: unspecified
**Severity**: normal
> Looks like a bug in broken attribute heuristics.

On second thought, I think what we're doing is fine. This is just broken wikitext.

The php parser gets away with it by refusing all "greater than" chars in attributes. ie.

  <div class="class>ey">stuff</div>

is rendered as,

  <div>ey"&gt;stuff</div>

which seems worse.
The template was returning something like,

  <table><tr><th style="text>great</th><td>"test</td></tr></table>

which parsoid rendered as,

  &lt;th style="text>great
  <table>
  <tbody>
  <tr>
  <td>"test</td></tr></tbody></table>

Looks like a bug in broken attribute heuristics.
Fixed the template in,
https://ru.wikipedia.org/w/index.php?title=%D0%9C%D0%BE%D0%B4%D1%83%D0%BB%D1%8C%3AUniversal_infocard&diff=64929809&oldid=64897667

But we should be more robust against unclosed attributes.
(In reply to James Forrester from comment #1)
> Looks like [[ru:Template:Универсальная карточка]] is getting a bunch of
> content fostered out somewhere?

I didn't go too deeply into the code, but it is build using this Lua module:
https://ru.wikipedia.org/wiki/Module:Universal_infocard

It pulls data from Wikidata, and seems to build tables using HTML rather than wiki table syntax. Maybe that is the cause.
Looks like [[ru:Template:Универсальная карточка]] is getting a bunch of content fostered out somewhere?
Reported by S Page at QA mailing list[1]. Reported to Sauce Labs support[2].

1: http://lists.wikimedia.org/pipermail/qa/2014-August/001843.html
2: http://lists.wikimedia.org/pipermail/qa/2014-August/001846.html

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**gerritadmin** wrote:

Change 153408 merged by jenkins-bot:
Chrome 28 is the last version that works properly on Sauce Labs

https://gerrit.wikimedia.org/r/153408
I have started builds for all Chrome jobs. The jobs should be more green now.

https://integration.wikimedia.org/ci/view/BrowserTests/job/browsertests-Flow-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/

https://integration.wikimedia.org/ci/view/BrowserTests/job/browsertests-Flow-test2.wikipedia.org-linux-chrome-sauce/

https://integration.wikimedia.org/ci/view/BrowserTests/job/browsertests-Math-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/

https://integration.wikimedia.org/ci/view/BrowserTests/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/

https://integration.wikimedia.org/ci/view/BrowserTests/job/browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/

https://integration.wikimedia.org/ci/view/BrowserTests/job/browsertests-PageTriage-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/

https://integration.wikimedia.org/ci/view/BrowserTests/job/browsertests-UploadWizard-commons.wikimedia.beta.wmflabs.org-linux-chrome-sauce/

https://integration.wikimedia.org/ci/view/BrowserTests/job/browsertests-VisualEditor-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/

https://integration.wikimedia.org/ci/view/BrowserTests/job/browsertests-VisualEditor-test2.wikipedia.org-linux-chrome-sauce/
**gerritadmin** wrote:

Change 153408 had a related patch set uploaded by Zfilipin:
Chrome 28 is the last version that works properly on Sauce Labs

https://gerrit.wikimedia.org/r/153408
Sauce Labs support answer:

Allison Wilbur (Sauce Labs Help Desk)
Aug 09 02:03 AM

Hi there,

I'm sorry this issue suddenly popped up for you! Sauce Labs just recently updated the default versions of Chrome, ChromeDriver, and Selenium that we serve up when no version is explicitly requested in the Desired Capabilities we receive.

Previously, the default values were:

Selenium: 2.30.0
Chrome: 27/28 (depending on environment - 28 for Linux)
ChromeDriver: 26.0.1383.0

The new default values are:
Selenium: 2.40.0
Chrome: 35
ChromeDriver: 2.10

If you set your Desired Capabilities to the previous values, I suspect your tests will behave as they used to. For example:

desired_capabilities['selenium-version'] = '2.30.0'
desired_capabilities['browserName'] = 'chrome'
desired_capabilities['version'] = '28'
desired_capabilities['chromedriver-version'] = '26.0.1383.0'

The extremely odd behavior you saw with the recent versions update is something I'm currently investigating, and I've filed an internal ticket to get this problem fixed. It seems to be related to the later versions of Chrome/ChromeDriver for some reason, and specific to Linux. I found this issue with send_keys on the ChromeDriver forums: https://code.google.com/p/chromedriver/issues/detail?id=467 It's not quite the same issue, but it looks like there's some strange behavior with text input in Linux.

I hope the previous values perform well for you as a workaround while we investigate the issues with the more recent versions of Chrome. I've linked this ticket to the issue, so I'll be sure to let you know when the fix is out so that you can test on more recent versions. If you want to try the later versions, I've had some success looping through my input and sending one key at a time, so perhaps something like that would help out.

Sorry again for the trouble here. Let me know if you have any additional questions and I'll be happy to help. Hope you have a great weekend!

Best,
Allison
https://en.wikipedia.org/wiki/Sonic_Adventure#Development

When I go here and click "edit beta", the <ref>s are re-numbered when ?veaction=edit loads.

For example, at the implicit ?action=view:

---
The character of Sonic was redesigned for the game by Sonic Team artist Yuji Uekawa, with longer legs and spines that Iizuka subsequently noted were more suitable for 3D than Sonic's original and more compact design, which was meant to be seen from the side.[46][47] 
---

At ?veaction=edit:

---
The character of Sonic was redesigned for the game by Sonic Team artist Yuji Uekawa, with longer legs and spines that Iizuka subsequently noted were more suitable for 3D than Sonic's original and more compact design, which was meant to be seen from the side.[42][43]
---

This is super-confusing.

--------------------------
**Version**: unspecified
**Severity**: normal
This sounds like the same thing as what's described as bug 50474.

*** This bug has been marked as a duplicate of bug 50474 ***
Goal:  Insert a new template.

Steps to reproduce:

1.  Insert > Template

2.  Start typing the template's name:  Citation nee…

3.  Think, "Ah, it's found it!  It's highlighted and has a checkmark next to it!  Great, I can stop typing that long name and just hit return to add the template that I want.

4.  Press return.

5.  Think, "Um, [[Template:Citation nee]] is a redlink.  Why did it add that?  Why didn't it add the highlighted-and-checkmarked [[Template:Citation needed]]?"

--------------------------
**Version**: unspecified
**Severity**: normal
I am inclined to close as Resolved: the feedback to a user for inserting templates has improved

- there is no check mark to a highlighted suggested selection anymore
- clicking Return with 'Citation nee'  selects the first highlighted template from the suggestions list
 - the next dialog box displays the template's  title and info/description to inform a user what kind of a template is about to be inserted
-  That dialog box requires a user to click 'Insert' button explicitly - not just pressing Return keyboard buttonn.
When {{GENDER:|...}} is part of a source string, GENDER: is not available as insertable.

Example string: https://translatewiki.net/wiki/MediaWiki:Visualeditor-editconflict/en

--------------------------
**Version**: master
**Severity**: enhancement
Change 153571 merged by Jsahleen:
Add parameterless GENDER as insertable

https://gerrit.wikimedia.org/r/153571
Change 153571 had a related patch set uploaded by Nikerabbit:
Add parameterless GENDER as insertable

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

Steps to reproduce:

1.Open a page with VE
2.Select a text
3.Click on Link inspector
4.While the link inspector is open, open Language inspector or Special Character inserter

Observed Result:
The UI of both the inspector appears a bit distorted having a whitespace at the bottom

See the screenshot attached

Environment:Production,test2,Betalabs

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

**Attached**: {F14605}
Checked betalabs  - all is displayed correctly.
Re-checked it in Ptoduction and test2 -  the Language, Link inspectors and Special character inserter looks normal. 

I will check betalabs when the env will be back to normal.
Environment- beta, production

1> Try to open your User page without logging in.
2> Shows the "Welcome to VE" popup, click on "continue" to proceed.
3> opens the page in VE mode , but the VE Edit tab is not seen on top.

In test2 follow the above steps and the page would open in the Read mode and all the tabs(Read, Edit and Edit source can be seen).

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows XP
Yes, this is intentionally how it's configured on some wikis.
screenshot

1> Preferences -> Gadgets
2> Enable this under Appearance -> Enable toggling between tabs and dropdown menus in the Vector skin. 
3> Save 
4> go back to User page. Notice now the Tabs Read, Edit and Edit Source all have been moved into a single drop down labeled “View”. However, enabling the same appearance in FF and Safari does not show the “View” dropdown.
Also, the “View” is out of position as compared to “More” and does not show the drop down arrow.See screenshot.

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

**Attached**: {F14485}
We don't track issues with gadgets in Phabricator, sorry.
Environment-test2
* Add a basic citation
* Add another non-basic(?) citation
* Go back and set group of basic citation to something, apply changes
* Undo changes twice

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 69119 ***
Also if you undo again, you get this:
Uncaught TypeError: Cannot read property 'length' of undefined
Then this:
Uncaught TypeError: Cannot read property 'canHaveChildren' of null
Then this:
Uncaught Error: Unbalanced input passed to document
Steps to Reproduce:
1. Open https://ru.wikipedia.org/w/index.php?oldid=63644335&veaction=edit and look at the second section.

The wikitext is:

=== Б ===

* [[Борисов, Бойко Методиев]] (род. 1959) — болгарский политик.
* {{NL|Борисов, Борис}}

{{NL}} is a template that transcludes the rest of this short list.

2. The first bullet point is plain wikitext.  Click on the first item and try to change some of the text (e.g., to change the birth date from 1959 to 1960).


Actual Results:  
The first bullet point can only be edited as the "content" part of a complex transclusion.  

Expected Results:  
That plain-text list items can be edited as plain old list items.

Reproducible: Didn't try

--------------------------
**Version**: unspecified
**Severity**: minor
This is not a problem with lists per se. This is a result of how Parsoid represents templates in the DOM, and where some transclusions doesn't generate well-balanced DOM structures.

Parsoid marks complete DOM subtrees as template-generated/affected. So, in scenarios where output of a template spans multiple dom subtrees, all those affected subtrees are wrapped as one piece.

You can reproduce this behavior with a simple example like: "a {{echo|b\n\nc}} d". In this example, b and c belong to different paragraphs which also contain content from outside the transclusion. So, all of it is pulled into the template wrapping.

This is the same behavior where multiple transclusions are used to generate football tables, succession tables, etc.
screenshot

Environment-test2

Steps- 

1> Insert-> Media.
2> In media Settings dialog insert a link or type in some text in a language.
3> Click on "Insert media". notice the file gets inserted in the background, and yet the media settings dialog never closes.

See screenshot.

Also See bug 65568.

--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Windows XP

**Attached**: {F14256}
I cannot reproduce it anymore in test2 or beta.Please close this issue.
Intention:
Re-use an existing reference

Steps to Reproduce:
1.  Open a page containing a citation.

2.  Cite > Re-use.  Click on a reference.

3.  Go to another sentence.

4.  Cite > Re-use.  Click on the same reference (it's already highlighted).


Actual Results:  
The first time, it adds the ref.  The second time, it does nothing.  You have to insert a different (wrong) ref, delete that, and then add the one that you wanted (now that it's stuck on the "wrong" one).  Canceling and trying again doesn't help.


Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 68582 ***
steps-
1> open a page in VE.
2> Insert -> Comment. Add/Edit Comment dialog does not pop.

--------------------------
**Version**: unspecified
**Severity**: minor
**OS**: Windows XP
This is the same bug as https://bugzilla.wikimedia.org/show_bug.cgi?id=68960
Just in Chrome the JS error is different , so initially I thought its a different one.
*** This bug has been marked as a duplicate of bug 68960 ***
yes, the error appearing in the console is:
Uncaught TypeError: undefined is not a function
Any errors in the JS console?
Screenshot

Steps to reproduce:

1.Open a page with Mobile VE in prouction

2.Make any edit and save it

3.Try to reopen the page with Mobile VE

Observed Result:
VE does not load the page and the error appears:
Error,can't load section

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

**Attached**: {F14658}
Think this was solved long ago?
References in MediaWiki view mode (rendering correctly)

This is most likely due to Cite, but the extension works in "view" mode and fails in VE in my local wiki.

The problem: 

Citations/References work well in view mode but when VE loads, they appear as their "raw" tags <ref>Something</ref> and <references />. 

More details: From within VE, even when the references appear broken like above, I can still add a reference, which renders correctly as [1]. When I save the page the wikitext is correct and the view mode recognizes all references (both those that were broken and those that were just inserted). Then if I re-edit the page, the references are broken again.

Details -

Cite extension is installed from the git repository, and this line is in LocalSettings.php:
require_once "$IP/extensions/Cite/Cite.php";

This happens in Chrome 36.0.1985.125 and Firefox 31.0 under Ubuntu 14.04


Attachments: 

View mode and edit mode of the same page (no change to wikitext)

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

**Attached**: {F14545}
Apparently, the solution was to update and restart Parsoid.
Created attachment 16107
Same page in view mode

**Attached**: {F14547}
Created attachment 16106
Same page in view mode

**Attached**: {F14546}
**Author:** `sure4us`

**Description:**
A number of people trying to install 1.23.1 + VE + Parsoid are finding an error that crashes the site.

https://www.mediawiki.org/wiki/Extension_talk:VisualEditor#MediaWiki_1.24wmf6_required_when_trying_to_install_VisualEditor_REL1.23_45012


I'm also experiencing it, here's the error messaging:


[d64ccb4d] /wiki/ Exception from line 3279 of /home/mywiki/public_html/wiki/includes/GlobalFunctions.php: MediaWiki 1.24wmf6 required--this is only 1.23.1

Backtrace:

#0 /home/mywiki/public_html/wiki/extensions/VisualEditor/VisualEditor.hooks.php(23): wfUseMW(string)
#1 [internal function]: VisualEditorHooks::onSetup()
#2 /home/mywiki/public_html/wiki/includes/Setup.php(601): call_user_func(string)
#3 /home/mywiki/public_html/wiki/includes/WebStart.php(156): require_once(string)
#4 /home/mywiki/public_html/wiki/index.php(43): require(string)
#5 {main}

--------------------------
**Version**: unspecified
**Severity**: normal
This sounds like the creation of the temporary tarball was very broken, but thanks to Kunal's work on ExtensionDistributor this should now be moot. Sorry for the troubles.
I just downloaded the latest tarball from <https://www.mediawiki.org/wiki/Special:ExtensionDistributor?extdist_extension=VisualEditor&extdist_version=REL1_23&extdist_submit=Continue>, and I see wmfUseMW( '1.22' ) in it.
If they installed VisualEditor master, than that is bound to fail because it requires 1.24alpha (as all extensions do unless otherwise noted).

There is a REL1_23 branch[1] which requires 1.22 or higher (not 1.24alpha).

It seems however that the custom 1.23 download made available is packages from some arbitrary version not documented anywhere and that version contains "wfUseMW( '1.24wmf6' );" in its code.

I suggest whatever hacks were applied to produce this tarball are applied to REL1_23 following regular code review. If it's based on master instead of REL1_23, we can fast-forward REL1_23 to master and apply the fixes then.

Either way whatever we promote as 1.23-compat should be git and go through review. And when it does, it should be fixed to not require wfUseMW( '1.24wmf6' ); which is a bit silly for code explicitly made for 1.23.

[1] https://github.com/wikimedia/mediawiki-extensions-VisualEditor/tree/REL1_23
[2] https://www.mediawiki.org/wiki/Extension:VisualEditor
screenshot1

Environments-test2, betalabs, production.

Steps-
1> open a blank page in VE and type in some text.
2> while the cursor is still at the end of the last character, add at least two categories.
3> Save the page.
4> Now open the page again in VE. Notice the categories are shown as return characters at the end of the text(one for each category added).See screenshots.

Happens only in Chrome and Safari.

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

**Attached**: {F14346}
Yeah, these are bug 48290 issues…

*** This bug has been marked as a duplicate of bug 48290 ***
Created attachment 16096
screenshot3

**Attached**: {F14348}
Created attachment 16095
screenshot2

**Attached**: {F14347}
screenshot

Environments-test2

Steps-
1> open a page in VE.
2> Insert ->Media. 
3>Select to add a media file. Opens the Media Settings dialog.
4>Now click on “Caption” pane and Select to insert a Link .
5> Click on the style text menu to select the Language and type some text. See screenshot.
6> Now move the cursor to the link, notice the link icon is not appearing, but the icon in the toolbar does get selected. 
7>Now  try to insert a new link by selecting the link icon on toolbar, does not open the link inspector and the text in the pane gets typed as normal text.

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

**Attached**: {F14342}
Issue fixed in test2.
Assuming yes.
Possibly fixed in 2014-07-31?
Cannot reproduce it anymore in test2 or beta.
Yeah, this is not very good.
same issue found in betalabs
screenshot1

Environment-test2, production

Steps-
1> Open a page in VE.
2> Insert ->Media. 
3>Select to add a media file. Opens the Media Settings dialog.
4>Now click on “Alternative Text”, with cursor in this input field. Select to insert a Comment or Special Character or a link.
5> Notice that the inspectors open up in the Alternative text input field (see screenshots), but when entered they do show up in the Caption pane.
Also see 62410 .

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

**Attached**: {F14337}
*** This bug has been marked as a duplicate of bug 68806 ***
same issue found in betalabs.
Created attachment 16092
screenshot3

**Attached**: {F14340}
Created attachment 16091
screenshot2

**Attached**: {F14339}
cloudbees branch was a step in moving jobs from Cloudbees. Now that the move is finished, the branch should be merged with master.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
Resolved in https://gerrit.wikimedia.org/r/#/c/156809/
I might have attempted this merge, but I proved to myself yesterday that I still don't understand jjb well enough to do this with confidence.
Change 152905 abandoned by Hashar:
Merge cloudbees branch into master

Reason:
Was merely to highlight how to handle the merge with git.  Will revisit when Zeljkof is back from vacations.

https://gerrit.wikimedia.org/r/152905
Here what I did:

 git remote update
 git checkout master
 git reset --hard gerrit/master
 git merge --no-ff gerrit/cloudbees
 # fix conflict
 git push gerrit HEAD:refs/for/master


I think the issue was when using git rebase. That create new commits that Gerrit does not know about.

git merge --no-ff prevents the rebase and thus keep all the commits from cloudbees branch as is.
Change 152905 had a related patch set uploaded by Hashar:
Merge cloudbees branch into master

https://gerrit.wikimedia.org/r/152905
Antoine, is the the way to go? Or is there a better way?
screenshot1

Environment- test2,betalabs.

Steps-
1>Open a page in VE.
2>open Advanced Settings .Enable Display title and enter a title. Click “Apply Changes”.
3>Click on “Save Page”
4>Click on “Review your Changes”. Notice DISPLAYTITLE:titlename is shown under your text.
5> Now click on Return to Save form. Click on “Cancel” on the Save your changes dialog.
6>Go to Advanced Settings again in Page options. 
7>Uncheck the “Enable Display title” checkbox and click to “Apply Changes”. 
8> Repeat step#3 and #4. Notice even after disabling the display title it is still visible under your text in the “Review your changes” dialog. Open the advanced settings and you would notice that the enable display title is unchecked, but it shows up in Review your changes.

Try the above steps with the other settings such as “Let this page be indexed by search engines”, “Show a tab on this page to add a new section”and with Categories too.Please see screenshots.

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

**Attached**: {F14247}
Yes, this is bug 68619.

*** This bug has been marked as a duplicate of bug 68619 ***
Created attachment 16071
screenshot2

**Attached**: {F14248}
screenshot1

Environment- test2,betalabs.

Steps-
1>Open a page in VE.
2>open Advanced Settings .Enable Display title and enter a title. Click “Apply Changes”.
3>Click on “Save Page”
4>Click on “Review your Changes”. Notice DISPLAYTITLE:titlename is shown under your text.
5> Now click on Return to Save form. Click on “Cancel” on the Save your changes dialog.
6>Go to Advanced Settings again in Page options. 
7>Uncheck the “Enable Display title” checkbox and click to “Apply Changes”. 
8> Repeat step#3 and #4. Notice even after disabling the display title it is still visible under your text in the “Review your changes” dialog. Open the advanced settings and you would notice that the enable display title is unchecked, but it shows up in Review your changes.

Try the above steps with the other settings such as “Let this page be indexed by search engines”, “Show a tab on this page to add a new section”and with Categories too.Please see screenshots.

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

**Attached**: {F14243}
*** This bug has been marked as a duplicate of bug 68619 ***
screenshot

Environment- test2 and betalabs

Steps-
1> Open a blank page in VE and type in some text.
2>At the end of the text insert a comment.
3>Click on the Comment , to open the comment edit dialog.
4> Now while the cursor is till in the comment edit dialog , click to insert a bullet point / numbered list.
5>Now click on “Done” or “Remove” to close the dialog. The dialog stays open.Please see screenshot.

Same behavior in Chrome, FF and Safari.

--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Windows XP

**Attached**: {F14169}
Merging with bug 68679.

*** This bug has been marked as a duplicate of bug 68679 ***
Screenshot of too-small comment popup

Currently, when the orange comment icon is clicked, we see only the first few words of the comment.

To read the whole comment, we have to click again, which takes us to the edit view. You shouldn't have to launch the editor just to read the whole text.

The little popup that comes up when you first click the icon (I've lost track of VE jargon, sorry) should show the entire comment text, over multiple lines if necessary, and preferably in black or a darker gray.

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

**Attached**: {F14130}
(In reply to This, that and the other (TTO) from comment #2)
> You don't think 8 words is rather too short?

The number of words shown is language dependent.

On my system, if the comment is "This is a ridiculously-long sesquipedalian comment." you get everything except " comment."

If the comment is "Please don't change Obama's name." it shows the entire thing, which is the point of showing the snippet version.
You don't think 8 words is rather too short?
No. People writing long comments is a sign that they're doing it wrong, and encouraging such bad practice is contrary to helping editors.
One of the CSS resource loader URL yield content which is gzipped twice :-(

The content is shown by piping to gzcat twice:

curl 'http://bits.beta.wmflabs.org/en.wikipedia.beta.wmflabs.org/load.php?debug=7Cext.uls.nojs%7Cext.visualEditor.viewPageTarget.noscript%7Cext.wikihiero%7Cmediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.skinning.interface%7Cmediawiki.ui.button%7Cskins.vector.styles%7Cwikibase.client.init&only=styles&skin=vector&*'|gzcat|gzcat

Headers:

> User-Agent: curl/7.30.0
> Host: bits.beta.wmflabs.org
> Accept: */*
> 
< HTTP/1.1 200 OK
* Server Apache is not blacklisted
< Server: Apache
< Access-Control-Allow-Origin: *
< Expires: Mon, 28 Jul 2014 09:22:53 GMT
< X-Content-Type-Options: nosniff
< Content-Encoding: gzip, gzip
< X-Powered-By: HHVM/3.3.0-dev
< Cache-control: public, max-age=300, s-maxage=300
< Vary: Accept-Encoding
< Last-Modified: Thu, 24 Jul 2014 03:43:51 GMT
< Content-Type: text/css; charset=utf-8
< Content-Length: 24050
< Accept-Ranges: bytes
< Date: Mon, 28 Jul 2014 09:19:08 GMT



Same goes on when passing Accept-Encoding: gzip

I restarted varnish on the bits cache to clear up the bits cache, hasn't solved anything.


The minified CSS cache key is enwiki:resourceloader:filter:minify-css:7:e07e6ad07840d291e66cf3fe9f0980c3

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed in 4bdfea04cea2e54e6076a1c6b955ba1e1b51209f.
Niklas reported it to be fixed in Vagrant:

 hhvm: set GzipCompressionLevel = 0 to avoid double-gzip
 https://gerrit.wikimedia.org/r/#/c/145771/

Which was bug 67928
Proper command:

curl 'http://bits.beta.wmflabs.org/en.wikipedia.beta.wmflabs.org/load.php?debug=7Cext.uls.nojs%7Cext.visualEditor.viewPageTarget.noscript%7Cext.wikihiero%7Cmediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.skinning.interface%7Cmediawiki.ui.button%7Cskins.vector.styles%7Cwikibase.client.init&only=styles&skin=vector&*' | gzcat | gzcat

** yields some CSS **
See https://it.wikipedia.org/w/index.php?title=Vallo_Atlantico&oldid=66317144&veaction=edit :
Reach the paragraph "Comandi del Vallo Atlantico", see there's a list there.
It looks weird because the syntax for the picture on the right is in the middle of the list.
Average user doesn't actually know/realize this and just wants to fix the list.
S/he will place the cursor right after the word "Danimarca" on the second line and hit Canc. The pic suddenly disappears.
 
(Right now there's a further bug 68708 which did lead to the image being removed without the user really noticing it: he noticed that the "Commando tedesco" line was not aligned properly and tried to fix that by going on that line and hitting Backspace. He didn't notice the pic getting highlighted and hit Backspace again, so the page lost focus and all he could see when he read the list again was that he had fixed it.)

--------------------------
**Version**: unspecified
**Severity**: normal
This is probably now fixed, as we change the selection when you type and move the object into view (so it's clear what's going to happen).
Steps to Reproduce:
1. Add some text to a page ("abc").

2. Click 'Save'.

3. Think, "Oops, I forgot to add…"

4. Click the cancel button on the Save dialog.

5. Go add the other text ("xyz") (or add or change images, templates, refs, or remove the abc text that you typed earlier; it doesn't matter what changes you make).

6. Save the page.

7. Where's the "xyz" text I just added?!

Actual Results:  
This is a "lose most of your work" bug:  

Everything you do after cancelling the first time is irretrievably lost, and unless you just happen to Review Changes before saving, you won't know that you're going to lose everything until it's too late to copy it to another page.


Reproducible: Always

Reported in Safari 7.1 on OS X 10.9.4; confirmed in Safari 6.1.4 and Firefox 30 on Mac OS 10.8.5

--------------------------
**Version**: unspecified
**Severity**: critical
*** This bug has been marked as a duplicate of bug 68619 ***
Intention:
Add a missing word ("and") towards the end of a sentence.  

Steps to Reproduce:
1. Start with a pragraph that contains:

* the en.wp {{convert}} template
* several [[Links]] after the template

2. Click before or after one of these links.

3. Type a space and the word "and" (or any word, but don't press return to create a new paragraph).

4. See the pawns?

5. Now click somewhere else, and watch the pawns and text replicate.

Actual Results:  
See https://en.wikipedia.org/w/index.php?oldid=618713444#Composition for an example of the results.


Reproducible: Always

Found in Firefox 31 on Windows 7; confirm in Safari 6 on Mac OS 10.8.5

May be related to Bug 68151

--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://en.wikipedia.org/w/index.php?oldid=618713444#Composition
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68151
Yeah, I think this is the same.

*** This bug has been marked as a duplicate of bug 68151 ***
It often happens to me that I select a letter in a word, copy it using Ctrl-C, and move the caret to the next line using the arrow-down keyboard key, and a space is added before the letter that I selected.

It's not completely consistent, but it happens in about 70% of my attempts to do the above.

--------------------------
**Version**: unspecified
**Severity**: normal
Not reproducible anymore - marking it as Resolved. 

For such issues any additional info would be helpful: which browser/OS the issue was happening. Also, the structure of a page may be important - say, the issue happens in bulleted list, or within a text with inline images etc
The `REQUEST_TIME` code that assumed HTTP context and was problematic when called from the command-line (e.g. in PHPUnit) was removed in {c12e93f9e1f5b05776bfb96ae467ffef15e7f13c}.

```lang=diff
@@ -53,22 +60,17 @@ static function logEvent( $schemaName, $revId, $event, $options = 0 ) {
-			'timestamp'        => $_SERVER[ 'REQUEST_TIME' ],		
```
Your definition of "a bunch" differs of 1-2 orders of magnitude from mine. :) I still have open patches to fix the bugs I found in the last phpunit run; until those are merged in gerrit, I won't try again.
Seems EventLogging works fine under HHVM with a bunch of other extensions. Proposed https://gerrit.wikimedia.org/r/#/c/185405/ passed and ran with:

```
mediawiki/extensions/AbuseFilter
mediawiki/extensions/CheckUser
mediawiki/extensions/ConfirmEdit
mediawiki/extensions/Echo
mediawiki/extensions/EventLogging
mediawiki/extensions/JsonConfig
mediawiki/extensions/Mantle
mediawiki/extensions/MobileApp
mediawiki/extensions/MobileFrontend
mediawiki/extensions/SpamBlacklist
mediawiki/extensions/Thanks
mediawiki/extensions/VisualEditor
mediawiki/extensions/WikiGrok
mediawiki/extensions/ZeroBanner
mediawiki/extensions/ZeroPortal
```

Can you still reproduce?
Possible regression: Today I created a few fresh accounts on beta labs (desktop Chrome browser, mobile site) to test other stuff, and I noticed that when I tapped the edit pencil for the first time, I was taken to the VE editor instead of wikitext editor. Awhile back, we decided *not* to send new users to VE by default on any wiki and merged a patch to fix this -- looks like it's no longer working 
:-/

--------------------------
**Version**: unspecified
**Severity**: normal
When I cleared cookies, the problem disappeared, so it must've been just lingering VE cookie crumbs on my machine from all those sockpuppets I've been using on beta labs :) Closing.
So far haven't been able to reproduce this. Tested in desktop Chrome on beta labs.
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/0AK0U7Nl
Screenshot of bug

In general items in the sidebar are wiki input (template names, parameter names) which are fine being cut off.

When the item is a UI element for inserting a new parameter though, it shouldn't be cut off. We might as well put the ellipsis in the localisation message (joking) for it is never rendered fully... (also no tooltip with full version). This is even more problematic considered it's localised. In English the first two words are enough to make sense of it, but we can't assume that for all languages.

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

**Attached**: {F14224}
Width is fine in en/fr/de/nl, and appears in response to user action, selected at first.
Right now there's imho two usability issues with the default (simplified) Template editor related to getting to the screen for adding parameters.

I expect to see an input field and a pool of parameters to pick from right after clicking.

Instead there is a widget labelled "Add more information". This is apparently the button to unhide the panel to add parameters. I'm not sure how this is useful, we can just ditch that button and have that always be visible? (maybe in the odd case of templates with no known parameters or explicitly documented as taking none we could hide it behind a button to avoid confusion, but we should optimise for the common case).

This widget is confusing because:
* It's labelled "more" information, but at this point it's the first parameter, not an additional one (unless you count the template name as information).
* It's called "information" which is a bit vague (we use "parameter" and "field" elsewhere).
* After inserting a parameter, the insertion panel goes away and I have to re-open it again. I recall it being there from the start and staying there in the past. Because it's implemented as a placeholder for an individual parameter now, this is presumably no longer possible. I think we should make this panel the "add parameter" interface, and not have "add parameter" insert this placeholder panel for a one-off use.

I'd say, as a first step (enough to fix this bug), hide the button, have the panel be visible from the start. And then continue like it is now (after inserting the first, the "add more information" button is used to add additional parameters.
It seems like the current version of the template dialog has fixed these usability problems, so I'm closing.
Screenshot

Steps to reproduce:

1.Open any page in betalabs with VE
2.Open the page settings option

Observed Result:
The Page Settings menu is getting cut off

See the screenshot attached

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

**Attached**: {F14188}
*** This bug has been marked as a duplicate of bug 57366 ***
Screenshot tests have their own build, we do not want them running in the regular VE build: https://integration.wikimedia.org/ci/view/BrowserTests/job/browsertests-VisualEditor-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce/115/testReport/

--------------------------
**Version**: wmf-deployment
**Severity**: normal
Change 149045 merged by jenkins-bot:
Language screenshot feature file runs only in language screenshot job

https://gerrit.wikimedia.org/r/149045
Change 149047 merged by jenkins-bot:
[BrowserTest] Language screenshot feature runs only for language screenshot job

https://gerrit.wikimedia.org/r/149047
Change 149047 had a related patch set uploaded by Vikassy:
[BrowserTest] Language screenshot feature runs only for language screenshot job

https://gerrit.wikimedia.org/r/149047
Change 149045 had a related patch set uploaded by Vikassy:
WIP: Language screenshot runs only for language screenshot job

https://gerrit.wikimedia.org/r/149045
Vikas and I will pair on this, probably today.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Select the image and insert a template like citation needed

Observed Result:
A highlight appears all around the image 
See the screenshot attached

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

**Attached**: {F14620}
Screenshot

Steps to reproduce:

1.Open a page with VE.
2.Go to Insert>Media.
3.Search for an image.
4.Select an image.
5.When the Media Settings>General settings for that image appears,click on the link inspector icon

Observed Result:
The link inspector icon appears over the toolbar,overlapping with the border of the Media dialog

See the screenshot attached


This issue was found in test2, I need to test it in master once Betalabs is alive again.

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

**Attached**: {F14472}
Resolved months ago.
When I select (highlight) some text on the edit mode and start to type some text by replacing the old text, Visual Editor starts copying the text and typing by itself. I've seen it happening only on few articles, like https://fi.wikipedia.org/w/index.php?title=Arseni_Jatsenjuk&veaction=edit and https://fi.wikipedia.org/w/index.php?title=Mykola_Azarov&veaction=edit

I tried this with Firefox and Chrome, logged-in / logged-out, and the same happens on both browsers.

--------------------------
**Version**: unspecified
**Severity**: normal
Seems to be fixed - not reproducible.
Yeah, I'm pretty sure we fixed this CE buggy stuff a few months ago.
I can't reproduce this issue...
In case someone didn't understand my explanation, I have a video uploaded to http://tinypic.com/r/mbik2w/8
On the video I only typed "k" (it doesn't matter what key you hit), and that's what happened.
https://test.wikipedia.org/w/index.php?title=Topic:Foo&action=edit&redlink=1

[42ec2509] /w/index.php?title=Topic:Foo&action=edit&redlink=1 Exception from line 2340 of /usr/local/apache/common-local/php-1.24wmf14/includes/EditPage.php: This content model is not supported: flow-board

Backtrace:

#0 /usr/local/apache/common-local/php-1.24wmf14/includes/EditPage.php(960): EditPage->toEditText(Flow\Content\BoardContent)
#1 /usr/local/apache/common-local/php-1.24wmf14/includes/EditPage.php(536): EditPage->initialiseForm()
#2 /usr/local/apache/common-local/php-1.24wmf14/includes/actions/EditAction.php(49): EditPage->edit()
#3 /usr/local/apache/common-local/php-1.24wmf14/includes/MediaWiki.php(431): EditAction->show()
#4 /usr/local/apache/common-local/php-1.24wmf14/includes/MediaWiki.php(295): MediaWiki->performAction(Article, Title)
#5 /usr/local/apache/common-local/php-1.24wmf14/includes/MediaWiki.php(603): MediaWiki->performRequest()
#6 /usr/local/apache/common-local/php-1.24wmf14/includes/MediaWiki.php(452): MediaWiki->main()
#7 /usr/local/apache/common-local/php-1.24wmf14/index.php(46): MediaWiki->run()
#8 /usr/local/apache/common-local/w/index.php(3): require(string)
#9 {main}

--------------------------
**Version**: master
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=73443
This bug is about the behavior of a wiki link `[[Topic:NoSuchUUID]]` MW detects the page doesn't exist so turns it into a URL with `?action=edit&redlink=1`.

Flow's behavior with such a "redlink" URL is now:
  # Redirect to plain Topic:NoSuchUUID
  # With the fix in T75443 , that results in HTTP status 500 and a friendlier "The requested page title was invalid. Pages in the Topic namespace are automatically created by Flow." (`flow-error-invalid-topic-uuid` msg)

I think this is reasonable behavior, so we can declare this resolved
Update: there is still an exception being thrown at 
https://test.wikipedia.org/w/index.php?title=Topic:Foo&action=edit&redlink=1
S Page is aware of this issue. He describes it here: https://www.mediawiki.org/wiki/User:S_Page_(WMF)#Flow_board_links
(In reply to Justin Breeze from comment #3)
> Just a note...
> 
> I am getting this same error on new pages only. I am using VisualEditor.
> 
> When I update the portion of the URL from "&action=edit&redlink=1" to
> "&veaction=edit&redlink=1" it works fine.

The only reason this works is because the &veaction=edit is completely ignored, thus not creating any problem.
Update: VisualEditor isn't the problem. Its the &action=edit portion of the link. If I click on a link that doesn't include &action=edit (even if the page isn't created), such as http://website/w/index.php/User_talk:User, everything works like normal. But if I click a link, such as http://website/w/index.php?title=User_talk:User&action=edit&redlink=1, I get the error described.
Confirmed on my wiki. Only happens with new pages and when VisualEditor is on. Everything is resolved when VisualEditor is turned off.
**jbreeze** wrote:

Just a note...

I am getting this same error on new pages only. I am using VisualEditor.

When I update the portion of the URL from "&action=edit&redlink=1" to "&veaction=edit&redlink=1" it works fine.
Just for the record, a different error is seen at https://test.wikipedia.org/wiki/Topic:Foo

== Error ==

Invalid value was provided for loading flow content. 

Return to Main Page.

[6cf2bd00] /wiki/Topic:Foo Exception from line 162 of /usr/local/apache/common-local/php-1.24wmf14/extensions/Flow/includes/Model/UUID.php: Unknown input to UUID class

Backtrace:

#0 /usr/local/apache/common-local/php-1.24wmf14/extensions/Flow/includes/Actions/Action.php(118): Flow\Model\UUID::create(string)
 #1 /usr/local/apache/common-local/php-1.24wmf14/extensions/Flow/includes/Actions/Action.php(70): Flow\Actions\FlowAction->detectWorkflowId(Title, WebRequest)
 #2 /usr/local/apache/common-local/php-1.24wmf14/extensions/Flow/includes/Actions/Action.php(32): Flow\Actions\FlowAction->showForAction(string)
 #3 /usr/local/apache/common-local/php-1.24wmf14/includes/MediaWiki.php(431): Flow\Actions\FlowAction->show()
 #4 /usr/local/apache/common-local/php-1.24wmf14/includes/MediaWiki.php(295): MediaWiki->performAction(Article, Title)
 #5 /usr/local/apache/common-local/php-1.24wmf14/includes/MediaWiki.php(603): MediaWiki->performRequest()
 #6 /usr/local/apache/common-local/php-1.24wmf14/includes/MediaWiki.php(452): MediaWiki->main()
 #7 /usr/local/apache/common-local/php-1.24wmf14/index.php(46): MediaWiki->run()
 #8 /usr/local/apache/common-local/w/index.php(3): require(string)
 #9 {main}
Put this in the backlog: https://trello.com/c/L7Kokob5

Thanks for the report!
Screenshot

Steps-
1> Select Language form the Style text drop down.
2>In the Language Selector dialog delete the two-letter code. Press done.
3> Now type in some text in the editor, notice that beside the Language icon there is “$1” in the tootltip. See Screenshot.

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

**Attached**: {F14154}
Fixed as a side effect of https://gerrit.wikimedia.org/r/#/c/160098/
Yes, happening in Betalabs as well.
Tested on test2.
**Author:** `Coiby.Xu`

**Description:**
I'm testing VisualEditor on 1.23.1. Everything is OK except for inserting an image. When you insert media, you can't use search function. The error message is 'error":{"code":"readapidenied","info":"You need read permission to use this module"}'. However if I set  $wgGroupPermissions['*']['read'] = true, the pictures will be shown.

--------------------------
**Version**: unspecified
**Severity**: major
I think this is bug 64822.

*** This bug has been marked as a duplicate of bug 64822 ***
Confirmed on officewiki
I can confirm this issue. The problem is related to the use of the parameter 'callback=jQuery...' in the api call. 

According to https://www.mediawiki.org/wiki/API:Data_formats#Callback_restrictions, when callback mode is used clients are treated as anonymous users, even after logging in. Is callback mode strictly necessary?
Screenshot

Steps to reproduce:

1.Open a page and insert an image
2.Insert another image inside it
3.Select the image inside and try to open link inspector

Observed Result;
The link inspector appears without any UI'


See the screenshot attached

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

**Attached**: {F14529}
The inspector now "works", but due to bug 72431 immediately closes, AFAICT. Nominally FIXED.
See https://el.wikipedia.org/w/index.php?title=%CE%A7%CF%81%CE%AE%CF%83%CF%84%CE%B7%CF%82%3AElitre_%28WMF%29%2Fsandbox&diff=4757904&oldid=4757901 .
Replace one or more words with "Foobar" (that is, highlight the word(s), then type Foobar). Works once, works twice, then the third time corruption happens and le wild snowman appears.
Must say that I only managed to reproduce that in my sandbox, which features content from https://el.wikipedia.org/wiki/%CE%95%CF%80%CE%B9%CF%84%CF%8C%CE%BA%CE%B9%CE%BF , and in this article page.
It happens in Chrome and Firefox, tested under Windows 7, Ubuntu 13.10 and OS X 10.8.
During an attempt to reproduce, VE also suppressed existing nowiki tags: https://el.wikipedia.org/w/index.php?title=%CE%A7%CF%81%CE%AE%CF%83%CF%84%CE%B7%CF%82:P.a.a/%CF%80%CF%81%CF%8C%CF%87%CE%B5%CE%B9%CF%81%CE%BF&diff=next&oldid=4757859 .

--------------------------
**Version**: unspecified
**Severity**: normal
I think the Πηγή template is the issue here; down-page of the template everything breaks, up-page it works. That means it's almost certainly a duplicate of bug 67992.

*** This bug has been marked as a duplicate of bug 67992 ***
I found another, smaller, text that manifests this bug https://el.wikipedia.org/w/index.php?title=%CE%A7%CF%81%CE%AE%CF%83%CF%84%CE%B7%CF%82:P.a.a/%CF%80%CF%81%CF%8C%CF%87%CE%B5%CE%B9%CF%81%CE%BF&oldid=4767252
(In reply to Elitre from comment #0)
> See
> https://el.wikipedia.org/w/index.
> php?title=%CE%A7%CF%81%CE%AE%CF%83%CF%84%CE%B7%CF%82%3AElitre_%28WMF%29%2Fsan
> dbox&diff=4757904&oldid=4757901 .
> Replace one or more words with "Foobar" (that is, highlight the word(s),
> then type Foobar). Works once, works twice, then the third time corruption
> happens and le wild snowman appears.
> Must say that I only managed to reproduce that in my sandbox, which features
> content from
> https://el.wikipedia.org/wiki/
> %CE%95%CF%80%CE%B9%CF%84%CF%8C%CE%BA%CE%B9%CE%BF , and in this article page.
> It happens in Chrome and Firefox, tested under Windows 7, Ubuntu 13.10 and
> OS X 10.8.
> During an attempt to reproduce, VE also suppressed existing nowiki tags:
> https://el.wikipedia.org/w/index.
> php?title=%CE%A7%CF%81%CE%AE%CF%83%CF%84%CE%B7%CF%82:P.a.a/
> %CF%80%CF%81%CF%8C%CF%87%CE%B5%CE%B9%CF%81%CE%BF&diff=next&oldid=4757859 .

The nowiki tags around the percentage signs were added by me, in an effort to eliminate a possible, if remote, cause of interference.
Take a page like https://en.wikipedia.org/wiki/Heliozela_rutilella?veaction=edit (that is, starting with a template, so there's some space above the first line of the article).
Clicking on the link tool and pressing ESC will automatically make the first word (Heliozela) a link to the Heliozela article. 
Click on the up arrow, then click on the link tool again, and press ESC. You get the word Heliozela again (with no links).

**See Also**:
T70101
Serious comment: Seems to be fixed now. Closing.
Test comment! Hi mom!
Load VE. Say "Foobar" is the first word on the page.
If you click on the link tool, by mistake or not, without selecting anything before, Foobar will automatically become a link to the Foobar page (it doesn't help that pressing ESC doesn't abort the action, the link gets applied anyway, as we know).
NicoV noticed this in several French articles, where you can quite tell links happened "by mistake" since the first word is an article, "le".

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68102
Ah. Bug 69407. Alright, thanks.
I hereby distance myself from that guy who wrote "enhancement" in comment 8, as differing interpretations and judgements of that term might trigger "lies". Please feel free to argument why not supporting Esc is a "serious bug" in a separate, non-enhancement request if you wish so. Thank you.
**ronnirubin** wrote:

(In reply to Andre Klapper from comment #8)
> (In reply to Arthur Rubin from comment #7)
> > I don't know how to reopen this.
> 
> You were asked to not reopen this, but to file a new and separate
> enhancement request for the Esc behavior if you wish so.

So, you want me to lie and call it an "enhancement request" rather than a bug fix.  _That_, I won't do.  I'll still call it a bug fix, and apparently a serious one.
(In reply to Arthur Rubin from comment #7)
> I don't know how to reopen this.

You were asked to not reopen this, but to file a new and separate enhancement request for the Esc behavior if you wish so.
**ronnirubin** wrote:

I don't know how to reopen this.  As an Admin on en.Wikipedia, I can say that having "Escape" _not_ close the box and take none of the actions indicated in the box is a deal-stopper for me.  I will argue against VE be made default if this isn't fixed.
Please don't edit war on Bugzilla. Create a new bug about an actual issue if you wish.
Well, give me one example of a software behaving like that: in any software I know, when you click on a button that open a dialog, if you cancel the dialog then no action is done.

The current behavior is probably the reason of many links created in frwiki to pages "Le", "La", "Les", ... (all created by VE) which we have to fix on a regular basis. And we obviously miss all the other links created by mistake.

Please, change the current behavior, so that Esc key behaves as in any normal software.
(In reply to NicoV from comment #2)
> But the main problem with this is that the ESC key is not working correctly
> (it should cancel the action and not silently validate it). Do you plan to
> do something to make the ESC key work as it works in every other application
> ?

You are mistaken. The Escape key is doing exactly what users expect; it closes the window. The user clicking the link button – not the closing the link editor window – is what makes the link.
Please read my comment: the main problem is ESC key not working at all as could be expected by any user.
I was the one reporting the issue with words like "le" being made into internal links by mistake on frwiki. I think the behavior of automatically selecting the entire word when make an internal link should be kept (it's probably causing less issues than it's avoiding).

But the main problem with this is that the ESC key is not working correctly (it should cancel the action and not silently validate it). Do you plan to do something to make the ESC key work as it works in every other application ?
This is explicitly a feature that was requested (years ago now). People clicking buttons and not paying attention to what they're doing seems more like a social issue than a software bug.
Seen on beta labs as 15 July: 

Upon loading a simple page such as http://en.wikipedia.beta.wmflabs.org/wiki/Media_Interface_VisualEditor_Test?veaction=edit

The contentEditable surface used to appear reliably in under ten seconds.  Now I am seeing 10+ second load times for about one page load of every three.

--------------------------
**Version**: unspecified
**Severity**: normal
I reported this poorly, needs more research.
*open old version of artcle
*press tab Edit
*make some changes
*press tab Edit source
*in warnng window press "Discard changes"
->will open this page https://en.wikipedia.org/w/index.php?action=edit&veswitched=1

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows 8.1
**Platform**: PC
(In reply to James Forrester from comment #1)
> This is consistent with how the wikitext editor works – on an old page, the
> "Read" link goes to the latest (not old) version of the page. VisualEditor
> deliberately does the same as that.


May be possible change link for tab Editsource while user work in VE and do the same thing that do [Ξ]->"Switch to source code". This enough intuitive behavior.
This is consistent with how the wikitext editor works – on an old page, the "Read" link goes to the latest (not old) version of the page. VisualEditor deliberately does the same as that.
in order to save this change a user must make another change in the dialog in addition to setting the image size to default

--------------------------
**Version**: unspecified
**Severity**: normal
Yeah, dupe of bug 67684.

*** This bug has been marked as a duplicate of bug 67684 ***
Has this bug been fixed? It works fine for me.
**Author:** `manueltassi91`

**Description:**
In itwiki, we've noticed that when including [it.wikipedia.org/wiki/Template:A] in a page using VE doesn't show all required parameters, but just one. In fact, with VE there should be three required parameters ("Motivazione", "Data di inserimento" "Argomento"), but in the dialog only "Motivazione" is shown.

--------------------------
**Version**: unspecified
**Severity**: normal
I wonder if it was just waiting for someone to null edit the template page. I guess this bug is WFM.
**manueltassi91** wrote:

No. At the moment the problem seems to be solved.
Is this still valid? I just checked and the three required parameters are showing.
Possibly a dupe of bug 50747, but still: if a parameter is mandatory, I need to 1) know it is, 2) know I need to add it or the template will be broken. I don't understand why we 1) aren't making the user aware that such parameters exist, 2) are even hiding them, dooming templates to be incomplete and users to be confused.
I couldn't reproduce this in any other article, but it may happen elsewhere:

1. Edit https://en.wikipedia.org/wiki/Pristina_International_Airport (I tested in this version: https://en.wikipedia.org/w/index.php?title=Pristina_International_Airport&oldid=615886404 ).

2. Put the caret in the first paragraph, in the word "handles".

3. Press Backspace.

Expected: The caret moves one character and deletes it.
Observed: The caret deletes one character before it, but moves back 26 characers to the beginning of the word "international".

Happened to me in Firefox and Chrome on Fedora.

--------------------------
**Version**: unspecified
**Severity**: normal
Aha, this was a dupe of bug 67862. Sorry!

*** This bug has been marked as a duplicate of bug 67862 ***
I guess it was fixed at some point. Thanks for testing.
Hmm... Can't reproduce on the latest version with Chrome.
**Author:** `002soym`

**Description:**
Intention:
To edit a wiki code

Steps to Reproduce:
A menu item of VisusalEditor in Ukrainian Wikipedia has been changed by mistake. Now we have instead of the correct menu item '''Редагувати код''' (Edit code) the absolutely incorrect '''Править викитекст'''. It's not even in Ukrainian.
[https://uk.wikipedia.org/wiki/MediaWiki:Visualeditor-ca-editsource shows] the correct label here.

Actual Results:  
menu item '''Править викитекст''' 

Expected Results:  
menu item '''Редагувати код''' (Edit code)

Reproducible: Didn't try

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://uk.wikipedia.org/wiki/%D0%92%D1%96%D0%BA%D1%96%D0%BF%D0%B5%D0%B4%D1%96%D1%8F
As I replied on wiki to you, this is bug 67805

*** This bug has been marked as a duplicate of bug 67805 ***
In production in beta. Steps to repro:

1. Go to French, Polish, or Russian Wikipedia (where VE should be the default editing experience). 
2. Opt into beta, log in, and attempt to edit a page.

Expected: I am taken to VE editing mode, since VE is the default editing experience on those projects.

Actual: I am taken to wikitext editing. Furthermore, I don't have the option to switch to VE editing in the edit window (the cog that shows me the drop-down menu is missing). 

Also observed on Portuguese and Spanish Wikipedia. It seems to be everywhere except enwiki.

--------------------------
**Version**: unspecified
**Severity**: normal
Derp, helps to enable beta again after you clear your cookies for testing purposes :)
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/EShXsKmu
new reflist behavior adds in the reflist to the saved/rendered display like TOC but when in VE edit mode the reflist is not displayed, which is confusing, especially when user is adding references

--------------------------
**Version**: unspecified
**Severity**: normal
What is the problem here on the Parsoid end?
I guess this refers to https://gerrit.wikimedia.org/r/#/c/141583/ / bug 66860.
Screenshot

Table cell templates are editable, but their re-rendering is broken.

Example: try modifying any of the table cell templates at https://nl.wikipedia.org/wiki/Gebruiker:Ad_Huikeshoven/jh?uselang=en&veaction=edit#Prestatietabel

They can be edited, such an edit can be saved and results in correct wikitext, but is rendered broken (the markup is rendered as text, instead of creating a table cell).

(Found when playing with bug 67850.)

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://nl.wikipedia.org/wiki/Gebruiker:Ad_Huikeshoven/jh?uselang=en&veaction=edit#Prestatietabel

**Attached**: {F14539}
This is because we don't (can't) send context right now when asking for the template to be re-rendered – bug 51146 is the original report of this issue. Merging. (Boo.)

*** This bug has been marked as a duplicate of bug 51146 ***
Reported on fr.wp. Verified so far in Win 7 (Chrome and FF). 

You can use this page https://fr.wikipedia.org/w/index.php?title=Utilisateur:Elitre_%28WMF%29/Prove2&oldid=105329509 to reproduce.
Steps:

    1) Place the cursor immediatly after "croisières", before the non-breaking space.
    2) Add a space. This space is added after the cursor.
    3) Press Right Arrow then Left Arrow to make the cursor move, but it is finally at the same place.
    4) Add a space : the pawn appears in the link.
    5) Again right arrow, then add another space : a second pawn appears after the link.
    6) If you try to type text after the last pawn, only a pawns appears. No text.

    To have text written from right to left :
    1) Place the cursor immediatly after "croisières", before the non-breaking space.
    2) Add a space. This space is added after the cursor.
    3) Press Right Arrow to make the cursor move.
    4) Add a space : the pawn appears.
    5) Again right arrow, then add another space (so efter the colon) : a second pawn appears.
    6) Left arrow twice (cursor before the colon) and type text : it's written from right to left.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 68151 ***
Cite menu is inaccessible

The dropdown menu for the Cite tool is not displaying correctly for me in Safari 6.1.4.  

The screenshots show two different font sizes/resolutions.  This isn't consistent for me.  I zoomed in before it happened the first time.

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

**Attached**: {F14279}
This sounds like bug 64388 which is very troubling. :-(

*** This bug has been marked as a duplicate of bug 64388 ***
Created attachment 15883
What happens is you have zoomed in

**Attached**: {F14282}
We currently don't. We should.

--------------------------
**Version**: unspecified
**Severity**: enhancement
*** This bug has been marked as a duplicate of bug 67690 ***
Steps to reproduce:

1.Open a page with Mobile VE with desktop safari or iOS safari
2.Create a link to a new page and save the page
3.Go to that new page that you just created link to
4.Edit that page and save it

Observed Result:

It will redirect you to the page that you started with at step1

Environment:Betalabs and test2

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60848
https://bugzilla.wikimedia.org/show_bug.cgi?id=65041
https://bugzilla.wikimedia.org/show_bug.cgi?id=69559
Bug is no longer reproducible due to https://gerrit.wikimedia.org/r/#/c/164131/
I think this bug is actually the same as bug 60848 and bug 65041. Bug 60848 was closed by Jon as WONTFIX. Should we reopen it? Bug 65041 is just another specific case of the underlying issue.
The issue here is that we're adding a hash to the URL when we launch the editor, and then doing history.back() after it's saved to restore the original URL. The only problem is that redlinks link directly to the editor, so once you're done, going back takes you to the previous article. Linking directly to the editor is the correct behavior (it's the same as is done on desktop). The problem is the  history.back() hack (IMO).
Reproducing this bug is currently blocked by bug 68249.
Just checked with Rumana and it's actually an issue in beta mode too.
So not necessarily related to ajax page loading/link hijacking :)
OT: I notice you are testing VisualEditor in alpha since the bug is assigned to alpha. Please don't.... Please use beta which is more stable and will help us filter out bugs in VE vs bugs in mobile.

Can you confirm the above problem happens in the alpha mode or is it beta mode (it does indeed sound like alpha)?
Sounds like another lazy-loading bug.
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/wdlVRRim
Screenshot

Steps to reproduce:

1.Select a reference note in VE with firefox
2.Press right/left
3.Type something


Observed Result:
A pawn appears instead of the text


See the screenshot attached

Environment:Production (en.wiki)

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

**Attached**: {F14615}
Boo.

*** This bug has been marked as a duplicate of bug 58315 ***
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Make a text Bold
3.Now place your cursor somewhere in the middle of that text
4.Select the option "Clear Styling" from style menu


Observed Result:
The text is still styled as Bold, however the highlight on Bold option in style menu is not anymore there.

See the screenshot attached

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

**Attached**: {F14613}
This is intentional; "clear styling" without a selection applies to the pre-annotation stack.
RD asked me to file this bug for him.

--------------------------
**Version**: unspecified
**Severity**: normal
Hmm, I guess "Temporarily disable VisualEditor while it is in beta" works. Missed that.
I am the RD to which Lego refers to. ;-)

Rather than creating a css hack to hide the effects of VE, it should be an option somewhere in user preferences to "disable" VE.  The default can be set to having VE enabled.

I am an OTRS administrator.  Some were originally under the impression that this was going to be the case but as of now there is no way to opt-out other than personal scripts.
Screen recording of bug

1. Edit page with a link is applied to multiple words in sequence.
   such as "QUnit - Foo bar baz".
2. Select part of it (e.g. "Foo bar baz")
3. Type something new (e.g. "Quux")

Expected:

Quux replaces "Foo bar baz" and is a link as well.

Actual:

The text is removed, the link now ends at "-" and the inserted text "Quux" is just plain unlinked text.

This might have to do with linktrail processing and the operation happening as separate delete/insert.


Video: http://cl.ly/2K1q1A471G2N

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

**Attached**: {F14240}
(In reply to This, that and the other from comment #2)
> (In reply to James Forrester from comment #1)
> > This is intentional behaviour.
> 
> Doesn't it strike you as something a user may very legitimately and
> intuitively want to accomplish?

Yes. We spent months discussing this, looking at dozens of different rich editors' behaviours. That's why I'm reasonably confident that the answer is "tough".
(In reply to James Forrester from comment #1)
> This is intentional behaviour.

Doesn't it strike you as something a user may very legitimately and intuitively want to accomplish?
You've failed to spot the key part of this – you have to select *to or past the end of the link*.

Selections from inside a whitespace-terminated annotation to outside it which replace into it with a whitespace character will terminate it. Selections from inside said annotation to another place inside it (in your example, "Foo bar ba" but not "Foo bar baz") don't.

This is intentional behaviour.
Screen recording of bug

1. Select text
2. cmd+K (Mac) to apply a link annotation

Expected:

Either it shows page titles with a default selection (e.g. a link to the exact link text), or only shows suggestions and require I pick one.

Actual:

Becomes link to the exact link text but with no way of knowing that, nor with an intuitive way to select a different target (see attached video).

http://cl.ly/3P2P2E1a1w1A

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

**Attached**: {F14235}
The current link inspector solved this bug. To clarify, as seen in the video, the problem was that the selection menu did not open by default (required an additional needless click/focus). Leaving the user in a confused state.

This has nothing to do with what the most common use case is. We still link to the target by default. But we now show the other options so that the user knows that it was actually turned into a link. Not just a pre-filled text box waiting for a user action. This made the most common use case more intuitive.
No. We chose to not show this as the most common case is making an internal link to the term you've selected, and we wanted this to be as painless as possible.
**Author:** `jazeckel`

**Description:**
wiki debug log for navigating to and attempting to edit a page

I am attempting to configure the VisualEditor REL1_23 to run with my MediaWiki instance.  I am using MediaWiki 1.23 and it is a private wiki.  It's served by IIS on Windows Server 2012 R2.  I am able to create a very simple page using it, although it runs slowly.  However, any attempt to edit the page -- even a page containing only one simple sentence -- times out with Parsoid.  I ran all of the Parsoid tests following installation and they all passed, and from Parsoid's test webpage (localhost:8000) I was able to run those tests and they succeed quickly.  However, I can't edit any pages of my wiki.  This is the output from the Parsoid service during an edit attempt:

[warning/api][null/Test] Failed API request, 8 retries remaining.
[info][localhost/Test] starting parsing
[info][localhost/Test?oldid=834] completed parsing in 45006 ms

The completed parsing line occurs after I click cancel on the prompt telling me the request timed out.  When I had the timeout set to 60s, I would see "8 tries remaining" and then "7 tries remaining" before it timed out (I have since changed the timeout to 45s).  The content of the page in this example is simply "this is a visual editor test."

Relevant information:
- Windows Server 2012 R2
- IIS v8.5.9600.16384
- 32-bit node.js
- Parsoid on port 8000
- Browser used is Chrome 35.0.1916.153 m
- MediaWiki 1.23, set to require log in to view/edit
- same problem in all skins that VisualEditor runs on

A debug log from MediaWiki is attached.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: other
**Platform**: PC

**Attached**: {F14490}
(In reply to C. Scott Ananian from comment #16)
> gwicke: we should probably not be timing out if the api request returns an
> error.  Maybe we should look into this?

My understanding of the code is that we only retry when getting an error object, but not if we got an HTTP status code. There's either no proper HTTP status returned by this particular wiki setup, or the request library returns an error when it should not. 

I just tested this locally, and there's no retrying on unauthorized requests. This means that this is probably an IIS-specific issue, where IIS does not return a proper HTTP status on authentication errors.
**jazeckel** wrote:

Okay, I finally have it working.  I think this boils down to configuration errors so the instructions for setup for Parsoid and the VisualEditor should probably be clarified, but also it would be nice to improve the error messaging so that a permissions error doesn't cause a timeout.

Here's what I did to fix it:
- made the key in parsoidConfig.setInterwiki equal to $wgVisualEditorParsoidPrefix, both of which I set to "auc" (rather than "localhost/auc")
- set $wgSessionsInObjectCache = true (this is the line that didn't seem to have any effect before, but that was probably because the rest was not configured right)
- set $wgVisualEditorParsoidForwardCookies = true (I already had that one set)

Thanks for your help!
**jazeckel** wrote:

FWIW if I go to http://localhost:8000/auc/Main_Page from a browser where my login credentials are cached, the content will load.  If I'm logged out of the wiki in that browser, I will get an error.
In particular, one running parsoid can service multiple different mediawikis.  They are distinguished by the $wgVisualEditorParsoidPrefix and corresponding localsettings.js.  For example, you should be able to visit your running parsoid instance on http://localhost:8080 (or whatever port you used) and then get different pages for:

http://localhost:8080/enwiki/Main_Page (links to wikipedia using 'enwiki' prefix)
http://localhost:8080/localhost/Main_Page
http://localhost:8080/foo/Main_Page

given

parsoidConfig.setInterwiki( 'localhost', 'some api endpoint' );
parsoidConfig.setInterwiki( 'foo', 'some different api endpoint' );

Our docs could probably explain this better.  Suggestions welcome.
(In reply to jazeckel from comment #15)
> Also, if I comment out the entire parsoidConfig.setInterwiki line in my
> localsettings.js, it loads the visual editor but with the wrong wiki's
> content.  It appears that having "localhost" as the key on that line will
> cause it to fail regardless, and if I change "localhost" to anything else it
> loads the wrong content.  For example, I could make the line:
> parsoidConfig.setInterwiki( 'foo', 'http://localhost/auc/wiki/api.php' );
> 
> and it will load the editor but with the wrong content.

Yes, the 'localhost' part here has to match the string you set $wgVisualEditorParsoidPrefix to.
(In reply to jazeckel from comment #11)
> Hmm, so this is kind of interesting.  If I go to the URL but with the server
> name instead of "localhost," I get what I assume is the correct result -- a
> big block of key value pairs about locales and such.  If I go to the URL
> with "localhost", I get this: 
> 
> {"error":{"code":"readapidenied","info":"You need read permission to use
> this module"}}
> 
> I don't see any PHP error logs created though perhaps I am not looking in
> the right place.

This is generated if the anonymous user doesn't have appropriate permissions to access the API.  In include/DefaultSettings.php there is a group of permissions including:

$wgGroupPermissions['*']['writeapi'] = true;

I'm guessing that one of these is prohibiting anonymous access to the API.  I bet it's not actually the case that it works when you use the server name, I bet that somehow you're actually accessing the wrong wiki in that case.  I'm not a mediawiki permissions expert though, so take what I say with a grain of salt.

If you are mucking with permissions, this link may be useful:
https://www.mediawiki.org/wiki/Extension:VisualEditor#Linking_with_Parsoid_in_private_wikis

gwicke: we should probably not be timing out if the api request returns an error.  Maybe we should look into this?
**jazeckel** wrote:

Also, if I comment out the entire parsoidConfig.setInterwiki line in my localsettings.js, it loads the visual editor but with the wrong wiki's content.  It appears that having "localhost" as the key on that line will cause it to fail regardless, and if I change "localhost" to anything else it loads the wrong content.  For example, I could make the line:
parsoidConfig.setInterwiki( 'foo', 'http://localhost/auc/wiki/api.php' );

and it will load the editor but with the wrong content.
**jazeckel** wrote:

To clarify, when it succeeds and loads the page from the wrong wiki, the URL I see in the debug output is "http://localhost/wiki/api.php" whereas the correct wiki is "http://localhost/auc/wiki/api.php", which is as specified in Parsoid's localsettings (although in localsettings it is specified now with servername instead of localhost).
**jazeckel** wrote:

This is extremely confusing.  Here are the current issues:
1) I don't understand why changing out localhost for servername should make a difference, considering they are the same machine.
2) If I change out localhost for servername in parsoid/api/localsettings.js, then when I try to edit the visual editor loads, but it loads with the content of a page from a different wiki that runs on the same server.  Is there a missing database configuration in the Parsoid localsettings?
3) If I change the wiki/localsettings.js to also use servername instead of localhost, it times out again.
It sounds like your configured API URL should actually include the real server name instead of 'localhost'. Could you change the config & verify that this fixes your issue?
**jazeckel** wrote:

Hmm, so this is kind of interesting.  If I go to the URL but with the server name instead of "localhost," I get what I assume is the correct result -- a big block of key value pairs about locales and such.  If I go to the URL with "localhost", I get this: 

{"error":{"code":"readapidenied","info":"You need read permission to use this module"}}

I don't see any PHP error logs created though perhaps I am not looking in the right place.
@jazeckel: so, when you visit http://localhost/auc/wiki/api.php?format=json&action=query&meta=siteinfo&siprop=namespaces%7Cnamespacealiases%7Cmagicwords%7Cfunctionhooks%7Cextensiontags%7Cgeneral%7Cinterwikimap%7Clanguages%7Cprotocols manually, what happens?  Does anything show up in your PHP server logs?

It sounds like there's something wrong with your wiki's API entrypoint.
**jazeckel** wrote:

Okay, I applied the patch, ran "node api/server.js" in the console, then loaded up my test page and clicked edit for the visual editor.  Some time passed with no output, then I got this:

Request 1: http://localhost/auc/wiki/api.php?format=json&action=query&meta=sitei
nfo&siprop=namespaces%7Cnamespacealiases%7Cmagicwords%7Cfunctionhooks%7Cextensio
ntags%7Cgeneral%7Cinterwikimap%7Clanguages%7Cprotocols: 40016ms

TypeError: Cannot read property 'statusCode' of undefined
    at Request.cb [as _callback] (D:\public\jazeckel\parsoid\lib\mediawiki.ApiRe
quest.js:99:49)
    at self.callback (D:\public\jazeckel\parsoid\node_modules\request\request.js
:121:22)
    at Request.emit (events.js:95:17)
    at null._onTimeout (D:\public\jazeckel\parsoid\node_modules\request\request.
js:679:12)
    at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)
worker 3128 died (8), restarting.
 - worker(3040) loading...
 - worker(3040) ready on :8000

After that I hit my 45 second timeout.
It might be easiest just to open lib/mediawiki.ApiRequest.js and apply the patch manually in your favorite editor.  It's only nine lines to copy-and-paste.  The lines with '+' at the front are additions.  The single line with '-' is a removal.
**jazeckel** wrote:

Can you point me to instructions on how to apply the patch?  I won't be able to do it until tomorrow morning.  Thanks!
Created attachment 15795
Debugging patch to dump timing and status code of API requests

Well, we don't have anything built in, but the attached patch is a hack which will dump the request timing and status codes.  If you apply this and then visit (say) http://localhost:8765/enwiki/Main_Page you should get a bunch of output on console about all the upstream API requests which Parsoid is making.  I suspect one or more of them is timing out.

**Attached**: {F14491}
Ok, I think we can rule out platform slowness.  So now I think my theory in comment 3 is probably on the right track.  Subbu, gwicke: do we have any tools to diagnose timeout issues in API requests made by Parsoid?
(Oh, and as a first guess at a diagnosis: it seems suspiciously like one or more of the 30-second timeouts are expiring internal to Parsoid -- parsoid uses internal requests to the api.php of the containing wiki; if those are timing out it is likely that parsoid will take a long time to reply.  But let's double-check the speed of parserTests and underlying node to be sure.)
As a first step, it would be useful to have some more information on your node.js setup, since we don't habitually test Parsoid on Windows.  Let's start with the output of 'node --version', some hardware information on the server in question (is it a virtual server?  If not, what is the CPU and clock speed and cache size), and how long 'tests/parserTests.js --quiet' takes to run.  With that we should at least narrow down the problem to node performance in general, or some quirk peculiar to how parsoid and mediawiki are interconnected.
This is pretty unhelpful, yes. 45 seconds is an insanely long time to parse the page - [[en:Barack Obama]] takes less than 12 seconds to parse, so it sounds like something is wrong there.

Punting to the Parsoid team to ask for advice (and they'll probably need some more information to work out why Parsoid is so slow for you).

If this server is going to be used by a number of people, I'd recommend putting a caching layer in front of Parsoid and using the Parsoid PHP extension to push changes to pages into the cache so they're available instantly.
VisualEditor correctly introduces visualeditor-ca-editsource, visualeditor-ca-editsource-section to change meaning of action=edit links, but it seems to reuse messages such as editsection, monobook-view-edit, vector-view-edit for its own veaction=edit links.
https://www.mediawiki.org/wiki/Localisation#Avoid_message_reuse

--------------------------
**Version**: unspecified
**Severity**: normal
Change 147737 abandoned by Jforrester:
Don't steal core's 'edit', 'create', 'editsection' by default

Reason:
Per discussion.

https://gerrit.wikimedia.org/r/147737
(In reply to Robin Pepermans (SPQRobin) from comment #4)
> having yet another message and consequently having only
> few translations.

No such risk in my proposal.
Change 147737 had a related patch set uploaded by Nemo bis:
Don't steal core's 'edit', 'create', 'editsection' by default

https://gerrit.wikimedia.org/r/147737
(In reply to Nemo from comment #3)
> How is linking veaction=edit not a different context than action=edit?

They are on the same location and for the same function (i.e. editing). There is only a slight difference, i.e. in core it uses the normal editor while in VisualEditor obviously the visual editor. In my opinion, this does not weigh against having yet another message and consequently having only few translations. 

Which makes me think, maybe we should have the ability to fall back to another message if a certain (identical but more specific) message is not translated.
(In reply to Robin Pepermans (SPQRobin) from comment #2)
> Message re-use
> needs to be avoided when re-using them in a different context.

How is linking veaction=edit not a different context than action=edit?
I don't see why we would need separate messages for these. As far as I can see, they are used on the same location for the same function, so having separate messages would be unnecessary duplication imho. Message re-use needs to be avoided when re-using them in a different context.
monobook-view-create and vector-view-create are also reused.

As written in VisualEditor.php, we can avoid message reuse by adding the following code:
 $wgVisualEditorTabMessages['edit'] = 'visualeditor-ca-ve-edit';
 $wgVisualEditorTabMessages['create'] = 'visualeditor-ca-ve-create';
 $wgVisualEditorTabMessages['editsection'] = 'visualeditor-ca-ve-edit-section';

But visualeditor-ca-ve-edit, visualeditor-ca-ve-create, and visualeditor-ca-ve-edit-section are all "VisualEditor".
On it.wp, trying to add a category in VisualEditor.
If you start typing "Terminologia dello", you'll be prompted to add 3 categories.
One of them though, "Terminologia dello sport", doesn't exist and never did.
(Also, no articles or templates with that name).

I'm told this link could be useful:
https://it.wikipedia.org/w/api.php?format=json&uselang=en-gb&action=query&list=allcategories&acprefix=Terminologia+dello+sport&acprop=hidden&redirects=

--------------------------
**Version**: unspecified
**Severity**: normal
This is likely the same issue as {T115756}.
I think you'd have to validate the "doesn't exist and never did" claim.  Categories are "created" as soon as the name of one is saved in any page.  If a redlink to that category ever existed, then the category itself was created (but not the separate description page for the category, which is what you need to turn an existing category into a bluelink).
I think you'd have to validate the "doesn't exist and never did" claim.  Categories are "created" as soon as the name of one is saved in any page.  If a redlink to that category ever existed, then the category itself was created (but not the separate description page for the category, which is what you need to turn an existing category into a bulling).
Some tables built from complex templates assume that there will be line breaks between the templates, so that this works:

{{tabletop}}
{{tablerow}}
{{tablerow}}
{{tablerow}}
{{tableend}}

but this does not:

{{tabletop}}{{tablerow}}{{tablerow}}{{tablerow}}{{tableend}}


There's another problem with transclusions containing content, which can be seen by opening the transclusion at https://en.wikipedia.org/wiki/Kilt#See_also in VisualEditor.  The template lines are fine, but the "Content" sections must always start with a blank line, to make up for the absence of line breaks at the end of the templates.  

The solution for both of these is probably the same:  Complex transclusions should always have line breaks after the templates.  I haven't been able to find any (in my quick search) that would break if this were implemented.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Pretty sure this is a dupe?

*** This bug has been marked as a duplicate of bug 50166 ***
I'm not entirely certain that there aren't multi-part templates that this is the wrong call for, but in general this is certainly a sensible tactic.
VisualEditor crashes when you try to save if the Defaultsummaries gadget is enabled. (https://en.wikipedia.org/wiki/MediaWiki:Gadget-defaultsummaries.js )  This is new; it used to work.

Workaround:  Disable the gadget.

(Might be Firefox-specific.  I haven't tested it.)

--------------------------
**Version**: unspecified
**Severity**: minor
Not really a VE bug, but here you go:

The gadget is using ve.init.mw.targets[0] to access the target, which isn't supposed to be a public API yet, but hey. This was removed recently and is now accessible via ve.init.mw.target.
Deleting the text from the article and converting it to a redirect page still leaves all the categories in it, as well as Other Stuff such as magic words and invisible templates.

This is a regression in comparison to the source editor, where the editor could just delete everything and be sure that categories, magic words, invisible templates and everything else is gone.

Just redirecting an article shouldn't necessarily remove everything, because it's actually possible that the editor wants to leave the article in a category. Some projects, including enwiki, have categories, templates etc. in redirect pages. But probably some kind of a warning should be shown.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 61858 ***
Clicking Save looks OK

After logging in, attempt to set beta settings. 

After clicking Save, get message "Error saving settings. Please make sure that you have cookies enabled"

This causes test failures such as https://integration.wikimedia.org/ci/view/BrowserTests/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox-sauce/36/testReport/(root)/VisualEditor/Going_back_from_save_screen_in_VisualEditor/

This is probably a problem in core, and very likely related to the VE bug https://bugzilla.wikimedia.org/show_bug.cgi?id=65709

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

**Attached**: {F14190}
Change 143799 merged by jenkins-bot:
Revert "Give anons tokens too"

https://gerrit.wikimedia.org/r/143799
Change 143799 had a related patch set uploaded by Jdlrobson:
Revert "Give anons tokens too"

https://gerrit.wikimedia.org/r/143799
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/jtxt8rEw
Created attachment 15756
Error after clicking Save

**Attached**: {F14191}
@James Forrester, the tab index isn't good yet.

Suppose I want to add a template with 4 parameters.
1. Press on a textbox of the first parameter
2. Press tab. This should move to the next parameter, but instead moves to button of info, and the next tab moves to button of delete. info and delete are less common than moving to next textbox.

so instead of fill, TAB, fill, TAB... you should do fill, 3 x TAB etc
I'm pretty sure this was done as part of bug 66824.

*** This bug has been marked as a duplicate of bug 66824 ***
Steps to reproduce:

1.  Open a page and make a change.  

2.  Click the Save button.

3.  Tab.  The cursor starts in the edit summary box (good) and goes to (using en.wp/Vector):

a) tick box for minor edit
b) link to the minor edit help page**
c) tick box for watching the page
d) three links in the licensing statement**
e) Review your changes button
f) Save button (inside the dialog box)
g) the browser's URL bar
h) the main Wikipedia search box 
g) the Cancel button (on VisualEditor's toolbar, and it works if you press return now)
h) the Save button (on VisualEditor's toolbar)
i) the top of the article
j) the slug at the top of the article, where it gets stuck forever.

Where it doesn't go is:

k) to the X at the top of the dialog box, so you can cancel saving and go back to editing. 


** I'd like these links to be skipped, but (a) maybe this is controlled by a browser setting and (b) maybe my opinion is in the minority.  I'd like these to be skipped so that I can save a page without having to press tab eight times between the edit summary and the final save button.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=67159
I think this is a dupe of bug 65554, which is now fixed.

*** This bug has been marked as a duplicate of bug 65554 ***
Here's the tab order in Firefox 30, starting from the edit summary box in the Save dialog:

a) tick box for minor edit
b) tick box for watching the page
c) the browser's URL bar
d) the browser's search box (for search engines)
e) who knows?  It disappears.
f) the main Wikipedia search box 
g) the top of the article
h) the MediaWiki "More" menu (where "Move" hides)
i) the icon/go button for the main Wikipedia search box
j) the languages (gear icon) button
k) the Save dialog (as a whole, not any useful piece of it)
l) who knows?  It disappears again.
m) back to the edit summary box, repeating endlessly.

Where it doesn't go is:

n) the Save button in the Save dialog,
o) the Review your changes button in the Save dialog, or
p) to the X at the top of the dialog box, so you can cancel saving and go back to editing. 


IMO the order ought to be, in its entirety, for all browsers:

a) tick box for minor edit
b) tick box for watching the page
c) the Review your changes button
d) the Save button
e) the X at the top of the dialog box
f) back to the edit summary—and repeat in a loop.
The above is the tab order in Safari 6.1.4 on Mac OS 10.8.5.
Steps to reproduce:

1.  Go to Page settings to create a redirect on the English Wikipedia.

2.  Type "foo" (an actual article—well, a redirect to an actual article about metasyntactic variables) in the field.

3.  Look at the search results, which are all about football (plus one for [[Foot (length)]] and one for the US FDA).  Think, "I must need to scroll down past all of this sports stuff"... but it doesn't scroll.


If you click on any of these items, then your correct link to "Foo" gets replaced by whatever was highlighted.  

It turns out that you can actually get the link to "Foo", by clicking on any place outside the dialog box (to make the search results go away) and then clicking on "Apply changes", but this is really Not Good.  To make things worse, due to bug 61861, you can't see what actually happened without either going to Review your changes or saving the page.

--------------------------
**Version**: unspecified
**Severity**: normal
Yeah, this is bug 54361.

*** This bug has been marked as a duplicate of bug 54361 ***
Clarification: the list of links does scroll, it's just that there's only 10(?) of them and Foo isn't among them, even though it exists. This is because MWTitleInputWidget, unlike MWLinkTargetInputWidget, does not reserve a special space for the title you typed. Instead, we assume that searching for pages whose names start with "Foo" will always return "Foo" as the first result, but that doesn't happen in practice because of a bug in the search system (I've also noticed these results being out of alphabetical order).

There's a bug... somewhere where we track things that go wrong because opensearch is unhelpful.
Screenshot

Steps to reproduce:

1.Load any page with sections in Betalabs

Observed Result:
There is no link for editing any section

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

**Attached**: {F14604}
Ignore this bug, this is for adding a tempalte Country Showdata in the page.
I can't reproduce in any of four browsers tested. :-(
Better followed-up in specific bugs and proposed UX changes, as discussed.
The link inspector has long been our most concentrated area of bugs. UX changes are coming in response to user testing, and many bug fixes are on their way as well - more are needed obviously.

1. There is no universal link creation process, as every application differs here, but I believe we are not totally off base in our initial design. As usually, we have to solve this problem with the most difficult constraints imaginable. Users are meant to be able to successfully navigate through a 3x3 matrix of options: link existing text, change linked text, create new link text; link to an internal page, a fragment on the existing page or an external page; produce an explicitly labeled link, an automatically labeled link or an unlabeled (external) link. We need to map out all the use cases and come up with a process that covers this matrix elegantly.

2. User testing has confirmed that, even though pressing enter, escape and clicking away all serve to apply and close, users want a button, and the back button doesn't make sense to them. The new design will do away with the back button. It will move the remove button to the bottom left and drop the confusing icon in favor of a destructive button labeled "Remove". On the bottom right will be a primary button labeled "Done", which will behave the same as pressing enter, escape or clicking away.

3. We need to use the transaction staging system to update the selected content dynamically as you type, making the link appear to be internal, external, red, auto-numbered, auto-labeled, etc.

4. The bug you experienced needs to be addressed, and I will see if it is resolved (or can be resolved) by my context and window refactoring work. The whole system has suffered from having a narrow entry point with too many poorly mapped forks in the road producing unreliable results with any given path at any given time.
I've filed the pawn bug as bug 67088.
(In reply to James Forrester from comment #2)
> Created attachment 15744 [details]
> Example video showing that issues are caused by having a link immediately
> preceding the new list item

This video does not follow the same steps. The link existing in the previous list item is irrelevant. You're pressing enter and clicking stuff in between which is what makes it save and work. Those are reflexes as result of hitting these bugs in the past presumably.

Here's the proof:

http://cl.ly/2P2h473b2A20

**Attached**: {F14577}
Created attachment 15744
Example video showing that issues are caused by having a link immediately preceding the new list item

**Attached**: {F14577}
Regarding the pawn, that also ate the first character (see "bc" instead of "abc" appear in the recording).
screenshot of problem

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/MediaWiki?veaction=edit

**Attached**: {F14540}
*** This bug has been marked as a duplicate of bug 66988 ***
I had this problem in Safari 6.1.4 on Mac OS 10.8.5
Safari 7
*** Bug 66988 has been marked as a duplicate of this bug. ***
WFM in Chrome & Firefox. What browser/version/OS are you using?
Created attachment 15733
Another problem

The second problem i sometimes see after initially loading. Interacting with the page makes the toolbar 'settle' and it's ok.

Experienced it on https://www.mediawiki.org/wiki/VisualEditor?veaction=edit

**Attached**: {F14541}
Why did it merge that subsection heading into the paragraph I was typing?

Steps to reproduce:

1.  Start editing a page with existing section headings.  Create a new paragraph above one of the section headings.

2.  At some point, it looks like the ==Section heading== has accidentally been merged to the paragraph that you're typing.  It's no longer present below (just a blank line where it had been), and the text of the section heading is now (in paragraph formatting) in the paragraph you're typing.

3.  Assume it's your fault (did you backspace?), and clean it up.  Replace the missing section heading.  Finish typing your paragraph, if necessary; you might have to do this a couple of times if the error recurs.

4.  Save the page.

5.  Check the diff, e.g., https://en.wikipedia.org/w/index.php?title=Candy_making&diff=prev&oldid=614021270

6.  Ask yourself, why are there three section headings named ==Safety== in a row?


If you don't replace the "missing" section heading, then everything works out:
https://en.wikipedia.org/w/index.php?title=Candy&diff=614296008&oldid=614177828

All of the attachments are from this diff.  I've only seen this in Firefox.

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

**Attached**: {F14503}
Can't reproduce. Hopefully this is properly gone now. Wish we could confirm. :-(
Created attachment 15723
One of these things is not like the other

**Attached**: {F14505}
Created attachment 15722
What it looked like just before I tried to save the page:  no ===Vegetarianism=== heading

**Attached**: {F14504}
I don't see the option to change the type of a parameter to "string/line" when I edit
https://pt.wikipedia.org/wiki/Template:Marca_de_projeto/dados?action=edit

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60693
Change 134928 merged by jenkins-bot:
Refactor TemplateData Editor

https://gerrit.wikimedia.org/r/134928
Change 134928 had a related patch set uploaded by Mooeypoo:
Refactor TemplateData Editor

https://gerrit.wikimedia.org/r/134928
Or are you referring to the change from "string/line" to just "line"?
https://gerrit.wikimedia.org/r/#/c/91623/9/spec.templatedata.json,unified
(I can't select "line" either).
I wasn't aware of that. In this case, there are docs to update, e.g.:
https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/TemplateData/Tutorial#Completing_the_TemplateData_information
Didn't we remove those sub-types?
That solution makes perfect sense, and matches the symptoms, so I'm marking this fixed and not doing the retesting I mentioned in comment #8.
Change 145127 merged by jenkins-bot:
Require git::clone before browsertests::bundle

https://gerrit.wikimedia.org/r/145127
Change 145127 had a related patch set uploaded by BryanDavis:
Require git::clone before browsertests::bundle

https://gerrit.wikimedia.org/r/145127
First try for me on a Trusty VM that had never had VE enabled before failed with:

Error: Working directory '/vagrant/mediawiki/extensions/VisualEditor/modules/ve-mw/test/browser' does not exist
Error: /Stage[main]/Role::Visualeditor/Mediawiki::Extension[VisualEditor]/Browsertests::Bundle[/vagrant/mediawiki/extensions/VisualEditor/modules/ve-mw/test/browser]/Ruby::Bundle[/vagrant/mediawiki/extensions/VisualEditor/modules/ve-mw/test/browser]/Exec[bundle-install-/vagrant/mediawiki/extensions/VisualEditor/modules/ve-mw/test/browser]/returns: change from notrun to 0 failed: Working directory '/vagrant/mediawiki/extensions/VisualEditor/modules/ve-mw/test/browser' does not exist

The problem for me was that browsertests::bundle doesn't require the git::clone.
VisualEditor is working now on that box (after a vagrant up --provision), except there are timeouts in the browser tests.

Next (when I have a chance), I'm going to try to destroy that box, and create a fresh one (but using the same Debian packages), to see if the problem manifests on a fresh build.
Created attachment 15845
Fresh install on 2014-07-03

It eventually failed due to not getting all the Debian packages.  I didn't try (yet) to re-provision and see if that fixed it

Dan, let's decide to how to proceed Tuesday.  I will make sure I don't lose the apt-cache, so I won't have to re-download the vast majority that did succeed (or the trusty base box).

**Attached**: {F13943}
Sure.

matthew@matthew-t520: ~/Code/Wikimedia/vagrant-ruby-visualeditor/mediawiki/extensions/VisualEditor (master|✔)% git status
# On branch master
nothing to commit (working directory clean)
matthew@matthew-t520: ~/Code/Wikimedia/vagrant-ruby-visualeditor/mediawiki/extensions/VisualEditor (master|✔)% git show-ref HEAD
4be59a00c12580e24e2de673c14e082bf714ee9c refs/remotes/origin/HEAD
matthew@matthew-t520: ~/Code/Wikimedia/vagrant-ruby-visualeditor/mediawiki/extensions/VisualEditor (master|✔)% git submodule
 a014302f441dda5c4805d378f4ccb67bc1d5e566 lib/ve (a014302)

Note, this is from a fresh MediaWiki-Vagrant VM I created (same one as comment #4), not my regular MediaWiki-Vagrant VM.
Can you verify the working commit of VE and its submodules? i.e. Please provide the output of `git status`, `git show-ref HEAD`, and `git submodule` under the mediawiki/extensions/VisualEditor subdirectory.
Matthew, Would you mind trying this again in case the fix to bug #66763 was related? Thanks!
Created attachment 15683
Puppet error with VisualEditor provisioning failure

Yes, it's reproducible on repeated provisioning runs.  I've attached the full log from a debug run.

**Attached**: {F13941}
I'm unable to repro this from a fresh VM with the given roles enabled. Do you continue to get this error after provisioning a second time?

Given the sometimes tricky nature of Puppet resource dependencies, it would help greatly to have a more detailed log of the run. Can you please specify `puppet_debug: true` in your `.settings.yaml` file and provide the output or `vagrant provision` as an attachment? Thanks!
Wikitext: '''foo[[File:Image.jpg|thumb]]bar'''

Resulting DOM: <body><b><figure><a><img /></a></figure>bar</b>

Block nodes like figure aren't supposed to occur inside of inline-ish (annotation) tags like b. When confronted with this, VisualEditor alienates the image to preserve its sanity (data model consistency), so bolded images can't be edited in VE.

Reported by mattk_ on IRC.

$ echo "'''foo[[File:Image.jpg|thumb]]bar'''" | node tests/parse.js

<!DOCTYPE html>
<html prefix="dc: http://purl.org/dc/terms/ mw: http://mediawiki.org/rdf/"><head prefix="mwr: http://en.wikipedia.org/wiki/Special:Redirect/"><meta property="mw:parsoidVersion" content="0"/><link rel="dc:isVersionOf" href="//en.wikipedia.org/wiki/Main_Page"/><title></title><base href="//en.wikipedia.org/wiki/Main_Page"/><link rel="stylesheet" href="//en.wikipedia.org/w/load.php?modules=mediawiki.skinning.elements|mediawiki.skinning.content|mediawiki.skinning.interface|skins.vector.styles|site|mediawiki.skinning.content.parsoid&amp;only=styles&amp;debug=true&amp;skin=vector"/></head><body data-parsoid='{"dsr":[0,37,0,0]}' lang="en" class="mw-content-ltr mw-body-content" dir="ltr"><b data-parsoid='{"dsr":[0,36,3,3]}'>foo<figure class="mw-default-size" typeof="mw:Image/Thumb" data-parsoid='{"optList":[{"ck":"thumbnail","ak":"thumb"}],"dsr":[6,30,2,2]}'><a href="./File:Image.jpg" data-parsoid='{"a":{"href":"./File:Image.jpg"},"sa":{},"dsr":[8,28,null,null]}'><img resource="./File:Image.jpg" src="//upload.wikimedia.org/wikipedia/en/thumb/7/78/Image.jpg/220px-Image.jpg" height="30" width="220" data-parsoid='{"a":{"resource":"./File:Image.jpg","height":"30","width":"220"},"sa":{"resource":"File:Image.jpg"}}'/></a></figure>bar</b>
</body></html>

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to ssastry from comment #8)
> Roan: see below .. I don't see a <b> inside the <a> tag. Can you provide the
> wikitext where you are seeing the problem html?
> 
> [subbu@earth lib] echo "'''foo[[File:Foobar.jpg|thumb|caption]]bar'''" |
> node parse --normalize
> 
> <p><b>foo</b></p>
> <figure><a href="File:Foobar.jpg"><img
> src="//upload.wikimedia.org/wikipedia/commons/3/3a/Foobar.jpg" height="26"
> width="220"/></a><figcaption><b>caption</b></figcaption></figure>
> <p><b>bar</b></p>

Sorry, I'm blind. You're right, the output is correct now.
Roan: see below .. I don't see a <b> inside the <a> tag. Can you provide the wikitext where you are seeing the problem html?

[subbu@earth lib] echo "'''foo[[File:Foobar.jpg|thumb|caption]]bar'''" | node parse --normalize

<p><b>foo</b></p>
<figure><a href="File:Foobar.jpg"><img src="//upload.wikimedia.org/wikipedia/commons/3/3a/Foobar.jpg" height="26" width="220"/></a><figcaption><b>caption</b></figcaption></figure>
<p><b>bar</b></p>
(In reply to Gerrit Notification Bot from comment #6)
> Change 162819 merged by jenkins-bot:
> (Bug 66749) Fix the test for DU.isGeneratedFigure
> 
> https://gerrit.wikimedia.org/r/162819

This makes it better, but the resulting HTML still violates the Parsoid HTML spec.

Old output: <body><b>foo<figure><a><img /></a></figure>bar</b></body>

New output: <body><p><b>foo</b></p><figure><a><b><img /></b></a></figure><p><b>bar</b></p></body>

At least the figure isn't bolded any more, but there's still a <b> tag between the <a> and the <img> whereas according to the spec, the structure should be <figure><a><img>
Change 162819 merged by jenkins-bot:
(Bug 66749) Fix the test for DU.isGeneratedFigure

https://gerrit.wikimedia.org/r/162819
Change 162819 had a related patch set uploaded by Subramanya Sastry:
(Bug 66749) Fix the test for DU.isGeneratedFigure

https://gerrit.wikimedia.org/r/162819
What Gabriel points out in comment 2 is exactly the same as bug 63642. The DOM I get from <p>'''foo[[File:Image.jpg|thumb|caption]]bar''' looks like <p><b>foo</b></p><figure><b><a><img /></a><figcaption>caption</figcaption></b></figure><p><b>bar</b></p>

(In reply to C. Scott Ananian from comment #1)
> Not sure this is a bug:
> 
> > div = document.createElement('div')
> <div>​</div>​
> > div.innerHTML="<b><figure></figure></b>"
> "<b><figure></figure></b>"
> > div.outerHTML
> "<div><b><figure></figure></b></div>"
> > div.innerHTML="<b><div></div></b>"
> "<b><div></div></b>"
> > div.outerHTML
> "<div><b><div></div></b></div>"
> 
> Note that HTML5 is perfectly happy to let the block element live inside the
> <b> tag.
Yeah, HTML lets you do it, but I don't think it's very sensible, and VE doesn't like it. I also see no reason why the behavior should be radically different depending on whether Parsoid has decided that the text is in a paragraph or free text. In the paragraph case, the bold tag is interrupted (and reapplied inside the figure, but that's bug 63642; really it should be reapplied in the caption instead, or not at all) and the figure isn't bolded, but in the free text case the figure is bolded. Given that the distinction between free text and paragraph text is pretty arbitrary, I don't think this makes much sense.

Speaking of, this paragraph vs free text stuff is also pretty broken. The following wikitext:

'''foo[[File:Image.jpg|thumb|caption]]bar'''

'''foo[[File:Image.jpg|thumb|caption]]bar'''

produces a DOM that looks like  <body><b>foo<figure><a><img /></a></figure>bar</b>\n\n<b>foo<figure><a><img /></a></figure>bar</b></body> which is wrong: bar and foo will be on the same line but shouldn't be.
(Taking the bug, since if it ends up being a real bug with our image spec, I'll fix it in Parsoid.  It appears that, to the extent this is a real bug, it's a dup of bug 63642 though.)
At a minimum, we should not create output that has the figcaption inside a figure wrapped into a formatting element.

Yet that's what I seem to get with this input:

<p>'''foo[[File:Image.jpg|thumb|caption]]bar'''
Not sure this is a bug:

> div = document.createElement('div')
<div>​</div>​
> div.innerHTML="<b><figure></figure></b>"
"<b><figure></figure></b>"
> div.outerHTML
"<div><b><figure></figure></b></div>"
> div.innerHTML="<b><div></div></b>"
"<b><div></div></b>"
> div.outerHTML
"<div><b><div></div></b></div>"

Note that HTML5 is perfectly happy to let the block element live inside the <b> tag.
Currently, Parsoid runs the following check to tell if an interwiki link points at the current wiki [1]:

if ( interwikiInfo.prefix === env.conf.wiki.iwp.replace( /wiki/, '' ) ) {

Obviously this is inadequate when the wiki name doesn't end in "wiki". (It's slightly unclear to me what "iwp" is; it claims to be an interwiki *prefix*, but some of the tests set it to "enwiki", so I'm assuming it's actually the DB name.)

See http://parsoid.wmflabs.org/_rt/mediawikiwiki/VisualEditor:Local. Currently the first link is "mw:WikiLink" and the second is "mw:ExtLink", which is wrong. The PHP parser renders them identically as internal links.

---
[1] http://git.wikimedia.org/blob/mediawiki%2Fservices%2Fparsoid.git/18e31a06252db3813fe844b62f15248289cdf4cb/lib%2Fext.core.LinkHandler.js#L106

--------------------------
**Version**: unspecified
**Severity**: normal
Change 155784 merged by jenkins-bot:
Handle local interwiki links.

https://gerrit.wikimedia.org/r/155784
Change 155784 had a related patch set uploaded by Cscott:
WIP: handle local interwiki links.

https://gerrit.wikimedia.org/r/155784
Ok, taking this.  It's related to bug 69909.  We should be using localinterwiki from the siteinfo.
Change 141276 merged by jenkins-bot:
Expose $wgLocalInterwikis via the API

https://gerrit.wikimedia.org/r/141276
Change 141276 had a related patch set uploaded by TTO:
Expose $wgLocalInterwikis via the API

https://gerrit.wikimedia.org/r/141276
The MediaWiki API needs to expose the contents of $wgLocalInterwikis via the API's meta=siteinfo&prop=interwikimap. Then Parsoid will be able to consume that information.
María typed her name in VisualEditor on a Mac:  [SHIFT] m + a + r + [OPTION] e + i + a. 

She runs Chrome on a MacBook Pro with a U.S. keyboard.  The result was this:


[top of page]
´

Lots of text here

María

The rest of the page

[end of page]


Using a normal keyboard shortcut to add accents to characters should not result in  stray "´" characters at the top of the page.

See https://office.wikimedia.org/w/index.php?diff=113478&oldid=113425 for an example.

--------------------------
**Version**: unspecified
**Severity**: normal
Testing after the latest update was unable to reproduce the problem.
I can't reproduce in Chrome or Safari either, in master, testing or production – possibly something odd with a system IME or similar? Provisionally marking as WORKSFORME – can María test again and confirm?
I can't reproduce this in Safari 6.1.4 on my Mac and haven't tried to reproduce it in Chrome.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Edit a page
3.Click on "Save Page"
4.Click on "Review your changes"

Observed Result:

Getting Error loading data from server while reviewing changes from Save dialog 

See the screenshot attached
Environment:Betalabs

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

**Attached**: {F13711}
*** This bug has been marked as a duplicate of bug 66669 ***
Change 139879 had a related patch set uploaded by Catrope:
Followup e48ecbc5: fix fatal error due to undefined variable

https://gerrit.wikimedia.org/r/139879
If VisualEditor ever throws an exception, which seems to be happening a lot, this means that the editor is inaccessible unless you resize the window and refresh.

When an error occurs the wikitext editor should be loaded instead.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 143797 merged by jenkins-bot:
If error occurs while loading VE, load source editor instead

https://gerrit.wikimedia.org/r/143797
Change 143797 had a related patch set uploaded by Kaldari:
If error occurs while loading VE, load source editor instead

https://gerrit.wikimedia.org/r/143797
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/iIcumWus
Incident #1:

Add a reference.  Try to re-use it.  It's not in the list at all.


Incident #2:

Add a reference using the Cite tool.  Try to re-use it.  It's not in the list at all.  Add a plain <references /> block (rather than {{reflist}}).  Go back and try to re-use it.  Now it's there.


Incident #3:

Add a reference.  Try to re-use it.  Only the number ("[1]") is present in the references list; the old refs are all listed correctly.  Cancel and go look at the new ref to make sure that it actually has contents.  Try to re-use it again.  Now the full description appears.  (Perhaps it was just being slow?  Perhaps it needed something else to trigger it?)


(All of these happened in Firefox.)

--------------------------
**Version**: unspecified
**Severity**: normal
Let's leave this as worksforme unless someone can find another bug to mark it as a duplicate of.
I don't think that these are actually three bugs:  I think they are all the same problem, which is that (what is now) Cite > Re-use did not correctly produce a list of existing citations.

I believe that this was resolved a couple of months ago, in some related work.  I haven't encountered this myself or heard any complaints about it for a long while.  The correct status is probably resolved/duplicate.
Why are there three bugs in one here? Is any of this still valid? Were you trying to use templates instead of the proper references tag in #1 and #3 as well?
There are a lot of templates that create or display links to other pages.  It would be nice if it were possible to click on those links (to open the linked pages in another tab) while editing VisualEditor.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 50966 ***
References in VE do not work properly in the vagrant VM without also having the Cite extension in place.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 139053 merged by jenkins-bot:
Added more depedency roles to visualeditor

https://gerrit.wikimedia.org/r/139053
Change 139053 had a related patch set uploaded by Dduvall:
Added more depedency roles to visualeditor

https://gerrit.wikimedia.org/r/139053
16:12 chrismcmahon: RoanKattouw: beyond needing Cite for references in VE, is any other extension required for handling templates in VE properly?
16:13 James_F: chrismcmahon: TemplateData.
16:13 James_F: chrismcmahon: And Lua and ParserFunctions for most of the existing corpus of templates.
16:13 chrismcmahon: James_F: awesome
Use existing references disabled for page with references

found in the course of enabling browser tests for the Vagrant role visualeditor: 

In the mediawiki visualeditor role and also in a bare wiki having the VisualEditor extensions, references are not handled properly.  

In the pure page view the existing references are not interpreted by the <references /> tag.  See screen shot. 

In VE, the "Use an existing reference" button is disabled. See screen shot.

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

**Attached**: {F13915}
I hate screen shots
gah,
(In reply to Chris McMahon from comment #1)
> Created attachment 15632 [details]
> "Use existing reference" button disabled on a page with a reference
Nice vacation accrual stats ;)

(In reply to Roan Kattouw from comment #2)
> Did you install the Cite extension? Without it, the <ref> and <references>
> tags don't work in read mode either.
Additionally, you need to restart Parsoid after installing the Cite extension.

**Attached**: {F13916}
Did you install the Cite extension? Without it, the <ref> and <references> tags don't work in read mode either.
Created attachment 15632
mistake, disregard

**Attached**: {F13916}
See the URL for an example.

The reference numbers are not localized in languages that use non-European numbers, such as Arabic and Persian. They are localized correctly while viewing the page.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://fa.wikipedia.org/wiki/User:Amire80/ref-numbers
*** This bug has been marked as a duplicate of bug 56240 ***
Whenever I try to launch the desktop VE, I get a JS error...

In Firefox: 'target.createSurface is not a function'
In Chrome: 'Uncaught TypeError: undefined is not a function'

In both cases it comes from ve.init.mw.Target.js, line 1312:
target.surface = target.createSurface( dmDoc );

The error doesn't happen in mobile VisualEditor.

--------------------------
**Version**: unspecified
**Severity**: major
Nevermind. Had to update the VE submodules.
Seen only one time:  https://wmf.ci.cloudbees.com/job/Flow-en.wikipedia.beta.wmflabs.org-linux-chrome/465/

As a logged-in user, create a new topic in Flow.  Topic was saved as anonymous, even though user logged in successfully and test showed no sign of user logging out. 

I want to note this because of the similarity to an intermittent issue when switching edit modes in VisualEditor, bug 65709

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
{T67709}
Closing - was seen only once & there hasn't been any new report since (and it's been open for > half a year)
"visual editor did more than i told it to: https://en.wikipedia.org/w/index.php?title=Cameroon&diff=611127082&oldid=610427158 "
"hmm looks like ve actually removed a duplicate parameter when i made that edit"

Seems this occurs when you edit a template in some way (e.g. adding a new parameter), if a named parameter has been set twice.

Not sure if this is intended behaviour or not. Bug might be a dupe, might be in Parsoid instead of VE, or something else.

--------------------------
**Version**: unspecified
**Severity**: normal
This is intended behaviour, yeah; we won't dirty-diff to fix broken wikitext when you edit something else, but VE will always fix up bad existing formatting when you change the item.
exit overlay

See attachments

* Different X icons used for VisualEditor close and OOUI close
* There are vertical borders in the VE toolbar

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

**Attached**: {F13867}
**jgonera** wrote:

Presently OOUI forms look completely different because of a few refactorings that happened in OOUI since that bug was reported. Visual consistency will be tackled in the new OOUI theme.
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/MaI2stPq
Created attachment 15539
Exit dialog in VE

**Attached**: {F13868}
Screenshot

Steps to reproduce:

1.Open a page
2.Attempt to insert a link with an existing target page such as "Test"

Observed Result :

The page "Test" appears under the New Page section inside Link Inspector.
See the screenshot attached

Environment:
https://en.wikipedia.org/

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

**Attached**: {F13800}
*** This bug has been marked as a duplicate of bug 51013 ***
Intention:
Change the contents of a category page (the description, not the files in it).  See https://commons.wikimedia.org/w/index.php?title=Category:Cuberdon&diff=prev&oldid=125000311

Steps to Reproduce:
1. Open the page in VisualEditor.
2. Change the description.
3. Save the page.

Actual Results:  
Upon savingm the description was displayed, but not the contents of the category.

Expected Results:  
You should be able to see all the images in that category, not just the text at the top of the cat page.

Reproducible: Didn't try

--------------------------
**Version**: unspecified
**Severity**: minor
*** This bug has been marked as a duplicate of bug 64239 ***
on http://en.m.wikipedia.beta.wmflabs.org/ as logged-in user; set Settings mode for VE access; edit a page; toggle VisualEditor mode

browser shows spinner forever

javascript error is "Error: Module not found: toggle 
Error
message: "Module not found: toggle"

--------------------------
**Version**: unspecified
**Severity**: normal
This is bug 65823 but the JavaScript error is unrelated to that and actually bug 65838
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/lIGKYsRM
https://pt.wikipedia.org/wiki/Jos%C3%A9_Antonio_Reyes?diff=38627387
https://pt.wikipedia.org/wiki/Jos%C3%A9_Antonio_Reyes?diff=38645684
https://pt.wikipedia.org/wiki/Jos%C3%A9_Antonio_Reyes?diff=39007919

--------------------------
**Version**: unspecified
**Severity**: normal
This shouldn't now be happening. Long-since fixed.
Seasoned Catalan Wikipedia editors are finding strange diffs done by new editors using VisualEditor. See these examples:

https://ca.wikipedia.org/w/index.php?title=Laocoont_o_sobre_els_l%C3%ADmits_en_la_pintura_i_poesia&diff=13401584&oldid=13401089

https://ca.wikipedia.org/w/index.php?title=Joan_Francesc_Ferrer_Sicilia&curid=1102012&diff=13399985&oldid=13399856

https://ca.wikipedia.org/w/index.php?title=Pere_Formiguera_i_Sala&oldid=13189613

https://ca.wikipedia.org/w/index.php?title=Pere_Formiguera_i_Sala&diff=13276699&oldid=13276658

We are still figuring out whether these strange edits are made on purpose or not, by humans or by some VisualEditor bug. Reporting here to check whether someone else has seen something similar elsewhere, or can shed some light.

Related discussion (in Catalan)
https://ca.wikipedia.org/wiki/Viquip%C3%A8dia:La_taverna/Ajuda#Curiositat

--------------------------
**Version**: unspecified
**Severity**: normal
While ca.wiki got plenty of strange characters during several weeks, that happened month ago, and the strange characters haven't been seen ever since.

We might not know the cause neither the solution, but the problem seems to be Resolved.

https://ca.wikipedia.org/wiki/Topic:Sb2iif7fvhy6p365
While ca.wiki got plenty of strange characters during several weeks, that happened month ago, and the strange characters haven't been seen ever since.

We might not know the cause neither the solution, but the problem seems to be Resolved.
See also Bug 63395
(In reply to Quim Gil from comment #7)
> it includes ☃ and ♙ !

These specific two icons (snowman ☃ and chess pawn ♙) are a debugging feature of VE and unrelated to the original issue reported here.  ☃ and ♙ usually means that Parsoid has encountered something confusing in the wikitext markup.
This problem keeps happening regularly, e.g. https://ca.wikipedia.org/w/index.php?title=Ferran_Clavell&diff=prev&oldid=13600764

The most surreal edit we have seen so far: https://ca.wikipedia.org/w/index.php?title=Ana_Zelich&diffonly=1&diff=13511465 -- it includes ☃ and ♙ !

One user reported MacBook Pro amb 10.8.5 with Chrome v34.0.1847.131. He also said that he could reproduce it sometimes by typing "wrong" accents, e.g. accent + space. 

This might be due to newbie users typing "L´aventura" instead of "L'aventura" (note the different ´ '). How to test this: at least in my International English keyboard you can type ´ by typing twice '.
Just in case those users all use Firefox, https://bugzilla.mozilla.org/show_bug.cgi?id=1015433 comes to my mind, though rather unlikely.
We really need more info on the browser(s) used....
The user hasn't answered yet. However, while bug 52327 is about "garbage" being injected in pages, that garbage consists at least in JavaScript chunks. In this case it is really meaningless garbage. Garbage so meaningless and relatively random that I still fail to deduce where does it come from.
I asked because I'm wondering if this is another case of broken browser plugins (bug 52327)...
More, from more users:

https://ca.wikipedia.org/w/index.php?title=Partit_dels_i_les_Comunistes_de_Catalunya&diff=prev&oldid=13430606

https://ca.wikipedia.org/w/index.php?title=Purita_Campos&diff=13441743&oldid=13383289

I will ask the user that replied which browser he is using.
Which browsers and browser versions are involved?
One of the editors, a school teacher, replied saying that he hadn't added those characters manually. We still haven't found a way to reproduce this problem.
Go to a page that doesn't exist.
Click edit so that VisualEditor loads.
Toggle to source mode.
A JavaScript exception is thrown and the loader never clears.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 135722 merged by jenkins-bot:
Use same options for VisualEditor and Editor overlays

https://gerrit.wikimedia.org/r/135722
Change 135722 had a related patch set uploaded by Jdlrobson:
Use same options for VisualEditor and Editor overlays

https://gerrit.wikimedia.org/r/135722
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/BGNz7shU
attempt to edit any page in http://en.wikipedia.beta.wmflabs.org/ with VisualEditor

get error "Error loading data from server: parsoidserver-http-bad-status: 503. Would you like to retry?"

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 65553 ***
I'm currently trying to edit Wikivoyage and nothing happens when I click edit. Very weird. hash does change...

--------------------------
**Version**: unspecified
**Severity**: normal
Change 134410 merged by jenkins-bot:
Fix edit link when VisualEditor is not available

https://gerrit.wikimedia.org/r/134410
Change 134411 merged by jenkins-bot:
Fix edit link when VisualEditor is not available

https://gerrit.wikimedia.org/r/134411
Change 134411 had a related patch set uploaded by MaxSem:
Fix edit link when VisualEditor is not available

https://gerrit.wikimedia.org/r/134411
Change 134410 had a related patch set uploaded by MaxSem:
Fix edit link when VisualEditor is not available

https://gerrit.wikimedia.org/r/134410
Change 134405 merged by jenkins-bot:
Fix edit link when VisualEditor is not available

https://gerrit.wikimedia.org/r/134405
Change 134405 had a related patch set uploaded by Jdlrobson:
Fix edit link when VisualEditor is not available

https://gerrit.wikimedia.org/r/134405
*** This bug has been marked as a duplicate of bug 65509 ***
Could have sworn I raised this bug previously but here we go again..
Load Article#editor/0 in alpha
See VisualEditor.
Switch to source editor.
Now refresh the page using browser.
Wikitext editor loads.
Attempt to switch to VisualEditor.
Fail.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 137731 merged by jenkins-bot:
Show loader when switching between editors

https://gerrit.wikimedia.org/r/137731
Change 137731 had a related patch set uploaded by Jdlrobson:
Show loader when switching between editors

https://gerrit.wikimedia.org/r/137731
Change 137251 abandoned by Jdlrobson:
Show a spinner when switching between editors

Reason:
I'm going to do this another way.

https://gerrit.wikimedia.org/r/137251
Change 137251 had a related patch set uploaded by Jdlrobson:
Show a spinner when switching between editors

https://gerrit.wikimedia.org/r/137251
Change 136249 had a related patch set uploaded by Jdlrobson:
WIP: have a standard way of invoking loader

https://gerrit.wikimedia.org/r/136249
Best way to simulate this... Open wikitext editor via clicking edit icon.
Kill your web server.
Click the toggle to VE icon.
Nothing happens.
Created attachment 15464
Double toolbar loading in VE

**Attached**: {F14060}
Created attachment 15463
Delay between clicking button and seeing VE

**Attached**: {F14059}
It's not just the spinner - just sometimes it doesn't even start loading. I'm worried this indicates some bigger kind of problem. Let me attach some videos demonstrating the behaviour I am seeing...
**jgonera** wrote:

I'm marking as workforsome, please raise another bug if there are problems with the spinner.
On my local instance it takes 2-3 seconds for VE to load cold but the spinner appears almost instantly.
I don't see any indicator whatsoever for those 5 seconds so usually click it more than once :-(


A few times I've also seen two toolbars get created.
**jgonera** wrote:

It takes about half a second on my vagrant instance, but the indication (loader) should probably appear earlier.
So actually I've noticed it does actually load eventually but it takes 6 seconds to do so and doesn't show a loading overlay or anything so it's not clear the click did anything...

I'm guessing you guys just have super fast instances...
Works for me. Tested in Firefox on latest master.
**jgonera** wrote:

Can't reproduce on latest master.
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/FcXnAItk
Steps to Reproduce:
1. Start with a link to another page, e.g., [[abc]].

2. Use the special character inserter tool to add a special character, with the goal of producing something like this:  [[abc|aübc]].



Actual Results:  
Instead of [[abc|aübc]], you get [[abc|a]]ü[[abc|bc]].


Reproducible: Always

Reproduced in Firefox and Safari.  May be related to Bug 60476 about character formatting?

--------------------------
**Version**: unspecified
**Severity**: normal
Yeah, merging this with bug 60476 and expanding the description there.

*** This bug has been marked as a duplicate of bug 60476 ***
I've been seeing this in the overnight runs of the browser tests in recent times. The build for VisualEditor will fail with a modal dialog that says "Error loading data from server: readonly. The wiki is currently in read-only mode. Would you like to retry?"

Here is an example from the overnight run Sunday 18 May: https://wmf.ci.cloudbees.com/job/VisualEditor-en.wikipedia.beta.wmflabs.org-linux-chrome/512/testReport/(root)/VisualEditor/Edit_with_strings__outline_example_____Editing_with_%C3%84%C3%8B%C3%8F%C3%96%C3%9C___Editing_with_%C3%84%C3%8B%C3%8F%C3%96%C3%9C___/

I can't think of any reason why beta labs would be in read-only mode late on a Sunday (PDT).  

I suspect this may also be the cause of the occasional failure in other builds with less information, for example "too many connection resets (due to Net::ReadTimeout - Net::ReadTimeout)" that we see in the MobileFrontend builds: too many connection resets (due to Net::ReadTimeout - Net::ReadTimeout) https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox/571/testReport/(root)/Check%20UI%20components/Check_existence_of_important_UI_components_on_other_pages_/

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68349
This seems to have been fixed by https://gerrit.wikimedia.org/r/#/c/149052/

Thanks Sam!
also see https://github.com/wikimedia/operations-mediawiki-config/commit/38990c671fd3b8d15f31a7c819e7bdd52ecef3ef
Adding Sean Pringle.  This seems to be getting worse. I'd like to either update the db less often or else make it less disruptive.
I saw this just now also.
Antoine, would these messages be relevant?  They do not seem to happen at any particular interval but they might be correlated to the time at which Rummana saw the problem.  

@deployment-bastion:/data/project/logs$ tail -f dberror.log 
Tue Jun 3 17:17:09 UTC 2014	deployment-apache01	testwiki	Error connecting to 10.68.17.94: :real_connect(): (42000/1049): Unknown database 'testwikidatawiki'
Tue Jun 3 17:17:09 UTC 2014	deployment-apache01	testwiki	Connection error: No working slave server: Unknown error (10.68.17.94)
Tue Jun 3 17:17:09 UTC 2014	deployment-apache01	testwiki	Error connecting to 10.68.17.94: :real_connect(): (42000/1049): Unknown database 'testwikidatawiki'
Tue Jun 3 17:17:09 UTC 2014	deployment-apache01	testwiki	Connection error: No working slave server: Unknown error (10.68.17.94)
Tue Jun 3 17:17:09 UTC 2014	deployment-apache01	testwiki	Error connecting to 10.68.17.94: :real_connect(): (42000/1049): Unknown database 'testwikidatawiki'
Tue Jun 3 17:17:09 UTC 2014	deployment-apache01	testwiki	Connection error: No working slave server: Unknown error (10.68.17.94)
Tue Jun 3 17:50:48 UTC 2014	deployment-apache01	testwiki	Error connecting to 10.68.17.94: :real_connect(): (42000/1049): Unknown database 'testwikidatawiki'
Tue Jun 3 17:50:48 UTC 2014	deployment-apache01	testwiki	Connection error: No working slave server: Unknown error (10.68.17.94)
Tue Jun 3 19:20:48 UTC 2014	deployment-apache01	testwiki	Error connecting to 10.68.17.94: :real_connect(): (42000/1049): Unknown database 'testwikidatawiki'
Tue Jun 3 19:20:48 UTC 2014	deployment-apache01	testwiki	Connection error: No working slave server: Unknown error (10.68.17.94)
Created attachment 15558
Screenshot

I have reproduced this issue today on Betalabs, attaching the screenshot

**Attached**: {F14002}
Right, and we know about the unexpected readonly status because it seems only VisualEditor displays that error in a javascript confirm modal dialog.  It might manifest in other ways that we would not see if not for the modal dialog that stops the test.
FWIW VisualEditor doesn't know about <readonlytext> – it's just passing on what it gets from the API.
On one SauceLab failure, it was POSTing to  "http://en.wikipedia.beta.wmflabs.org/wiki/User:Selenium_user/firefox?vehidebetadialog=true&veaction=edit"

The message:

  The wiki is currently in read-only mode. Would you like to retry?

Which comes from ApiBase::dieReadOnly(). That method seems to only be called when wfReadOnly() is true which is some legacy code that would let us create a file on the cluster that would disable edits entirely.

There is like 0% change it is being triggered that way unless something mess with $wgReadOnly.  So most probably the i18n message is being reused by another path of code.
Who could investigate this?
If I recall correctly, this is something that can happen when things go sideways with the database. Not sure if that's what's going on here, but may be worth looking into.
I think this is the first time I've seen the wiki read-only during the day (PDT) https://wmf.ci.cloudbees.com/job/VisualEditor-en.wikipedia.beta.wmflabs.org-linux-firefox/4/testReport/(root)/Switching%20between%20wikitext%20and%20Visual%20Editor%20modes/Switch_editing_modes_via_toolbar/
It should be disabled/muted like we do in other cases.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 65310 ***
Screenshot

I am getting this issue while trying to edit :https://en.m.wikipedia.org/wiki/User:RYasmeen_(WMF)/sandbox

I dont know how I stumbled upon it, but I can not edit my sandbox anymore with Mobile VE in any device/browser.

However, if I add it to or remove it from my watchlist by tapping on star, only then the lock disappears from the edit icon and I can edit.

See the screenshot attached

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

**Attached**: {F13821}
Probably a glitch in protection checking or something odd?
Works for me..
https://en.m.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/sandbox?mobileaction=alpha
Load VE and switch to wikitext editor - triggers Validation error against schema MobileWebEditing: Missing property: funnel

--------------------------
**Version**: unspecified
**Severity**: normal
Ignore above activity.
Change 135971 abandoned by Jdlrobson:
Set funnel on VE

https://gerrit.wikimedia.org/r/135971
Change 135971 had a related patch set uploaded by Jdlrobson:
Set funnel on VE

https://gerrit.wikimedia.org/r/135971
Change 134587 merged by jenkins-bot:
Stop EventLogging errors when switching from VisualEditor to Editor

https://gerrit.wikimedia.org/r/134587
Change 134587 had a related patch set uploaded by Jdlrobson:
Stop EventLogging errors when switching from VisualEditor to Editor

https://gerrit.wikimedia.org/r/134587
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/NxeR9xyO
Per the design mock-up at https://trello.com/c/xCo6uLAZ/9-5-references-dropdown-from-toolbar-styling (and a conversation with Kaity to confirm), when a user opens a popupToolGroup, all other tools in the toolbar should be disabled. Clicking off the popupToolGroup should close the popup and reactivate the other tools.

--------------------------
**Version**: unspecified
**Severity**: normal
After talking with Trevor and Kaity, we're going to punt this one for now.
Steps to reproduce:

1.  Be me, or one of several other people, but not James F.  (This step may be difficult to reproduce.  ;-)

2.  Login on Firefox. 

3.  Try to open an article in VisualEditor.

4.  Wait.  Wait.  Wait.  Wonder why a page that pops open in Safari in less than five seconds still hasn't opened in Firefox despite the animated blue bar showing for more than 30 seconds now.

5.  Wait.  Wait.  Wait.  Wonder if this is ever going to open.   

6.  Give up and reload.  Maybe it works this time; maybe it doesn't.  If it doesn't, consider restarting Firefox.  That usually helps... for one article.  Then it goes back to its old behavior of occasionally opening a page, but not usually.


I don't feel like I have a lot of useful information to give you, but this has been a problem for a couple of weeks and does not seem to be getting better.  Logging out may help, according to https://en.wikipedia.org/w/index.php?oldid=608667917#VE_does_not_start

--------------------------
**Version**: unspecified
**Severity**: normal
Whatever this problem was, there are no reports of it any more, and it could not be reproduced, so I'm closing.
"Storage error" load.php:161
"[Exception... "Persistent storage maximum size reached"  code: "1014" nsresult: "0x805303f6 (NS_ERROR_DOM_QUOTA_REACHED)"  location: "<unknown>"]" DOMException [NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"
code: 1014
nsresult: 0x805303f6
location: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20140626T181618Z:183] load.php:161

"Storage error" load.php:161
"[Exception... "Persistent storage maximum size reached"  code: "1014" nsresult: "0x805303f6 (NS_ERROR_DOM_QUOTA_REACHED)"  location: "<unknown>"]" DOMException [NS_ERROR_DOM_QUOTA_REACHED: "Persistent storage maximum size reached"
code: 1014
nsresult: 0x805303f6
location: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20140626T181618Z:183]
Are/were there any errors in the JS console at all?
I think this might have been solved for me, by removing one of Eran's scripts from common.js  However, another user who has reported the same problem isn't running that script.
Screenshot

Steps to reproduced:

1.Open a page with VE
2.Insert an image and go to the advanced Settings to make some changes
3.Apply the changes 
4.Now insert another image and open the media settings for it

Observed Result:
Instead of starting from General Settings as default tab, it opens up the Advanced settings, moreover if you edited say the image size section of the last image, the scroll bar position for the newly added image is also at the same exact position.

Test Environment:Betalabs, test2 and production

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

**Attached**: {F13579}
Seems to have been fixed at some point.
This sounds like a problem with BookletLayout. Trevor?
**Author:** `sean.chen`

**Description:**
hi,

we are using MediaWiki for our intranet on Government of Ontario and we are amazed by the new and cool VisualEditor! And we want to set up VisualEditor while we upgrade our MediaWiki to version 1.23.x.

However we need a customized skin instead of the default Vector skin. Is that possible to set up VisualEditor on a customized skin and how?

thanks a lot,

-Sean

--------------------------
**Version**: unspecified
**Severity**: major
Also because this is for support, not an actual software issue, I have set it to resolved invalid.
Kind of relevant to this are my (WIP) notes on what VE expects of a skin, which you can find at bug 61500.
You can try setting $wgVisualEditorSupportedSkins[] = 'nameofyourskin'; in your configuration. If your skin is a derivative of one of the supported skins (vector, apex, monobook, minerva), this should come pretty close to making things work, with only a few CSS issues remaining. You can fix the CSS problems by copying and tweaking ve.init.mw.ViewPageTarget-vector.css and -vector-hd.css (or another one if your skin isn't based on Vector).

Right now our skin integration is still a bit sucky. ve.init.mw.ViewPageTarget-shared.css needs to be loaded for all skins but isn't right now; I'll fix that. You also need to add your skin styles into VisualEditor.php itself (search for skinStyles), which is ugly. We'll need to work on improving that.

In the meantime, feel free to pop into our IRC channel (#mediawiki-visualeditor on freenode) for interactive help.
Steps to reproduce:

1.Open a page with mobile VE

Observed Result:

The Cite option is appearing in the toolbar which is not supposed to be there just yet? The drop-down menu does not have any background layout.Clicking on any of the options make VE completely stuck

--------------------------
**Version**: unspecified
**Severity**: normal
This apparently was intentional. Now styled. :-)
The dropdown appears to be unstyled in the mobile skin. Also, the mobile CSS that removes all text labels everywhere is probably undesirable in this case (and seems like overkill in general; it should be a conscious choice).
This is now appearing in production as well after today's deployment
Created attachment 15383
Screenshot

**Attached**: {F13527}
Toolbar with missing tool icons – undo, redo, all dropdown arrows, link, help, page notices, page options (several icons missing in the dropdowns too)

If one forces VE to load with the raster icons, a bunch of them are missing.

I'm not sure if this actually happens if any of the supported or greylisted browsers right now, but it blocks a fix for Opera 12 which doesn't handle elements with SVG background images and border-radius set.

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

**Attached**: {F14072}
(In reply to Thiemo Mättig from comment #3)
> (In reply to James Forrester from comment #2)
> > We do not intend to load raster icons in VisualEditor.
> 
> You *do* load raster icons in VisualEditor.

…

> Are you planning to remove this feature?

Yes, you're right, it was archaïc code we forgot to get rid of, and we should remove it. Done in gerrit 134758.
(In reply to James Forrester from comment #2)
> We do not intend to load raster icons in VisualEditor.

You *do* load raster icons in VisualEditor. Look:

https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FVisualEditor/HEAD/modules%2Fve-mw%2Finit%2Fve.init.mw.Target.js
https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FVisualEditor/HEAD/modules%2Fve-mw%2Fui%2Fstyles
https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FVisualEditor/HEAD/modules%2Fve-mw%2Fui%2Fstyles%2Fimages%2Ficons

Are you planning to remove this feature?
We do not intend to load raster icons in VisualEditor.
Created attachment 15373
Correctly rendered SVG toolbar

(The Opera 12 fix I mentioned is Ieafeb9075f741fe6e2624c5c62cf2ea8138e63de.)

**Attached**: {F14073}
scroll bar gets wider

Steps to reproduce:

1.Open a page with VE in Firefox
2.Open any drop down box which has a scroll bar in it
3.Hover over the scroll bar

Observed Result:
The scroll bar becomes a bit wider 

See the video attached

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

**Attached**: {F13998}
That's OS behaviour when it thinks you want to manually interact with the scrollbar.
Seen in automated tests in beta labs 11 May and 12 May (and occasionally earlier). 

Browser encounters a modal dialog saying "Error loading data from server: readonly. The wiki is currently in read-only mode. Would you like to retry?"  The wiki is almost certainly not in read-only mode. 

This may not actually be a VE error, I think it's coming from line 337 of ve.init.mw.ViewPageTarget.js, but I haven't tracked it to whatever is feeding the "read-only" status message to VE.

--------------------------
**Version**: unspecified
**Severity**: normal
It seems the main issue was the database lag that would cause MediaWiki to switch readonly.  The threshold has been raised a few months ago and I have not heard of "beta is read only" issues since.

Assuming this bug is fixed.
Several failed builds with this error over the last few days, this is the most recent from last night 13 May: 

https://wmf.ci.cloudbees.com/job/VisualEditor-en.wikipedia.beta.wmflabs.org-linux-chrome/500/
There is a few errors such as:

Mon May 12 5:32:25 UTC 2014	deployment-apache01	testwiki	Error connecting to 10.68.17.94: :real_connect(): (42000/1049): Unknown database 'testwikidatawiki'
Mon May 12 5:32:25 UTC 2014	deployment-apache01	testwiki	Connection error: No working slave server: Unknown error (10.68.17.94)


Do you have an example of a failing build ? Will help find the exact time it happened and thus to investigate around that date/time.
(11:08:16 AM) chrismcmahon: James_F:  I'm sure the read-only was not VE itself, but I do wonder if you've ever seen that msg. in VE or know what might cause it. 

(11:09:16 AM) James_F: chrismcmahon: It happens locally when I lock the DB manually, and I've seen it when wikis are under high load in production due to the auto-lock.

(11:09:31 AM) James_F: chrismcmahon: I believe it happens only in extremes, when master is lagging with load.

(11:10:29 AM) chrismcmahon: James_F:  thanks, that's helpful, I've never seen that.  I can't imagine what would cause that kind of load in beta labs at that hour though.
I've never seen this modal dialog or this error message under any circumstances other than when editing with VE. 

I am curious as to the root cause though, I've never heard of a wiki automatically putting itself into read-only mode.
Are you absolutely sure that Beta Labs wasn't catching up from too many edits? The site automatically puts itself into "read only" mode for a few seconds from time to time… Either way, this is a deployment-prep issue.
Created attachment 15357
read-only status modal dialog in VE

**Attached**: {F13976}
Steps to Reproduce:
1. Create a page that contains at least one image with no thumb or similar file specification, e.g., 

[[File:Example.jpg|Here's an image.]]

2. Open the page in VisualEditor.  

3. Select the image and open the image inspector.

4. Try to get out of the image inspector.

Actual Results:  
The "Advanced settings" pane in the image inspector has a spinning death spiral and the error message, "Size values are invalid. Could not retrieve original file size." 

The X to close the image inspector does not respond.


Reproducible: Always

This was first reported by Magioladitis for the pdf's listed here:  https://el.wikipedia.org/w/index.php?oldid=4650532#.CE.94.CE.B9.CE.B1.CE.BB.CE.AD.CE.BE.CE.B5.CE.B9.CF.82

--------------------------
**Version**: unspecified
**Severity**: normal
Not exactly:  I selected it and pressed the Return key.  It has the same effect.
Okay I just realized a huge bug: The image dialog popup/button doesn't appear (because it shouldn't yet) but double-clicking opens the media edit dialog.

And since the image is inline, the dialog is not ready to handle it, the dialog then crashes.

This seems to be a double-click bug; WhatamIdoing can you approve that this is how you opened the dialog?
(In reply to Moriel Schottlender from comment #1)
> This image is rendered as an inline image and the dialog, at the moment,
> won't edit it at all. The editing capability for inline images is introduced
> in the upcoming (big) change for the Image Model.
> 
> I've tried to reproduce the bug in both local master and in betalabs and the
> image doesn't let me open the edit dialog (as expected)
> 
> See here:
> http://en.wikipedia.beta.wmflabs.org/wiki/
> 2014_May_11_TestImageBug?veaction=edit
> 
> Am I missing something?

Double clicking the image opens the "Media settings" dialog for me.
This image is rendered as an inline image and the dialog, at the moment, won't edit it at all. The editing capability for inline images is introduced in the upcoming (big) change for the Image Model.

I've tried to reproduce the bug in both local master and in betalabs and the image doesn't let me open the edit dialog (as expected)

See here: http://en.wikipedia.beta.wmflabs.org/wiki/2014_May_11_TestImageBug?veaction=edit

Am I missing something?
Steps to Reproduce:
1. Type a few paragraphs of plain text in another document (e.g., an e-mail message with rich text turned off).

2. Open VisualEditor.  Copy and paste your paragraphs into VisualEditor.

3. Place your cursor in the first paragraph.  Click the list button to turn the first line (only) into a list.

Actual Results:  
The entire pasted section is indented as if it were a list (a list separated by <br>, not with a bullet in front of each paragraph).

However, when you save the page, only the first paragraph has actually been turned into a list.

See you at http://en.wikipedia.beta.wmflabs.org/w/index.php?diff=92716&oldid=92715


Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: normal
Created attachment 15315
Photo collage showing before-and-after difference in formatting

**Attached**: {F14093}
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Template
3.Type something in the textbox
4.As soos as the suggestion dropdown box for template appears click on "Add template" button

Observed Result:
The first suggestion of the dropdown box gets stuck in the transclusion dialog box

See the screenshot attached

Browser:Firefox

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

**Attached**: {F14019}
Can't reproduce
In LocalSettings.php I enabled scary transclusions:
$wgEnableAPI = true;
$wgEnableWriteAPI = true;
$wgEnableScaryTranscluding = true;
$wgTranscludeCacheExpiry = 0;

Then in a template I have this:
{{raw:lo::{{{1}}}}}

I see this in the log:
[info][localhost:Test] starting parsing
[warning/api][localhost:Test][oldid:306] Failed API request, 8 retries remaining.
... and so on.

If just {{raw:lo::someItem}} is on the page parsoid evaluates this OK. But when this is in a template the requests fail for some reason.

--------------------------
**Version**: unspecified
**Severity**: normal
This works now, I do not know what have happend but works, with both prefixes I inserted in the db :)
Can you try with {{raw:lowiki::xxx}} for prefix lo. Just a hunch.
Oh, yikes, I missed the "interwiki" in the subject line. Thanks for the clarification.
Sorry, {{raw:lo::xxx}} should transclude template xxx from wiki with prefix 'lo'. This is what I did:

1) Create a template containing just plain text on a wiki (A).
2) From another wiki (B), make sure you have scary transclusion enabled and the other wiki in the transclusion database.
3) Make a template that transcludes the template from wiki A.
4) Create a page at wiki B the template you created in step 3.
I'm having trouble reproducing this bug. Here's what I did:

1) Create a template Template:Lo::someItem with the content: Hi
2) Create a template Template:Another with the content: {{raw:lo::{{{1}}}}}
3) Create a page Testing with the content: {{another|someItem}}

Result on Testing is: Hi

I can edit all of the above in VisualEditor.
Intention:
Add a citation inside (not after) a hieroglyphics block.

Steps to Reproduce:
1. Open page containing hieroglyphics.  Open hierglyphics tool.

2. Open Citation tool (or Insert > Reference).  Add citation.  

3. Close citation tool ("Apply changes").



Actual Results:  
The refernce is correctly added, but the hieroglyphics inspector stays open and empty until you save the page.


Reproducible: Always

Bonus bug:

Before saving page, try editing a nearby link, gallery, or math formula.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 56644 ***
When MediaWiki's interface language is set to Vietnamese and MathJax rendering is turned on, the MathJax menus appear in English even though a Vietnamese localization is available. This issue does not occur when uselang=es etc.

Steps to reproduce:

1. Go to [[mw:Special:Preferences#mw-prefsection-rendering]] and turn on MathJax.
2. Change the interface language to Vietnamese.
3. Go to [[mw:User:Mxn/MathJax vi]] and right-click on the matrix.

Expected results:

The menus should all be translated, as they are at <https://github.com/mathjax/MathJax-i18n/tree/master/JSON/vi>.

Actual results:

All the menus are in English.

Note that MathJax-i18n was missing entries in config.js for a number of languages, including Vietnamese, until very recently: <https://github.com/mathjax/MathJax-i18n/pull/1>.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/User:Mxn/64809
**physik** wrote:

OK. But it will be resolved by upgrading to MathJax 2.4. So it's the same problem

%%%*** This bug has been marked as a duplicate of bug 70207 ***%%%
(In reply to physikerwelt from comment #2)
> https://www.mediawiki.org/wiki/User:Mxn/64809?veaction=edit looks good for
> me.

This bug doesn't relate to VisualEditor. If I right-click on the matrix in [[mw:User:Mxn/64809]], the context menu is still in English, with items such as "Show Math As".
**physik** wrote:

https://www.mediawiki.org/wiki/User:Mxn/64809?veaction=edit looks good for me.
As you mentioned, this is fixed upstream but not yet released -- the upcoming MathJax v2.4 will have the updated locale.
Steps to reproduce:


1.Open a page with VE
2.Insert  a math function with math inspector

Observed Result:
Nothing gets added

--------------------------
**Version**: unspecified
**Severity**: normal
This works for me… Maybe a caching issue?
https://test2.wikipedia.org/wiki/Special:Preferences#mw-prefsection-betafeatures

Under "VisualEditor language tool", if I click discussion or information I get sent to https://test2.wikipedia.org/wiki/&lt;visualeditor-preference-experimental-info-link&gt; or https://test2.wikipedia.org/wiki/&lt;visualeditor-preference-experimental-discussion-link&gt;

Localisation cache issue?

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: https://test2.wikipedia.org/wiki/Special:Preferences#mw-prefsection-betafeatures
Links to https://www.mediawiki.org/wiki/VisualEditor/Beta_Features/Language and https://www.mediawiki.org/wiki/Talk:VisualEditor/Beta_Features/Language for me now.
Closing as WORSKFORME (please reopen if still a problem).
Steps to Reproduce:
1.  Select a ref tag.

2.  Click on bold in the character formatting menu.



Actual Results:  
It dutifully adds the character formatting:  <ref>Foo</ref> becomes '''<ref>Foo</ref>'''

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:Whatamidoing_(WMF)/Sandbox&diff=91700&oldid=91692


Reproducible: Didn't try

--------------------------
**Version**: unspecified
**Severity**: minor
If it's "valid", then why doesn't it do anything?  

'''<ref>Foo</ref>''' doesn't actually produce a bold-faced [1].

I see your point about (b) but you can't see the existence of the misplaced bold in VisualEditor, so I doubt that anyone would actually use it to fix it.
Why not? This is entirely valid, and relatively common, wikitext… VE has to let you make all kinds of stupid stylistic errors, because (a) it's our job to let you do anything you can validly do in wikitext, and (b) you might want to use VE to correct such things, which stripping in VE would prevent.
It's not just refs:  templates, hieroglyphics, galleries, math equation... Not images, though.

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:Whatamidoing_(WMF)/Sandbox&diff=91706&oldid=91700
For Chrome

Steps to reproduce:

1.Open this link:https://test2.m.wikipedia.org/wiki/0.8863089695452125?title=0.8863089695452125&campaign=random#editor/0

2.Make some edit

3.Save the page

Observed Result:

In Chrome: The page suddenly disappears and redirects me to Google Search Page 
In FireFox: It keeps the VE edit mode open 

See the screenshots attached

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

**Attached**: {F13949}
*** This bug has been marked as a duplicate of bug 60848 ***
Created attachment 15260
for Firefox

**Attached**: {F13950}
Right now, if you switch to alpha mode and click the edit button on a page like...
https://en.m.wikipedia.org/wiki/User_talk:Kaldari
...you get an error since VisualEditor is disabled for that namespace on en.wiki.

To fix this, we need to surface the config settings in wmgVisualEditorNamespaces on the client-side and use it in the editor loading process in editor.js.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 132124 merged by jenkins-bot:
Only create editor switcher from wikitext editor if VE is usable

https://gerrit.wikimedia.org/r/132124
Change 132124 had a related patch set uploaded by Kaldari:
Only create editor switcher from wikitext editor if VE is usable

https://gerrit.wikimedia.org/r/132124
Change 130794 merged by jenkins-bot:
Make sure mobile VisualEditor is only loaded when appropriate

https://gerrit.wikimedia.org/r/130794
Change 130794 had a related patch set uploaded by Kaldari:
Make sure mobile VisualEditor is only loaded when appropriate

https://gerrit.wikimedia.org/r/130794
Looks like the information is already available on the client-side:
mw.config.get( 'wgVisualEditorConfig' ).namespaces
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/cZTY61hQ
Original bug title:
VisualEditor: Inserting Media fails when caret is not positioned after initialization

And this is how to reproduce the issue:
* Go to https://www.mediawiki.org/wiki/Sandbox?veaction=edit
* Confirm the "This is our new tool ...."
* Reload the page
* Press "Insert"
* Press "Media" (dialog opens)
* Click one of the images.

Result:
Mozilla Firefox:
* POST https://www.mediawiki.org/w/api.php [HTTP/1.1 200 OK 281ms]
** http://pastebin.de/124264
* TypeError: splice is undefined load.php:153
** http://pastebin.de/124263
* Nothing happens except that the dialog is closed.
* Pressing "Insert" -> "Media" now does not open any dialog

Opera Next:
* Uncaught TypeError: Cannot read property 'apply' of undefined VM140:146
* Nothing happens except that the dialog is closed.
* Pressing "Insert" -> "Media" now does not open any dialog
* Stacktrace: http://pastebin.de/124262

--------------
Expected:
* Image inserted
* Being able to add further images to the page

--------------
Unrelated question:
* Why are you using FormData for this specific request?



--------------

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=64759
*** This bug has been marked as a duplicate of bug 64434 ***
In VisualEditor When we are at the edit mode it doesn't show redirected internal links in green.

It can be as an option in top tool box or in setting part

--------------------------
**Version**: unspecified
**Severity**: normal
VisualEditor is designed to look like the read mode; having redirects as green for read mode is bug 166, and making VE copy them if they change is bug 61072, so merging with that.

*** This bug has been marked as a duplicate of bug 61072 ***
Steps to Reproduce:
1. Enable VisualEditor formulae editing at Special:Preferences#mw-prefsection-betafeatures.

2. Change math-related preferences to:
   * Leave it as TeX (for text browsers) (radio button; it's off by default)
   * MathJax (experimental; best for most browsers) (tick box; it's off by default)

3. Open a page like [[:w:Torque]] in VisualEditor.

4. Select a math formula from the page.

5. Open the math editing tool.

6. Change some thing in the formula (e.g., replace "alpha" with "beta").

7. Look at the mess in the new version of the math formula (the one on the page, not the TeX code in the editing tool).



Reproducible: Always

See screenshots here:

https://en.wikipedia.org/wiki/File:Bug_with_using_VE_and_mathjax.png

https://commons.wikimedia.org/wiki/File:MathJax_mess_2014-04-28_at_2.33.08_PM.png

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 60728 ***
The CSS problem is caused by this rule

.ve-ce-protectedNode, .ve-ce-protectedNode * {
  position: relative !important;
  top: 0 !important;
  left: 0 !important;
  bottom: 0 !important;
  right: 0 !important;
  ...
}

MathJax makes heavy use of absolute positioning with elements like 

<span style="font-family: MathJax_Size4; position: absolute; top: -1.624em; left: 0.003em;">⎜<span style="display: inline-block; width: 0px; height: 3.975em;"></span></span>

so the .ve-ce-protectedNode CSS overrides all the positioning creating the mess.
See https://en.wikipedia.org/w/index.php?oldid=606239634#Problem_with_MathJax_and_visual_editor. for an analysis of CSS-related issues.  MathJax uses absolute positioning, and VisualEditor uses relative positioning.
Screenshot

Steps to reproduce:


1.Go to the last line of this page:http://en.wikipedia.beta.wmflabs.org/wiki/28thAprilChrome?veaction=edit

2.Press return

Observed Result:

An error appears in the console:
Uncaught Error: Offset could not be translated to a DOM element and offset: 675 

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**: {F13655}
Re-checked the page and the test scenario - no errors displayed in Console; Save button works as expected. Closing the issue as resolved.
After the above steps if you click on "Save Page" dialog box and close it.
Then again try to click on "Save Page" button it does not do anything.
Patch for php notice

PHP Notice:  Undefined index: visualeditor-enable-language in extensions/VisualEditor/VisualEditor.hooks.php on line 402

Attaching patch since I can't submit to gerrit from here.

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

**Attached**: {F13607}
Fixed in gerrit 130496.
Intention:
Move a tag from the middle of a page to the top.

Steps to Reproduce:
See https://en.wikipedia.org/w/index.php?title=User:WhatamIdoing/Sandbox_3&diff=606088818&oldid=606088072 for the (entirely correct) diff.

1. Select the essay tag in the middle of the page.

2. Command-X to cut it.

3. Scroll to the top.  Place cursor in the slug at the top.  Command-V to paste it.


Actual Results:  
The template that was displayed (upon pasting) does not look like the template that was cut.  It showed a "clean up" broom.

The changes to the wikitext (upon saving) were correct, and the template displayed correctly upon refresh (after saving).


Reproducible: Didn't try

--------------------------
**Version**: unspecified
**Severity**: minor
Created attachment 15227
The essay tag (the top one) as it should have appeared upon pasting, and as it did appear after saving the page.

**Attached**: {F13515}
Created attachment 15226
The essay tag, pasted at the top.  It does not look like what I cut from the middle.

**Attached**: {F13514}
Created attachment 15225
The essay tag, as seen originally in the middle of the page

**Attached**: {F13513}
**Author:** `petter.viippola`

**Description:**
I've done these steps and VisualEditor still dosen't work. There seems to be a problem with loading VisualEditor. I can only edit source, the command edit isn't possible to use. I've removed all the Parsoid options.

cd extensions
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/VisualEditor.git  
cd VisualEditor
git submodule update --init

require_once("$IP/extensions/VisualEditor/VisualEditor.php");

$wgDefaultUserOptions['visualeditor-enable'] = 1;
 

$wgHiddenPrefs[] = 'visualeditor-enable';

Everything else seems to be working the wiki, with got it ad-connected. Can there be any issues regarding to that?

Best regards
Petter

--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Linux
**Platform**: PC
Did this issue get resolved? I'm tempted to mark these sorts of entries as resolved worksforme.
**petter.viippola** wrote:

We are getting some other strange errors if we try with chrome on a testclient.
server:parsoidserver-http-curl-error: couldn't connect to host.

Does this mean we have the wrong configuration in the localsettings.js file?

Best regards
Petter
**petter.viippola** wrote:

[Mon Apr 28 14:39:36 2014] [error] [client 10.1.101.39] PHP Notice:  Undefined index: visualeditor-enable-language in /var/www/mediawiki-1.22.5/extensions/VisualEditor/VisualEditor.hooks.php on line 402, referer:http://wiki.ad.xxxxxx.se/index.php?title=SpaceClaim&action=edit

This is the only error we get in the httpd, error.log.

Best Regards

Petter
**petter.viippola** wrote:

I can look tomorrow when i get back to work.

The logs dosen't give any intresseting entries about problems with loading the VisualEditor.
There is no errors when i open a page, log in et.c. That's the strange part.

We have tried with chrome/"the wrong ie8". I noticted it wasn't supported by IE, so we tried chrome but it was the same result.

Best Regards

Petter
Does VisualEditor show up on Special:Version?

If no, are there entries in your PHP error logs on the server?

If yes, are there errors in your JS console on your client when you open a page?

(What browser are you using? Note that Internet Explorer and a number of other elderly browser versions don't work with VisualEditor yet.)
screenshot

Steps to Reproduce:

1.Go to this page: https://en.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/sandbox&veaction=edit

2.Click on Edit beta for the Page Title

3.Now press return after any line to add a new line in the page

Observed Result:

An error appears in the console:
Uncaught TypeError: Cannot read property 'nodeType' of undefined 

See the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=User:RYasmeen_(WMF)/sandbox&oldid=605655480

**Attached**: {F13859}
This now works for me – deployment glitch?
Actual Results:  
TeamGale added some citations and then saved the page.  She received an "unknown error" and assumed that the page did not get saved.  So she saved the page again.  Upon checking the history, she found that both attempts to save the page had resulted in a new version:

https://en.wikipedia.org/w/index.php?title=Sakis_Rouvas&diff=605148987&oldid=605133988

https://en.wikipedia.org/w/index.php?title=Sakis_Rouvas&diff=605149076&oldid=605148987

However, the first diff removed the end of the page, including the reference secyion, external links, navboxes, succession boxes, categories, and more.  These were automagically restored when she saved the second time.


Reproducible: Didn't try

TeamGale usually edits with Firefox 28 on Windows 8.

--------------------------
**Version**: unspecified
**Severity**: normal
Provisionally marking this as 'Resolved' as no reported recurrences in two years.
See for example https://integration.wikimedia.org/ci/job/mwext-VisualEditor-doc-publish/2336/console from https://gerrit.wikimedia.org/r/#/c/129372/

--------------------------
**Version**: wmf-deployment
**Severity**: normal
Job is now passing: https://integration.wikimedia.org/ci/job/mwext-VisualEditor-doc-publish/2337/console
Change 129401 merged by jenkins-bot:
Revert "mwext-VisualEditor-doc-publish: Simplify rsync calls"

https://gerrit.wikimedia.org/r/129401
Change 129401 had a related patch set uploaded by Hashar:
Revert "mwext-VisualEditor-doc-publish: Simplify rsync calls"

https://gerrit.wikimedia.org/r/129401
Caused by https://gerrit.wikimedia.org/r/#/c/125546/2/mediawiki-extensions.yaml,unified which uses a a dest dir:  $$WORKSPACE/docs/lib  :-D
Steps to reproduce:

1.Go to this page:https://test2.wikipedia.org/w/index.php?title=22ndaprilFF&veaction=edit

2.Select the image:"K" which is now in 220x200 px size

3.Now go to Advanced Settings and select the tab "Default" and click on "Apply changes"

Observed Result:
It turns the image into full size 600x600 px

Also,
If you first make the image as full size, then click on default size and click on "Apply Changes" nothing happens


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

--------------------------
**Version**: unspecified
**Severity**: normal
Agreed; basic images have a default size of full size.
Yes, it turns the image to 600x600 because it's the image's original dimensions, which are considered "default" for image of the type "basic".

This is intended behavior.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Edit something
3.Save the page
4.Without scrolling the page, again reopen the VE for that page

Observed Result:

"Success! Your edit was saved" message stays in the VE mode .

See the screenshot too

Test Environment: https://test2.m.wikipedia.org/

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

**Attached**: {F13581}
Change 130782 merged by jenkins-bot:
Close drawers/toasts on a click event

https://gerrit.wikimedia.org/r/130782
Change 130782 had a related patch set uploaded by Jdlrobson:
Close toasts on a click event

https://gerrit.wikimedia.org/r/130782
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1958
We should probably dismiss this message when the user opens VE again.

Sounds like this code is in MobileFrontend.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Media
3.Type something on the search box to search for a media


Observed Result:
No search results for images appears in the dialog


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**: {F13537}
(In reply to Alex Monk from comment #2)
> Hmm... Reminds me of bug 63989

No, this was a deployment issue with the Beta Labs move.
Hmm... Reminds me of bug 63989
This is now fixed .I am getting search results for the media now
It just happened to me on both Chrome and FF, Win 7, Vector. 
If I remove a category on it.wp, that's not considered as a change? The Save button stays grey. I need to type something and then delete it in order to be able to save my edit.

--------------------------
**Version**: unspecified
**Severity**: normal
At least provisionally…
Can you still not reproduce this issue? Maybe this should be marked worksforme.
Yes. Although as of now, I can't reproduce this issue, so I'm bringing it back to unconfirmed.
Once you do type something and delete it, does the category get removed in the edit?
Right now, we have cut-copy-paste feature in VE but there is no icon for these Clipboard actions.
It would be nice to have them on the toolbar as it is a pretty good feature with no visual indication that it exists.

--------------------------
**Version**: unspecified
**Severity**: enhancement
WONTFIXing, but really this is CANTFIX, sadly.
Google Docs shows that message in non-Chrome browsers. In Chrome browsers it asks you to install a plugin. Basically this is impossible due to the (fairly sensible) browser security model.
Triggering a cut/copy/paste from JavaScript might be hard due to security restrictions :( . Google Docs, for instance, has cut/copy/paste actions in the edit menu, but if you try to use them you get a dialog that says "these actions are unavailable via the Edit menu, but you can still use Ctrl+X / Ctrl+C / Ctrl+V".

We might be able to do this using execCommand though, but I don't know how well that works and how reliable it is. CC Ed because he's done a bunch of work on contentEditable copy/paste in the past so he might know more.
In the template dialog, when you add a parameter, that parameter's input field is then focused. This makes perfect sense. In the citation dialog, this doesn't happen, and instead the input field that was focused most recently is focused.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 64098 ***
Screenshot

Steps to reproduce:


1.Open a page with VE
2.Go to Cite> Website/Book/Newspaper/Journal 
3.Observe that, Cite Options dialog does not have "Show Options" button
4.Now open a reference dialog box and Go to Cite>Cite> Website/Book/Newspaper/Journal

Observed Result:
In this case, there is a "Show Options" button for Cite options

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

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

**Attached**: {F14020}
This is pretty much intentional; citation templates that aren't the only thing in a reference (or aren't even in a reference) get the citation icon, but aren't "real" citations. For now I'm WONTFIXing this.
VisualEditor cut off last several characters of article text during two edits at pl.wp.

https://pl.wikipedia.org/w/index.php?diff=39198236
https://pl.wikipedia.org/w/index.php?diff=39246345

These are two consecutive edits to the same article, [[pl:Lamborghini Aventador]].

Content maiming → marking as 'major'.

Originally reported at https://pl.wikipedia.org/wiki/Wikipedia:VisualEditor/Opinie#Lamborghini_Aventador_-_ko.C5.84cowe_znaki by WTM.

--------------------------
**Version**: unspecified
**Severity**: major
Can't reproduce. Reopen if you can.
It seems typography refresh enlarged body font size but VE didn't follow this change.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 63985 ***
Intention:
Remove a copyright violation

Steps to Reproduce:
I removed the first instance of a ref tag.  See https://en.wikipedia.org/w/index.php?title=Male_rape&diff=604793477&oldid=604792987


Actual Results:  
The re-used ref was "moved", but that had the effect of changing it, because the next instance of the same named ref had a different description.


Reproducible: Didn't try

I don't know how to solve this.  The wikitext shouldn't have been written that way in the first place.

--------------------------
**Version**: unspecified
**Severity**: minor
(In reply to WhatamIdoing from comment #2)
> There's no way for VisualEditor to know which is the "right" ref when two
> refs have the same name but different content.  I've seen this occasionally,
> and the "mismatched" refs sometimes have functionally the same content
> (e.g., one with a typo or abbreviation not present in the other).
> 
> We could pop up an message about the error in the wikitext (which is
> probably something that should be done by MediaWiki, not VisualEditor).  In
> VisualEditor, we could rename the refs to force them to be separated.   Or
> we could do nothing, and maintain bug-for-bug compatibility with Cite.php's
> lack of internal checking.

See bug 66233 for warning/stopping the user in Cite.php for this and other issues.
There's no way for VisualEditor to know which is the "right" ref when two refs have the same name but different content.  I've seen this occasionally, and the "mismatched" refs sometimes have functionally the same content (e.g., one with a typo or abbreviation not present in the other).

We could pop up an message about the error in the wikitext (which is probably something that should be done by MediaWiki, not VisualEditor).  In VisualEditor, we could rename the refs to force them to be separated.   Or we could do nothing, and maintain bug-for-bug compatibility with Cite.php's lack of internal checking.
I'm pretty sure this is a WONTFIX; if the wikitext is in such a broken state that it defines a reference twice, there's nothing sane that VisualEditor can really do.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert a image
3.Add some content in the page
4.Add some references
5.Make the image left aligned
6.Add a reflist in a way so that the references in that list is to the right of the image
7.Save the page

Observed result:

Reference numbers in reflist are getting overlapped by the image

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

**Attached**: {F13726}
Not a VE issue, happens in read mode too.

(That should be fixed though)
An IP user at sv.wp reports this (GoogleTranslated):
In Ubuntu 10.13 crashes Firefox when I want to save a source.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
Insufficient information to triage.
**Author:** `tech`

**Description:**
Running an up-to-date VisualEditor extension and parsoid server on mediawiki-1.22.2, when I use 'Insert Media' no matter the search term (exact filenames are no better) nothing is returned.

Checking server logs and debugging client browser data shows that VE only goes as far as a call to the API 'api.php?format=json&action=query&meta=filerepoinfo' which returns:

{
  query: {
    repos: [
      {
        name: "local",
        displayname: null,
        rootUrl: "/images",
        local: true
      }
    ]
  }
}

There are no further queries to the API after this call.

I can add wikiCommons, with "$wgUseInstantCommons = true", which successfully searches the wikiCommons, but has no effect on local media.

I can manually add media with the standard editor and the [[File:image.ext]] syntax, but if I double click a previously attached image in VE all of the fields in the media dialog box are vacant and I can't change any values or even close the dialog.

A query of 'api.php?action=query&list=allimages&format=json' returns a complete set of media as expected.

Further, looking at the API documentation on the server the example listed for filerepoinfo is 'api.php?action=query&meta=filerepoinfo&friprop=apiurl|name|displayname', but it returns in the warnings field: "Unrecognized value for parameter 'friprop': apiurl". Suggesting that perhaps a variable in LocalSettings.php is missing or inaccurate, I've looked over this several times, but don't see any glaring issues.

The server in question is behind an intranet, but I'm happy to answer any questions.

Thanks,
Patrick

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
(In reply to Patrick King from comment #0)
> Running an up-to-date VisualEditor extension and parsoid server on
> mediawiki-1.22.2, when I use 'Insert Media' no matter the search term (exact
> filenames are no better) nothing is returned.

Sorry, I completely missed the bit of your question asking about MediaWiki 1.22 – for media search to work, VisualEditor requires APIs that were introduced in MediaWiki 1.23. Indeed, the code intentionally asserts that you are running the right version of MediaWiki to avoid these issues.

For comparison, my local repo (running 1.24 alpha) comes out with:

{
    "query": {
        "repos": [
            {
                "name": "local",
                "displayname": "devwiki",
                "rootUrl": "/images",
                "local": true,
                "url": "/images",
                "thumbUrl": "/images/thumb",
                "initialCapital": true,
                "scriptDirUrl": "/w",
                "scriptExtension": ".php",
                "favicon": "http://localhost:8080/favicon.ico"
            }
        ]
    }
}

Some of these extra return parts are required for VisualEditor's media search to work.


(In reply to Patrick King from comment #2)
> Yes, I did have it installed on the server's root (with a wiki. subdomain).

Quite apart from the MediaWiki 1.22 issue, that's bug 62007 (MediaWiki installed on the server's root is an unsupported configuration by its API, apparently).
**tech** wrote:

Upgraded mediawiki to 1.22.5.

Installed parsoid and VisualEditor as new. 

Merged basic LocalSettings.php.

Uploaded a new file.

File and description in Special:ListFiles.

Still no change to this bug, nothing listed, no search results - only call to api is to query filerepoinfo, result as above.
**tech** wrote:

Yes, I did have it installed on the server's root (with a wiki. subdomain). But I've just tested with the '/w' leading path ($wgScriptPath = "/w") and it's made no difference, no images are showing up even with exact filenames. 

filerepoinfo query returns:
{"query":{"repos":[{"name":"local","displayname":null,"rootUrl":"/w/images","local":true}]}}
Do you have your wiki installed in the server's root (i.e. corp.foo.com/index.php?title=Main_Page rather than corp.foo.com/w/index.php?title=Main_Page)?

This appears to be a quite common configuration, but is explicitly advised against in MediaWiki's documentation because it doesn't work very well with MediaWiki's API and is the cause of similar issues to this for a number of people. :-(
After two weeks of vote we've just deliberated in favor of the Visual Editor activation for the logged users who want to tick it only: https://fr.wikinews.org/wiki/Wikinews:Prise_de_d%C3%A9cision/Installation_de_l%27%C3%A9diteur_visuel.

Thank you for your work.

--------------------------
**Version**: unspecified
**Severity**: enhancement
(In reply to JackPotte from comment #5)
> I've ticked the feature and got an error "parsoidserver-http-bad-status:
> 404" on each attempt with Firefox 28.0, even after a cache reset.

Sorry about that; there was a deployment issue. It should now be working for you.
I've ticked the feature and got an error "parsoidserver-http-bad-status: 404" on each attempt with Firefox 28.0, even after a cache reset.
This is now done.
Change 125538 merged by jenkins-bot:
Enable VisualEditor on French Wikinews

https://gerrit.wikimedia.org/r/125538
(In reply to Gerrit Notification Bot from comment #1)
> Change 125538 had a related patch set uploaded by Catrope:
> Enable VisualEditor on French Wikinews
> 
> https://gerrit.wikimedia.org/r/125538
Scheduled for deployment on Monday April 14 at 23:00 UTC (Tuesday 01:00 CEST).
Change 125538 had a related patch set uploaded by Catrope:
Enable VisualEditor on French Wikinews

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

1.Open a page with VE
2.Insert a reference 
3.Open the reference dialog box again
4.Add a cite web template inside it
5.Save the reference

Observed Result:
A separate reference gets added just next to the existing reference

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

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 63828 ***
This happens not only for adding template rather doing any change/edit on the existing reference
Intention:
Add a new infobox using VE (from scratch)

Steps to Reproduce:
1. Go to https://sv.wikipedia.org/wiki/Anv%C3%A4ndare:Andr%C3%A9_Costa_%28WMSE%29/VEtest2?veaction=edit
2. Enter edit-mode for the template
3. Go to the "medlemskap" parameter. Click value.
4. Go to the "budget" parameter. Click the value.

Actual Results:  
3. Nothing happens. You must use the down arrow to reveal hidden text.
4. Value window re-sizes and introduces a scrollbar revealing previously hidden text.

Expected Results:  
Both cases: Window should have been re-seized on initialisation or indicated that there is more information than shown.
First case: Window should have been re-seized or a scrollbar introduced.

Reproducible: Always

The main issue is that you might not ever expect that there is more information in the template value than is initially shown.

--------------------------
**Version**: unspecified
**Severity**: normal
Intention:
Create a new article using VE

Steps to Reproduce:
1. Go to https://en.wikipedia.org/wiki/THISISNOTANARTICLE?veaction=edit
2. Wait for notices to load


Actual Results:  
All references to the pagename are changed to API (e.g. hover over search, or see the Special:Mypage/API link.

Expected Results:  
these links should point to the pagename (e.g. Special:Mypage/THISISNOTANARTICLE)

Reproducible: Always

This is occurs for any site using a pagename reference in MediaWiki:Newarticletext

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 63600 ***
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert a link
3.Insert a math node right after the link
4.Select the math formula
5.Click on the link inspector
6.When the link suggestions drop down appears close the inspector

Observed Result:
The link inspector inserts plain text right before the math node

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/9thapril2014?veaction=edit

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

**Attached**: {F13666}
*** This bug has been marked as a duplicate of bug 56644 ***
Centered wrt the slug

Steps to reproduce:


1.Open a page with VE
2.Insert an image just after a block slug
3.Now change the image position to Centre/Left and Image type to Frame

Observed Result:

The Image is not centered/ left aligned with respect to the page width rather with the width of the slug

Try the first image on this page: https://test2.wikipedia.org/wiki/9thapril2014?veaction=edit

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**: {F13663}
We don't slug after lists any more, and it looks like in this case you were inserting into the list, not a paragraph after it.
Note: The block slug in the example page is after an indented list
When you open an existing template, it looks like only the first parameter can be removed.  To discover that it is possible to remove a template parameter, you must first click in that parameter's data box. 

Instead, the trash icon should be visible on all items always.

--------------------------
**Version**: unspecified
**Severity**: enhancement
No. We considered this as part of the design, but it makes the interface far too heavy, cluttered and confusing for such an edge case task.
On any editable page on http://en.m.wikipedia.beta.wmflabs.org/ a logged-in user in alpha mode should invoke VisualEditor when clicking the edit icon. 

Instead the user gets the normal non-VE editor.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 63658 ***
Change 124881 merged by jenkins-bot:
Revert "Only offer VisualEditor if installed and enabled"

https://gerrit.wikimedia.org/r/124881
This was introduced by another patchset.
Change 124881 had a related patch set uploaded by Jdlrobson:
Revert "Only offer VisualEditor if installed and enabled"

https://gerrit.wikimedia.org/r/124881
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1916
To replicate:
Disable VisualEditor and load the editor. Wikitext editor loads but according to toolbar VisualEditor is available.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 126672 merged by jenkins-bot:
Make sure VisualEditor is installed before trying to use it

https://gerrit.wikimedia.org/r/126672
Change 126672 had a related patch set uploaded by Kaldari:
Make sure VisualEditor is installed before trying to use it

https://gerrit.wikimedia.org/r/126672
sorry Theo! I missed that. I don't follow comments on merged commits. Can you bring up your questions on bug 63736 and I'll do my best to answer them in next 24hrs!

Ryan see Bug: 63736 this bug was raised after a fix for it was merged that had to be reverted :(
(In reply to Ryan Kaldari from comment #2)

> I can't replicate this. If I disable the VisualEditor and try to load the
> editor in Alpha mode, the editor won't even load. It gives me an unknown
> dependency JS error. Looking at the code in editor.js, it doesn't look like
> it takes into account the possibility of the VisualEditor being disabled
> (which should probably be filed as a different bug).

This. x1000.

I brought this up as a comment on a patch in Gerrit[1], along with a possible solution, but there were never any replies.

Right now MobileFrontend editing does not work on non-VE-enabled websites... which includes my dev site :P

Probably worthy of a bug...

[1] https://gerrit.wikimedia.org/r/#/c/124881/
I can't replicate this. If I disable the VisualEditor and try to load the editor in Alpha mode, the editor won't even load. It gives me an unknown dependency JS error. Looking at the code in editor.js, it doesn't look like it takes into account the possibility of the VisualEditor being disabled (which should probably be filed as a different bug).

If you can replicate this, please post more detailed replication steps.
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1913
screenshot of VE, mozilla ff

When going to
https://en.wikipedia.org/wiki/File:Henri_Rousseau_009.jpg?veaction=edit
VE has 1 notice telling me:

"Du bist einem Link zu einer Seite gefolgt, die nicht vorhanden ist. Um diese Seite anzulegen, trage deinen Text in das untenstehende Bearbeitungsfeld ein (weitere Informationen auf der [/wiki/Help:Contents Hilfeseite])."

Note the "[/wiki/Help:Contents Hilfeseite]" part. I guess it should be a link.


"Newarticletext" seems to be the only message containing this text. And there was only one hit for "Newarticletext" in the VE repo:
https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/797430e9efd4c773c149718ad086f51f8aa042f6/ApiVisualEditor.php#L339

Indeed, the issue seems to be at the PHP side;
POST /w/api.php
action	visualeditor
format	json
paction	parse
page	File:Henri_Rousseau_009.jpg

returns the message as "<p>Du bist einem Link zu einer [...] der [/wiki/Help:Contents Hilfeseite] [...] deines Browsers. </p>"

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

**Attached**: {F14035}
*** This bug has been marked as a duplicate of bug 63600 ***
--------------------------
**Version**: unspecified
**Severity**: normal
Change 126672 merged by jenkins-bot:
Make sure VisualEditor is installed before trying to use it

https://gerrit.wikimedia.org/r/126672
Change 126672 had a related patch set uploaded by Kaldari:
Make sure VisualEditor is installed before trying to use it

https://gerrit.wikimedia.org/r/126672
Probably the easiest thing to do would be to just check mw.config.get( 'wgVisualEditorConfig' ). If VisualEditor isn't installed, that will return null.
*** Bug 63736 has been marked as a duplicate of this bug. ***
I had to revert this change... since the code is loaded asynchronously it will always return false.
Change 124494 merged by jenkins-bot:
Only offer VisualEditor if installed and enabled

https://gerrit.wikimedia.org/r/124494
Change 124494 had a related patch set uploaded by Jdlrobson:
Only offer VisualEditor if installed and enabled

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

Steps to reproduce:
Try to open any page with VE in test 2

Observed Result:
The following error appears and VE does not load
TypeError: undefined is not a function TypeError {stack: (...), message: "undefined is not a function"}

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

**Attached**: {F13971}
Looks like this got fixed at some point.
VisualEditor incorrect display of image inside <small> tags

This may depend on Bug 51614 "Tool to set/unset text as small".

Start with a page like https://en.wikipedia.org/w/index.php?oldid=603182124#Referenced_text that contains this wikitext:

<small>
[[File:Example.jpg|thumb|Caption]]
</small>

When you open the page in VisualEditor, the image "thumb" has a box the entire width of the screen, the image is the correct size, but centered, and you can't select (and therefore can't edit) the image.

The caption's text is small, which is probably expected.

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

**Attached**: {F13959}
Yeah, we should fix this sooner rather than later. Sorry.

*** This bug has been marked as a duplicate of bug 51614 ***
See
https://fr.wikipedia.org/wiki/Utilisateur:Elitre_(WMF)/Prove5?veaction=edit
https://it.wikipedia.org/wiki/Utente:Elitre_(WMF)/Sandbox_VE8?veaction=edit
and https://en.wikipedia.org/wiki/User:Elitre_(WMF)/Sandbox3?veaction=edit .
The widget behaves as if you are attempting to create the article "API".
On en.wp it also provides a direct link to create Special:Mypage/API.

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

**Description:**
visual editor from git f8d56e6804a12248b485c2d3b49d4ff0ffa7220c

testcase : https://www.zabbix.org/wiki/Bugsquash_Days
(if creating a new account, real name is mandatory)

edit the page with visual editor. using the cursor keys, modify on of the event link texts :

"Wikitext markup detected
You are using VisualEditor - wikitext does not work here. Click "Edit source" to edit the page in wikitext mode – unsaved changes will be lost."

--------------------------
**Version**: unspecified
**Severity**: normal
Yeah, the regex can't avoid false positives without making typing very slow; instead, we plan to remove the wikitext warning in a while.
**richlv** wrote:

hmm, this might be caused by #-number sequence in the bullet points... if so, not sure whether that can be easily solved
Screenshot

For all pages on test2 I am getting the following error upon loading and Ve does not open for that page

Uncaught TypeError: Object #<Object> has no method 'lookup' 

Try this page:
https://test2.wikipedia.org/wiki/User:RYasmeen_(WMF)/sandbox?veaction=edit

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

**Attached**: {F13741}
This now WFM; possibly a gadget issue?
As a logged in user on http://en.wikipedia.beta.wmflabs.org/ edit any page. 

Choose "Insert Media"

Search for something e.g. "San Francisco"

Select a media image. 

Insert Media interface does nothing, but should offer a Save and then Review your changes options.

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix on production
verified the fix on mw.org
This issue got fixed by :https://gerrit.wikimedia.org/r/123803
Verified in betalabs.
seen on beta labs http://en.wikipedia.beta.wmflabs.org/

After clicking Edit for VisualEditor, sometimes the user waits longer than expected for the editable div to appear.  

There is a default timeout of 5 seconds in the automated browser tests, and these tests are failing more and more often because the edit surface in VE takes longer than 5 seconds to appear, for a page of reasonable size.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to Chris McMahon from comment #2)
> Well, the *tests* are fixed, but it is a bit sketchy that the editable div
> is taking so long to manifest.

Beta Labs being slow isn't really a bug so much as a statement of fact…
Well, the *tests* are fixed, but it is a bit sketchy that the editable div is taking so long to manifest.
Fixed in gerrit 123450.
Firefox display bug

This is related to Bug 63432, about the mis-display of an icon in the media settings dialog box, and Bug 63127, about the reference box.

It also displays incorrectly in template boxes (see attachment), references (the icon at "Options" for "Use this group"—see bug 63127), and pretty much everything in the "Page options" (three bars icon) menu.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63127
https://bugzilla.wikimedia.org/show_bug.cgi?id=63432

**Attached**: {F13423}
*** This bug has been marked as a duplicate of bug 63127 ***
Firefox-only display bug

If you open the image dialog box and go to "Advanced settings" in Firefox, the "window" icon next to the headline "Positions" is misplaced, so that it covers up the checkbox for "Wrap content with this item".

This cannot be reproduced in Safari or Chrome.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63127
https://bugzilla.wikimedia.org/show_bug.cgi?id=63433

**Attached**: {F13420}
*** This bug has been marked as a duplicate of bug 63127 ***
To replicate:
1) Browse to http://en.m.wikipedia.beta.wmflabs.org/ in a browser window with at least one dimension > 700px
2) Opt-in to MobileFrontend's experimental feature (main menu -> settings -> beta -> 'on' -> save; main menu -> settings -> experimental -> 'on' -> save)
3) Browse to random article
4) Tap/click pencil icon to edit

Current behavior:
 Receive error "Error, can't load section"
Expected behavrio:
 VisualEditor interface loaded to edit article


When looking through the network requests, you should see an API request for the VE action (something like http://en.m.wikipedia.beta.wmflabs.org/w/api.php?format=json&action=visualeditor&paction=parse&page=0.019064959779951818) with a server response of:
'{"servedby":"deployment-apache02","error":{"code":"parsoidserver-http-bad-status","info":"503"}}'

--------------------------
**Version**: unspecified
**Severity**: normal
This appears to be resolved now. Dunno what changed, but it is at least working again ;)
video capture of the bug

Steps to reproduce:

1.Open a page with VE

2.Insert an image or a reference somewhere at the centre of the page for better viewing the effect of it.

3.Now click on the Reference Icon or the Media Settings icon

Observed Result:

You will see the hand icon inside the dialog box and upon double clicking it selects some part of the dialog box.

See the Video Capture attached.




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

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

**Attached**: {F13360}
Re-checked - non-reproducible anymore, most likely due to re-design of citation dialog/edit boxes.
The recommended way to deal with private wikis is documented at

https://www.mediawiki.org/wiki/Extension:VisualEditor#Linking_with_Parsoid_in_private_wikis
**koem** wrote:

ok, solved it by:

          if ( $_SERVER['REMOTE_ADDR'] == '127.0.0.1' ) {
           $wgGroupPermissions['*']['read'] = true;
           $wgGroupPermissions['*']['edit'] = true;
          } else {
           $wgGroupPermissions['*']['edit'] = false;
           $wgGroupPermissions['*']['read'] = false;
          }

and in localsettings.js

          parsoidConfig.setInterwiki( 'localhost', 'http://localhost/mediawiki/api.php' );

please add this to the documentation
**koem** wrote:

When I comment out these lines in LocalSettings.php - then it works. But then my wiki isn't private anymore ...

$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['read'] = false;
**Author:** `andr55`

**Description:**
I would like the extension:variables installed.

It is available at https://www.mediawiki.org/wiki/Extension:Variables

It is rated as stable.
It allows creating local variables valid only in the current page.

The current use case is to define a long string to be used in over 100 templates as part of links inside a larger template page.
This extension will help alleviate constant ongoing problems in a frequently accessed and edited page.  (Over 400 edits in the last month.)

1) By using a local variable, it removes the problem of typos, very common in the page where it will be used.  As well, it will minimize the problem of broken links, as many editors avoid typing the long string necessary to create valid links.

2) It keeps this string local to the only page where it will be used, thus not polluting the template namespace, and avoiding potential name conflicts with other templates.

3) The variable can be defined at the beginning, with a brief description to ensure that it's use is understood, so it becomes self-documenting where it is used.

4) A shorter and more useful name can be chosen than for a template, as a template name would have to avoid ambiguity with other template pages.

5) In the likely case that this string needs to be changed in the future, it can be done more easily, as it will be on the page where it is used.

6) Although this is for use as part of a link, it could equally be used for other cases, as presented in examples on the extension page.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
It was marked as a verified duplicate of T9865 while in Bugzilla: http://bugs.wmflabs.org/show_bug.cgi?id=63324
The extension was never installed, so I'm not sure why this is marked Resolved.
(In reply to andré from comment #8)
> So you are saying that problems with the implementation of these new
> features interfere with this extension ?

It's not a problem with those features, it's a design requirement.

We had to deal with that requirement when creating Scribunto, too.

> I'm assuming that all this extension does is scan the page, taking the
> variable definitions and replacing all instances using the defined
> variables, before any other parsing of the page.  The result is a page that
> shows no evidence of the extension.

I haven't checked, but I'd imagine the model is more that when the parsing process calls the hook for #vardefine it sets some internal state, and when it calls the hook for #var then it returns that internal state. Much like how with Cite a <ref> sets some internal state and <references> uses that to construct a list of references.

> Maybe there needs to be a processing priority established ?

Let's not add even more passes to the parser. The Parsoid folks already want to do that for Cite (and do do it in Parsoid).

> Maybe you can explain how any problems with the new VisualEditor and Parsoid
> are not orthogonal to this extension ?

Because wikitext needs to be parsed?

> I'm not trying to distract you from solving VisualEditor problems,

Not my department anyway.
**andr55** wrote:

(In reply to Brad Jorsch from comment #6)
> (In reply to andré from comment #4)
%%%> > > *** This bug has been marked as a duplicate of bug 7865 ***%%%
> > 
> > Not appropriate, for a very old bug rejected for circumstances which likely
> > have changed.
> 
> Circumstances have in fact changed.
> 
> However, they've changed such that closing this as anything other than
> WONTFIX is even more unlikely: VisualEditor and Parsoid require the ability
> to reparse fragments of the page and then merge the new HTML into the
> previously-rendered HTML, meaning that new wikitext that affects other parts
> of the page will not be added (and it's even difficult to fix bugs in Cite
> due to this issue).

So you are saying that problems with the implementation of these new features interfere with this extension ?
I don't understand.
 
I'm assuming that all this extension does is scan the page, taking the variable definitions and replacing all instances using the defined variables, before any other parsing of the page.  The result is a page that shows no evidence of the extension.
Is there something that prevents it from processing before any other parsing ?
Maybe there needs to be a processing priority established ?

Maybe you can explain how any problems with the new VisualEditor and Parsoid are not orthogonal to this extension ?
I haven't used VisualEditor yet as I am very comfortable with the older editor, so I'm not aware of any problems there.

BTW, to facilitate the use of this extension, WP could always make some supplementary requirement such as the use of the extension be signaled by a definition at/near the beginning of the page.  Or maybe restrict it to user: space initially, for testing purposes.

I'm not trying to distract you from solving VisualEditor problems, but we have a pre-existing editor which works very well, and extension:Variables is an important enhancement.
**andr55** wrote:

(In reply to Andre Klapper from comment #5)
> (In reply to andré from comment #3)
> I don't know what this refers to, but so far it looked like the bug report
> was about deploying an extension instead.

Exactly.  I was responding to your comment #1 

> > Not appropriate, for a very old bug rejected for circumstances which
> > likely have changed.
> 
> Please provide proof for the "likely".

Evidently there have been considerable changes to WP since 2006.
As well, looking at the changelog of extension:Variables, there was a major re-write for version 2.0.0.  (It is now at 2.0.1)
(In reply to andré from comment #4)
> > *** This bug has been marked as a duplicate of bug 7865 ***
> 
> Not appropriate, for a very old bug rejected for circumstances which likely
> have changed.

Circumstances have in fact changed.

However, they've changed such that closing this as anything other than WONTFIX is even more unlikely: VisualEditor and Parsoid require the ability to reparse fragments of the page and then merge the new HTML into the previously-rendered HTML, meaning that new wikitext that affects other parts of the page will not be added (and it's even difficult to fix bugs in Cite due to this issue).
(In reply to andré from comment #3)
I don't know what this refers to, but so far it looked like the bug report was about deploying an extension instead.

> Not appropriate, for a very old bug rejected for circumstances which
> likely have changed.

Please provide proof for the "likely".
**andr55** wrote:

(In reply to Andre Klapper from comment #1)
> Hi André, thanks for taking the time to report this!
> 
> (In reply to andré from comment #0)
> > I would like the extension:variables installed.
> 
> On which site? For any configuration change, a local consensus is required.
> Could you discuss the matter on the Village pump page of your wiki to
> confirm that this change is wanted by the community, and paste the link to
> the discussion here?
> 
> Also, please see https://www.mediawiki.org/wiki/Review_queue for a checklist
> of steps how to proceed before marking this as blocking bug 31235.

Thanks for the feedback.
The page in question is a template on the English WP.
I've already had contact with someone on the Village pump page, who wasn't aware of this extension.
I'll get back when I have the confirmation.
This was rejected way back in the day (bug 7865). I assume the rejection still stands.

-----

2) It keeps this string local to the only page where it will be used, thus not polluting the template namespace, and avoiding potential name conflicts with other templates.

Fun fact, there are 74106937111882365071085430405560261026092790186009960985252853765064
40296955904 possible template names, (This is an under-estimate, I didn't count most non-english letters). You could easily use Template:PageNameHere/Specific_string_name, or even just make it a subpage of the actual page not in the template namespace, etc. Now namespacing things might be nice just generally, but we're not running out of template names.

>It is rated as stable.

Just for the record, those ratings are done by the extension author. There are lots of extensions marked unstable which are actually more stable than the stable extensions. So the rating is pretty much meaningless. (Which isn't necessarily to say anything bad about this particular extension, I have no idea how stable it may or may not be)

*** This bug has been marked as a duplicate of bug 7865 ***
Hi André, thanks for taking the time to report this!

(In reply to andré from comment #0)
> I would like the extension:variables installed.

On which site? For any configuration change, a local consensus is required. Could you discuss the matter on the Village pump page of your wiki to confirm that this change is wanted by the community, and paste the link to the discussion here?

Also, please see https://www.mediawiki.org/wiki/Review_queue for a checklist of steps how to proceed before marking this as blocking bug 31235.
Steps to Reproduce:
1.  Enable the edit-summary gadget at the English Wikipedia as described in Bug 63314.

2.  Make a small change to any page.  Click "Save".  Notice the two drop-down menus underneath the edit summary textarea.

3.  Oops, you need to make another change before you save.  Close the save dialog (e.g., press the Escape key).

4.  No, that change is not important (or make another change; it doesn't matter).  Go back to 'Save'.

5.  Count the number of dropdown menus present.



Reproducible: Always

Repeating this process several times resulted in at least four pairs of dropdown menus in Firefox before I gave up.  

In Safari, I got two pairs, and then (consistently) on the third time, VisualEditor seemed to crash (whole page grays out [or "whites out", really], nothing happens until I hit Escape).  But after pressing Escape, everything's fine, and the process can be repeated several more times, resulting in half a dozen pairs of drop downs.  (The white/apparent crash comes back after a few more rounds, but just press Escape again and keep going.)  

Saving the page was ultimately successful.

--------------------------
**Version**: unspecified
**Severity**: minor
Bugs with gadgets aren't tracked in Bugzilla (per community request about forking the discussion from on-wiki venues), so marking this as INVALID, sorry.
Intention:
Add a pre-set edit summary to an edit using a gadget.

Steps to Reproduce:
1.  Turn on the gadget at en.wp:   Preferences > Gadgets > Editing > "Add two new dropdown boxes below the edit summary box with some useful default summaries"

2. Edit any article with VisualEditor.

3.  Save page.  Don't click or type anything into the edit summary box.  Just click on an item something from one of the dropdown menus added by the gadget, and then click on 'Save'.

4.  Look for the edit summary in the page history.

Actual Results:  
The edit summary displays in the textarea of the save dialog, but it is not saved with the edit.

If you click in the textarea after (but not before) choosing an edit summary from the dropdown menu, then the edit is saved correctly.


Reproducible: Always

Confirmed in Chrome, Safari, and Firefox on Mac and Ubuntu.

--------------------------
**Version**: unspecified
**Severity**: minor
Bugs with gadgets aren't tracked in Bugzilla (per community request about forking the discussion from on-wiki venues), so marking this as INVALID, sorry.
Impossible to delete this addition: https//fr.wiktionary.org/w/index.php?title=pr%C3%A9dominer&diff=prev&oldid=18065635

because VE consider it as a template part: https://commons.wikimedia.org/wiki/File:VisualEditor_bug_on_fr.wikt.PNG

Tested on two PCs, including one with Firefox 28.0.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://fr.wiktionary.org/w/index.php?title=pr%C3%A9dominer&diff=prev&oldid=18065635
The problem here is that the template "{{S|étymologie}}" creates a broken block object, so everything after it has to be part of the same block. (This, BTW, is horrible wikitext.)

When Parsoid encounters this, it has no choice but to assume that the (mistaken) rest of the block was intended to be there, so groups it in with the template. Had the user put a newline in correctly it would have worked fine, but this isn't great. :-(

What do you suggest we should do in this case?
picture of the bug

Template's html code shows on page when editing. I don't know should we change something with our templates on fi-wiki, or is it possible to fix in VisualEditor.

How to reproduce:
1) go to https://fi.wikipedia.org/wiki/Australian_Grand_Prix_2014?veaction=edit
2) see the 2 templates on the bottom of the page

If you need more information, feel free to ask.

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

**Attached**: {F13012}
Closed. Thanks for your investigating.
Hi, i think that the idea of the "lisätyylit" is to add css inline rules to div and stuff after that is to end css-rules and add some table attributes. However it has never worked because there is div element and not table. It also broke resulting html-code even it seemed to work.

Reason why visual editor broke is the mismatching doublequotes in expanded template result (in lisätyyli param: '... both" cellpadding="2" cellspacing="5"':

-- Clip --
<div class="NavFrame " style=" margin: auto; background-color: #ffffff; border: 1px #aaaaaa solid; margin: 0.5em auto auto auto; width: 600px; text-align: center; font-size: 95%; clear: both;; background-color: #FFFFFF; color: #000000; width: auto;"><div class="NavHead" style="display:block;text-align:center;background-color: #F3D161;">
-- Clip --

I fixed some templates with this change and my guess that all of F1-templates can be fixed with same way: 
- https://fi.wikipedia.org/w/index.php?title=Malline%3ABrasilian_Grand_Prix&diff=13955778&oldid=13575504

However there seems to be little delay before change can be seen in visual editor after template is fixed and i could not find any way to purge visual editors cache. 

If it ok for stryn i think that this bug can be closed.
Well, https://fi.wikipedia.org/w/index.php?title=Malline:Australian_Grand_Prix&action=edit


| lisätyylit = ...styleinfo..." cellpadding="2" cellspacing="5"

What is that, and what gave anyone the idea that that would ever work ? :D
When you click the edit button the address bar changes but the editor doesn't overlay. Many a time I find myself clicking it several times.

The problem stems from VisualEditor code being loaded via mw.loader.using but no LoadingOverlay being shown.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 124025 merged by jenkins-bot:
Show LoadingOverlay when loading VE

https://gerrit.wikimedia.org/r/124025
Change 124025 had a related patch set uploaded by JGonera:
Show LoadingOverlay when loading VE

https://gerrit.wikimedia.org/r/124025
The loader should show and the overlay should be semi transparent.
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1817
--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Mac OS X 10.9
**Platform**: Macintosh
Not convinced that this is something we should fix – the whole point of browser zoom is that VE shouldn't care what the zoom level is, and should be consistent. If you zoom out to the level that things are too small, then you won't be easily able to click them. If you zoom in, they will get bigger.

Unless I'm missing something?
Navigate here: https://www.mediawiki.org/wiki/VisualEditor:Test12

Open the VisualEditor

Open the template editor for the page's content — should be Template:Longformcontent

Scroll to the fourth parameter text entry field.

Scroll within the fourth parameter's text entry field to "Maecenas non condimentum risus."

Click "Maecenas non condimentum risus."

Defect: the cursor is placed at the top of the text entry field, by "Lorem ipsum dolor"

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Mac OS X 10.9
I think this is now fixed on production, and this ticket should be closed.
Screenshot

See the screenshot attached

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

**Attached**: {F13208}
Verified the fix in test2
Change 120854 merged by jenkins-bot:
Make VE math inspector title not be null

https://gerrit.wikimedia.org/r/120854
Verified the fix on betalabs:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Reference_numbering&veaction=edit
Change 120846 merged by jenkins-bot:
Make VE math inspector title not be null

https://gerrit.wikimedia.org/r/120846
Change 120854 had a related patch set uploaded by Jforrester:
Make VE math inspector title not be null

https://gerrit.wikimedia.org/r/120854
Change 120846 had a related patch set uploaded by Catrope:
Make VE math inspector title not be null

https://gerrit.wikimedia.org/r/120846
see https://gerrit.wikimedia.org/r/#/c/119217/

update VisualEditor appropriately

--------------------------
**Version**: unspecified
**Severity**: normal
There is something that should be triggered to change the appearance of the save button in IE that isn't being triggered.  I need to find it.

--------------------------
**Version**: unspecified
**Severity**: normal
Think this is a dupe of Bug #63039

*** This bug has been marked as a duplicate of bug 63039 ***
Steps to reproduce:

1.Open a page with VE
2.Insert an image/reference
3.Inside the reference or media dialog box insert a link/special character inserter
4.Now hover over any button on the link inspector like close or delete button

Observed Result:
The dialog box is getting misplaced like flickering

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/User:RYasmeen_%28WMF%29?veaction=edit

--------------------------
**Version**: unspecified
**Severity**: normal
For completion, usage of `.oo-ui-force-gpu-composite-layer()` in v0.24.3 resolved this misbehaviour in Chrome.
Reference task: {T64591}
*** This bug has been marked as a duplicate of bug 62591 ***
Update: this is only when *animating* opacity, not when changing opacity.
Updated summary: there are also smaller wiggling bugs when you hover over close buttons of popups and various other places.
This turns out to be because Chrome turns some sort of hardware acceleration or whatever on or off when the opacity is not 1. When you hover over certain icons, we change the opacity from 0.8 to 1, which triggers acceleration stuff, and so everything wiggles.

I'll try to come up with a minimal test case and file this bug against Chrome, but for now I'll just change all opacity: 1; rules to opacity: 0.99;
This may be a particularly bad incarnation of the wiggling issue (mouse over the closing X of the edit notices popup and you'll see the text wiggle), exacerbated by the fact that this is in an iframe.

I think Trevor addressed wiggliness in the template dialog using -webkit-backface-visibility: hidden;, we should try that here.
When reaching the bottom of a list of parameters for a given template, cursor in the box of the last parameter, if you hit Tab you'll be taken directly to the "Apply changes" button, while some users would expect "Add Parameter" to be reachable then.

--------------------------
**Version**: unspecified
**Severity**: normal
I believe this was fixed with bug 65474 being completed. Sorry for getting this out of order.

*** This bug has been marked as a duplicate of bug 65474 ***
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Now open a link inspector
3.Do not insert any link, just close the link inspector by pressing "<" or the trash icon

Observed Result:

The link inspector icon is still active on the toolbar

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**: {F12885}
This isn't a bug; the "active" state is intentional.
unexpected session no longer valid message

Seen in some automated tests, for example https://wmf.ci.cloudbees.com/job/VisualEditor-en.wikipedia.beta.wmflabs.org-linux-firefox/410/testReport/(root)/VisualEditor/Edit_with_strings__outline_example_____Editing_with_%C3%A1%C3%A9%C3%AD%C3%B3%C3%BA___Editing_with_%C3%A1%C3%A9%C3%AD%C3%B3%C3%BA___/

in the span of less than 90 seconds, this test does these steps: 

* start a browser (Firefox)
* login to beta labs and navigate to an editable page
* dismisses the beta warning
* edits the page with a smallish string
* click Save page
* click This is a minor edit
* click Review your changes
* click Return to save form
* edit the description of the change
* click Save page the second time

At the last step, the result shows an error message "Warning: we could not process your edit because the session was no longer valid..." 

See screen shot.  

Note in the screen shot that the user is still logged in properly at the time they receive the error message.

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

**Attached**: {F12866}
Wasn't this the bug that was caused by the mobile test for logging the user out running in parallel?
I think its great that developers add special characters option. While I would see here an improvment to load on every different wikipedia its charset, which was after the years of its ussage developed. Its not an "extra" of folks, its the fact that every language has some specifics (Spanish ¿, Czech „“) which are not native to keyboards. But yet when we want to have a clear and quality ecyclopedia we use them.
VisualEditor has used MediaWiki core's list of characters since around March.
Intention:
Find out why [[Page]] was a redlink by opening the link in another window.

Steps to Reproduce:
1. Open a sandbox in a subpage, e.g. [[User:Example/Sandbox]]

2. Add a redlink to a non-existent [[Page]].

3. Ctrl-click on the redlink to open the non-existent page in another tab.

4. See that the page actually opened in [[User:Example/Page]] instead of at [[Page]].



Reproducible: Always

This was fixed in Bug 59196 but has re-appeared for redlinks only.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 58314 ***
Intention:
Add a link to a redirect page.

Steps to Reproduce:
1. Go to Mediawiki.org.  Open a page in VisualEditor and type some text.

2. Select a word and try to link it to [[Help:Help]], an existing redirect page.



Actual Results:  
It claims that the existing page is a "New Page"/redlink.


Reproducible: Always

This only happens at Mediawiki.org  The problem cannot be reproduced at either beta labs or at the Wikipedias, so it must be something in wmf18.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 54361 ***
What the page ought to look like

If you have an inline template (like {{highlight}} at en.wp) with a lot of text in it, the text needs to wrap instead of behaving like a block.

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

**Attached**: {F13155}
*** This bug has been marked as a duplicate of bug 51708 ***
Created attachment 14855
What the page actually looks like inside VisualEditor

**Attached**: {F13156}
Steps to Reproduce:
1. Using Safari, open https://en.wikipedia.org/w/index.php?oldid=600087421 and scroll to the ==Referenced text== (first) section.

2. Select a sentence in the first paragraph, including at least one <ref> tag.

3. Control-click on your choice of "refs" in the next paragraph.  (These are all {{sfn}} templates.)

4.  Pretty, isn't it?

Actual Results:  
Text all over the page was selected, but not box-type templates.


Reproducible: Sometimes

Unable to reproduce in Firefox.

--------------------------
**Version**: unspecified
**Severity**: normal
Seems to be long-fixed?
Created attachment 14845
Screenshot showing strange selection pattern

**Attached**: {F13075}
Would be nice to see this there.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This was done in bug 53050. Unfortunately due to bug 53972 it doesn't display in production for Wikimedia sites yet, sorry.

*** This bug has been marked as a duplicate of bug 53972 ***
Intention:
Add a Babel box

Steps to Reproduce:
1. Add {{#babel:en|de-1|es-1|vo-0}} using the workaround described in bug 62750.

2. Look at the results.

3. Save the page.  Look at the very different results.

Actual Results:  
See the screenshot.  The first shows the left-aligned box before save; the second shows the right-aligned, colorful box after the save.

Expected Results:  
What you saw in VisualEditor would have some signficant relationship to what you saw when the page was saved.

Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: normal
Re-checked it in production - no difference in displaying {{#babel:en|de-1|es-1|vo-0}} in VE and in Read mode.
Created attachment 14838
Screenshots showing radically different displays of the same content pre- and post-saving.

**Attached**: {F13023}
If I cut items from a bulleted list and try to past them into another bulleted list, the formatting gets confusing:

*Extra empty bullets get left behind when I cut.
*The relationship between an existing list and new items I paste to the end of it can be wonky. Extra line breaks appear, and sub-bullets lost their relationship to each other, so that pressing tab to increase the level of indentation sometimes creates two bullets in a row instead of just increasing the level of indentation.

See this screen recording for more details of my experience: https://commons.wikimedia.org/wiki/File:Screen_recording_of_trying_to_move_bulleted_list_items_in_VisualEditor.ogv

--------------------------
**Version**: unspecified
**Severity**: normal
Appears to be fixed now. If you can still reproduce, please reopen.
Screenshot

Steps to reproduce:


1.Open a page with VE
2.Add some headings
3.Save the page

Observed Result:

Edit links are not appearing for the headings

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

**Attached**: {F13017}
Was caused by a transcluded page that set __NOSECTIONEDIT__
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/17thMarchrome
In its current form I'm always wondering "check what?" and "switched what?"

Can't them be replaced by sentences like "Switched from VisualEditor" and "Check VisualEditor errors" or something better?

--------------------------
**Version**: unspecified
**Severity**: normal
=/
(In reply to Helder from comment #0)
> In its current form I'm always wondering "check what?" and "switched what?"
> 
> Can't them be replaced by sentences like "Switched from VisualEditor" and
> "Check VisualEditor errors" or something better?

Space is at a premium where tags are involved. They occur in page histories, recent changes, watchlists, diffs, IRC feeds, and other places. Brevity is important.

Also, as Alex says, if this is just fixing the qqq messages to make these clearer, this can be done at TranslateWiki.net without the need for a bug.
Aren't the docs supposed to clear up issues like this? Are they insufficient?
Intention:
Edit https://www.mediawiki.org/wiki/User:Quiddity_(WMF)


Steps to Reproduce:
1. Click on https://www.mediawiki.org/wiki/User:Quiddity_%28WMF%29?veaction=edit

2. Template is selected.

3. But there's no puzzle piece, and you can't edit it.


Actual Results:  
You can't edit the template unless you click outside the template (e.g., in the title or on a blank spot in the sidebar) first.


Reproducible: Always

See bug 62542, for inability to use cursor keys to deselect the template.

--------------------------
**Version**: unspecified
**Severity**: minor
Merging with the more general bug 57477.

*** This bug has been marked as a duplicate of bug 57477 ***
See icons overlapping other elements at
https://commons.wikimedia.org/wiki/File:Bug_EV_insertion_mod%C3%A8les_ic%C3%B4ne_d%C3%A9plac%C3%A9e.png
https://commons.wikimedia.org/wiki/File:Bug_EV_-_insertion_mod%C3%A8les_ic%C3%B4ne_d%C3%A9plac%C3%A9e_02.png
https://commons.wikimedia.org/wiki/File:Bug_EV_-_insertion_mod%C3%A8les_ic%C3%B4ne_d%C3%A9plac%C3%A9e_03.png

You can also see this very easily through the Options menu on other sites.

--------------------------
**Version**: unspecified
**Severity**: normal
duplicate of bug 63127
Some texts on the "page options" menu are unreadable because there is some buttons in wrong places. At least I can't check "redirect this page to" checkbox because the button is on the checkbox.

Sorry about my "ASAP" comment. It looks bad, but there's no "ASAP" hurry (and for the record, I've never done any patches [maybe I need to learn]).
So does this "only" look bad, or is actually some functionality broken (icon is a button which is not clickable anymore but should be, etc)?
 
I'm slightly allergic to "should do ASAP" comments -- if things should be fixed ASAP, providing a patch helps more than adding comments about ASAP. ;))
The same problem exists also with Firefox 28.0. Should be fixed ASAP.
Clicking "Edit" (VisualEditor) on https://wikitech.wikimedia.org/wiki/Shell_Request/Rxy shows an error from the server about content model json being incompatible.

However VisualEditor shouldn't initialise that far in the first place, we know the content model (conf.wgPageContentModel).

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to Yaron Koren from comment #6)
> I'm marking this as "invalid" - I would change the component to Semantic
> MediaWiki, but that's not longer on Bugzilla. If you want to submit it as an
> SMW bug, you need to go to the SMW GitHub page.

Since the bug was filed it appears the page linked has been converted to actually be wikitext-based – Krinkle, can we leave this closed or do we need to raise a GitHub issue?

(I note that it is actually wikitext, not JSON, content; perhaps us having a year-old version of SMW doesn't help.)
I'm marking this as "invalid" - I would change the component to Semantic MediaWiki, but that's not longer on Bugzilla. If you want to submit it as an SMW bug, you need to go to the SMW GitHub page.
Yes, Semantic Forms only provides the edit button/page - it doesn't affect the actual content page. If any SMW-related extension is causing this error, I would assume it's Semantic MediaWiki itself.
(In reply to Yaron Koren from comment #3)
> Well, "lies" is a strong word. :) What makes you think this problem comes
> from Semantic Forms?


The wiki uses Semantic MediaWiki, and this is FormEdit-able page (Special:Formedit). That's Semantic Forms, right?

Or is the turning the page itself into semantic data done (json content model) done by another Semantic extension and Semantic Forms only provides the special page and edit button?
Well, "lies" is a strong word. :) What makes you think this problem comes from Semantic Forms? Is it just the fact that the page uses a form?

Also, you wrote, "it admits its JSON", meaning that the page really holds JSON but claims that it's holding wikitext. Isn't the problem the other way around?
OutputPage.php exports:

> 'wgPageContentModel' => $title->getContentModel(),
Hm... Looks like a bug with Semantic MediaWiki.

It is exporting mw.config wgPageContentModel = 'wikitext', and yet when you really ask it it admits its JSON.

> > mw.config.get( 'wgPageContentModel' );
> < "wikitext"

> click "Edit"
> < AJAX Eror
> {
>   .. Exception Caught: The content format json is not supported by the content model wikitext.
The first external link in the "Further reading" section of https://en.wikipedia.org/w/index.php?title=State_Patty%27s_Day&oldid=597985640&veaction=edit is not shown the same in VisualEditor as the PHP parser.

In VE, the text shows as "'s+Day%22&hl=en&sa=X&ei=7XQyUaeaD4LqiQL9zIHIBw&ved=0CDAQ6AEwAA#v=onepage&q=%22State%20Patty's%20Day%22&f=false Early Adulthood in a Family Context - Alan Booth - Google Books".

In a normal view (https://en.wikipedia.org/w/index.php?title=State_Patty%27s_Day&oldid=597985640), it shows as "Early Adulthood in a Family Context - Alan Booth - Google Books".

--------------------------
**Version**: unspecified
**Severity**: normal
This appears to now work.
https://jv.wikipedia.org/wiki/Cithakan:Lahirmati (Template:Birth and death) is converted to span tags in this edit:  https://jv.wikipedia.org/w/index.php?title=Jojon&curid=74332&diff=881686&oldid=830430

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

Steps to reproduce:

1.Open a page with VE
2.Add a bullet list
3.Insert an image as an item to the bullet list.

Observed Result:
The bullet goes away but if you place the cursor in that position the bullet list icon remains active in the menu.


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

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

**Attached**: {F13399}
1. Open empty.html in SA demo
2. Open the language inspector or the special character inspector
3. Type, a pawn appears

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed these focus/range issues a while ago.
The fix for bug 48418 made the assumption that {CREDITS|AUTHORS}.* files were wikitext (with the implication that wikitext bullets should precede each file), contrary to expectations.

Instead, we should treat their contents as the plain text they (mostly) were until this feature was added, and merely wrap them in <pre>s for Special:Version/Credits/… etc. purposes.

--------------------------
**Version**: unspecified
**Severity**: minor
Change 116517 merged by jenkins-bot:
Reformat AUTHORS as wikitext

https://gerrit.wikimedia.org/r/116517
Change 116515 merged by Mwalker:
Special:Version: Treat AUTHORS.txt and CREDITS.txt as text, not wikitext

https://gerrit.wikimedia.org/r/116515
Change 116516 abandoned by Jforrester:
Reformat AUTHORS as wikitext

Reason:
Already done in I213caa7692bdb0a.

https://gerrit.wikimedia.org/r/116516
Change 116517 had a related patch set uploaded by Anomie:
Reformat AUTHORS as wikitext

https://gerrit.wikimedia.org/r/116517
Change 116516 had a related patch set uploaded by Anomie:
Reformat AUTHORS as wikitext

https://gerrit.wikimedia.org/r/116516
Change 116515 had a related patch set uploaded by Anomie:
Special:Version: Treat AUTHORS.txt and CREDITS.txt as text, not wikitext

https://gerrit.wikimedia.org/r/116515
(In reply to Brad Jorsch from comment #3)
> (In reply to James Forrester from comment #0)
> > Instead, we should treat their contents as the plain text they (mostly) were
> > until this feature was added
> 
> I'm not sure about "mostly".
> 
> I haven't tried to account for changes since this feature was added, but
> looking at the situation now for extensions in git, these appear to be
> wikitext:
> * CentralNotice/CREDITS
> * CirrusSearch/CREDITS
> * MultimediaViewer/AUTHORS
> * RevisionCommentSupplement/CREDITS
> * UniversalLanguageSelector/CREDITS
> * UploadWizard/CREDITS
> * Wikilog/CREDITS
> * WikiLove/CREDITS
> 
> These don't:
> * BetaFeatures/AUTHORS
> * ContentTranslation/AUTHORS.txt
> * EventLogging/AUTHORS
> * Parsoid/AUTHORS.txt
> * VisualEditor/AUTHORS.txt
> 
> Based on that, I'd lean towards renaming BetaFeatures/AUTHORS and
> EventLogging/AUTHORS to have a ".txt" extension (or just reformat them as
> wikitext) and only apply <pre> if the file used ends in ".txt".

Works for me; have re-named the bug appropriately.
(In reply to James Forrester from comment #0)
> Instead, we should treat their contents as the plain text they (mostly) were
> until this feature was added

I'm not sure about "mostly".

I haven't tried to account for changes since this feature was added, but looking at the situation now for extensions in git, these appear to be wikitext:
* CentralNotice/CREDITS
* CirrusSearch/CREDITS
* MultimediaViewer/AUTHORS
* RevisionCommentSupplement/CREDITS
* UniversalLanguageSelector/CREDITS
* UploadWizard/CREDITS
* Wikilog/CREDITS
* WikiLove/CREDITS

These don't:
* BetaFeatures/AUTHORS
* ContentTranslation/AUTHORS.txt
* EventLogging/AUTHORS
* Parsoid/AUTHORS.txt
* VisualEditor/AUTHORS.txt

Based on that, I'd lean towards renaming BetaFeatures/AUTHORS and EventLogging/AUTHORS to have a ".txt" extension (or just reformat them as wikitext) and only apply <pre> if the file used ends in ".txt".
(In reply to MZMcBride from comment #1)
> This bug can probably be marked with the "easy" keyword, if there's
> consensus to change the behavior.

Agreed, but let's get rough consensus first.
This bug can probably be marked with the "easy" keyword, if there's consensus to change the behavior.
List of repositories that need to be updated is here:

https://github.com/wikimedia/mediawiki-selenium#links

Do not forget mediawiki_selenium gem.

To update Ruby to version 2.1.1, locate Gemfile file, either in the root of the repository (mediawiki_selenium) or in tests/browser folder, or in /modules/ve-mw/test/browser folder (VisualEditor).

The first line in the Gemfile should be changed from:

#ruby=ruby-2.1.0

to

#ruby=ruby-2.1.1

Then, Jenkins jobs that run Selenium tests should be updated. The repository is located here:

https://github.com/zeljkofilipin/jenkins-job-builder-config

Find all files that contain this:

RUBY_VERSION=2.1.0

and replace it with:

RUBY_VERSION=2.1.1

--------------------------
**Version**: wmf-deployment
**Severity**: normal
(Should've been changed back to RESOLVED FIXED over a month ago.)
Change 141134 abandoned by Alex Monk:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/141134
Change 141134 had a related patch set uploaded by Inchikutty:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/141134
I have pushed the changes to Cloudbees, Ruby 2.1.1 installs just fine:

https://wmf.ci.cloudbees.com/job/CirrusSearch-en.wikipedia.beta.wmflabs.org-linux-firefox/42/console
(In reply to Vikas from comment #16)
> I have sent you pull request from github to Jenkins jobs. Here is the link
> 
> https://github.com/zeljkofilipin/jenkins-job-builder-config/pull/1

Merged into master branch.
Change 116705 merged by jenkins-bot:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116705
Change 116704 merged by jenkins-bot:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116704
Change 116708 merged by jenkins-bot:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116708
Change 116707 merged by jenkins-bot:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116707
Change 116709 merged by jenkins-bot:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116709
Change 116710 merged by jenkins-bot:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116710
Change 116711 merged by jenkins-bot:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116711
Change 116715 merged by jenkins-bot:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116715
Change 116716 merged by jenkins-bot:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116716
Change 116522 merged by jenkins-bot:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116522
Change 116712 merged by jenkins-bot:
[Browser tests] Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116712
Change 116529 merged by jenkins-bot:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116529
Change 116706 merged by jenkins-bot:
QA: Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116706
Change 116700 merged by jenkins-bot:
Updated Ruby version from 2.1.0 to 2.1.1 in tests/browser

https://gerrit.wikimedia.org/r/116700
Change 116713 merged by jenkins-bot:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116713
I have sent you pull request from github to Jenkins jobs. Here is the link

https://github.com/zeljkofilipin/jenkins-job-builder-config/pull/1
Change 116522 had a related patch set uploaded by Vikassy:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116522
Change 116529 had a related patch set uploaded by Vikassy:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116529
Change 116700 had a related patch set uploaded by Vikassy:
Updated Ruby version from 2.1.0 to 2.1.1 in tests/browser

https://gerrit.wikimedia.org/r/116700
Change 116716 had a related patch set uploaded by Vikassy:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116716
Change 116715 had a related patch set uploaded by Vikassy:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116715
Change 116713 had a related patch set uploaded by Vikassy:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116713
Change 116712 had a related patch set uploaded by Vikassy:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116712
Change 116711 had a related patch set uploaded by Vikassy:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116711
Change 116710 had a related patch set uploaded by Vikassy:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116710
Change 116709 had a related patch set uploaded by Vikassy:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116709
Change 116708 had a related patch set uploaded by Vikassy:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116708
Change 116707 had a related patch set uploaded by Vikassy:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116707
Change 116706 had a related patch set uploaded by Vikassy:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116706
Change 116705 had a related patch set uploaded by Vikassy:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116705
Change 116704 had a related patch set uploaded by Vikassy:
Updated Ruby version from 2.1.0 to 2.1.1

https://gerrit.wikimedia.org/r/116704
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 TypeError: Cannot call method 'getModel' of null appears in the console and user cannot go to the next line anymore and has to cancel that session.

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/w/index.php?title=27thfebchrome&veaction=edit

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

**Attached**: {F13193}
I'm going to take a wild guess and claim that this is a DUPE of bug 59911, but we should verify.

*** This bug has been marked as a duplicate of bug 59911 ***
It happens in FireFox too, but the error message is different there:
TypeError: outermostNode is null
	

...unt=outerParent.getChildren().length;if(outermostNode.type==='listItem'&&outerPa...
Steps to reproduce:

1.Open a page with VE which has a reflist at the end of the page

2.Place your cursor at the end of the page and press enter to add a newline

Observed Result:
No newline gets added and an error appears in the console:


Uncaught TypeError: Cannot call method 'getModel' of null load.php:268
ve.ce.Surface.handleEnter load.php:268
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 load.php:38

--------------------------
**Version**: unspecified
**Severity**: normal
This issue got resolved with  bug 59911
This is almost certainly the same as bug 59911; merging with that.

*** This bug has been marked as a duplicate of bug 59911 ***
**cornel.punga** wrote:

I confirm it. Reproduced both steps, same error, no newline added.
Created attachment 14682
Screenshot

**Attached**: {F12998}
Hello,
French Wikiversity need help to fixe the visual editor working on the "recherche:" space name.
Thanks a lot.

--------------------------
**Version**: unspecified
**Severity**: normal
Now done. If you want any further changes, happy to help!
Change 115299 merged by jenkins-bot:
Enable VE in the "Recherche:" (104) namespace for frwikiversity

https://gerrit.wikimedia.org/r/115299
Change 115299 had a related patch set uploaded by Jforrester:
Enable VE in the "Recherche:" (104) namespace for frwikiversity

https://gerrit.wikimedia.org/r/115299
No problem. Do you also want it on the Projet / Faculté / Département namespaces?
Steps to reproduce:

1.  Go to Page settings to set a redirect.  

2.  Skip the tick box; just click in the field and type in your page name.

3.  Apply changes.

4.  Change your mind.  Go back to Page settings.  Untick the checkbox.

5.  Apply changes.

6.  Figure out the perfect target.  Go back to Page settings.  

7.  Skip the tick box, just like you dud in Step 2; just click in the field.  Why won't it let me type there now?

--------------------------
**Version**: unspecified
**Severity**: minor
(In reply to WhatamIdoing from comment #0)
> 7.  Skip the tick box, just like you dud in Step 2; just click in the field.
> Why won't it let me type there now?

Because it shouldn't have let you type there initially (bug 61864), but there was a line missing from the logic.

*** This bug has been marked as a duplicate of bug 61864 ***
picture of the box

Parameter box is too small

How to reproduce:
1) go to https://en.wikipedia.org/wiki/Saint_Titus?veaction=edit
2) click the "multiple issues" template on the top of the page and click "transclusion"

there is in the "issues" box:

{{refimprove|date=December 2010}}
{{lead too short|date=July 2013}}

and I only can see a blank row and little bit of the first line of text. Boxes should be resizable/moveable.

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

**Attached**: {F12824}
This is the same as 61289 which is already fixed and will be release to MediaWiki.org this Thursday.

*** This bug has been marked as a duplicate of bug 61289 ***
This is related to Bug 57209.

List-defined references (https://en.wikipedia.org/wiki/Wikipedia:LDR#WP:LDR) are listed in the {{reflist}} template rather than in the regular text of the page. References that are defined inside the {{reflist}} are not visible when you try to re-use an existing reference.

Steps to reproduce:

1. Open a page that uses list-defined references with the {{reflist}} template (rather than <references></ref>).

2. Go to Insert > Reference to add a new reference.  Click "Re-use existing reference".

3. Discover that the numbers ("[1]") and ref names are visible, but the contents are not.

This problem does not exist if the non-template method is used.  This problem also exists for refs inside blockquotes, infoboxes, and other templates.

--------------------------
**Version**: unspecified
**Severity**: normal
Not possible without re-writing the Cite extension from scratch, which is sort-of planned but won't be done before 2015 at the earliest. Marking as "INVALID", but it's mostly a "can't fix".
Screenshot-1

Steps to reproduce:

1.Open a page with VE
2.Insert a gallery
3.Select the gallery and apply the formated Preformatted and observe the blue highlight box
4.Deselect and again select the gallery
5.Change the format to Paragraph to Heading and observe the position of the blue highlighted box

Observed Result:
The highlight box does not get reposition according to the new position of the gallery.


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/21stfebff?veaction=edit

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

**Attached**: {F13200}
Galleries can no longer take a paragraph style, which is correct and fixes this bug.
Created attachment 14655
Screenshot

**Attached**: {F13201}
Intention:
Open https://en.wikipedia.org/wiki/Afroyim_v._Rusk (TFA) in VisualEditor.

Steps to Reproduce:
1. Click to the Main Page.
2. Click to the article (https://en.wikipedia.org/wiki/Afroyim_v._Rusk)
3. Click on "Edit beta".
4. Wait a long time.
5. Discover two copies of the entire article.

Actual Results:  
Two copies of the article appear, one above the other.  This happens in Safari 6 but not in Firefox 27; it happens only when editing the actual mainspace page, not when editing a copy in a sandbox.


Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to WhatamIdoing from comment #4)
> I can't reproduce this right now.  However, the timestamp on the screenshot
> is 10:55 a.m. PST (and it had been onscreen for a few minutes before then),
> and I thought that the deployment was set to start about five minutes after
> that.

The new version went a little early today, apparently (but only by a few minutes – see https://wikitech.wikimedia.org/wiki/Server_Admin_Log#February_20 where "testwiki to 1.23wmf15 and build l10n cache" at 16:58, though the changes start a couple of minutes before the log), but there were bigger issues involving deployment today that took down all the phase0 wikis (yay). Nothing to do with VisualEditor, but might well have caused random and otherwise inexplicable issues like this.

However, for enwiki changes didn't happen until 21:26, so it /shouldn't/ have been affected, so it's a bit of a mystery. :-(

Marking as WORKSFORME for now.
I can't reproduce this right now.  However, the timestamp on the screenshot is 10:55 a.m. PST (and it had been onscreen for a few minutes before then), and I thought that the deployment was set to start about five minutes after that.
I've just loaded it 5 times (with hard refreshes) each in Chrome, Safari and Firefox, without incident – perhaps it could be an odd cacheing issue with the switch-over to the new version?

Can you reproduce still?
I have just managed to get the article to open with a single copy, so this is intermittent.  

Also, notice the absence of VisualEditor's toolbar.  The top of the attached image is the top of the browser window.
Created attachment 14636
Screenshot showing the bottom of first copy of the article and the top of the second copy.

**Attached**: {F13022}
* Latest master mediawiki-core and VisualEditor
* Edit Worksheet page
* Open "Options" dialog

Nothing happens, console shows:



 Uncaught TypeError: undefined is not a function
 >         this.tableOfContents = new OO.ui.FieldLayout(new OO.ui.ButtonSelectWidget({'$': this.$}).addItems([new OO.ui.ButtonOptionWidget('mwTOCForce', {'label': ve.msg('visualeditor-dialog-meta-settings-toc-force')}), new OO.ui.ButtonOptionWidget(
 VeUiMWSettingsPage
 ve.ui.MWMetaDialog.initialize
 oo.EventEmitter.emit
 (anonymous function)
 pollExternalStylesheets

--------------------------
**Version**: unspecified
**Severity**: critical
[19:12]	Krinkle	Yeah, I just updated mw-core again and it works now
This works fine for me with the current MW core. Ensure you have https://gerrit.wikimedia.org/r/#/c/113508/ .
> OO.ui.FieldLayout is undefined
(Can still reproduce on VisualEditor @ 0b97870 after todays' merges)
Screenshot

Steps to reproduce:


1.Open a page with VE
2.Go to Page Settings
3.Check the box Redirect this page to and specify the page/article to which it will redirect to.
4.Apply changes
5.Save the page
6.Reopen VE for this page


Observed Result:
The page settings page pops up with ./ appended as prefix to the article name


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/19thfebchrome?veaction=edit

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

**Attached**: {F13414}
Verified the fix in test2
Change 114381 merged by jenkins-bot:
Deal with ./ prefixes etc. in MWRedirectMetaItem

https://gerrit.wikimedia.org/r/114381
Change 114381 had a related patch set uploaded by Catrope:
Deal with ./ prefixes etc. in MWRedirectMetaItem

https://gerrit.wikimedia.org/r/114381
(In reply to ryasmeen from comment #0)
> Created attachment 14632 [details]
> Screenshot
> 
> Steps to reproduce:
> 
> 
> 1.Open a page with VE
> 2.Go to Page Settings
> 3.Check the box Redirect this page to and specify the page/article to which
> it will redirect to.
> 4.Apply changes
> 5.Save the page
> 6.Reopen VE for this page
> 
> 
> Observed Result:
> The page settings page pops up with
That's a feature.

> ./ appended as prefix to the article name
>
That's a bug :(

**Attached**: {F13414}
Screenshot

Steps to reproduce:

1.Go to Edit Source mode
2.Add a text or anything else in a newline
3.Save the page
4.Open the page with VE

Observed Result:
The newly added text gets merged with the previous line adding a return character between the lines.


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/19thfebchrome?veaction=edit

See the screenshot attached

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

**Attached**: {F13402}
*** This bug has been marked as a duplicate of bug 48290 ***
If you add "File:Example.jpg", without actively specifying a size, then you should get [[File:Example.jpg|thumb|Here is a caption]].  You should not get [[File:Example.jpg|thumb|220x220px|Here is a caption]].

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 61324 ***
During a test,
I tried to create a wikilink to
http://fr.wikipedia.org/wiki/Cabin_Fever:_Patient_Zero .
What I did was writing Cabin Fever: Patient Zero,
then selecting all the 4 words, copy/pasting that precise URL and selecting the "red" option in the dropdown menu as if to link to a new page.
The result is https://fr.wikipedia.org/w/index.php?title=Utilisateur%3AElitre_%28WMF%29%2FProve2&diff=101406090&oldid=101406077 ,
that shows up as [Fever: Patient Zero] in view mode, while the wikicode shows the word Cabin as an existing part of the label.
This happened on both Chrome and FF, Win7.

--------------------------
**Version**: unspecified
**Severity**: normal
Seems to be fixed now.
Steps to reproduce:


1.Open a page in VE
2.Go to Insert>Transclusion
3.Search for a template like Cite Web
4.Click on "Add template"
5.When all the parameters appear, insert a value in one of the parameters then press tab to go to the next parameter.

Observed Result:
Pressing tab does take user to the next tab

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/New_deep?veaction=edit

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production:https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/sandbox?veaction=edit
Verified the fix in test2 environment
Screenshot

Steps to reproduce:

1.Open a page in VE
2.Add a reference to the page
3.Open the reference dialog box
4.Add a text
5.Go to the next line and then a Cite web template 
6.Go to the next line and add a math funtion
7.Save the page
8.Reopen the page and open the reference dialog box

Observed Result:
After every element return arrow is getting placed.

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/18thfebchrome?veaction=edit

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

**Attached**: {F13281}
I think this is just an artefact of "↵" characters being show for the <br />s put in by Parsoid…
Split off from bug 43058.

Editing the last equation at 
https://www.mediawiki.org/wiki/VisualEditor:TestMath?veaction=edit

if you actually make a change to the text of the equation the displayed equation becomes very jumbled. Any vertical positioning is lost, and text from different lines are overlaid on top of each other.

This happens with Chrome on a Mac.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52499
MathJax will be removed T99369
The problem seems to be a clash of CSS styling. MathJax makes heavy use of position: absolute, position: relative and setting the top, and left properties eg

<span style="position: absolute; clip: rect(1.501em 1000.003em 2.347em -0.518em); top: -2.145em; left: 0.003em;">...</span>

yet this is all rendered to nothing by the CSS rule

.ve-ce-protectedNode, .ve-ce-protectedNode * {
  position: relative !important;
  top: 0 !important;
  left: 0 !important;
  bottom: 0 !important;
  right: 0 !important;
  ...
}

If you comment out these css properties the MathJax displays OK.
Created attachment 15234
Screenshot of garbled output

This is a screenshot of the type of output obtained. You need MathJax on and image will become garbled as soon as the formula is edited with the VisualEditor formulae editing beta feature.

**Attached**: {F13244}
The special character inserter tool has hard-coded texts which are not translatable.

There is texts "symbols", "accents" and "math" which are not translatable, because there is no existing MediaWiki messages.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to Stryn from comment #1)
> I guess
> https://translatewiki.net/w/i.php?title=MediaWiki:Visualeditor-
> specialcharinspector-characterlist-insert/en is the one that needs to be
> translated.

Correct.
BTW I just saw https://www.mediawiki.org/wiki/Thread:VisualEditor/Feedback/Feedback_for_the_character_inserter/reply_%2836%29

so I guess https://translatewiki.net/w/i.php?title=MediaWiki:Visualeditor-specialcharinspector-characterlist-insert/en is the one that needs to be translated.
**Author:** `paulomsimoes`

**Description:**
VE is unable to insert a internal reference with sub-section. Example:

[["Wikipédia Article name"#"Section name"]], return only [["Wikipédia Article name"]] (without redirect to section), as per [https://pt.wikipedia.org/w/index.php?title=Faculdade_Salesiana_de_Maca%C3%A9&diff=38176530&oldid=38176349|this edit].

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows XP
I don't understand this bug report, sorry.

It is certainly possible right now to write "Foo#Bar" as your target, though VisualEditor doesn't validate "#Bar" as being a valid section so it may be confusing…

Do you mean that you would expect the link inspector to understand sections and give a better experience for that? If so, I think this is bug 50881. Provisionally merging with that one.

*** This bug has been marked as a duplicate of bug 50881 ***
**Author:** `jhall`

**Description:**
The VisualEditor headings.feature has begun to fail[1] when run via CloudBees (but not when run locally).  Relevant Selenium log message is (example is for the "Subheading1" scenario, but the pattern is the same for all scenarios in this test):

00:25:21.230 INFO - Executing: [find element: By.xpath: .//a[@title='^3']] at URL: /session/83a0781b-247c-4f0a-88f8-a93cef166a15/element)
00:25:21.247 WARN - Exception thrown
org.openqa.selenium.NoSuchElementException: Unable to locate element: {"method":"xpath","selector":".//a[@title='^3']"}
Command duration or timeout: 13 milliseconds
For documentation on this error, please visit: http://seleniumhq.org/exceptions/no_such_element.html
Build info: version: '2.39.0', revision: 'ff23eac', time: '2013-12-16 16:11:15'
System info: host: 'chef', ip: '127.0.1.1', os.name: 'Linux', os.arch: 'i386', os.version: '3.2.0-56-virtual', java.version: '1.6.0_31'
Session ID: 185a49ff-3267-43a3-ad44-3e6881cd0d43
Driver info: org.openqa.selenium.firefox.FirefoxDriver
Capabilities [{platform=LINUX, acceptSslCerts=true, javascriptEnabled=true, browserName=firefox, rotatable=false, locationContextEnabled=true, version=26.0, cssSelectorsEnabled=true, databaseEnabled=true, handlesAlerts=true, browserConnectionEnabled=true, nativeEvents=false, webStorageEnabled=true, applicationCacheEnabled=true, takesScreenshot=true}]

The problem does not repro when the test is run on a MacBook, and the insertion of the following command into the headings_steps.rb file at appropriate points succeeds as expected:

@browser.a(:xpath, ".//a[@title='^3']").should exist

Need to figure out why these test scenarios fail when run via CloudBees, since they seem to be perfectly legitimate test cases.

[1] https://wmf.ci.cloudbees.com/view/r-ve/job/VisualEditor-en.wikipedia.beta.wmflabs.org-linux-firefox/327/testReport/

--------------------------
**Version**: wmf-deployment
**Severity**: normal
Chris, since we are moving away from Cloudbees, do you plan to investigate this or should be close it?
All patches merged - 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 114114 merged by jenkins-bot:
[Browser test] Repair broken "header" browser test

https://gerrit.wikimedia.org/r/114114
Change 114114 had a related patch set uploaded by Jhall:
[Browser test] Repair broken "header" browser test

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

Steps to reproduce

1.Open a page with VE
2.Go to Insert>Media
3.Insert the search string "April"

Observed Result:

An error appears in the console:
Uncaught TypeError: Cannot read property '0' of undefined 

and the search spinner continues indefinitely

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=14thfebchrome&veaction=edit

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

**Attached**: {F12972}
Verified the fix on betalabs
That, too, *should* be fixed with this commit.
Change 113478 merged by jenkins-bot:
Only display image info if that exists

https://gerrit.wikimedia.org/r/113478
There is another error appearing while I search for hoo:
load.p...014333Z (line 583)
TypeError: this.data.imageinfo is undefined

Not Sure if it is related with this particular issue or not.
Change 113478 had a related patch set uploaded by Mooeypoo:
Only display image info if that exists

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

Steps to reproduce:

1.Open a page in test 2

2.Select an image

3.Go to the Media Settings >Advanced Settings for that image

Observed Result:
 All the button labels are missing for Media Type Section in Media Settings>Advanced Settings in test2

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/13thfebchrome?veaction=edit

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

**Attached**: {F12856}
Verified the fix on test 2
Deployment issue, now fixed.
As an admin on en.wp, I get a blank edit notice popup on every page I edit, with a red link to the page notice. I seem to recall that this is some interaction with local site JS/CSS, and that this was fixed at some point in the past.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=43013
Merging into bug 43013. Gah. :-(

*** This bug has been marked as a duplicate of bug 43013 ***
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Create a link which has a target of existing page or a new page

Observed Result:
There is no drop down appearing with matched pages suggestion or a new page section.

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/w/index.php?title=User:RYasmeen_%28WMF%29&veaction=edit

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

**Attached**: {F13342}
I'm going to write this one us as a server issue.
To reproduce:

1. Go to https://en.m.wikipedia.org/wiki/ASCII in desktop Firefox.
2. Press the pencil button to edit.

Expected: The mobile editing is supposed to open.
Observed:
1. The editing interface doesn't open. The page stays the same.
2. The following errors are displayed in the JS console:

"Exception thrown by job.error" (load.php:145)
"Error: Container must be attached to the DOM" [object Error] (load.php:145)

This works in desktop Google Chrome.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to Juliusz Gonera from comment #6)
> Also, Amir, if you're getting "Error, can't load section." on your local
> instance that probably means you're trying to use VE without running Parsoid.

Oh, useful to know. Thanks.
**jgonera** wrote:

Also, Amir, if you're getting "Error, can't load section." on your local instance that probably means you're trying to use VE without running Parsoid.
The behavior described sounds like this was in experimental and likely an issue with VisualEditor. I am entirely unable to reproduce in FF or Chrome, in stable, beta, or alpha. I assume the issue was fixed since this was reported, so marking as WORKSFORME. Amir, please reopen if the issue is still present and let us know if you're in stable/beta/alpha.
I can't reproduce in any mode, including experimental (on en.wiki or local master). Can someone verify whether or not it is still reproducable?
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1697
If I try this on my local machine on master, I get something a bit different: I don't see JS errors, but I see a notification drawer at the bottom of the page:
"Error, can't load section."
I can reproduce this in experimental mode (not in standard or beta).
Intention:
Look up something in another window

Steps to Reproduce:
1. Open Media settings for an existing image, using Safari.

2. Click on "Advanced settings".  Don't click inside any text field (e.g., width or height).

3. Decide that you need to go to another window or browser tab for a moment, so click elsewhere.

4. Go back to VisualEditor.

5. Discover that the Media settings dialog has put you back in "General settings" again.

Converse is also true:  if you put the text cursor in the "Height" box and then switch to "General settings" before leaving the page for a moment, you will be flipped back to "Advanced settings".



Reproducible: Always

Reproducible in Safari, not in Firefox.  Perhaps it's because Safari "helpfully" flips the box to wherever the text cursor is, and Firefox ignores it?

--------------------------
**Version**: unspecified
**Severity**: minor
*** This bug has been marked as a duplicate of bug 61062 ***
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Add a special character 
3.Add a hiero on the next line
4.Save the page 
5.Reopen the page, add a gallery just after the special character but before hiero
6.Save the page
7.Reopen the page

Observed Result:
Double arrow appears just after gallery but before hiero

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/Justhiero?veaction=edit

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

**Attached**: {F13041}
These don't show now; I think the upstream Parsoid fixes will have helped.
Steps to reproduce:

1.Open the page in VE
2.Add an image
3.Go to Media Settings>Advanced Settings
4.Change the image type to Thumbnail ,Frame or Border
5.Apply the changes

Observed Result:
There is no apparent different in either of these image types when selected


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&veaction=edit

--------------------------
**Version**: unspecified
**Severity**: normal
Per Moriel's statement in comment 4.
Turns out: This is intended behavior.

Images with |frameless but no position render as inline images in both Parsoid and the PHP Parser. That is, apparently, intended, as counterintuitive as it may be.

Since we can't edit inline images just yet in VE, this turns out to be a bit of a hassle (and a bug) -- but hopefully very soon we'll be able to edit inline images in the media edit dialog, which would solve the issue of having the resulting image uneditable.
Okay, for some reason, when an image has |frameless but no position set, VE intercepts it as an inline image.

So, when a new image is inserted, the position is set to default (no representation in the wikitext) and when we set it to "frameless" it results in the following wikitext:

[[File:Diplopedia main page.jpg|frameless|150x150px|]]

It seems that since it's missing a position, VE reads it as an inline image.
Sorry little change in the steps to reproduce:

1.Open the page in VE
2.Add an image
3.Go to Media Settings>Advanced Settings
4.Change the image type to Frameless
5.Save the page
6.Reopen the editor and go the media settings again
7.Now change the image type to Thumbnail, then frame

Observed Result:
There is no thumbnail icon getting added in the VE mode unless user saves it, and then if he changes to frameless, it also looks pretty similar to the type thumbnail because both of them has no thumbnail icon beside the caption field.

Selecting border also does not make any change compared to frameless which has a separate ticket:https://bugzilla.wikimedia.org/show_bug.cgi?id=61155
I can't manage to reproduce in master in both Firefox 26.0 and Chrome 32.0 under Ubuntu.

A new inserted image is inserted as "thumb" which is what I see selected in the media edit dialog when it's opened. Changing to "frameless" changes the type (and changes the view properly for me) as well as changing to "Framed" (though that one is a bit more subtle, because the difference between them isn't too noticeable)

It seems to work for me as expected in master.
**Author:** `robert.labrie`

**Description:**
The VisualEditor insert media only searches commons. I have a media item called "WOM HighLevelDesign.png" but when searching for HighLevelDesign there are no results. Looking at the request in Firebug:

Request:
GET http://commons.wikimedia.org/w/api.php?callback=jQuery18305320913342615314_1392057641882&format=json&action=query&generator=search&gsrsearch=HighLevelDesign&gsrnamespace=6&gsrlimit=15&gsroffset=0&prop=imageinfo&iiprop=dimensions%7Curl&iiurlheight=150 HTTP/1.1
Host: commons.wikimedia.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://opsdocs.carnival.com/index.php?title=Main_Page&veaction=edit
Connection: keep-alive

Response:
HTTP/1.1 200 OK
Via: 1.1 varnish, 1.1 varnish, 1.1 CCLPRDINFTMG3
Connection: Keep-Alive
Proxy-Connection: Keep-Alive
Content-Length: 110
Age: 0
Date: Mon, 10 Feb 2014 19:33:02 GMT
Content-Type: text/javascript; charset=utf-8
Server: Apache
Accept-Ranges: bytes
X-Powered-By: PHP/5.3.10-1ubuntu3.9+wmf1
x-content-type-options: nosniff
Cache-Control: private
x-frame-options: SAMEORIGIN
Vary: Accept-Encoding,X-Forwarded-Proto
X-Vary-Options: Accept-Encoding;list-contains=gzip,X-Forwarded-Proto,Cookie;string-contains=commonswikiToken;string-contains=commonswikiLoggedOut;string-contains=forceHTTPS;string-contains=commonswikiSession;string-contains=centralauth_Token;string-contains=centralauth_Session;string-contains=centralauth_LoggedOut;string-contains=mf_useformat;string-contains=stopMobileRedirect
X-Varnish: 2999015801, 4264856558
X-Cache: cp1055 miss (0), cp1052 frontend miss (0)


jQuery18305320913342615314_1392057641882({"query":{"searchinfo":{"totalhits":0,"suggestion":"Hauserdesign"}}})

--------------------------
**Version**: unspecified
**Severity**: normal
Marking as INVALID; this isn't a bug in VisualEditor, but an artefact of the (not very good) search system in MediaWiki (and a continuing issue even with CirrusSearch).
Can you also add a direct link to the image?
I've CC'd Nik Everitt, our CirrusSearch guru, to see if he can provide any insight.
After a bit of testing and fiddling around, there seems to be an issue with the API call itself and its response. 

The API returns a list of matches by complete words, and it seems that it considers the suffix as a word as well.

So, in my local wiki I have an image "image of space.jpg". 

API calls:

&gsrsearch=space.jpg --> 1 match
&gsrsearch=space --> 0 matches
&gsrsearch=image --> 1 matches
&gsrsearch=from --> 0 matches
&gsrsearch=image+from --> 1 match
&gsrsearch=image+from+space --> 0 matches

I am not sure if this is because of the specific query we use to search images or if this is an artefact of the API itself. 

I'm conducting further research.

Robert, if you have time to test this, try to see if you get the image you are looking for when typing "HighLevelDesign.png" or "WOM". Are you getting the local image on those searches?
**robert.labrie** wrote:

After cleaning my cache and setting $wgUseInstantCommons  = false; the result is now as follows:

GET /api.php?format=json&action=query&meta=filerepoinfo HTTP/1.1
Host: opsdocs.carnival.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
X-Requested-With: XMLHttpRequest
Referer: http://opsdocs.carnival.com/index.php?title=Main_Page&veaction=edit
Cookie: wikidb796_session=86334fa21b8c09bd7c07958bdc0ac86e; wikidb796UserID=2; wikidb796UserName=CARNIVAL%5Crobertla; wikidb796Token=ceb473edd15eddf81147a6c9f583acf3; website#lang=en
Connection: keep-alive


HTTP/1.1 200 OK
Cache-Control: private
Content-Type: application/json; charset=utf-8
Vary: Accept-Encoding
Server: Microsoft-IIS/8.0
X-Powered-By: PHP/5.3.24
x-content-type-options: nosniff
x-frame-options: DENY
Persistent-Auth: true
Date: Mon, 10 Feb 2014 19:55:15 GMT
Content-Length: 198

{"query":{"repos":[{"name":"local","displayname":null,"rootUrl":"/images","local":true,"url":"/images","thumbUrl":"/images/thumb","initialCapital":true,"scriptDirUrl":"","scriptExtension":".php"}]}}
This happens with Monobook (I tried this with Chrome on fr. and it.wp).
The text in the Option menu is in a larger and different font than the one under Insert.

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

Steps to reproduce:
1.Open a page with Ve
2.Select a gallery
3.Open the gallery inspector 
4.Click else where in the page to close the inspector

Observed Result:
The gallery remains highlighted in the page though it is not selected and link inspector is not appearing on the gallery

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

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

**Attached**: {F12831}
Appears to have been fixed a while ago.
Actual Results:  
VisualEditor loses most of the table.


Reproducible: Couldn't Reproduce

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=Misl&diff=594020475&oldid=593707943
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49942
Probably a browser bug or flakiness.
MathJax has started centering displayed equations. For example
https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Mathematics&curid=148395&diff=594391082&oldid=594388357
the display equation is centered. Previously they were aligned left.

Looking at the generated the code we see 
<div class="MathJax_Display" role="textbox" aria-readonly="true" style="text-align: center;">
  <span class="MathJax" id="MathJax-Element-2-Frame" style=""> ...
  </span>
</div>

the centering is in the code rather than in a style sheet.

Aligning equations to the left is the desirable format.

--------------------------
**Version**: unspecified
**Severity**: normal
**physik** wrote:

I could not find any centered equations anymore. Please reopen in case I missed something.
**physik** wrote:

nageh: Form a client-side perspective this approach is perfectly fine. However, after discussions wiht Gabriel, I'm convinced that there are good (technical) reasons that tag extension should be functionally dependend from their input and not from their context.
On the other hand this means that the math extension can not decide if the input was :<math or just <math because the : context is hidden.
The only workable solution is to add an aditional parameter to the math tag.
(In reply to nageh from comment #27)
> See, this is what sets me up. "It's a heuristic written specifically for
> MediaWiki's math extension." Bullshit! The heuristic was written
> specifically for my mathJax user script to cleverly tell apart inline math
> (where indices of large operators are ordered horizontally) from display
> math (where indices are stacked). This was actually all explained in bug
> 35188. And display math has always been left-aligned with my script.

Nageh: I'm not sure what is your intention, but your complaints do not sound very constructive. The comment you state seems to be from Peter Krautzberger so you should ask him directly. But in my opinion, he is just saying that this heuristic is not part of the MathJax code and didn't mean to accuse you of anything. Honestly, I really don't understand why you are getting nervous for that.
**mal.malego** wrote:

See, this is what sets me up. "It's a heuristic written specifically for MediaWiki's math extension." Bullshit! The heuristic was written specifically for my mathJax user script to cleverly tell apart inline math (where indices of large operators are ordered horizontally) from display math (where indices are stacked). This was actually all explained in bug 35188. And display math has always been left-aligned with my script.
Change 119010 merged by TheDJ:
Fix MathJax centers equations

https://gerrit.wikimedia.org/r/119010
Just to add a further complication. 

Bug 37938 is about support for definition lists in VE. As you all know Wikitext plays fast and loose with these transforming : into <dd>. VE being pretty strict with its html does not play nicely with these. I recently found a tricky bug where its difficult to add text after a maths equation 
https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2014_2#Trying_to_add_a_line_after_an_equation

Quite what VE's long term plan for using : as indentation I'm not quite so sure on. 

As to "heuristic is unwanted by the community". I think this refers to poll at
https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Mathematics#Should_display_equations_be_centered.3F
which was closed at "Consensus is overwhelmingly in favour of left alignment.". The heuristic was mentioned a little in the discussion. I don't think many really understood what heuristic was about so we can't really conclude what the community  thinks of the idea.
So to be more accurate, I believe the real issue is that the heuristic forced MathJax's "display mode". But because this "display mode" does not exist (yet) in MediaWiki, Nageh added this displayAlign: "left" config to get MediaWiki's default mode.

Moritz's plan was to generalize the math modes to have, inline/display (the classical modes line in MathJax, TeX, MathML etc) and "inline displaystyle" (MediaWiki's default). In his branch, the displayAlign: "left" was removed because the display and centering/displaystyle stuff is done elsewhere in MediaWiki. However, because it was hard to get review, he only merged changes step-by-step and unfortunately displayAlign: "left" was removed before the whole math modes are ready... So actually the only thing necessary for 119010 was to keep this heuristic and add this config option back.

But as Moritz said on the entry, he is willing to make progress on the new modes and get his work merged, not only to fix bugs. Hopefully, we will recover the desired rendering soon.
(In reply to nageh from comment #22)
> And I still don't understand why the "heuristic is unwanted by the
> community" according to the comment in the source file. I thought this was
> only about that display equations should be left-aligned (which they always
> were in my code)?

At some point some changes caused the heuristic to force the equation to be centered (probably because we removed displayAlign: "left" too early in the development) so that's probably what Moritz meant by "unwanted by the community". I think you should not pay too much attention to this comment (actually I believe it should be removed, it's not really useful to have it). The plan to add an explicit display attribute is exactly to avoid this kind of unexpected behaviors and inconsistencies between MathJax/mathoid/LaTeXML/texvc...
**mal.malego** wrote:

And I still don't understand why the "heuristic is unwanted by the community" according to the comment in the source file. I thought this was only about that display equations should be left-aligned (which they always were in my code)?
**mal.malego** wrote:

Ha. I do get a bit sensible when I see things being discussed that have long been addressed in my code as if I hadn't done any work on it at all, and when I see comments in the git repository that seem to imply that problems were due to bugs in my code.
As far as Moritz's efforts are concerned, I'm not exactly familiar with his works but I wish him well and encourage him.
Peace out.
(In reply to nageh from comment #19)
> So far I have ignored all these bug reports, and it seems for good. It is
> funny how much I am blamed here for all these bugs while clearly my code has
> had it right from the very start. The heuristic is not about selecting
> centered or left-aligned maths, it is about deciding the way big operators
> are rendered. From the very first day my script had included as part of the
> MathJax config environment
> displayAlign: "left"
> It seems that all my work was in vain, as if it hadn't existed at all. Sigh,
> I shall not read any of these comments.

I'm not sure where you see that you are blamed. I think everybody recognize your efforts with client-side MathJax on MediaWiki. But if the MathJax option has never been enabled by default, there are good reasons (e.g. performance just to mention one of them). So Moritz has done an awesome work to implement server-side conversion, improves the texvc situation and more. Unfortunately, this is a big and complicate change and review has been slow. The goal is to have the traditional inline mode / display mode that we find in math documents and the default/current MediaWiki rendering "inline displaystyle". This handles whether the equation is centered or not and whether the displaystyle is used or not. Moritz has done several versions and branches to try to get the patch accepted and things may have been broken in the battle. Again, I don't think anyone blamed you. I'm sorry to see that you take that personally, instead of encouraging Moritz (and others)'s effort.
**mal.malego** wrote:

So far I have ignored all these bug reports, and it seems for good. It is funny how much I am blamed here for all these bugs while clearly my code has had it right from the very start. The heuristic is not about selecting centered or left-aligned maths, it is about deciding the way big operators are rendered. From the very first day my script had included as part of the MathJax config environment
displayAlign: "left"
It seems that all my work was in vain, as if it hadn't existed at all. Sigh, I shall not read any of these comments.
**physik** wrote:

https://gerrit.wikimedia.org/r/119010 should fix the problem
now someone has to do the code review.
Change 119010 had a related patch set uploaded by Physikerwelt:
Fix MathJax centers equations

https://gerrit.wikimedia.org/r/119010
**physik** wrote:

For me it looks as I could simply merge my patch that I have already implemented.
However, I'd like to wait until https://bugzilla.wikimedia.org/show_bug.cgi?id=61006 is merged. Just to be sure, that noting breaks.
Hello,

Thank you for all the work. I just want to say the consensus in the math editor community is to stop centering the equations. So, if possible, you can start fixing this bug.
Just seen there is a related thread on the MathJax mailing list
  https://groups.google.com/forum/#!topic/mathjax-users/JwE_lr-HtpQ
Looks like there is a 
  displayAlign: "center"
parameter you can set in the hub see
  http://docs.mathjax.org/en/latest/options/hub.html
Things get a bit tricky if we want to allow both left aligned and center aligned equations.
@physikerwelt why don't you just disable the heuristic? Or as a compromise, instead of making the equation display-style, make it inline but add \displaystyle to it to get display-style layout. 

Whatever comes out of the RFC could inform Math 2.0 for how to implement real display math.
**physik** wrote:

Are there special system stylesheets that are loaded that do not belong to the default mediawiki schema?
**physik** wrote:

Hi Richard Morris,

I'm trying to reproduce it the well defined Vagrant development environment as described here. That I set up as described here.
http://www.formulasearchengine.com/sites/formulasearchengine.com/files/How%20to%20review%20the%20math%20extension_0.pdf

Did anyone manage to reproduce the problem with vagrant?
It would be very interesting how the production environment differs from vagrant with regard to MathJax. I was thinking that the problem might be related to my browser cache... but I can see the problem at enwiki
Best
Physikerwelt
DOn't know if this helps but a simple example using the MathJax content delivery network creates centered equations.

<html><head>
<script type="text/javascript"
  src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
</script>

<script type="text/javascript">
	MathJax.Hub.Config({
		jax : [ "input/TeX", "output/HTML-CSS" ],
		extensions : [ "tex2jax.js" ],
		"HTML-CSS" : {
			scale : 150
		},
		tex2jax : {
			inlineMath : [ [ '$', '$' ], [ '\\(', '\\)' ] ]
		}
	});
</script>
</head>
<body>
<dl>
<dt>
$$1 + 2 + 3 + \dots = -{1 \over 12}.$$
</dt>
</dl>
</body>
</html>

The bit which sets up the centering is in
https://github.com/mathjax/MathJax/blob/master/jax/output/HTML-CSS/config.js
**physik** wrote:

mh... bad news. I can not reproduce the problem locally.
If I copy the example 
"I use MathJax, so my view may not be typical, but there could be a problem here.
:<math>a R b \and b R c \rightarrow a R c</math>
Yep, it's a problem here, also."
from the page I get
"<dl>
<dd><span class="MathJax_Preview"></span><span style="" aria-readonly="true" role="textbox" id="MathJax-Element-1-Frame" ..."
even though I was using action=purge&debug=true
**physik** wrote:

oups... I don't like that workaround at all.
I think I'll force mathjax to render everything on the left side for now.
An alternative temporary workaround would be to add the CSS rule somewhere in the global site wide CSS or a users common.css

.MathJax_Display { text-align : left !important; } 

this would align all display equations to the left without having to change any wikitext. This would eliminate the problems in comment 6 but does require a friendly admin.
**anmichvon-wikipedia** wrote:

One possible workarround is appending &nbsp; behind the equitation.

:<math>...</math> &nbsp; <!-- hard blank works around bug 61051 -->

But who removes the garbage, when 61051 is fixed? 

So what about a template that just delivers the hard space and can be cleanly deployed and removed by bots?

:<math>...</math> {{Bugfix-61051|Don't touch, will be removed automatically if and when...}}

Possible Contras:
* Deployment by bot would produce many instances that could affect the servers load. 
* Bug will be fixed in short time, so don't mess around that much. It just isn't worth the effort.
* Might collide with other bot jobs involved in the migration from version 1.1 to version 2.0.

Pros:
* Workable plan to resolve the situation. 
* No garbage left over after jobs are done, if properly in concert with other operations of the migration.

User:Pyrometer (Home-Wiki: de.wikipedia.org)
I've just open an RFC on the question of should display equations to be centered? As this affects multiple wiki's is is open to users from all projects.

https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Mathematics#Should_display_equations_be_centered.3F
**physik** wrote:

Of course I would really get some feedback about this problem from the community...
Chaning the code is easy... but getting feedback or codereview is realy hard.
**physik** wrote:

No Math 2.0 will have a selector to switch the style. 

Currently the situation is as follows:
The PNG mode creates a new latex document for each equation and puts $$ followed by the secured user input followed by $$ into the document body. The resulting dvi image is cropped to that the equation that was rendered centered on a page generated by latex is no longer centered. So it's not centered displaystyle.

The default for Math2.0 intends to keep this layout, but also offers to alternatives "displaystyle" which centers equations and "inline" which uses the inline mode (so the layout fit's into the text).

To convert the old math elements one could write a bot that transforms 
:<math> to math elements with the displaystyle property.
Another bot could search for html math and convert it back to math tags.

I would prefer to keep that two phase approach.
If this option is merged mathjax will behave like all other rendering modes.
(Frédéric an me tested that.)

So the centered equation in MathJax are a bug in the middle of changing from version 1.1 to version 2.0
This is caused by a custom MathJax extension used in the MediaWiki Math Extension, wiki2jax, https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FMath/ff83048597fb256c2579f16ddcd982ef2ae75460/modules%2FMathJax%2Funpacked%2Fextensions%2Fwiki2jax.js. That custom extension contains a simple heuristic (part of the ConvertMath function) to identify display style equations.

> Aligning equations to the left is the desirable format.

IIUC that's simply due to the :<math>...</math> hack which the community adopted because the math extension lacks support for display style -- see  https://bugzilla.wikimedia.org/show_bug.cgi?id=12223. Traditionally, display-style math layout is centered.

I think you opened a discussion about community preference on the WikiProject Math page, too. So perhaps it's best to wait until there's a more definitive response. 

Physikerwelt will correct me, but once Math extension 2.0 is ready, the heuristic would also apply to the default image rendering.

Peter.
*** Bug 61139 has been marked as a duplicate of this bug. ***
What am I previewing?!

In story 1625 we removed preview from VisualEditor but we left the header in place.
https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1625

This looks strange as demonstrated by attachment as nothing as being previewed.

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

**Attached**: {F13434}
Change 115550 merged by jenkins-bot:
Change header message when saving in VE

https://gerrit.wikimedia.org/r/115550
Change 115550 had a related patch set uploaded by JGonera:
Change header message when saving in VE

https://gerrit.wikimedia.org/r/115550
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1677
Screenshot

Steps to reproduce:


1.Open a page with VE
2.Add Sub-heading 1 to sub-heading 4 
3.Save the page
4.Observe the table of contents

Observed Result:
The table of content is appearing without any style and  order

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=Jan28thff

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

**Attached**: {F13292}
This is due to the Typography refresh Beta Feature.
Screenshot

TypeError: OO.ui.IconButtonWidget  is not a constructor appears in production and "Save Page" and "Cancel" button is not appearing inside VE

Page:https://en.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/sandbox?veaction=edit

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

**Attached**: {F13263}
Think this was a deployment issue.
Also, on load appearing TypeError: this.toolbarSaveButton is null
This is happening in FireFox.In Chrome, it is working fine.
Intention:
Insert media file in article using Firefox

Steps to Reproduce:
0. Open up Firefox
1. Go to https://sv.wikipedia.org/wiki/Foo?veaction=edit&uselang=en
2. Click Insert -> Media
3. Write "Foo" in search window
4. Select image
5. Click Insert -> Media again

Actual Results:  
After 3: Image search returns 5*3 images
After 5: Image search returns more images accessible using the vertical scrollbar

Expected Results:  
After 3: Image search returns more images accessible using the vertical scrollbar

Reproducible: Didn't try

This problem becomes more severe since beginners don't realise that there are ever more than 15 possible images, meaning they can usually not find an image they previously identified on Commons.

Works fine in Chrome though.

--------------------------
**Version**: unspecified
**Severity**: normal
I can no longer reproduce it so seems fixed (in Firefox or on our side).

I'll close it as fixed.
This may have been fixed.  I can't reproduce this in Firefox 30.  The first search on a random article produced more images than fit on the screen, and I could get to them with the scrollbar.
(In reply to comment #0)
> 
> Reproducible: Didn't try
> 
Missed this on filing bug. Definitely reproducible.

On a side note I'm running Firefox 26.0
Created attachment 14509
Screencast

**Attached**: {F13230}
In the VE mode

Steps to reproduce:

1.Open the page with VE
2.Insert a reference for a text
3.Add the same reference again somewhere in the page
4.Add the reflist
5.Save the page

Observed Result:
 The repeated reference appears as (a,b) in the reflist in the readmode but as (1.0,1.1) inside VE in Betalabs.

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=Ehat

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

**Attached**: {F13133}
This is because the Parsoid (re)implementation of Cite doesn't support the customisation of the i18n message currently – merging with that issue.

*** This bug has been marked as a duplicate of bug 43235 ***
Created attachment 14500
In the read mode

**Attached**: {F13134}
In alpha, navigate to a non-existent page. You should see the text 'This page doesn't exist. Why not be bold and create it?'. Tap on the pencil edit icon. A cursor should show up in the editable area. Tapping outside of the editable area makes the cursor go away. Knowing where to tap in order to get the cursor back is a bit of a mystery. Perhaps we should make the tappable area for this visible to users.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Eh I must've been using an outdated version; I just tested again to take some screenshots and the editable area now appears very obvious. Closing as WFM.
Arthur not sure I follow. Can you provide some screenshots (sadly VE is broken everywhere for me to test)?
Are you asking for placeholder text?
Does this differ from VisualEditor desktop experience?
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1673
Steps to Reproduce:
1. Open the gallery inserter tool.
2. Don't add any content.
3. Discover that no matter what you do from here, it's going to add a pair of gallery tags that is difficult to select (for removal) in VisualEditor and pointless on the page.



Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: minor
This was fixed a few weeks ago (though if you insert " " it will insert, but… there's no defeating a user intentionally breaking things).
Steps to Reproduce:
1. Click on Insert > Gallery
2. Think "Oops, I meant to click on Transclusion".
3. Try to get out of there without having a gallery added to your page.

Actual Results:  
Click the < button:  it adds a nearly invisible empty gallery.  Press the ESCape key:  it adds a nearly inisible empty gallery.  Click elsewhere:  it adds a nearly invisible empty gallery.

Expected Results:  
I expected a trash can, but I'd prefer an X of the universal "click here to cancel" variety.

Reproducible: Didn't try

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #1)
> This should probably be merged with Bug 60779.

Done (and fixed, yay).

*** This bug has been marked as a duplicate of bug 60779 ***
This should probably be merged with Bug 60779.
I am not sure what I did wrong the last time. I have tried again with a clean VM and visual editor works just fine.
There's also a 'vagrant git-update' command now that attempts to pull all latest changes to git repos.
Thanks, I got the same advice from James_F at #wikimedia-qa. The strange thing is that I have created the vagrant vm today. Shouldn't it have the lates core then?
MediaWiki-Vagrant git-clones MediaWiki core the first time you provision it and leaves it for you to manage thereafter. You can go to the mediawiki/ subdirectory and run 'git pull' to get the latest.
Might need to split this later, and/or add more details, here's what we know now from it.wp users.

Not logged in user, Firefox 26.0, Windows 7 reports the following.
*When you try to edit a template, the template inspector will look empty.
*When you try to add a new template, the inspector won't provide any suggestions for existing ones.
*When you try to choose an option from the 3-bars menu on the right, none will work (nothing will happen clicking on those), except for the "Switch to wikitext" one.

User:Nnvu, Chrome ver. 32.0.1700.102 m, Windows 8.1, Vector reports having the same issues, plus:
*When you click on a wikilink anywhere in the page, instead than getting the box to edit it, you'll be directed to the linked page (the page will even ask you if you're sure you wanna leave).
*When you save the page, it will stay in edit mode. If you click Save again, you'll get both the save dialog and the loading bar that keeps going. (The page results correctly saved from the history, nonetheless.) 

Nnvu could check the console once, and said that this message
*event.returnValue is deprecated. Please use the standard event.preventDefault() instead.
appeared once the editing page was loaded, while
*Uncaught TypeError: Object #<Object> has no method 'apiRequest' VM189:567
is what he got while trying to type inside the template inspector.

VE will work fine for him:
*if he logs out (but while when he's logged-in, disabling all BetaFeatures, all the gadgets and even blanking .js pages won't still help);
*if he uses FF, as a logged-in user.

--------------------------
**Version**: unspecified
**Severity**: normal
This may have been due to some faulty cached code – we saw a similar issue during the aborted deployment of wmf12 to Wikipedias yesterday.
Apparently everything is back to normal now.
I can't reproduce any of this, and other users can't as well.
Two inspector icon together over the math function

Steps to produce:


1.Open the page with VE
2.Add a Math function such as \pi
3.Now add a text before that such as life of pi
4.Now select the text and the math function together
5.Apply link on it
6.Now select the Math function

Observed Result:
The Math inspector icon and the link inspector icon opens together over the math function.

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=Test2chrome&veaction=edit

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

**Attached**: {F12944}
This is expected behaviour.
Similar to bug 52036.
When you blank a page with VE, protection templates like
https://en.wikipedia.org/wiki/Template:Pp-move-indef
or
https://en.wikipedia.org/wiki/Template:Pp-blp
will stay.

https://en.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&diff=prev&oldid=593889831

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52036
*** This bug has been marked as a duplicate of bug 49806 ***
Also categories, interwikis, maybe other stuff that's not editable in the main editor. This sounds like the expected behavior to me.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert a gallery
3.Select the gallery
4.Open a Math Formula window.
5.Type something on the editor

Observed Result:
The math function appears inside gallery .However, if you close the math inspector it will place the math function properly after the gallery not inside it.

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=3rdfebFF&veaction=edit

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

**Attached**: {F12825}
*** This bug has been marked as a duplicate of bug 56644 ***
**Author:** `jhall`

**Description:**
Per a request from James Forrester, we should create a new browser test(s) in the VisualEditor repo that will verify the availability of VisualEditor on production wikis in two categories:

1) Test whether VE loads if invoked on each of the currently ~300 wikis that VisualEditor is deployed to.  This is just checking that ?veaction=edit causes a VE surface to load.

2) Test whether VE's edit tab appears on the ~150 wikis to which is is deployed to as default for all users.  This is checking that the tab for VisualEditor loads for logged-out users.

Some caveats regarding this new test:

1)  The test should not perform any writing actions to the wiki (just loading, no saving).

2) We're probably only looking for a quick verification every week or so, rather than 
​every 12 hours (as with the existing schedule for other VE browser tests).

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60842
**jhall** wrote:

Yep, this one is resolved. Job is up-and-running via CloudBees:

https://wmf.ci.cloudbees.com/view/r-ve/job/VisualEditor-production.wikimedia.org/
Jeff, is this resolved?
Change 112809 merged by jenkins-bot:
[Browser test] Update list of prod wikis to be verified.

https://gerrit.wikimedia.org/r/112809
Change 112809 had a related patch set uploaded by Jhall:
[Browser test] Update list of prod wikis to be verified.

https://gerrit.wikimedia.org/r/112809
**jhall** wrote:

CloudBees/Jenkins job for this task is[1]

[1] https://wmf.ci.cloudbees.com/view/r-ve/job/VisualEditor-production.wikimedia.org/
Change 111142 merged by jenkins-bot:
[Browser test] VisualEditor availability on prod wikis

https://gerrit.wikimedia.org/r/111142
**jhall** wrote:

Re-opening since this is still work-in-progress.
**jhall** wrote:

Setting status back to RESOLVED since I'm not quite done with this just yet...
Change 111142 had a related patch set uploaded by Jhall:
[Browser test] WIP Test VisualEditor availability on production wikis

https://gerrit.wikimedia.org/r/111142
**jhall** wrote:

From James: "The list of 300 wikis is[1] – though that contains at the bottom 4 private wikis that shouldn't be tested."

[1] http://noc.wikimedia.org/conf/highlight.php?file=visualeditor.dblist
screenshot of error

If I have {{archives}} or {{Talk header}} in the page header area, Flow gives this error (screenshot):

The error message received was: Exception Caught: ID searchbox already defined

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

**Attached**: {F13408}
Change 111224 merged by jenkins-bot:
Don't error out on duplicate id's

https://gerrit.wikimedia.org/r/111224
I think the "id=searchbox" is coming from https://www.mediawiki.org/wiki/Extension:InputBox and there are frequently more than one searchbox per page so that does need to be solved.

aha! bug 11777 (Multiple inputboxes make page invalid due to repetitive similar id) I don't know if that bug needs to be poked, with this fresh example? It's been silent since Sept 2012.
Change 111224 had a related patch set uploaded by EBernhardson:
Don't error out on duplicate id's

https://gerrit.wikimedia.org/r/111224
*** Bug 60816 has been marked as a duplicate of this bug. ***
Parsoid is being strict about disallowing the duplicate element IDs in HTML (bug 60816).

But these templates should not be causing invalid HTML output by specifying id=searchbox twice.  Somewhere besides {{archives |search=yes}} there must be another id=searchbox; I tried adding the template wikitext to [[wp:Wikipedia_talk:Flow/Developer_test_page]] but couldn't reproduce it. Assuming that's the problem these templates should use a unique ID, maybe we can alert their authors. Any special styling or behavior they're getting should be due to classes, not an ID.

For grins, you could try to add the problematic templates in VisualEditor.
Created attachment 14474
screenshot 2

After reading the error in the preview (screenshot 1), I removed the {{archives}} box, and hit save. That resulted in this: (screenshot 2)

So I re-edited the header to remove {{Talk header}}. Once I hit save for that, it was still displaying the same error, until I did shift-F5 (hard-refresh).

**Attached**: {F13410}
screenshot

Steps to reproduce:

1.Open a page with Ve
2.Select a text
3.Apply Superscript
4.Apply Strikethrough
5.Apply Underline
6.Unselect superscript  
7.Make it superscript again (Observe that strikethrough is now below the text, this is one issue)
8.Unselect Underline
9.Make it underline again

Observed Result
The Strikethrough and Underline gets overlapped for a superscript text

**This is a FireFox only bug.Works perfectly on Chrome**


Test Environment: https://test2.wikipedia.org/
Browser:  FF 25
OS: MAC OS X 10. 8. 5 
https://test2.wikipedia.org/w/index.php?title=3rdfebFF&veaction=edit

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

**Attached**: {F13396}
I don't believe this is anything other than Firefox being difficult…
The floating palette for the special character tool is annoyingly out of reach if your cursor is at the bottom of your screen.  You have to scroll down (sometimes a lot) to reach the character that you want.  It's also narrow, which limits the number of characters that can be seen at once.

It should be replaced with a fixed, full-width tool that is attached to the main toolbar.  This allows more characters to be displayed at once and is always visible, no matter where you are typing.

This might also be convenient way to address the problems in bug 60657.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Fixed by the "Special Characters" insertion redesign (can be tested already on http://en.wikipedia.beta.wmflabs.org )
> The floating palette for the special character tool is annoyingly out of reach if your cursor is at the bottom of your screen. You have to scroll down (sometimes a lot) to reach the character that you want.

@Whatamidoing-WMF: Is this still valid?
Being at the very bottom in Firefox 36 with my cursor, trying to insert a special character the view scrolls automatically down. See screenshot:

{F55250}
Is this still valid? What about T78038?
http://en.m.wikipedia.beta.wmflabs.org/w/api.php?format=json&action=visualeditor&paction=parse&page=Selenium_Edit_Test

Any idea why this request ends up with the response:
{"servedby":"deployment-apache32","error":{"code":"parsoidserver-http-bad-status","info":"404"}}

It prevents VisualEditor from loading on mobile...

--------------------------
**Version**: unspecified
**Severity**: normal
I'm closing this bug as worksforme, as the underlying API outage has since been fixed. Bug 58390 tracks the error code issue.
The API issues were probably the internal LVS failure today, caused by a networking configuration error. See Mark's mail titled "Outage report: LVS outage February 3, 2013" on the ops list.
This page loads for me: http://parsoid-lb.eqiad.wikimedia.org/itwiki/Utente%3ABaruneju%2Fsandbox2?oldid=63854985

Sometimes issues in the MW API are misreported as 404s on our end, so maybe this was a transient API failure. The misleading error reporting is tracked in bug 58390.
The problem is not limited to the mobile version, it also happens on the Web using both Firefox and Chrome, both Monobook and Vector.
Example response: (on it.wiki user sandbox, but it also applies to en.wiki NS:0)

{"servedby":"mw1121","error":{"code":"parsoidserver-http-timed-out","info":"http://10.2.2.29/itwiki/Utente%3ABaruneju%2Fsandbox2?oldid=63854985"}}
Screenshot attached

Steps to reproduce:

1.Open a page with VE which contains an image
2.Now select the image
3.Resize the window (Not the image)

Observed Result:


The image resize handle gets displaced


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**: {F13198}
*** This bug has been marked as a duplicate of bug 55789 ***
(Tested on Firefox 26, Windows Vista)
Steps to reproduce
- Edit the [[Jefferson Davis County Courthouse (Mississippi)]] page using the visual editor.
- Click the image present in the article.
- Press "Insert => Gallery".

The result of this is that the visual editor will break to a point where one cannot use it without entirely reloading the page. For example:
- Pressing "Insert => Gallery" again yields no reaction.
- Pressing "Insert => Special Character" results in a window that seems to be a hybrid of the gallery and character insertion tool.
- Clicking any page link in the article will no longer result in the usual "Edit Link" popup. Using the link button on the interface will result in a hybrid version of the link window and the gallery window.

Interestingly, there are no errors in Firefox's error console.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows Vista
**Platform**: PC
(For future reference, please report only one issue per bug report. Thank you!)
*** This bug has been marked as a duplicate of bug 60502 ***
Screenshot

Steps to reproduce:


1.Create a page on Betalabs
2.Add some content and save it
3.Reopen the page with VE

Observed Result:
Content of some article is showing up instead of my own edited content


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/31st_january

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F13186}
Verified the fix on Betalabs.
The puppet agent didn't seem to be running on the parsoid host in beta labs, and after starting that Parsoid was not restarted to reflect the the changes. Fixed that manually, and verified fixed at http://en.wikipedia.beta.wmflabs.org/wiki/0.6884344289426402?veaction=edit.
Change 111350 merged by Alexandros Kosiaris:
Bug 60694: Make the config file path configurable

https://gerrit.wikimedia.org/r/111350
Change 111350 had a related patch set uploaded by GWicke:
Bug 60694: Make the config file path configurable

https://gerrit.wikimedia.org/r/111350
We need this on beta labs at the earliest opportunity.  I raised the importance.
https://gerrit.wikimedia.org/r/#/c/110666/ creates a Debian package and makes the config file path configurable in /etc/defaults/mediawiki-parsoid. We might still want to fix this in puppet temporarily until we move to deb-based installs.
Another symptom of this is if you add or edit a post to a Flow board on betalabs (e.g. http://en.wikipedia.beta.wmflabs.org/wiki/Talk:Flow_QA ) and transclude a page with {{:Article name }}, it pulls in the page from enwiki.
On deployment-parsoid2 in /var/log/parsoid/parsoid.log

{ [Error: Cannot find module '/srv/deployment/parsoid/conf/wmf/localsettings.js'] code: 'MODULE_NOT_FOUND' }

There is no conf directory but there is a file /srv/deployment/parsoid/localsettings.js which is described in puppet:

 manifests/role/parsoid.pp:    file { '/srv/deployment/parsoid/localsettings.js':

I introduced it on Jan 2 with https://gerrit.wikimedia.org/r/#/c/104938/


The upstart configuration I wrote ( /etc/init/parsoid.conf ) was pointing to it but now points to ../conf/wmf/localsettings.js.

So I guess the easiest path is to use an env variable such as PARSOID_CONF, set it in /etc/default/parsoid and make it vary in the puppet configuration.
A bit more investigation shows that VE is sending the right oldid.

I think this is caused by Parsoid not finding its config file in the deploy repo. In the production upstart config we are now passing the explicit path to a config file to parsoid, which is checked into conf/wmf/localsettings.js in the deploy repo. Beta labs might still rely on localsettings.js being in src/api, which will no longer work.

I think we'll need to make the config path configurable in the upstart file, and set a different path (ideally conf/wmf-beta or the like) for betalabs.
Note that this could also be VE sending the wrong oldid, as that will always take precedence over the page name.
This is unlikely to be related to bug 60372, as a) the oldid is sent, and b) it only happened sometimes under high request loads.

This does not happen in production (running Parsoid master right now). I'm suspecting a configuration issue in betalabs.
It seems to be quite easy to consistently reproduce. Just click 'random article' and then load the VisualEditor. I get the contents of a different article 100% of the time. The really weird thing is that the articles that are being loaded don't seem to even exist on Beta Labs.
Does beta.wmflabs.org have latest parsoid master? Related is bug 60372 which was fixed in https://gerrit.wikimedia.org/r/#/c/110233/
I noticed this today at
http://en.m.wikipedia.beta.wmflabs.org/wiki/0.07511468210381089

Whenever I load VisualEditor, it loads the allergy article instead.
**jhall** wrote:

I've also been seeing this behavior in beta labs today, although it's been difficult to consistently reproduce.  I've seen it much more frequently with the automated browser tests than I have with manual testing.
Now, Uncaught TypeError: Cannot read property 'status' of null is appearing while trying to open VE in betalabs
Intention:
Add special characters

Steps to Reproduce:
If any of the following that happen to rely on special characters:

* A template
* A parameter name in said template
* Data for parameter (e.g., the name of a person or place)
* A link to another page
* A category
* A media item (e.g., image) that you can't find otherwise
* An image or a caption in a image gallery
* An edit summary

then they cannot be successfully used in VisualEditor.  Probably there are uses for it in the Mathematics Formulae tool as well.  

Basically, if you have a cursor for typing anything, anywhere in the entire VisualEditor interface, then you need access to the special character inserter.




Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: enhancement
Is that title better, @Jdforrester-WMF?
I could write it up as a whole series of bugs, if you'd like:  Make it
possible to access VisualEditor's special character tool when adding a
template (ie., typing the name of the template).  Make it possible to
access VisualEditor's special character tool when filling in parameter data
for templates.  Make it possible to access VisualEditor's special character
tool when editing citations.  Make it possible to access VisualEditor's
special character tool when searching for media.  Make it possible to
access VisualEditor's special character tool when typing a file name or
caption in a gallery.  Make it possible to access VisualEditor's special
character tool when writing an edit summary.  Make it possible to access
VisualEditor's special character tool when adding a category (including a
redlink category).
This isn't a bug. It isn't a task. It isn't asking for anything. It doesn't have an actionable element at all.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Now add an image to the page
3.Now add a template infobox-country or any other infobox template like infobox-company
4.Save the page
5.Open the page again.
6.Now Select the template 

Observed Result:

The template edit icon is appearing over the image now


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/Image_after_template

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

**Attached**: {F13094}
Think I'm going to merge this with bug 51548.

*** This bug has been marked as a duplicate of bug 51548 ***
Screenshot

Steps to reproduce:

1.Insert and image 
2.Go to Media Settings

Observed Result:

General Settings and Advanced Settings button tags are missing on Media Settings widget

See the screenshot attached.

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

**Attached**: {F13065}
All the labels and messages are appearing now in test2 and mediawiki
Created attachment 14420
Screenshot

**Attached**: {F13066}
Infact all the textbox name and heading of the advanced dialog Settings page is missing
See the second screenshot
Screenshot attached

Steps to reproduce;


1.Open a page with VE
2.Add a bullet list or a numbered list
3.Keep on pressing the Add or decrease indentation  button for a bullet point 


Observed Result:
"Confirm Navigation?" dialog box are showing up .

See the screenshot attached.

Test Environment: mw.org
Browser: Chrome Version 26.0.1410.65 & FF25
OS: MAC OS X 10. 8. 5 
Page:https://www.mediawiki.org/w/index.php?title=User:RYasmeen_(WMF)&veaction=edit

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

**Attached**: {F13048}
This now seems to be fixed!
Screenshot

Steps to reproduce:



1.Open any page with VE in test 2
2.Add some content and Save page

Observed Result:
"Review your changes" and "Save Page" button layout missing in test2

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

**Attached**: {F13039}
Not happening anymore
It would make sense, since all repositories (except VisualEditor) have Selenium tests already there:

https://github.com/wikimedia/mediawiki-selenium#links

--------------------------
**Version**: unspecified
**Severity**: normal
Change 111998 merged by Cmcmahon:
Moved Selenium tests from root folder of qa/browsertests repository to tests/browser folder

https://gerrit.wikimedia.org/r/111998
Change 111997 merged by jenkins-bot:
Moved tests from root folder to tests/browser folder

https://gerrit.wikimedia.org/r/111997
Change 111998 had a related patch set uploaded by Zfilipin:
Moved Selenium tests from root folder of qa/browsertests repository to tests/browser folder

https://gerrit.wikimedia.org/r/111998
Change 111997 had a related patch set uploaded by Zfilipin:
Moved tests from root folder to tests/browser folder

https://gerrit.wikimedia.org/r/111997
Chris, Jeff, what do you think?

It would simplify our documentation and also Jenkins job template[1].

We could replace

if [ -d "${FOLDER}" ]; then cd ${FOLDER}; fi

with just

cd ${FOLDER}

1: https://github.com/wikimedia/mediawiki-selenium/blob/master/docs/template.md#jelly-based-transformation
Screenshot

Cannot load any page on Betalabs.Getting the following error:

6ca85571] /wiki/29th_January Exception from line 84 of /data/project/apache/common-local/php-master/extensions/Wikidata/extensions/Wikibase/repo/Wikibase.hooks.php: Wikibase: Incomplete configuration: $wgWBRepoSettings["entityNamespaces"] has to be set to an array mapping content model IDs to namespace IDs. See ExampleSettings.php for details and examples.

Backtrace:

#0 [internal function]: Wikibase\RepoHooks::onSetupAfterCache()
#1 /data/project/apache/common-local/php-master/includes/Hooks.php(206): call_user_func_array(string, array)
#2 /data/project/apache/common-local/php-master/includes/GlobalFunctions.php(3976): Hooks::run(string, array, NULL)
#3 /data/project/apache/common-local/php-master/includes/Setup.php(520): wfRunHooks(string)
#4 /data/project/apache/common-local/php-master/includes/WebStart.php(153): require_once(string)
#5 /data/project/apache/common-local/php-master/index.php(46): require(string)
#6 /data/project/apache/common-local/w/index.php(3): require(string)
#7 {main}

--------------------------
**Version**: wmf-deployment
**Severity**: normal

**Attached**: {F12982}
*** Bug 60612 has been marked as a duplicate of this bug. ***
Thanks.Verified the fix.
Fixed, will propagate to labs within the next 30 minutes, probably a bit earlier
Being worked on.
The VisualEditor template editor works on infobox templates like https://en.wikipedia.org/wiki/Template:Infobox_NRHP . On templates like https://en.wikipedia.org/wiki/Template:NRHP_header and https://en.wikipedia.org/wiki/Template:NRHP_row it doesn't work (yet) probably because these templates generate tables. We have a lot of these templates in a lot of different languages, see for example https://en.wikipedia.org/wiki/Category:Monument_list_templates . It would be nice if VE could be used to edit these templates.

--------------------------
**Version**: unspecified
**Severity**: normal
As @Etonkovidova said, it is possible (though not user-friendly) to do this. I'm tentatively closing; if anyone has specific ideas for how to make this more user friendly, feel free to open another task.
The template content(and fields) can be edited via Transclusion or in Edit Source. 
Checked in production  {{NRHP row}} , {NRHP header}}- in VE in Transclusion box the templates can be edited.
--------------------------
**Version**: unspecified
**Severity**: normal
I can't reproduce this now – presumably now fixed by not allowing empty galleries.
Steps to reproduce:

1.Open a page with VE
2.Add a numbered list/bullet list
3.Add an empty gallery as an item in the list.
4.Now place the cursor in the last bullet/numbered point
5.Press Enter twice

Observed Result:

It keeps on adding new bullets or numbered points in the list even after hitting return twice.

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=29th_January&veaction=edit
Intention:
Add a special character.

Steps to Reproduce:
1. Open a page in VisualEditor.  Don't click anywhere in it.

2. Go to Insert > Special characters to open the Special charater inserter tool.

3. Click on a character (or several).

Actual Results:  
Nothing is added, but the "Save" button lights up.  You can't use it, though.

If you click elsewhere, the tool disappears, but nothing else happens.  "Save" is still green, but you still can't use it.

If you go back into the special character tool and add a new special character, then all the original ones appear at the start of the page, but the tool's dialog box is still open.  

If you then cancel (to get rid of the box), Bad Things happen, including snowmen and partial duplication of the page.  You still can't save.


Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: normal
This has now been "fixed" by the simple effort of making this route impossible; tools are now disabled if there isn't an active surface insertion point.
When launching VE in Firefox, it throws the following error:
'mozMatchesSelector' called on an object that does not implement interface

Happens on beta labs and local master.

--------------------------
**Version**: unspecified
**Severity**: trivial
Can't reproduce this now (Firefox 33.1 with Firebug)…
Actually, it's not a JS error, but a breakpoint being triggered in Firebug.
Happens in Firefox 26 and latest nightly build.

Although it's not that helpful for debugging, the error is thrown from line 5303 of jquery.js:
var ret = matches.call( elem, expr );
When you click "Review your changes" in the save dialog, it used to grow to accommodate the fact that diffs tend to be bigger than the regular save dialog contents. However, it stopped doing this a while ago.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 116897 merged by jenkins-bot:
Update VE core submodule to master (ab70193)

https://gerrit.wikimedia.org/r/116897
Change 116897 had a related patch set uploaded by Catrope:
Update VE core submodule to 4513d9c21a9502b2fc2d9b6739c2dac0af21e03e

https://gerrit.wikimedia.org/r/116897
Redirects are normal wiki pages of main ns. So why not should allow to edit them with VisualEditor? For example in cases, I remove redirect and want edit a page.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to Juan de Vojníkov from comment #2)
> Why you mareked it as duplicate. 

Because it is the same request as bug 50878.

> I can see the other bug takes care of en.w.

No. https://gerrit.wikimedia.org/r/#/c/95213/ is generic. It's code in VisualEditor itself, not in server configuration.
(In reply to James Forrester from comment #1)
> 
%%%> *** This bug has been marked as a duplicate of bug 50878 ***%%%

Why you mareked it as duplicate. I can see the other bug takes care of en.w. Here I am talking about cs.w and potetionally every other.
*** This bug has been marked as a duplicate of bug 50878 ***
When I loaded [[mw:Mobile wikitext editing]] recently as a logged-in user, the page looked completely blank. This may be an issue in VisualEditor, I'm not sure. Purging the page fixed the issue.

My suspicion is that Parsoid somehow returned blank content. Unfortunately I'm unable to reproduce this issue.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/Mobile_wikitext_editing
Without a way to reproduce this or some kind of error log we can't really do anything here. There have also not been any other reports about blank pages, so closing this bug as worksforme.
This is the Parsoid output: http://parsoid-lb.eqiad.wikimedia.org/mediawikiwiki/Mobile_wikitext_editing?oldid=889921

Client-side VE issues typically result in JS errors in the browser JS console. Could you check whether that is the case?
I'm on 1.23wmf10 and the master build of both VisualEditor and Parsoid. I can insert and resize an image just fine, but clicking on the icon in the upper right performs no action. I discovered the following message:

Uncaught TypeError: undefined is not a function 

load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cdata%2Cicons-vector%2Cmwcore%2Cmwgalle…:344
VeUiMediaSizeWidget load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cdata%2Cicons-vector%2Cmwcore%2Cmwgalle…:344
ve.ui.MWMediaEditDialog.initialize load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cdata%2Cicons-vector%2Cmwcore%2Cmwgalle…:528
oo.EventEmitter.emit load.php?debug=false&lang=en&modules=ext.visualEditor.base%2Cmediawiki%2CviewPageTarget%7Cjquery.pl…:112
(anonymous function) load.php?debug=false&lang=en&modules=ext.visualEditor.base%2Cmediawiki%2CviewPageTarget%7Cjquery.pl…:125
pollExternalStylesheets load.php?debug=false&lang=en&modules=ext.visualEditor.base%2Cmediawiki%2CviewPageTarget%7Cjquery.pl…:124

--------------------------
**Version**: unspecified
**Severity**: normal
Updating to a more recent build of VisualEditor resolves this issue.
Intention:
<References /> automatically updates as you edit a page.  The {{Reflist}} template does not.  Can the handling of the template be improved so that refs inside the {{ref list}} template also update automatically?




Reproducible: Didn't try

--------------------------
**Version**: unspecified
**Severity**: enhancement
This is a confusing response. {{reflist}} is used all over the place, often by preference.

A blank "wontfix" doesn't address the reasons for this statement, and they do in fact need addressing. Are you planning to systematically remove {{reflist}}, for example? Clarification is needed on this point.
(In reply to comment #0)
> Intention:
> <References /> automatically updates as you edit a page.  The {{Reflist}}
> template does not.  Can the handling of the template be improved so that refs
> inside the {{ref list}} template also update automatically?

Unfortunately, no, we can't.

This is one of the (many) reasons why we discourage people from using {{Reflist}}.
screenshot

Steps to reproduce:

1.Open a page which contains image with VE
2.Add a large caption to the image by going to Media Settings
3.Click on "Apply Changes"
4.Attempt to resize the image

Observed Result:
The image resize handle is not at the most bottom-left corner of the blue highlighted selection box around the image but at the corner of the image.
It looks a bit odd to have it somewhere in the middle of the border when it has a large caption.
Probably ,having it at the corner most corner will look better.

See the screenshot attached.

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

**Attached**: {F13020}
This is correct as you are resizing the image, not the caption.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert a template like Cite web
3.Select the parameter URL
4.Add a value in this field like http://yahoo.com
5.Now select this text from right to left
6.Mouse up just a little beyond the borderline between left panel and right panel

Observed Result:

The parameter on the right panel gets switched to the next parameter which is "Source Title"

See the screenshot attached.

Test Environment: https://test2.wikipedia.org/
Browser: Chrome Version 26.0.1410.65 
Page:https://test2.wikipedia.org/w/index.php?title=22nd_january&veaction=edit

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

**Attached**: {F13019}
I don't see any oddities now… marking as such.
I'm not quite sure what was happening here, but is this bug still valid?
Seen as of Jan 22

As a logged in user, edit any page on http://en.wikipedia.beta.wmflabs.org/ with VisualEditor. 

User sees the ve-init-mw-viewPageTarget-loading bars moving, but VE never arrives. 

Checked in Chrome and Firefox

--------------------------
**Version**: unspecified
**Severity**: major
VisualEditor is working for me on beta.  I noticed some files belonged to root user, I have changed back to be owned by mwdeploy:mwdeploy.  That might have caused some update issue since the update job runs as mwdeploy.
(In reply to comment #2)
> (In reply to comment #1)
> > Is the version of VE referenced by the mediawiki/extensions meta repo?
> 
> http://en.wikipedia.beta.wmflabs.org/wiki/Special:Version says it's got VE
> 37e90c1 from yesterday – https://gerrit.wikimedia.org/r/#/c/108713/ – which
> isn't the latest version.

That is bug 49846 (VE not being automatically updated on beta) which is now fixed.
Antoine, is this tracked already?
(In reply to comment #1)
> Is the version of VE referenced by the mediawiki/extensions meta repo?

http://en.wikipedia.beta.wmflabs.org/wiki/Special:Version says it's got VE 37e90c1 from yesterday – https://gerrit.wikimedia.org/r/#/c/108713/ – which isn't the latest version.
Is the version of VE referenced by the mediawiki/extensions meta repo?
Screenshot

Steps to reproduce:

1.Open a page with VE which has a gallery in it
2.Add another gallery code just after the already existing one
3.Save the page
4.Reopen the page with VE

Observed Result
A return arrow appears between the two galleries

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/Thedomtest?veaction=edit

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

**Attached**: {F12925}
This also looks to have been fixed, probably by Parsoid.
Screenshot

Steps to reproduce:

1.Open a page with VE which has for example the following gallery code:
<gallery>
File:Joo Chiat Place.jpg|Item 1
File:Joo Chiat Place.jpg|a link to [[Help:Contents]]
File:Joo Chiat Place.jpg
File:Joo Chiat Place.jpg|alt=An example image. It has flowers
File:Joo Chiat Place.jpg| ''italic caption''
</gallery>

2.Click on the gallery and open it with the new gallery inspector

Observed Result:
There is an extra newline inserted at the beginning of gallery code inside the inspector.


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/Thedomtest?veaction=edit

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

**Attached**: {F12923}
No longer occurs, probably fixed a long time ago.

{F128164}
NemesisIII reports that when VEditing a page, existing reference numbers do not appear as "superscripted" as they should.
See section "projet" of https://commons.wikimedia.org/wiki/File:Bug_%C3%A9diteur_visuel_affichage_appels_de_r%C3%A9f%C3%A9rence.png (from https://fr.wikipedia.org/wiki/Avenue_Foch?veaction=edit ).
Number 3 and 4 are existing references, and they are very low. Number 5 instead is a newly added reference, which displays ok (note that this reference does not really exist in the article, it was added just to take the screenshot).

According to my tests, only fr.wp seems affected. I was able to reproduce this with
*Firefox (both Vector and Monobook)
*Chrome (Monobook)
*Opera (while logged out).

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed ages ago, I think.
Updating the link, https://fr.wikipedia.org/wiki/Avenue_Foch_(Paris)?veaction=edit .
**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

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

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
*** This bug has been marked as a duplicate of bug 60188 ***
Single node

Steps to reproduce:


1.Open a page with VE which has image inside it
2.Select the image

Observed Result:
There is just one node appearing on the bottom-left corner of the image to resize it,previously there used to four nodes to drag.


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**: normal

**Attached**: {F13171}
Not a bug; intentional behaviour change. :-)
In edit source mode

Steps to reproduce:

1.Open a page with VE which has some references and <references/> tag added 
2.Add an image in the page
3.Go to media settings and add a caption with reference inside it
4.Save the page

Observed Result:
An error appears in the read mode :"Cite error: <ref> tags exist, but no <references/> tag was found "

Also in the resulting wikitext, the reference inside image did not get added in the <references/> section



Although if you go to Edit mode the reference inside the image is correctly showing up in the <references/> tag.

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

See the screenshot attached

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

**Attached**: {F13149}
This is because the <references /> was before the <ref>.

Yay MediaWiki. :-(

Fixed: 

https://test2.wikipedia.org/w/index.php?title=Wmf11&oldid=71790

vs.

https://test2.wikipedia.org/w/index.php?title=Wmf11&oldid=71598
Created attachment 14327
In Edit mode

**Attached**: {F13150}
The i18n messages for the Toolbar insert button and the subsequent special character tree does not seem to sync with translated messages at Translatewiki. 
For some reason French and German gives correct messages but others give English default messages.

The strings are:
visualeditor-toolbar-insert
visualeditor-specialcharacter-button-tooltip
visualeditor-specialcharacterinspector-title
visualeditor-specialcharinspector-characterlist-insert

Possibly related to them being marked as non-translatable on translatewiki.

See annotated screenshot at:
https://commons.wikimedia.org/wiki/File:VisualEditorBugInsert.png

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to Lokal_Profil from comment #7)
> Whatever was done seems to have worked. Thanks (closing)

Yes, that was https://gerrit.wikimedia.org/r/#/c/109420/ (+ https://gerrit.wikimedia.org/r/#/c/112650/ ).
Whatever was done seems to have worked. Thanks (closing)
(In reply to comment #5)
> These translations are still not being pushed through, is there anything else
> which might have caused this?
> 
> Could translations which were done whilst the messages were "untranslatable"
> somehow have not triggered an updated translation?

Opening again as this has not gotten fixed. See e.g. https://sv.wikipedia.org/wiki/Foo?veaction=edit&uselang=sv where "Insert" is still displayed as well as the other messages. To the list above can be added

Visualeditor-mwgalleryinspector-title
These translations are still not being pushed through, is there anything else which might have caused this?

Could translations which were done whilst the messages were "untranslatable" somehow have not triggered an updated translation?
Change 109420 had a related patch set uploaded by Jforrester:
Re-enable support for two VisualEditor related groups

https://gerrit.wikimedia.org/r/109420
Change 107541 abandoned by Jforrester:
Add support for moved VisualEditor core

Reason:
Done instead in Ia580491d9b329200d3def5425d887f0062e0a1a2.

https://gerrit.wikimedia.org/r/107541
Change 107541 had a related patch set uploaded by Jforrester:
Add support for moved VisualEditor core

https://gerrit.wikimedia.org/r/107541
Yeah, this is because TranslateWiki.Net removed tracking of VisualEditor's core messages (rather than the MW-specific ones) when the repo was split, and haven't yet added them back. Sorry about this!
**Author:** `swalling`

**Description:**
Screenshot on enwiki

Detection of the 'edit' tab and section edit links is broken currently, probably due to https://gerrit.wikimedia.org/r/#/c/97701/ change in VE.

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

**Attached**: {F13059}
Change 107735 merged by jenkins-bot:
Change how presence of VisualEditor is determined

https://gerrit.wikimedia.org/r/107735
Change 107734 merged by jenkins-bot:
Change how presence of VisualEditor is determined

https://gerrit.wikimedia.org/r/107734
Change 107735 had a related patch set uploaded by Mattflaschen:
Change how presence of VisualEditor is determined

https://gerrit.wikimedia.org/r/107735
Change 107734 had a related patch set uploaded by Mattflaschen:
Change how presence of VisualEditor is determined

https://gerrit.wikimedia.org/r/107734
Change 107631 merged by jenkins-bot:
Change how presence of VisualEditor is determined

https://gerrit.wikimedia.org/r/107631
Change 107631 had a related patch set uploaded by Mattflaschen:
Change how presence of VisualEditor is determined

https://gerrit.wikimedia.org/r/107631
Specifically, VE's isAvailable used to imply that the preference was also enabled, meaning the VE edit tab would be there.

Now, isAvailable doesn't say anything about the preference. So if you have VE disabled, the tab will be missing, so it can't attach to it, and shows in the center like that.
https://en.m.wikipedia.org/wiki/Lost_Coon_Lake?title=Lost_Coon_Lake&campaign=mobile-mainpage-keepgoing-links&mobileaction=alpha#editor/0

Expected:
The Keep Going overlay should appear below the VE overlay.

--------------------------
**Version**: unspecified
**Severity**: normal
Seems to have fixed itself.
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1627
Hi
If I apply a category to a page using VE, it generates an incorrect code (for example %2520 instead of _ I think) and it has only one square character.

Latest git of VE.

--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: http://wiki.mc128k.info/index.php/Test
Upgraded to latest git for MW, VE and Parsoid, now it works! Thanks!
I'm sorry for the delay. Tried upgrading to latest and I get the same error. See the link.
http://wiki.mc128k.info/index.php/Test
Marking as "WORKSFORME"; feel free to re-open if you have more details.
Can you give some more details? It appears to be working locally, and on WMF production (see e.g. https://www.mediawiki.org/w/index.php?title=VisualEditor:Test&diff=885698&oldid=885622 for it working).

A screenshot or copy-paste of your resultant wikitext (and ideally a dump of the HTML that got sent to Parsoid) would be hugely helpful.
**Author:** `kwang`

**Description:**
If you are in the keep going campaign and you are in alpha, when you click edit you don't get VE you get the wikitext editor.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 108990 merged by jenkins-bot:
Make KeepGoing/toast confirmation run when editing using VE

https://gerrit.wikimedia.org/r/108990
Change 109436 merged by jenkins-bot:
QA: Define expected behaviour for VisualEditor overlay for bug 59932

https://gerrit.wikimedia.org/r/109436
Change 109436 had a related patch set uploaded by Jdlrobson:
QA: Define expected behaviour for VisualEditor overlay for bug 59932

https://gerrit.wikimedia.org/r/109436
**kwang** wrote:

Unable to reproduce. I think this might actually have been the portrait landscape bug and I got confused.
**kwang** wrote:

This was originally if I launched keep going from the main page I was unable to get visual editor to launch. But this seems to be fixed now, or I am unable to reproduce anymore.
Change 108990 had a related patch set uploaded by Jdlrobson:
Make KeepGoing run when editing using VE

https://gerrit.wikimedia.org/r/108990
I don't understand this bug. You can't currently enter the KeepGoing campaign via VE. Kenan could you explain what the exact problem is here?

Is the request that when I edit for the first time via VisualEditor it starts the Keep Going campaign to edit?
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1614
Screenshot in the Edit source mode

Steps to reproduce:

1.Open a page with VE 
2.Insert any image
3.Resize the image to specific size.For example:587x687px
4.Save the page
5.Open the page in Edit Source mode


Observed Result:
The Edit source mode shows the size of the image differently as 587x411

Test Environment: mw.org
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5

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

**Attached**: {F12636}
After checking with the Parsoid team, this isn't a bug -- Parsoid serializes a square bounding box (max sizes) which is why the wikistring is different than the actual image size (that preserves aspect ratio).
Created attachment 14285
Size in the tooltip of VE

**Attached**: {F12637}
Intention:
If I understand it correctly, the user defines a link target for text. This seems to highlight/mark the text for that user, so if the user then enters a space as the next letter as s/he wants to continue writing, this will overwrite the marked text. Says this happens with Safari 6.1.1 and Firefox 26.0 on OS X 10.7.5 and 10.8.5 (all four combinations). Haven't tried other browsers/operating systems. 

Steps to Reproduce:
1. Tried but could not duplicate this problem in Firefox 26 or Chrome 31
2. 
3. 



Reproducible: Couldn't Reproduce

Andre says: https://bugzilla.wikimedia.org/show_bug.cgi?id=57716 item 2# feels slightly related but not exactly the same.

--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://sv.wikipedia.org/wiki/Wikipedia:VisualEditor/%C3%85terkoppling#L.C3.A4nkad_text_blir_markerad_och_f.C3.B6rsvinner
I don't know about this; this is intentional behaviour to give users the ability to do something further with their selection (often laboriously-made) if they want to, especially for those primarily using keyboard input.

When you click away from the inspector, we move the cursor to where you clicked it. However, if you're using keyboard driving, you might want to adjust the item you just selected and did an action on, e.g. adding bold/etc. styling.

In general, we've designed the editor so that removing the selection using the keyboard needs you to destroy the selection (type over it) or move the cursor with the cursor keys. I don't think we want to move away from this model, so I'm going to mark this as WONTFIX, but I'd be happy to discuss further if people think this is a mistake.
Thanks, NH. :) Actually, I was able to reproduce it this time! The text that was to be linked was selected or highlighted so that it could be linked. Pressing enter the first time makes the linking box/window/popup go away. Pressing enter a second time makes the newly-linked text go away. The work around is to click with cursor elsewhere on the page so as to deselect/unhighlight the text. But if this can be fixed code wise, would save everyone one additional click. HTH. :)
**nh.wikipedia** wrote:

Anna Koval got it right, but I'll clarify anyway:

1) Open some page for editing.
2) Type a word that you wish to link to another page.
3) Press Command-K or click at the link tool button.
4) Select or type the name of the target page and press enter twice.
5) When you continue to type the linked word disappears.

If you, at step (4), click at the "Close" button in the link dialog instead of using the Enter key to complete, this does not happen.
For the records: From https://sv.wikipedia.org/wiki/Wikipedia:VisualEditor/%C3%85terkoppling#L.C3.A4nkad_text_blir_markerad_och_f.C3.B6rsvinner

I cannot reproduce in Firefox 26 on Fedora Linux 20 on cs.wikipedia.org - after clicking the "Close" button on the left in the "Link target" dialog the link text is not highlighted for me.
In read mode

Steps to reproduce:

1.Open a page with VE
2.Add few images to the page
3.Save the Page
4.Now click on any of the newly added images 
5.Press back button from the browser to go back to the article

Observed Result:
The images in the page gets disappeared in the readmode though opening the VE shows up all the images.

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/Wmf10


See the screenshots attached.

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

**Attached**: {F12534}
Cannot reproduce it now.
This is occurring in mw.org too for adding any image.
Slight modification in the steps:

1.Open a page with VE
2.Add a heading/subheading to the page
3.Place the cursor right after the heading text
4.Insert an image
5.Save the page
6.Now click on any of the newly added images 
7.Press back button from the browser to go back to the article

Observed Result:
The newly added image and the heading is not showing up in the readmode.
Created attachment 14276
In edit mode

**Attached**: {F12535}
Section heading got moved below the link of heading

Steps to reproduce:

1.Open a page with VE which has a section with section heading
2.Cut the whole section with its heading
3.Paste it back in the same position

Observed Result:
The heading of the section gets placed under the heading line with the contect

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/9th_jan?veaction=edit

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

**Attached**: {F12519}
Seems to be l10n cache related, but is fixed
Intention:
Cut the appendices from an article (to see if they were the source of a problem), and then put them back (because they weren't)

Steps to Reproduce:
1. Select several sections from the end of an article, all the way to the end of the page.

2. Command-x to cut.

3. Command-v to paste.

Actual Results:  
The section headings were duplicated, but the content was not.  The result is two sets of section headings, the first of which is empty.  

https://en.wikipedia.org/w/index.php?title=User%3AEdgepedia%2FVE%2FS%26D&diff=588724359&oldid=588539903


Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: normal
[[https://en.wikipedia.org/w/index.php?title=User%3ANeil_P._Quinn-WMF%2FT61847&diff=657363248&oldid=657363001|Seems to work correctly now]] in Safari 8.0.3, although the copy-and-pasting does produce some significant normalization that may be a separate issue.
wikitext after step 8

Steps to reproduce:

1.Open a page with VE
2.Type the following text:
Tex ted
3.Select this part of the text "Tex t" with a space in between.
4.Now apply a link on it with command+k
5.Save the page.
6.Go to Edit source and observe the resulting wikitext for this is:
[[tex t]]<nowiki/>ed

7.Now reopen the page delete the space make it "texted" and delete the link applied.
8.Reapply another link by selecting the whole text "texted"

Observed Result:
The <nowiki/> tag still remains.The resulting wikitext after step 8 is:
[[texted|text]]<nowiki/>[[texted|ed]]

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=Jan8th&action=edit

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

**Attached**: {F12427}
This is because <nowiki /s> (unlike <nowiki>s) are "meta" items in the DOM rather than things VE can edit; merging with bug 56381.

*** This bug has been marked as a duplicate of bug 56381 ***
When a page is loaded in portrait mode the VisualEditor is not loaded. We should get clever about when to load it.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 110625 merged by jenkins-bot:
Load Tablet styles if portrait or landscape meets threshold

https://gerrit.wikimedia.org/r/110625
Change 110625 had a related patch set uploaded by Jdlrobson:
Load Tablet styles if portrait or landscape meets threshold

https://gerrit.wikimedia.org/r/110625
http://googlewebmastercentral.blogspot.com/2011/03/mo-better-to-also-detect-mobile-user.html has a few ideas.

Kenan suggests if the diagonal length of the screen is greater than 5.1 inches than we should assume tablet.
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1603
At some point VisualEditor should be enabled in the remaining namespace.

I've seen a few requests for it, so this tracking bug will also provide an easy answer for why it isnt feasible now. e.g.

https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=589149415#VE_on_Wikipedia:_namespace
Screenshot

Steps to reproduce:

1.Attempt to create a new page with VE in FireFox 25 in any way.For example:Type this URL:
http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Textnew&veaction=edit

Observed Result:

An error appears in the console:

"NetworkError: 404 Not Found - http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Textnew&veaction=edit"
index....on=edit

See the screenshot attached.

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser:  FF 25
OS: MAC OS X 10. 8. 5

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

**Attached**: {F12343}
Not occurring anymore on test 2
However, the page can be created even though the error appears.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Open the Categories Dialog box from Settings>Categories

Observed Result:
The error " Uncaught TypeError: Cannot read property 'langlinks' of undefined " appears in the console.

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=Jan7th&veaction=edit

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

**Attached**: {F12329}
Not appearing any more .Got fixed in wmf11
Created attachment 14259
Settings>Page Settings

**Attached**: {F12330}
The error also appears when user goes to Setting>Page Settings.
Screenshot attached
Intention:
Remove an empty section heading created in a previous edit (bug 59647) by VisualEditor

Steps to Reproduce:
1. Select the empty section heading
2. Press the delete/backspace key


Actual Results:  
The line went away.  However, a nowiki tag remained, and the first item in the list of categories was added to the last paragraph on the page, instead of remaining on its own line.

Expected Results:  
The section heading would go away.  Zero nowiki tags would be present.  Content above and below would not get smashed into a single line.

Reproducible: Didn't try

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=Celebrity_branding&diff=589156903&oldid=589156664
This is because <nowiki /s> (unlike <nowiki>s) are "meta" items in the DOM
rather than things VE can edit; merging with bug 56381.

*** This bug has been marked as a duplicate of bug 56381 ***
On the page on mediawiki.org https://www.mediawiki.org/wiki/Manual:ISBN (check action=history) VisualEditor keeps removing certain characters after I try to use it to make changes to the page. An example is given at https://www.mediawiki.org/wiki/VisualEditor:Test

Reproduction steps:
1. Set up a new page using the following code
<space><space><space><url><apostrophe>
<newline><space><space><space>
example text1

example text2
Where <space> is one hit of the spacebar and <url> could be any URL
2. Modify other places in the text, such as "example text2".
3. See the first character in "example text1" get cut off.
4. Modify "example text2" again and see "example text1" get cut off again.

Example permalink: https://www.mediawiki.org/w/index.php?title=VisualEditor:Test&oldid=873656

--------------------------
**Version**: unspecified
**Severity**: normal
Non-reproducible - most likely fixed.
Intention:
Copyedit an article

Steps to Reproduce:
1. I italicized two words.  I cut two sentences (including links and one ref) and pasted them in a different place.
2. I tried to save the page.


Actual Results:  
The "Save" button looks normal, but clicking on it does nothing.

Expected Results:  
That I could save the page.  When I re-opened the page in VisualEditor and made the same changes, it worked (https://en.wikipedia.org/w/index.php?title=Neuralgia&diff=589057635&oldid=580866827).

Reproducible: Couldn't Reproduce

Firefox 26

--------------------------
**Version**: unspecified
**Severity**: normal
Also, in cases like this where pressing things (buttons etc.) appear to have no affect, you should try checking the JS console for errors.
(Quoting WhatamIdoing from comment #0)
> Reproducible: Couldn't Reproduce

Invalid/worksforme from creation then...
Checkbox "Watch this page" in save dialog unchecked even that page is watched

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed in the re-write in early January; sorry for the slow triage.
Screenshot

Steps to reproduce:

1.Open a page with VE in FireFox
2.Click on the Categories button to open up the dialog box to add categories

Observed Result:
TypeError: response.visualeditor is undefined appears in the console

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/3rd_janff?veaction=edit

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

**Attached**: {F12794}
Not appearing anymore.got fixed in wmf11
Intention:
I used my userpage as a sandbox
https://da.wikipedia.org/w/index.php?title=Bruger:Elitre_(WMF)&action=history,
and the edits in which I tried to add references do not show up in the history,
although I did manage to save them and also got the message that confirms this.

(For the record, I was trying to reproduce
https://da.wikipedia.org/w/index.php?title=F-35_Lightning_II&diff=prev&oldid=7409486
and
https://da.wikipedia.org/w/index.php?title=Enhedslisten&diff=prev&oldid=7414100
, where there might be a connection between adding a reference and getting a
duplicated infobox).




Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: normal
Alright!
If you can't reproduce any longer, given how old the task is, feel free to close - it can be reopened if and when the need arises.
I can't duplicate this - adding references works fine and the edits show up in my history.
Reproducible: Always?
Intention:
Move a sentence to a diffeent place on the page.

Steps to Reproduce:
1. In Firefox, open a page containing existing [[links]] to other pages on the wiki.
2. Cut one of them.
3. Paste it in a different spot.

Actual Results:  
The link gets converted from [[Link]] into [http://en.wikipedia.org/wiki/Link].

See https://en.wikipedia.org/w/index.php?title=User:Edgepedia/VE/S%26D&diff=588724142&oldid=588539903 and https://en.wikipedia.org/w/index.php?title=Silaum_silaus&diff=588803158&oldid=587979575  

Expected Results:  
The [[Link]] would remain an internal link.

Reproducible: Sometimes

One of these pages involved the {{sfn}} (shortened footnotes) template.

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

*** This bug has been marked as a duplicate of bug 58136 ***
1. Edit an article with VisualEditor
2. Select a word for which a redirect exists (not an actual page)
3. Click the "link" icon.

EXPECTED

Since a redirect exists, the link inspector shows the option in blue (since the link is functional). All the better if it is shown in italics, just like redirects are shown by MediaWiki in lists of pages.

ACTUAL

Redirects are ignored by the link inspector. They appear just as red as a missing string. This creates a lot of extra work having to search the string manually in another window.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50593
https://bugzilla.wikimedia.org/show_bug.cgi?id=50240
Merging with bug 49502.

*** This bug has been marked as a duplicate of bug 49502 ***
Intention:
Click on a link within VisualEditor

Steps to Reproduce:
1. Open an existing page in a subpage (e.g., User:Example/Sandbox)
2. Control-click on any [[link]] and copy the link
3. Paste the link somewhere to see what it says


Actual Results:  
Instead of the expected link to en.wikipedia.org/wiki/Link, the user saw links to en.wikipedia.org/wiki/User:Username/Link.  When this intermittent problem was happening, then all links on the page would do it.  However, it only happened during some editing sessions/some days.



Reproducible: Sometimes

Firefox 26 on Windows 7, Vector skin.  Is intermittent there; could not be immediately reproduced in either Firefox or Safari on a Mac.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48915
https://bugzilla.wikimedia.org/show_bug.cgi?id=58314
*** This bug has been marked as a duplicate of bug 58314 ***
Change 119914 had a related patch set uploaded by Catrope:
Hack around Parsoid's href prefixing in rendering new links

https://gerrit.wikimedia.org/r/119914
*** This bug has been marked as a duplicate of bug 58314 ***
The brilliant "Codename Lisa" has figured out how to reproduce it consistently:

1. Open a user subpage.
2. Create a new link to an article on main space, e.g. [[Link]]
3. Control-click on the link and copy it (or open the link in a new window)
4. Discover that the link leads to [[User:YOURUSERNAME/Link]].

More interestingly:

1. Open a user subpage.
2. Create a new link to an article on main space, e.g. [[Link]].
3. Control-click on the link and copy it (or open the link in a new window)
4. Save the page.
5. Re-enter edit mode.
6. Control-click on the same link again.
7. Discover that the link now leads to [[Link]].

Expected result:

In both steps 3 and 6, the article must open at [[Link]], not at [[User:Username/Link]].

Actual result:

In step 3, a subpage with the same {{SUBPAGENAME}} as the link name opens. Step 6 is always successful. Pre-existing links open correctly.
Steps to reproduce:

1.Open a page with VE
2.Select a text  
3.Apply some formatting from the formatting menu in the toolbar for example:
Bold/Italic/Superscript
4.Also apply a link on the text
5.Now from the formatting menu select the "Clear formatting" option

Observed Result:

Along with all the text formatting, the link applied on the text also gets removed.
It is better if Clear formatting only removes the text formatting not the link applied because that is not part of text formatting options.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 51757 ***
TypeError

Steps to reproduce:

1.Open a page with VE which contains a hiero
2.Copy the hiero
3.Open another page in FireFox with VE
4.Paste the heiro
5.Save the page
6.Reopen the page and Press enter to go to the next line after the hiero

Observed Result:
Cannot go to the next line of an article after copy-paste of an hiero.The following error appears in the console:
 
TypeError: outermostNode is null

	

...documentModel,selection.from,'\n');}else{node.traverseUpstream(function(node){if...

load.p...4146Z&* (line 261)

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

**Attached**: {F12558}
This looks like we fixed it ages ago.
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/w/index.php?title=28th_decemberff&veaction=edit
Screenshot of the error

I have got this error several times in Betalabs recently,it happens if I keep VE open for a while for a page and then do some more edit and hit the "Save Page" button.
I was still logged in to the previous session when this error appeared.

"TypeError :this.timings is undefined "

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**: {F12542}
This was caused by a call to `.this.events.track()` in a detached way, which means `this` isn't bound and `ArticleTargetEvents` members like `timings` would not be found. This has since been fixed (based on the current code), though I can't find the exact commit.
Is this still occurring?
Whoops, sorry, you're right!

I use Firefox 26.0 on Ubuntu 12.04 LTS.
(In reply to comment #1)
> Happens frequently in Firefox under Ubuntu too

Version information welcome, in general (don't know which version of Firefox is shipped on which version of Ubuntu).
Happens frequently in Firefox under Ubuntu too, I have to click the "Save" twice to get it to actually save.
Selecting the whole line

Steps to reproduce:

1.Open a page with VE
2.Select a text to apply the paragraph format "Preformatted".Select the text in a way so that it selects the whole line.Check the screenshot of selection to better understand.

3.Now select the option preformatted from paragraph styling options

Observed Result:
The Preformatted option gets applied to the other following text/element even though they are not selected.

If the selection is done such way that it spans multiple empty lines then the preformatted options gets applied to those empty lines too.

See the screenshots 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/28th_december

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

**Attached**: {F12538}
The selection of the following line is different than selecting the text on the line. If you choose to select just the text, you will get the behavior you are looking for. If you select the line and it's break (or empty lines after it) then you will get the behavior you are reporting as a bug.

This is not a bug, it's doing exactly what it should. However, it may be valuable to revisit how we can better communicate what is selected and how to achieve the desired result to the user.

Unfortunately, we have limited control over selection because we use ContentEditable, which is provided by the browser. The selection of a line and it's break may be something we can disable, but likely there will be negative effects on user experience and browser compatibility.

Marking as invalid, since this is not a bug, but a known feature. I'm happy to discuss the UX impact of this feature and possible changes that could improve the situation on a different, enhancement, bug.
Sorry, I think I could not explain it properly in my steps.The issue was not about applying the format on the whole line rather on an immediate following line which was not selected.

For example the content of a page is as follows:

The text
another text



Not selected text


Now if you select "the text" and "another text" but stop the selection just above the line "Not Selected text" and apply the format, it gets applied to "Not Selected text"

So, I am reopening the bug again as it is a different issue.
Yes, content formatting applies to the line(s) selected, not the text selection. This is by design (rather than splitting the text). Closing as WONTFIX, but happy to discuss if someone things we should split instead.
Created attachment 14184
Observed Result

**Attached**: {F12541}
Created attachment 14183
Selecting multiple lines

**Attached**: {F12539}
Intention:
Turn a list of seven single-spaced items into a properly formatted list.

Steps to Reproduce:
1. Start with a page that contains a list of items that do not have blank lines between them.

2. Open VisualEditor and select all the items.

3. Click the 'list' button.

Actual Results:  
Only the first item is given list formatting.

If some items are double-spaced and others are not, then double-spaced items are given list formatting, and any items without a blank line above them (except the first item, which always becomes list-formatted) is left as a plain paragraph rather than being formatted as a list item.

Expected Results:  
All the items would be given list formatting.

Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=User:Whatamidoing_(WMF)/sandbox&diff=587947827&oldid=587947700
At https://en.wikipedia.org/w/index.php?title=User:Whatamidoing_(WMF)/sandbox&diff=587948540&oldid=587948443 you can see the 'workaround'.  This wikitext:

* Monday is washing day.
Tuesday is ironing day.
Wednesday is mending day.
Thursday is marketing day.
Friday is cleaning day.
Saturday is baking day. 

displays like this in view mode:

* Monday is washing day.
Tuesday is ironing day. Wednesday is mending day. Thursday is marketing day. Friday is cleaning day. Saturday is baking day. 

and displays like this within VisualEditor:

* Monday is washing day.
Tuesday is ironing day.↵Wednesday is mending day.↵Thursday is marketing day.↵Friday is cleaning day.↵Saturday is baking day. 

If you select the subsequent items (Tuesday through Saturday), and click the button to apply list formatting, then only the "Tuesday" line acquires list formatting.  This looks in VisualEditor like this:  

* Monday is washing day.
* Tuesday is ironing day.↵Wednesday is mending day.↵Thursday is marketing day.↵Friday is cleaning day.↵Saturday is baking day. 

If you save and re-open, you see this:

* Monday is washing day.
* Tuesday is ironing day.

Wednesday is mending day.↵Thursday is marketing day.↵Friday is cleaning day.↵Saturday is baking day. 

and the wikitext is this:

* Monday is washing day.

* Tuesday is ironing day.

Wednesday is mending day.
Thursday is marketing day.
Friday is cleaning day.
Saturday is baking day. 

(Notice the HTML-list-formatting-breaking unwanted blank line between Monday and Tuesday.)

Selecting the "↵" and hitting return produces the desired list.
Steps to reproduce:

1.Open the editor for a page
2.Create a link


Observed Result:
There is no suggestion appearing for the link creation and also in the console the error 500 (Internal Server Error) appearing


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 issue is not appearing anymore
There is a similar error appearing while adding media files to the page too.

The error is as following:
GET http://en.wikipedia.beta.wmflabs.org/w/api.php?callback=jQuery1830288604790…imit=15&gsroffset=0&prop=imageinfo&iiprop=dimensions%7Curl&iiurlheight=150 500 (Internal Server Error) load.php:128
Created attachment 14171
Screenshot of the error

**Attached**: {F12356}
I know this could be my fault, but I checked everything and it looks like it's a bug. Please correct me if I am wrong.

Whenever I click the edit button the webpage does nothing. I see from the javascript debugger that the code stops at this line:

return typeof jQuery !== "undefined" && (!e || jQuery.event.triggered !== e.type) ? jQuery.event.dispatch.apply(eventHandle.elem, arguments) : undefined;

Any clues?

I checked parsoid, tried creating a new settings file with minimal options, upgraded to latest trunk version both core and visualeditor.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
**Platform**: PC
(In reply to comment #8)
> When you download the VE extension, the lib folder is empty. (well, only an
> empty subfolder). This is the cause.
The empty folder is a submodule. Run 'git submodule update --init' to download it, and 'git submodule update' to update it after running git pull.
When you download the VE extension, the lib folder is empty. (well, only an empty subfolder). This is the cause.
Is there anything relevant in the Apache error log (could be folder/file access permissions)? Or in the debug log (see https://www.mediawiki.org/wiki/Manual:How_to_debug#Setting_up_a_debug_log_file )?
Screen shot of console errors

**Attached**: {F12331}
**sumanah** wrote:

Mc128k in #mediawiki just now confirmed that s/he has tried upgrading to the latest git master of VE and the bug still occurs.
Adding more infos: debugging shows many 404 errors, and the lib/ve/ folder is empty. Something went very wrong with some git merge I think.
I tried installing a clean mediawiki with only VE with a local sqlite database. Same issue, not even picked my config file, made one new.
It’s a private wiki, but VE should work even with readonly access (at least it worked before) by entering ?veaction=edit at the end of the URL. I tried firefox and Safari for Mac.

This worked and now it doesn’t: http://wiki.mc128k.info/index.php?title=Test&veaction=edit

I also noticed that if I click edit from the read tab it does nothing, if I click edit from the edit source tab it changes the URL, but nothing again.

Thanks.
Any link to reproduce the problem? Which browser(s) does this happen with?
Screenshot of the error

Steps to reproduce:

1.Open a page with editor.
2.Add some content and image
3.Save the page

Observed Result:
The content of the page is appearing more condensed and all the images are no more right aligned.

See the screenshot attached

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

**Attached**: {F12290}
This was the ill-advised changes to the Typography Refresh update.
This is happening on test2 too for both Chrome and FireFox
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/Link_to_catapult
screenshot

I was trying to open some page on betalabs , it appears that none of the resources are loading properly.

Getting some errors like following while attempting to login:
Failed to load resource https://bits.beta.wmflabs.org/en.wikipedia.beta.wmflabs.org/load.php?debug=…m%7Cskins.common.interface%7Cskins.vector.styles&only=styles&skin=vector&*
Failed to load resource https://bits.beta.wmflabs.org/en.wikipedia.beta.wmflabs.org/load.php?debug=false&lang=en&modules=site&only=styles&skin=vector&*
Failed to load resource https://bits.beta.wmflabs.org/en.wikipedia.beta.wmflabs.org/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector&*
Failed to load resource https://upload.beta.wmflabs.org/wikipedia/en/b/bc/Wiki.png
Failed to load resource https://bits.beta.wmflabs.org/static-master/skins/vector/images/search-ltr.png?303-4
Failed to load resource https://bits.beta.wmflabs.org/images/wikimedia-button.png
Failed to load resource https://bits.beta.wmflabs.org/static-master/skins/common/images/poweredby_mediawiki_88x31.png

Please see the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F12273}
Beta bits cluster issues, now fixed.
Before facing this issue , I was prompted with warning of server's certificate not trusted, after proceeding anyway its using https protocol to load the pages.
The page I tried to open was: https://en.wikipedia.beta.wmflabs.org/wiki/Link_to_catapult

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65
OS: MAC OS X 10. 8. 5
Intention:
Add a citation template

Steps to Reproduce:
1. Choose Insert > Reference

2. Choose Insert > Transclusion

3. Type "Cite web" into the box. Hit return twice.

4. Click "URL access date" to add that parameter to the list. Cursor jumped back to "Add parameter" (not unreasonable; you might want to add lots of parameters before filling any of them in).

5. Click "URL access date", which is now the first item in the left-hand column's list of parameters, so I can add today's date to my reference. Cursor jumped back to "Add parameter" (definitely unreasonable).

6. Repeat that step as many times as you feel like.

7. Give up and click on the second parameter, which is "Source title". Cursor jumped to the parameter box for "URL access date".

8. Click on the third parameter in the list, which is "URL". Cursor jumped to the parameter box for "Source title". The only way to fill in any information for the last parameter in the list is to scroll down the list in the right-hand column.

9. Read the article on [[:en:Fencepost error]].  



Expected Results:  
That clicking on the second parameter would actually take me to the second parameter, not to the first one.

Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: major
This was fixed in gerrit 99749.
Selecting the reference with reference list

Steps to reproduce:

1.Open a page which has reference and reference list with VE on FireFox25
2.Select the reference and the reference list and press delete
3.Save the page

Observed Result:

In Edit mode the order (1.) remains in the page.However, in the read mode the order will not appear.In edit source mode , there is a # appearing.

Test Environment: https://test2.wikipedia.org/
Browser: FF 25
OS: MAC OS X 10. 8. 5 
Page:https://test2.wikipedia.org/wiki/The_title

The wikitext of the page before deleting:
reference<ref>refererence</ref>
<references />

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

**Attached**: {F12253}
Is this still occurring?
screenshot of the lock icon appearing

Steps to reproduce:

1.Open the editor for a page which contains some references and a reference list

2.Copy the references and the reference list and paste into anothe rVE

3.Save the page

Observed Result:

A lock icon is appearing beside the reference for a reference list in FireFox in test2 
Page:https://test2.wikipedia.org/wiki/23rdtemplatepaste

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

**Attached**: {F12241}
This is because the links are to HTTPS sites.
the screenshot of the error

Steps to reproduce:

1.Open the editor for a existing VE
2.Create a link to a new page
3.Click on the link to open that new page in the same or a new tab
4.Click on the Create button

Observed Result:

Ve does not load,An error is shown on the console:
TypeError: list[firingIndex] is undefined
	

....split(core_rspace),function(_,flag){object[flag]=true;});return object;}jQuery....

load.p...025514Z (line 12)

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F12227}
Yes,it happens for every page including new page when I switch from wikitext editor to VE.
But yes, it does not happen when I visit the page in read mode first by typing the address to go to the link directly
I cannot reproduce this in quick testing (FF 25.0.1/Mac 10.9.1) – is this on every new page when transitioning from the wikitext editor to VE? Does it happen if you visit the page first in read mode? What about if you go directly to the link by typing in the address by hand?
Screenshot

Steps to reproduce:

1.Open the Editor for a page which contains an image with FireFox

2.Copy the image and paste it into another VE

3.Save the page.

Observed Result:
After copy paste before saving it appears as an uneditable object in VE .After saving the image appears as a link in the page as follows:

In read mode and Edit mode: 

link=https://test2.wikipedia.org/wiki/File:158869_at_Truro.JPG|200x200px

In Edit Source mode:[[undefined|link=https://test2.wikipedia.org/wiki/File:158869_at_Truro.JPG|200x200px]]
See the screenshot attached.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also:**
{T78026}

**Attached**: {F12212}
This has probably been fixed for a while.
This is occurring in mw.org now
Created attachment 14161
Before Saving

**Attached**: {F12213}
In http://en.wikipedia.beta.wmflabs.org/
Edit Source and Edit button is appearing as <visualeditor-ca-editsource> and Edit<visualeditor-beta-appendix>

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 58897 ***
This was an artifact of today's issue with database connections, resolved after restarting apaches on beta
The issue is not happening now.
okay will verify it, once bug 58897 gets resolved.
On the few times when bug 58897 isn't having an effect so I can see the page, it seems to work for me right now…
Created attachment 14158
screenshot

**Attached**: {F12188}
Support adding and removing <code> elements.

--------------------------
**Version**: unspecified
**Severity**: normal
This was done in July last year.
I tried to give L10n-bot the correct access rights, but failed; I've removed my attempts again. Please give L10n-bot the rights at URL so that it can merge its own submits, like in MediaWiki repos.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/wikimania-scholarships,access
Nothing new or different. Give Code Review / Verified / Submit to the l10n-bot group.

I did it in VisualEditor/* and oojs/* so those repo hierarchies will be fine from now on.
Thanks, Chad. Can you explain what you did? This may make a future occurrence ore easy to resolve.
Done.
The same issue exists for the following repos:
* VisualEditor/VisualEditor
* oojs/ui
What's keeping this from being addressed?
Screenshot

Steps to reproduce:

1.Open the editor for a page
2.Add a text or a link or a numbered list
3.Copy a math formula from another VE
4.Paste it into the next line after step 2
5.Save the page

Observed Result:
The math formula is  getting merged with the previous element

Please check :http://en.wikipedia.beta.wmflabs.org/wiki/Mathpaste20th

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

**Attached**: {F12767}
Not occurring anymore.Changing the status to Resolved-WorksforMe
Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.6
OS:MAC OS X 10.8.5
Steps to reproduce:

1.Open the editor
2.Create a numbered list with 4 items.For example:
# item 1
# item 2
# item 3
# item 4

3.Now place the cursor at the end of item 2 and press enter
4.Add a new item 3( it gets added properly)
5.Now place the cursor just before item 1 and press enter to move it to the next line 
6.Type a new item1 in first line
7.Delete the new item

Observed Result:

The order  (1.) does not get deleted.In read mode the list appears like this:
 
 1.
 2. item 1
 3. item 2
 4. new item 3
 5. new item 4
 6. item 3
 7. item 4 

After saving, in read mode the list appears as follows:

1.item 1
2.item 2
3.new item 3
4.new item 4
5.item 3
6.item 4

--------------------------
**Version**: unspecified
**Severity**: normal
I think that this is "expected" behaviour (blank <li>s don't show in read mode, but do in wikitext and VE), confusingly.
Created attachment 14151
In read mode

**Attached**: {F12756}
Created attachment 14150
In VE edit mode

**Attached**: {F12755}
Created attachment 14149
In edit source mode

**Attached**: {F12754}
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=Another_page20th
**jhall** wrote:

Changing bug status since task in still WIP.
Change 103058 abandoned by Jhall:
[Browser test] WIP Add session teardown steps

Reason:
Abandoning this change after a pairing session with Chris McMahon, since we settled on change #103566 as a better solution for the root problem.

https://gerrit.wikimedia.org/r/103058
Change 103058 had a related patch set uploaded by Jhall:
[Browser test] Add session teardowns steps

https://gerrit.wikimedia.org/r/103058
**jhall** wrote:

Complete Sauce Log

**Attached**: {F12749}
On fr.wp,
NemesisIII usually copy/pastes titles of articles in the reference dialog.
This led to this diff, https://fr.wikipedia.org/w/index.php?title=France_Roche&diff=prev&oldid=99244364, where the newly added link is among equal signs, as if its style was "Page title" rather than "Paragraph".

When I tried to replicate this behavior,
I got a slightly different result https://fr.wikipedia.org/w/index.php?title=Utilisateur%3AElitre_%28WMF%29%2FProve&diff=99382715&oldid=99382337.
Reference #2 is now... definitely different from the others (waaay bigger), and certainly not standard as it should be.

--------------------------
**Version**: unspecified
**Severity**: normal
I've [[https://fr.wikipedia.org/w/index.php?title=Utilisateur%3ANeil_P._Quinn-WMF%2FTestcase%2FT60689&diff=114195603&oldid=114195075|tested this]] again using headlines from three different news sites, and the reference dialog now seems to correctly strip all rich formatting. Closing.
I've [[https://fr.wikipedia.org/w/index.php?title=Utilisateur%3ANeil_P._Quinn-WMF%2FTestcase%2FT60689&diff=114195603&oldid=114195075|tested this]] again using headlines from three different news sites, and the reference dialog seems to correctly strip all rich formatting. Closing.
NicoV, this bug is entirely about the reference dialog, so what you should do for refs is the only thing that we're talking about here.  So if "manuals of style usually say that external links should not be in the text of the article, but as references", then we SHOULD retain these links in the refs.
Problem with this is and other design decisions in VE is that the exception is privileged over the most common situation.

In most cases, you really don't want the formatting to be copied over like that when you're copying something from an external website:
* italic, bold: probably ok
* links: probably usually ok (and this is not really true, because manuals of style usually say that external links should not be in the text of the article, but as references or in an "external links" section)
* everything else: usually not ok (I would say 99%), and even when it seems ok, it's not really a good idea. Why? Take the example of a different language: the notion should be kept in the end, but all wikis I know have defined a {{lang}} template to do that and discourage the use of <span lang="xxx">. And this is true for many things: even the links/italics/bold for a reference are usually handled by a template like {{cite web}} to have a consistent look&feel in wikipedia.

Copying from an other page of wikipedia is an other subject: for this, copying the full wikimarkup would be usually good.
There are good reasons to retain basic character formatting (e.g., italics) and linked URLs (e.g., the equivalent of [http://my.source.org Reliable Title]).  

I suppose that font might be useful, if it has the effect of switching to a different language.  I'm just not sure that we'll encounter that.  <span lang="jv-java"> of course should not get dropped, and LTR/RTL switches are critical.  Imagine a ref including both Arabic and a European language without this feature.
(In reply to NicoV from comment #3)
Precisely.
I think keeping the formatting of a non-wiki contents is not really a good thing: every wiki has its own manual of style, to have a consistent look and feel in articles. There's almost no chance at all that a non-wiki contents will be formatted following the manual of style of the wiki.
There's seldom use to keep font family, font size, color, ... from an external contents.
I'm pretty sure it's working as intended, but I am not sure if it's helpful that it allows changing style to text (given it's a reference), and if there's a way to prevent that, because changing style to the single reference when you add it is not possible now.
This may be a case of 'working as designed':  Rich copying and pasting means that the style of the copied/pasted contents is retained.  This is a new feature, so users are surprised by this.  We don't want to break formatting for references:  titles should remain italicized, journal volumes should remain bolded, etc.  However, perhaps it would be possible to set the contents of all refs to "Paragraph"?
Steps to reproduce:

1.Open the editor
2.Add a Hieroglyphic
3.When the cursor moves to the next line , add a heading and save the page

Observed Result:
The heading bar appears above the hiero where as the section edit options appear where the text of heading appears.The text styling for the heading changes to paragraph format.

The wikitext resulting from these actions is:
== <hiero>A
</hiero>heading following hiero ==

Found in:http://en.wikipedia.beta.wmflabs.org/wiki/Nonexist
Test Environment: betalabs
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5

--------------------------
**Version**: unspecified
**Severity**: normal
Is this still occurring?
After adding the heading the cursor jumps to the beginning of the text in the first line of the document
Created attachment 14131
screenshot

**Attached**: {F12544}
Esperanto commonly uses some special characters.  The "x-method" of entering them (cx -> ĉ, gx -> ĝ, hx -> ĥ, jx -> ĵ, sx -> ŝ, ux -> ŭ (and the capital letters)) is already implemented in the Universal Language Selector and other MediaWiki software at https://doc.wikimedia.org/mediawiki-core/master/php/html/LanguageEo_8php_source.html launguages/classes/LanguageEO.php  

VisualEditor should support the same method.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This is a duplicate of bug 49569.

*** This bug has been marked as a duplicate of bug 49569 ***
Ok I've confirmed that the ULS IME *doesn't* seem to work in current VE deployment.

(This has replaced, or should replace, the old save-time transform...)

James, is there a general issue with ULS IMEs working/not working in VE? Have we run into this issue for other languages? What can we do to help it work? Do we have to adapt the IME to work in VE particularly? Or is there currently no way for any of the ULS IMEs to work?
Now on eo.wiki does not work such post-save transformation, see https://eo.wikipedia.org/w/index.php?title=Uzanto:KuBOT/provejo&diff=5371450&oldid=5333431 (should appear "eĥoŝanĝo ĉiuĵaŭde" both in page and in the edit summary).

If ULS IME stuff just work it would be great - even another transform methods for Esperanto, already included in ULS, would work.
Shouldn't the existing ULS IME stuff just work? Or does every one require custom support in VE?
(In reply to comment #1)
> What is this method? How does it work? It looks just like a basic post-save
> transform - if so, that should already work with VisualEditor…

It's an input method in jquery.ime. https://github.com/wikimedia/jquery.ime/blob/master/rules/eo/eo-x.js
What is this method? How does it work? It looks just like a basic post-save transform - if so, that should already work with VisualEditor…
In VisualEditor, enter

   one[space][Ctrl-I]two[space][Ctrl-I]three

This will result in wiki text 

   one ''two ''three

but clearly

   one ''two'' three

was intended. I don't think a trailing (or leading?) space in italic/bold wikitext is ever appropriate.

The fixed Bug 33108 is similar but deals with selected text.

<editorial>
I believe some of the hostility towards VE in the Wikipedia community results from issues like this: editors with long watchlists feel they have to clean up after many such VE edits.
</editorial>

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

*** This bug has been marked as a duplicate of bug 52037 ***
Right now we've a BetaFeatures component – https://bugzilla.wikimedia.org/buglist.cgi?component=BetaFeatures&product=MediaWiki%20extensions&list_id=259910 – but no single place to put bug reports about features that use BetaFeatures.

Some of these have components of their own (e.g. MediaViewer) or even products (e.g. VisualEditor), but others don't (and probably won't).

Right now, there's nowhere to raise a bug about e.g. Typography refresh that won't muddy up the bugs about BetaFeatures itself, as opposed to things that use it.

Suggestions on better naming welcome. :-)

--------------------------
**Version**: unspecified
**Severity**: normal
If features could provide preferred bug links that would be more useful.. Personally I just want to use talk pages for both of my features. I ignore the VectorBeta component. With respect to typography it's just not stable enough to warrant bugzilla bugs.
The primary organization structure of Bugzilla is products and components which are mostly based on code repositories or code areas.

(In reply to comment #6)
> 1) People should not be expected to know from which extension beta features
> come from so in the current scenario various bugs will be filed incorrectly.

I'm happy to edit the BetaFeatures component description in Bugzilla to link to a wikipage that explains which beta feature is called how. https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-betafeatures has links to "Information" and "Discussion" so you're free to add a link to corresponding Bugzilla components on the Information page. Or using the Bugzilla parameter of the {{Extension}} template.

> Now I am seeing a flood of bugs filed under mobile from problems experienced
> in the Beta Features environment field.

Example bugs welcome so I can investigate plus if there are patterns I should improve documentation.
Please reconsider or at least rethink the problem as there is a real problem here in my opinion.

From my perspective:
1) People should not be expected to know from which extension beta features come from so in the current scenario various bugs will be filed incorrectly.
2) Beta features don't always plan to graduate to stable so are lower priority then the extensions that house them. For example - nearby pages is part of MobileFrontend.
The purpose of the experiment was to explore whether such a feature was useful in desktop. If it is, it will need MediaWiki UI and a massive rewrite before being pushed to desktop.

Now I am seeing a flood of bugs filed under mobile from problems experienced in the Beta Features environment field. These tend to not be helpful as I'm aware the code has issues when run in desktop.

I would like some way of keeping these bugs separate from what I see as real bugs. I am very close to wanting to kill this beta feature because of this noise as I feel the bugs are intruding on the mobile teams core work which would be a huge shame. Please dont make me do this...
(In reply to comment #1)
> All BetaFeatures are currently parts of some extension, so the bugs should
> probably be filed in the extensions, no?

Yes. If extensions are missing I should create them (bug 58616, bug 58617, etc).
So… we should just throw them in "General" and hope they get worked on? Lovely. :-(
Yeah, agreed with MatmaRex, this seems mighty silly. If anything, it wouldn't go under the Extensions product, because you're talking about something that *isn't* an extension, it's either only part of one or some sort of weird core betafeature.
(In reply to comment #0)
> Right now, there's nowhere to raise a bug about e.g. Typography refresh that
> won't muddy up the bugs about BetaFeatures itself, as opposed to things that
> use it.

Those should be filed against VectorBeta. Though, supposedly those styles are actually in core, so the bugs should be filed in core?

(In reply to comment #1)
> All BetaFeatures are currently parts of some extension, so the bugs should
> probably be filed in the extensions, no?

I agree.
All BetaFeatures are currently parts of some extension, so the bugs should probably be filed in the extensions, no?
When I tab through the various input controls and highlight the "save page" button in VisualEditor, I can't seem to use the return key to submit the form/press the button. I'll upload a screenshot momentarily.

--------------------------
**Version**: unspecified
**Severity**: normal
Up-merging to the upstream issue.

*** This bug has been marked as a duplicate of bug 62337 ***
Created attachment 14117
VisualEditor on mediawiki.org with "save page" button highlighted, 2013-12-16

**Attached**: {F12370}
Input text ([[mw:VisualEditor:What A]]):

---
=== test ===
what is '''this''' i don't ''even''
---

I copy and paste this text from [[mw:VisualEditor:What A]] to [[mw:VisualEditor:What B]] and I end up with largely the same result, except an invisible non-breaking space is inserted before "test". If you view the HTML page source of [[mw:VisualEditor:What B]], it's trivial to spot:

---
<span class="mw-headline" id=".C2.A0test">&#160;test</span>
---

--------------------------
**Version**: unspecified
**Severity**: normal
1. Go to a non-existent page and edit it with VE
2. Click to the right of the article title
3. Click the link icon on the toolbar

The link inspector appears next to the page title, pointing to what is an uneditable area of the page.

Link creation works correctly, despite the incorrect location of the inspector.

--------------------------
**Version**: unspecified
**Severity**: minor
Seems to work correctly now.
I ran into an issue with VisualEditor, when I tried to replace an letter with an diatric letter in defaultsort. VisualEditor would not activate the "Save page" button, making me unable to save the change. Also, I noticed, that if I would add some random letters to the page, after the defaultsort change, VisualEditor would still not activate the "Save page" button.

Here is one of three nearly indentical tests where I found this issue. The other two where to test whether the bug was reproducable.
# Change [[:is:Flokkur:Stjórnmál í Sádí-Arabíu]]
# Open the More settings panel, and choose Page settings.
# Sort the page as "Sádí-Arabíu" (without the hyphens).
# Click apply changes
# Notice that the "Save page" button does not activate.

Expected behaviour: Should allow me to save the page, when changing an letter to an diatric letter. Adding text afterwards definatly should allow me to save the page.

--------------------------
**Version**: unspecified
**Severity**: normal
I can no longer reproduce this bug.

Closed as worksforme.
Intention:
Copyedit a sentence.  I clicked after the word "elbow" to add another phrase.


Actual Results:  
It typed my words in the middle of a sentence four lines lower.  The diff was correct, but did not include several of the last changes I made (e.g., adding paragraph breaks).  Also, in cutting and pasting another paragraph, the ref's contents were removed.


Reproducible: Didn't try

--------------------------
**Version**: unspecified
**Severity**: normal
Seems to [[https://en.wikipedia.org/w/index.php?title=User%3ANeil_P._Quinn-WMF%2FTestcase%2FT60493&diff=657353327&oldid=657353041|work correctly now]]. Closing.
The diff (what ended up being saved) is at https://en.wikipedia.org/w/index.php?title=Diffuse_large_B-cell_lymphoma&diff=586098843&oldid=582235478
Created attachment 14098
Screenshot of the article after encountering the problem, but before saving

Four places are marked in the image:

(1) I split the paragraph as shown here, but this line break did not get saved.

(2) I clicked above the '2' and started typing after "elbow".  The next few words should have been "or a surgically implanted port".  The words "or a sur" were visible on the screen at the time I saved, but did not appear in the diff.

(3) The highlighted (blue) spot is where VisualEditor tried to put part of these words.  I have just 'undone' the addition of the text in the wrong paragraph.

(4) The first thing I did in this article was to cut text out of the ==Treatment== section and use it to create a separate ==Research== section.  Ref #30 turned into <sup>[30]</sup> when I did this.  In addition to losing the refs, it may have added line breaks; they do not appear in the original wikitext, but I had to remove several before saving.

The number of lines in between where I clicked to type at (2) and where it tried to put the words at (3) is approximately the same number of lines as what was moved to (4).

**Attached**: {F12250}
"Edit" tab not change to "Vew source" with protected template subpage, see https://commons.wikimedia.org/wiki/Template:Delete/layout

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://commons.wikimedia.org/wiki/Template:Delete/layout
So this is actually a duplicate report of a different, much older one :)

*** This bug has been marked as a duplicate of bug 11700 ***
Actually, that was too quick. This also affects core with VisualEditor disabled. Sorry.
*** This bug has been marked as a duplicate of bug 53893 ***
Let's copy the relatively simple {{irc}} template from 

https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2013-12-04

to

https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2013-12-18

1. Open both pages in Edit mode.

2. Copy "#wikimedia-meetbotconnect" from one page and paste it in the other.

EXPECTED

The template is copied as i to the destination page.

ACTUALLY

If selecting only the text generated by the template, Ctrl-C seems to be not enough. Ctrl-V in the other page will still paste whatever you hadd in your clipboard before.

If selecting the text of the template plus some extra text, then Ctrl-C does copy something, and Ctrl-V does paste a visually equivalent text.

However, when checking the wikitext source of the page one can see that the original template has been rendered as HTML.

See https://www.mediawiki.org/w/index.php?title=Architecture_meetings%2FRFC_review_2013-12-18&diff=841813&oldid=838192

If this is part of a secret, long-term Parsoid plan to convert all template instances to HTML, fine. However, if this is not the intended behavior...  ;)

--------------------------
**Version**: unspecified
**Severity**: normal
I can no longer reproduce this in Firefox.  It's been months since the last time I remember seeing this.
Can't reproduce this issue...
https://en.wikipedia.org/w/index.php?title=User:Edgepedia/VE/S%26D&diff=588724142&oldid=588539903 (Command-F to search for "Commons") shows the same kind of problem, except that the result doesn't look right.  The image is missing, the box is missing, and the text is on the left rather than on the right.  The appendices are duplicated in that diff, so you can see both what's wrong (the first set of ==External links==) and what it ought to do (the very bottom of the page).
The browser tests for Flow should be triggered by Gerrit just like it
is already the case for ULS (bug 52120) or going to be for VisualEditor (bug 53691).

The tests need to be carefully filtered out since they are expecting content or
behavior which are not to be found on a freshly installed wiki.

CC QA

--------------------------
**Version**: wmf-deployment
**Severity**: normal
We are not going to trigger browser tests on patch submission for now.  It is not that trivial to setup.
Resetting ticket status as patch was merged
Nice! I retriggered the job and it took screenshots for the failures: https://integration.wikimedia.org/ci/job/mwext-browsertests-Flow-phantomjs/6/
As far as I can see[1], Flow is now using mediawiki_selenium 0.2.7, so screen shots should be taken.

1: https://github.com/wikimedia/mediawiki-extensions-Flow/blob/master/tests/browser/Gemfile.lock#L25
Antoine, do you still need help with this?
( and one can trigger a run manually using the lame tutorial at https://www.mediawiki.org/wiki/Continuous_integration/Tutorials/Trigger_a_job_manually )
I got Cirrus Search tests working with Nik and I am close to finish the integration of the VisualEditor tests.

I triggered a run of the Flow browsertests this morning and they are failing: https://integration.wikimedia.org/ci/job/mwext-browsertests-Flow-phantomjs/5/ I havent investigated though.

Cucumber HTML report is https://integration.wikimedia.org/ci/job/mwext-browsertests-Flow-phantomjs/5/artifact/log/report.html


The screenshots are not taken because the repository uses mediawiki_selenium (0.2.2), should use 0.2.3 to let us specify the screenshot destination.
Change 112874 merged by jenkins-bot:
Tag browser tests with @clean

https://gerrit.wikimedia.org/r/112874
Change 112874 had a related patch set uploaded by Hashar:
Tag browser tests with @clean

https://gerrit.wikimedia.org/r/112874
*** Bug 61219 has been marked as a duplicate of this bug. ***
**Author:** `littlesandra88`

**Description:**
For private wiki's that requires login

$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['read'] = false;

I get this from nodejs

Stack trace: AccessDeniedError: Your wiki requires a logged-in account to access the API.

when I do

lynx  http://localhost:8000/localhost/x

--------------------------
**Version**: unspecified
**Severity**: normal
Yes, that should work unless things have changed in VE land in the meantime.
**littlesandra88** wrote:

Very interesting. I would like to try that.

Based on https://www.mediawiki.org/wiki/Talk:Parsoid#More_private_wiki_trouble would it be correct that all I have to do is adding

$wgVisualEditorParsoidPrefix = 'localhost'; 
$wgVisualEditorParsoidForwardCookies = true;

and then it should work?
Parsoid forwards cookies to the API and disables caching if a cookie is set. The VisualEditor extension for example supports forwarding cookies to Parsoid for private wikis, see their settings.

Parsoid should not have access to sensitive information like passwords. In the longer term we'll probably add support for time-limited signed token forwarding once MediaWiki in general gains support for that.
**littlesandra88** wrote:

If your wiki requires login, then the wiki api.php page, which parsoid needs, also requires login. There is no way to specify a username+password to parsoid so it can access this page. That is what you see in the error message.

To fix this, I guess a dummy account have to be made in MediaWiki, and then the username+password needs to be entered somewhere in parsoid config files.
The behavior looks correct to me.

Can you be more specific about where you see a problem here?
Safari 7:

https://www.mediawiki.org/wiki/Communication?veaction=edit

Copy from under H1, including template up to just before the Chat header. I get:
[Error] TypeError: 'undefined' is not an object (evaluating 'delete children[i].values[attribute]')
	removeAttributeRecursive (load.php, line 20)
	removeAttributeRecursive (load.php, line 20)
	removeAttributeRecursive (load.php, line 20)
	removeAttributeRecursive (load.php, line 20)
	removeHtmlAttribute (load.php, line 20)
	getClonedElement (load.php, line 202)
	cloneElements (load.php, line 170)
	onCopy (load.php, line 292)
	proxy (load.php, line 10)
	dispatch (load.php, line 45)
	eventHandle (load.php, line 38)

--------------------------
**Version**: unspecified
**Severity**: normal
This appears to now work for me; sorry for the epically slow triage.
[Error] TypeError: 'undefined' is not an object (evaluating '$node.data('view').getModel')
	getOffsetFromTextNode (load.php, line 244)
	getOffset (load.php, line 244)
	getRange (load.php, line 248)
	pollOnceInternal (load.php, line 319)
	pollOnce (load.php, line 319)
	documentOnBlur (load.php, line 287)
	proxy (load.php, line 10)
	focus
	afterPaste (load.php, line 299)
	(anonymous function) (load.php, line 294)
	proxy (load.php, line 10)

--------------------------
**Version**: unspecified
**Severity**: normal
Does this bug mean "you can copy stuff, but nothing happens when you try to paste it"?
I haven't seen this problem for a long time, so we should probably close it.
I can't reproduce this now (Mac OS X 10.9 / Safari 7.0.2) – can you, or should we mark as WORKSFORME?
I have trouble reproducing this one, but I think it sometimes happens if you delete something in a surface and then try to copy something else in that surface. Or if you select a block in the destination and then do a paste replace.

Safari 7
I selected all VE content from: "It is important to make", up to "Mediawiki-l mailinglist thread "mysql5 binary schema" 25.03.2009"

I could pinpoint it to trying to copying the Header "scripts" and the warning template that follows it.

[Error] TypeError: 'undefined' is not an object (evaluating 'delete children[i].values[attribute]')
	removeAttributeRecursive (load.php, line 20)
	removeAttributeRecursive (load.php, line 20)
	removeHtmlAttribute (load.php, line 20)
	getClonedElement (load.php, line 202)
	cloneElements (load.php, line 170)
	onCopy (load.php, line 292)
	proxy (load.php, line 10)
	dispatch (load.php, line 45)
	eventHandle (load.php, line 38)

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/Manual:Backing_up_a_wiki?veaction=edit
Can't reproduce any more. We did a lot of changes to Select-All in the intervening period, which probably fixed it.
On Safari 7 btw:

I have a slight suspicion thrown Undefined errors like these during copy might also be responsible for the broken internal links that are pasted: [[https://www.mediawiki.org/wiki/Manual:Restoring_a_wiki_from_backup|Manual:Restoring a wiki from backup]]
screenshot

Steps to reproduce:

1.Open the editor
2.Insert an image

Observed Result:
An error appears:
Uncaught TypeError: Property 'jQuery18302923649437725544_1386807070459' of object [object Object] is not a function api.php:1

see the screenshot attached.

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

**Attached**: {F11996}
This is actually still happening. It is a race condition that we can't do anything about and isn't actually affecting anything. It's just a weird warning that jQuery's callback system emits due to <script> limitations.

See bug 59604 for more information.

*** This bug has been marked as a duplicate of bug 59604 ***
Not happening anymore on betalabs with Chrome and FF with MAC OS X 10.8.5
This is again happening and the image inserted us appearing as a file link.See the screenshot attached.
Created attachment 14215
Screenshot

**Attached**: {F11997}
Test Environment: betalabs
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/Pagelink11thdecember?veaction=edit
Derk-Jan Hartman has responded on wiki http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=585724128&oldid=585724057
so it looks like some of the work of splitting has been done.

2. I suspect this might be caused by JS errors being thrown because of a copy action on the originating surface. All following copy actions from the source surface (even small ones) might then become corrupted I suspect. bug 58379
3. Probably the same problem as 2
4. I was not able to reproduce this: [28]
5. I was not able to reproduce this: [29]
6. I was not fully able to reproduce this, but there seems to be in issue in the paragraph following the template. bug 58384
7. This seems to be because this table also doesn't render properly in the original surface to begin with. bug 58387
8. I was not able to reproduce this [30], but again, if 2. occurred in the original source surface before your action, then this might cause that I guess. Also it seems that the syntax highlight classes are not dynamically loaded when you paste this content into the target. I reported this as bug 58388
9. Clouds seem to be the result of pasting something over existing content. bug 58389
10. not able to reproduce this yet.
SO to recap: Filing issues is definitely welcome (though only one problem per report), and if I have enough time later today I might try to split this into separate reports. It's not that bug reports aren't welcome, it's that they need to be one issue per report (which is more work for reporters, I know :-/  ).
Sorry, but this bug report is not handable so I am closing it as INVALID (which does not refer to the bugs you mention, but to this report itself). 
Please see https://www.mediawiki.org/wiki/How_to_report_a_bug
Please re-submit this as individual bugs, as you have been asked before. As it is, it's unactionable.
Screenshot

Steps to reproduce:

1.Open the editor
2.Copy a text or a link 
3.Paste it into another VE
4.Press enter

Observed Result:
Newline cannot be entered in the other VE where the text was pasted into .

It is giving an error :

Resource interpreted as Font but transferred with MIME type application/font-woff: "http://bits.beta.wmflabs.org/static-master/extensions/UniversalLanguageSelector/data/fontrepo/fonts/Autonym/Autonym.woff?version=20131205".

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

**Attached**: {F12813}
I cant reproduce this one either now .I think it got fixed somehow because now the cursor is moving to the next line automatically, after pasting a text into another VE.
The error you're showing looks like an unrelated warning. I can't reproduce the newline bug either.
Test Environment: betalabs
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=11th_december&veaction=edit
**Author:** `littlesandra88`

**Description:**
After having upgraded from mw1.19 til mw1.22 I

cd extensions
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/VisualEditor.git

and added

require_once "$IP/extensions/VisualEditor/VisualEditor.php";
$wgDefaultUserOptions['visualeditor-enable'] = 1;
$wgHiddenPrefs[] = 'visualeditor-enable';

to LocalSettings.php as described at

http://www.mediawiki.org/wiki/Extension:VisualEditor

When I visit the wiki I get in the browser

[da26e58f] 2013-12-11 13:28:05: Fatal exception of type MWException

Using CentOS6 64bit

--------------------------
**Version**: 1.22.0
**Severity**: normal
As that's support, could you please raise this in https://www.mediawiki.org/wiki/Project:Support_desk ? Thanks for your understanding!
**littlesandra88** wrote:

I would prefer to stay at mw1.22 and use an older visual editor, but finding the last git commit that broke mw1.22 is probably not easy.

When I look at the git snapshots I don't see anything in the extensions/.

Can you explain what I have to do to get all the files that makes up a full mw?
So yeah, VisualEditor is rather experimental and needs non-released versions to work. You can download either 1.23alpha (aka git master) via git or at https://toolserver.org/~krinkle/mwSnapshots/snapshots/mediawiki-core/mediawiki-latest.tar.gz , or the wmf/1.23wmf2 branch (or some other wmf branch greater than 1.23wmf2) via git. These are of course experimental versions of MediaWiki, so it may not be as stable.

You could also try downloading an earlier version of VisualEditor, if one is available.

---

Closing bug as INVALID since this isn't really a MW bug.
**littlesandra88** wrote:

Very useful variable =)

Does the following make sense?

[df264ef0] / Exception from line 3078 of /var/www/mediawiki-1.22.0/includes/GlobalFunctions.php: MediaWiki 1.23wmf2 required--this is only 1.22.0

Backtrace:

#0 /var/www/mediawiki-1.22.0/extensions/VisualEditor/VisualEditor.hooks.php(23): wfUseMW(string)
#1 [internal function]: VisualEditorHooks::onSetup()
#2 /var/www/mediawiki-1.22.0/includes/Setup.php(592): call_user_func(string)
#3 /var/www/mediawiki-1.22.0/includes/WebStart.php(153): require_once(string)
#4 /var/www/mediawiki-1.22.0/index.php(46): require(string)
#5 {main}
(In reply to comment #2)
> to LocalSettings.php. Should I do more?

$wgShowExceptionDetails
**littlesandra88** wrote:

Hmmm. Do you know which commit that broke mw1.22 comparability? Because then I could just "git checkout" that version.

I don't see any extra debug info in the browser of httpd log by adding

error_reporting( -1 );
ini_set( 'display_errors', 1 );

to LocalSettings.php. Should I do more?
(In reply to comment #0)
> After having upgraded from mw1.19 til mw1.22 I
> cd extensions
> git clone
> https://gerrit.wikimedia.org/r/p/mediawiki/extensions/VisualEditor.git

So you cloned git master of VisualEditor?

VisualEditor git master requires MW 1.23 - see https://www.mediawiki.org/wiki/Extension:VisualEditor

> [da26e58f] 2013-12-11 13:28:05: Fatal exception of type MWException

See https://www.mediawiki.org/wiki/Manual:How_to_debug
**Author:** `William915`

**Description:**
For Cantonese Wikipedia, MediaWiki:edittools is quite a useful tool to insert special characters used solely in Cantonese and not in Mandarin. It would be really helpful if it is shown in the interface of VisualEditor as well. I am not sure whether other wikis have similar requests for this.

--------------------------
**Version**: unspecified
**Severity**: enhancement
I think that this should be merged into bug 38029, though there are issues there (which I'll comment on).

*** This bug has been marked as a duplicate of bug 38029 ***
This relates to bug 50296 (which implements an alternative to MediaWiki:edittools) which is fixed, but not yet deployed. And slightly to bug 38029, because the new implementation does not actually reuse those same characters.
This is about https://zh-yue.wikipedia.org/wiki/MediaWiki:Edittools ?

So I enabled 即見編輯 (Visual Editor) on https://zh-yue.wikipedia.org/wiki/Special:%E5%96%9C%E5%A5%BD%E8%A8%AD%E5%AE%9A#mw-prefsection-betafeatures .

But comparing VE (編輯) and classical editing (改原碼) I'd love to know *where* you would display MediaWiki:edittools because there is no textfield anymore?
Screenshot of the error

Error contacting parsoid server error occurring while saving or editing a page on betalabs

See the screenshot attached

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

**Attached**: {F12611}
This was probably a Beta Labs configuration/load issue; closing.
Getting error "Error loading data from server: parsoidserver-http-bad-status: 503. Would you like to retry?"

after clicking on Edit beta on this page:
http://en.wikipedia.beta.wmflabs.org/wiki/Paste
Created attachment 14040
Screenshot of the error

**Attached**: {F12612}
Screenshot of the error

Steps to reproduce:

1.Open the Editor.
2.Open the transclusion dialog.
3.Click on the trash icon on the right
4.Click on "Apply Changes"
5.Click on Save Pages
6.Click on "Review your changes"

Observed Result:

Although there is no change in the template dialog box, the "Apply changes" button in the transclusion dialog box remains active.
After clicking on "Review your changes" it says: 
"Could not start the review because your revision matches the latest version of this page"

See the scrrenshot attached.

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

**Attached**: {F12587}
Merging into 55976.

*** This bug has been marked as a duplicate of bug 55976 ***
Created attachment 14037
Apply changes button remains active

**Attached**: {F12588}
Steps to Reproduce:
From Deryck at mw:VisualEditor/Feedback:

Suppose I have:

A foobar B
C foobar D
E foobar F
== foobarbaz ==
foobar

* When I hit delete at B, the paragraph break is removed correctly, but the cursor jumps to the beginning of the previous paragraph (A).
* When I hit delete at D, the paragraph break is also removed correctly, but the cursor jumps to or the right-hand side margin of the paragraph before that (to the right of B).
* Sometimes the paragraph break is removed, and the first letter of the next paragraph is moved to the beginning of the previous paragraph (can't figure out the conditions of this, only observed it once and can't replicate it).
* When I hit delete at F (just before a section header), the section header disappears... this might be the correct behaviour, but sadly hitting Ctrl+Z does not restore the section header.




Reproducible: Didn't try

--------------------------
**Version**: unspecified
**Severity**: normal
The original issue(s) appear(s) to be fixed. The issue spotted by Tilman has been filed as bug 67985.
Another example:

In https://en.wikipedia.org/w/index.php?oldid=616866203&veaction=edit , place the cursor left of "F" in the word "Former" in the first paragrah, and hit the delete key. The "F" is deleted correctly, but the cursor jumps two to the left (between "s" and ".").

Reproduced in Firefox and Chromium under Ubuntu 14.04.
Similar, scary things happen at fr.wp, as reported by VEditors there.

Just a few examples:
0. Try to VEdit https://fr.wikipedia.org/wiki/Utilisateur:Elitre_(WMF)/Prove .
1. Hit Del right next to "blabla".
2. Notice the cursor is now on the top left margin of the page.
3. Hit any key, say "w". I now have two more lines in my section, the first with a "b" on it, the second with a "w".
4. Wait for some seconds. Watch as a "b" gets magically added to the header title.

0. VEdit the page again.
1. Hit Del right next to "Hawker Siddeley Andover".
2. Hit any key, say "w". Watch as a pawn appears on the previous line, and both the letter and the pawn multiply after a few seconds.
The sequence above was performed on Firefox on Win7.

---------------

I've tried reproducing this on Firefox 25 on Ubuntu 12.04. Errors occur at all 3 locations for which errors have been described:

The position of the cursor after hitting delete is unpredictable (read: Deryck has seen a few different outcomes and doesn't have enough time to exhaust all the possibilities); occasionally it even goes to the correct place.

The "eating up" of the next (sometimes even previous) paragraph only occurs if you start inserting text immediately after hitting delete. If you click anywhere in the textbox or hit the arrow keys on the keyboard, no text is corrupted.

Hitting Ctrl+Z after these errors yields unpredictable behaviour (same meaning of "unpredictable").
If I copy from
https://www.mediawiki.org/w/index.php?title=Wikimedia_Engineering/2013-14_Goals&veaction=edit

to https://www.mediawiki.org/w/index.php?title=User:Eloquence/CP_tests&veaction=edit after clearing it

and select the first section (from start to "new opportunities." including the navigation template), I get a JavaScript error 

Uncaught TypeError: Cannot call method 'getType' of undefined  

on the console, and VisualEditor becomes unresponsive.

--------------------------
**Version**: unspecified
**Severity**: normal
I think that this, too, was fixed by Ed as part of his suite of fixes for template copying; marking as WORKSFORME. Again, sorry for slow triage.
How is a new user supposed to know the meaning of "Transclusion"?

This should be replaced by something easier to understand such as "Template". It should also be easier to translate....

The term is used on these messages:
	'visualeditor-dialog-transclusion-title' => 'Transclusion',
	'visualeditor-dialogbutton-transclusion-tooltip' => 'Transclusion',

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 55434 ***
BTW: I reported this after a comment on Portuguese Wikipedia:
https://pt.wikipedia.org/wiki/WP:Esplanada/an%C3%BAncios?oldid=37579154#Predefini.C3.A7.C3.A3o_para_o_Dicion.C3.A1rio_Cravo_Albin
Broken UI 1

Steps to reproduce:

1.Open the Editor
2.Add a text and select it
3.Press command+k to add link onto the text
4.Again press command+k to modify it
 

Observed Result:

The link inspector UI gets broken 

See the screenshots attached

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

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

**Attached**: {F12374}
This issue got fixed.Not occurring anymore.
Clicking on the Link icon on the link also does that
Created attachment 14017
Broken UI 2

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

1.Open the editor.
2.Select an image
3.Open the More>Special Character window


Observed Result:
The image gets deleted

Test Environment: betalabs
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=6th_december&veaction=edit

--------------------------
**Version**: unspecified
**Severity**: normal
This is intentional. Closing as INVALID.
The behavior is different when the same action is done with Latex or Hieroglyphics which has been described in a separate issue:
https://bugzilla.wikimedia.org/show_bug.cgi?id=58045
sorry there are two more steps to the repro adding it here.

4.Select any special character

The special character does get added on the first line of the page
but the image gets deleted.
Empty hiero tags

Steps to reproduce:

1.Open the editor
2.Open the hiero insertion tool
3.Now without closing it open another dialog box for example:Click on Latex/Special Characters/Reference etc.
4.Close the second window
5.Save the page

Observed Result:
The hiero insertion tool is also getting closed after step 4 but if you go to edit source you will see empty hiero tags 
Now if you log out and press the back button on the browser and try editing the page as anonymous user , there are yellow bordered boxes saying "Sorry this element can only be edited in source mode now", on the positions where empty hiero tags are added

See the screenshots attached.

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

**Attached**: {F12355}
Is this still occurring?
(In reply to comment #1)
> Created attachment 14012 [details]
> yellow bordered boxes

I see one tooltip (singular) saying "Sorry, this element can only be edited in source mode for now." I assume that's what you mean...

**Attached**: {F12357}
Created attachment 14012
yellow bordered boxes

**Attached**: {F12357}
screenshot

Steps to reproduce:

1.Open the Editor
2.Add a link
3.Place the cursor just after that link position
4.Go to More>Special Characters

Observed Result:
The special character insertion tool does not open up

See the screenshot attached

Test Environment: betalabs
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=6th_december&veaction=edit

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

**Attached**: {F12351}
Cannot reproduce it now on betalabs:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Page_create&veaction=edit
**Author:** `jhall`

**Description:**
Per a request from James F, we should start to expand the selection of environments (OS and browser combinations) that Visual Editor automated tests run via CloudBees.  

For example, add a "Internet Explorer 10 on Windows 8" test, and related variations that CloudBees/SauceLabs can accommodate.

Per Chris M, a good way to get started is to copy the existing "Selenium" template in CloudBees and figure out what we need to do to add Windows into the mix.

--------------------------
**Version**: unspecified
**Severity**: normal
Yes.
Can this be closed? We have this job now, for example:

https://integration.wikimedia.org/ci/view/BrowserTests/job/browsertests-VisualEditor-en.wikipedia.beta.wmflabs.org-windows_xp-firefox-sauce/
Jeff, where are the jobs configured? I do not see them anywhere. This is where I have looked:

https://github.com/zeljkofilipin/jenkins-job-builder-config
https://gerrit.wikimedia.org/r/#/admin/projects/integration/jenkins-job-builder-config

Did you create the jobs manually?
**jhall** wrote:

Tests have been setup in CloudBees at the following locations:

1) Chrome on Windows XP: https://wmf.ci.cloudbees.com/view/ve/job/VisualEditor-en.wikipedia.beta.wmflabs.org-windows_xp-chrome/
2) Firefox on Windows XP: https://wmf.ci.cloudbees.com/view/ve/job/VisualEditor-en.wikipedia.beta.wmflabs.org-windows_xp-firefox/
Change 110980 abandoned by Jhall:
Adding new priority Windows browser tests for VisualEditor.

Reason:
Abandoning this change per a discussion between Chris, Željko and myself.  We have decided to implement new (browser + OS) combinations for use with SauceLabs via environment variable values rather than via hard-coded amendments to the mediawiki-selenium gem itself.

https://gerrit.wikimedia.org/r/110980
**jhall** wrote:

Setting bug status back to resolved since the 110980 Gerrit patch is a first step only; if that change works out well, we can add additional (browser + OS) combinations to work towards eventually resolving this bug.
Change 110980 had a related patch set uploaded by Jhall:
Adding new priority Windows browser tests for VisualEditor.

https://gerrit.wikimedia.org/r/110980
**jhall** wrote:

Per a chat with Rummana, the priority test environments to add (via CloudBees and Sauce Labs) are:

1) Chrome on Windows XP
2) Firefox on Windows XP
(In reply to comment #3)
> #2 The entire config folder will soon(tm) be moved to mediawiki-selenium
> gem[2]. We should probably rename config.yml to browsers.yml (since it no
> longer has any other information, only browsers) and expand the number of
> combinations, like Wikibase has already done[3]

config.yml is now moved to mediawiki-selenium gem. Feel free to expand the number of browser/OS combinations in the gem.
**jhall** wrote:

(In reply to comment #3)
> #1 I would hesitate to add more Jenkins jobs until existing ones[1] are rock
> solid (meaning there were no failures in a week or so).
> 
> #2 The entire config folder will soon(tm) be moved to mediawiki-selenium
> gem[2]. We should probably rename config.yml to browsers.yml (since it no
> longer has any other information, only browsers) and expand the number of
> combinations, like Wikibase has already done[3]
> 
> 1: https://wmf.ci.cloudbees.com/view/r-ve/
> 2: https://gerrit.wikimedia.org/r/#/c/90560
> 3:
> https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/master/tests/
> browser/config/browsers.yml

Thanks Željko - I agree with both of your points, especially #1, which is an ongoing problem area (which I am working on!)
#1 I would hesitate to add more Jenkins jobs until existing ones[1] are rock solid (meaning there were no failures in a week or so).

#2 The entire config folder will soon(tm) be moved to mediawiki-selenium gem[2]. We should probably rename config.yml to browsers.yml (since it no longer has any other information, only browsers) and expand the number of combinations, like Wikibase has already done[3]

1: https://wmf.ci.cloudbees.com/view/r-ve/
2: https://gerrit.wikimedia.org/r/#/c/90560
3: https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/master/tests/browser/config/browsers.yml
**jhall** wrote:

In addition to the new template in CloudBees, I think we'll need to expand the config.yml file in the VisualEditor repo:

https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/master/modules/ve-mw/test/browser/config/config.yml

For example, our existing "firefox" profile is hard-coded to Firefox version 23 on Linux, so we'll need to add more entries for Firefox on Windows 8, etc.
**jhall** wrote:

Created a new test template to mess around with:

https://wmf.ci.cloudbees.com/template/81889c2c-ef15-4fad-b39b-8256eb9e841a/
When ve-activated class is set on the body, it would be lovely to deactivate this feature as it's rather irritating. Think it's Shift+cursor or Ctrl+Shift+cursor or something similar?

--------------------------
**Version**: master
**Severity**: normal
We backported this fix to 1.23wmf6, so mediawiki.org and all sister sites should be fixed now.
Change 100611 merged by MarkTraceur:
Move clearInterface things to mw.LightboxInterface

https://gerrit.wikimedia.org/r/100611
Change 100611 had a related patch set uploaded by MarkTraceur:
Move clearInterface things to mw.LightboxInterface

https://gerrit.wikimedia.org/r/100611
Bam. Done. Thanks.
Change 99722 merged by jenkins-bot:
Move clearInterface things to mw.LightboxInterface

https://gerrit.wikimedia.org/r/99722
Change 99722 had a related patch set uploaded by MarkTraceur:
Move clearInterface things to mw.LightboxInterface

https://gerrit.wikimedia.org/r/99722
This may be because we don't clear keydown listener events on closing the viewer. Patch incomiiiiing
Screenshot of the error

Steps to reproduce:

1.Open the Editor
2.Add a reference to a line
3.Add a references list
4.Now add someother lines after the reflist with references
5.Save the page

Observed Result:
The following error appears where as there is already a reflist.

Cite error: There are <ref> tags on this page, but the references will not show without a {{reflist}} template (see the help page).

See the screenshot attached

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

**Attached**: {F12198}
*** This bug has been marked as a duplicate of bug 54906 ***
Test Environment: production
Browser: Chrome Version 26.0.1410.65
OS: MAC OS X 10. 8. 5 
Page:
https://en.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/testinfobox
Screenshot of the error

Steps to reproduce:

1.Click on Create beta
2.Press Shift+Right arrow

Observed Result:
Some images/logos from media commons opens up with image viewer in VE.

See the screenshot attached.

Following errors are found:
Uncaught TypeError: Cannot read property 'pages' of undefined
XMLHttpRequest cannot load http://commons.wikimedia.org/w/api.php?action=query&format=json&list=users&ususers=Mike%2Elifeguard&usprop=gender. Origin http://en.wikipedia.beta.wmflabs.org is not allowed by Access-Control-Allow-Origin. /w/index.php?title=Rys&veaction=edit#mediaviewer/File:Wikibooks-logo.svg/1:1
Uncaught TypeError: Cannot read property 'pages' of undefined
XMLHttpRequest cannot load http://commons.wikimedia.org/w/api.php?action=query&format=json&list=users&ususers=-xfi-&usprop=gender. Origin http://en.wikipedia.beta.wmflabs.org is not allowed by Access-Control-Allow-Origin.

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

**Attached**: {F12098}
I think this was fixed a while ago with fixes to MediaViewer.
Pressing just right arrow is now bringing up those logos
Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 &       FF 25
OS: MAC OS X 10. 8. 5
Currently, while saving a page or when a link insertion too; searches for matching page it is taking longer than usual time in Betalabs.

I am not facing it any other environment.

--------------------------
**Version**: unspecified
**Severity**: normal
I think this was due to the Labs cluster being DDoSed; marking as WORKSFORME as that's been cleared up.
Beta features have icons to represent them at Special:Preferences.

They usually show a schematic representation of a MediaWiki page with a logo in the top left corner, and this of course means that they should be flipped for RTL languages.

Some of them are trivial - just a horizontal flip.

Some of them are less trivial - for example, in the one for the VisualEditor formula editing I flipped the image and then flipped the Sigma icon inside it so it would still look like Σ and not flipped.

Some of them are even less trivial, for example the icons for the font style experiments. It shows the Latin letter A, and it's weird to show a Latin letter in the beginning of a right-to-left text. Luckily, there are only two major right-to-left scripts, so I made one icon for Hebrew and one for Arabic.

Some relevant sample commits by myself, already merged:
* https://gerrit.wikimedia.org/r/#/c/94379/
* https://gerrit.wikimedia.org/r/#/c/94269/
* https://gerrit.wikimedia.org/r/#/c/94423/

On this commit Jon and Juliusz complained that the image should be re-saved with a smaller size and less metadata:
* https://gerrit.wikimedia.org/r/#/c/98159/

The SVGs from the previous merged commits may have to be re-done as well.

Any future beta features should have RTL-compatible icons from the start, preferably done by professional designers.

See some more details here:
https://www.mediawiki.org/wiki/Design_best_practices#Right-to-left_languages

--------------------------
**Version**: unspecified
**Severity**: normal
Done by Amir. In future, it's the PM's job (i.e. my job for now) to make sure this is done before deployment.
Try editing https://www.mediawiki.org/wiki/User:Amire80/phpi in VE.

The template's content doesn't show when editing in VE.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to Alex Monk from comment #1)
> Works for me.

For me too. Probably got fixed at some point. Thanks for testing.
Works for me.
Screenshot

I am getting pawn while typing fast on some pages on betalabs sometimes.
It is not always reproducible.
I will update the bug if i find any steps to reproduce.

See the screenshots attached.

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

**Attached**: {F12011}
These issues seem now to be fixed.
Got following error while this was happening:
Uncaught Error: Offset could not be translated to a DOM element and offset: 93
Uncaught Error: Offset could not be translated to a DOM element and offset: 169
Created attachment 13973
screenshot of pawns

**Attached**: {F12012}
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/New_page_on_latex
**Author:** `Wikifram`

**Description:**
Currently, bugs about Flow are shelved under Mediawiki extensions, unlike e.g. VisualEditor or less important things like QRpedia. Considering the probable serious influx of Flow bugs in the near future, I would propose that it gets its own "level", so that e.g. in the search box it is selectable (I mean that if you select "search bugs" on the left side, under "Product", you should be able to choose "Flow" directly.

--------------------------
**Version**: unspecified
**Severity**: normal
**Wikifram** wrote:

Yeah, sorry about my earlier remark, I was pissed off at a WMF representative (for a oomment made at Mediawiki, not on Bugzilla) and your comment came for me at the wrong time. I shouldn't have replied so strongly. I still think it isn't user friendly to not have it separately, but I appreciate that you try to make it easier for everyone involved anyway.
I wouldn't translate it to that, however Bugzilla is primarily a tool for developers and tech-savvy users (though I try to make it more user-friendly, e.g. by the guided bug entry form which is now linked from the very top of https://bugzilla.wikimedia.org/enter_bug.cgi?product=Wikimedia since yesterday).

If you don't feel comfortable on https://bugzilla.gnome.org/enter_bug.cgi and don't know that Flow is a "MediaWiki extension" (and can be found under that product), http://www.mediawiki.org/wiki/Extension:Flow and especially https://www.mediawiki.org/wiki/Flow_Portal#Contact_and_links provide links how to provide feedback and also where exactly to find and create new bug reports or feature requests. 

Furthermore, once Flow has seen wider deployment, I expect the Flow team and involved Communication folks to set up similar Feedback channels like for VisualEditor at https://en.wikipedia.org/wiki/WP:VE/F which do not necessarily require to interact with Bugzilla.
**Wikifram** wrote:

So, translated, "fuck everyone wanting to find something, Bugzilla is not for you"? Very user-friendly reply. What's the advantage of keeping Flow buried among the other extensions like "AbsenteeLandlord", "Desysop", and so on? I hope yu will reconsider once you get lots of Flow bugs here, which will probably be soon.
Flow is technically speaking an extension, and Bugzilla's taxomony is not primarily based on visibility. 
(However there have been exceptions from rules, e.g. when the codebase is rather complex and requires subcomponents, like in case of VisualEditor.)
Steps to reproduce:

1.Click on the Edit beta button
2.Switch to Edit Source
3.Switch back to VE
4.Click on Cancel
5.Reload the page


Observed Result:
Even after cancelling the edit, in the URL "&veaction=edit" still remains appended , therefore after reloading the page, VE opens up.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 57901 ***
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=Groel&veaction=edit
Also, set up initial jobs for projects that already use csslint in their local-dev Gruntfile (oojs-ui and visualeditor at the moment).

--------------------------
**Version**: wmf-deployment
**Severity**: normal
(In reply to comment #5)
> Does that also lint less or is there a extra tool?

No, we don't yet use cssslint in mediawiki-core (current code doesn't pass) and neither does it validate LESS in any way.
This has been installed, deployed and is now also actively used by various projects.

In the main 'test' pipelines, however, this is no longer used as we have since migrated to using npm-test (from package.json) directly by installing it in a virtual machine in labs and executing it as specified by the source repository (instead of the install provided by Jenkins).
Does that also lint less or is there a extra tool?
Change 98868 merged by Krinkle:
Create macro for csslint and use in oojs-ui and VisualEditor

https://gerrit.wikimedia.org/r/98868
Change 98868 had a related patch set uploaded by Krinkle:
Create macro for csslint and use in oojs-ui and VisualEditor

https://gerrit.wikimedia.org/r/98868
Change 98722 merged by jenkins-bot:
Install Grunt plugin for csslint

https://gerrit.wikimedia.org/r/98722
Change 98722 had a related patch set uploaded by Krinkle:
Install Grunt plugin for csslint

https://gerrit.wikimedia.org/r/98722
Screenshot of the error

Steps to reproduce:

1.Click on the Edit button
2.Type something on the first line
3.Place the cursor at the beginning of the line and insert a template "Bronze Age"
4.Save the page
5.Reopen the editor
6.Click on More>Reference and add a reference
7.Type something on the CE
8.Click on Save Page

Observed Result:
The Save page loader continues for indefinite amount of time.
The following errors are found in the developers tool:

Uncaught TypeError: Cannot call method 'apply' of undefined load.php:2
Uncaught Error: Unbalanced input passed to document load.php:109
Uncaught TypeError: Cannot read property 'keyedNodes' of undefined load.php:201

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

**Attached**: {F12768}
I can't reproduce this, so I assume it is fixed. Please reopen if reproduction of the bug is achieved.
This is so old I wonder if it still happens?
I encountered a very similar bug two days ago at https://en.wikipedia.org/w/index.php?title=San_Francisco%E2%80%93Oakland_Bay_Bridge&oldid=650099835&veaction=edit, twice (once when clicking the Save button, and then after starting anew and clicking "Switch to source editing" in the Hamburger menu. In both cases, nothing happened after the click except console error messages, and consequently I wasn't able to save my edit).

I wasn't able to reproduce it again, but I remember that the edit involved deleting the first reference and replacing it with a different one, using a citation template where I added an additional (non-default) parameter and then deleted it again in the template editor.

This was in Chrome on a MacBook. Unfortunately I lost the JavaScipt console's output due to an unrelated crash, but I remember that it contained the word "unbalanced" just like in the original bug report here.
Could not reproduce on https://en.wikipedia.org/w/index.php?title=User%3AAKlapper_%28WMF%29%2FSandbox%2FT88306&diff=649905376&oldid=649903809 following exactly the steps in T59898#645389 in Firefox 36. 

Is this still an issue, 15 months later? Setting task status to "Stalled".
Now The Save Page button does not work after the following steps:
1.Click on the Edit button
2.Type something on the first line
3.Place the cursor at the beginning of the line and insert an image 
4.Save the page
5.Reopen the editor
6.Press Delete twice
7.Type something 
8.Click the button "save page"

Following error appears:
Uncaught Error: Unbalanced data: looking for closing /mwBlockImage load.php:150
I can't reproduce now - perhaps due to fixing bug 57654?
Another way to reproduce it:
After step 5 just click on "Delete" and click the button "Save".

The following error appear this time:


Uncaught Error: Unbalanced set of replace operations found load.php:65
Uncaught Error: Unbalanced data: looking for closing /mwBlockImage load.php:146
This issue can be reproduced with images too instead of template.
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/infinite_save?veaction=edit
Screenshot

Steps to reproduce:

1.Click on the "Edit" button for a page
2.Type something with a link on the main page
3.Add a template for example:Bronze Age
4.Save the page
5.Reopen the editor

Observed Result:

1. Opening the editor selects/highlights the template,but if user attempts to press delete it deletes the first line gets deleted

2.If user clicks on the numbered list or bullet list icon from the toolbar a link icon appears on the template

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

**Attached**: {F12499}
Possibly maybe this is now fixed? I couldn't reproduce, but I may have been doing it wrongly.
Slight modification on steps to reproduce:

3.When you add a template place your cursor at the beginning of the first line which contains a link.
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)/sandbox?veaction=edit
screenshot

Steps to reproduce:

1.Place the cursor at the end of the text or in the beginning or in the middle of a text
2.Now select any or all of the options from More>Computer Code/Strikethrough/Underline/Superscript/Subscript

Observed Result:

Observe that all the options are highlighted in the menu bar but the text format does not change accordingly.If the format of the text is not suppose to change, providing way to disable to the highlight will be better

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

**Attached**: {F12445}
It looks like a formatting button like "subscript" is highlighted if a character typed in the cursor's current location would have that formatting. This seems like a sensible behavior.
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_%28WMF%29/pawn?veaction=edit
Steps to reproduce:

1.Click on the Edit button for a page
2.Insert a image in the page
3.Go to the media settings and add another image as caption
4.Save the page
5.Reopen the editor .
6.Open the image settings and delete the image as caption.
7.Undo the action
8.Click on the media settings button for the image that is as caption

Observed result:
A media settings dialog box appears with no content but it cannot be crossed out .Also the "apply changes" button does not work therefore editor becomes unresponsive.

--------------------------
**Version**: unspecified
**Severity**: normal
Looks like this got fixed at some point.
Test Environment: production
Browser:  FF 25
OS: MAC OS X 10. 8. 5 
Example Page:https://en.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/cancelled_edit_then_create_page&veaction=edit
Intention:
Add a label to [http://example.com/]

Steps to Reproduce:
1. Open the page in VisualEditor
2. Click on the link (which displays as "[1]")


Actual Results:  
Nothing.  It is not possible to edit the link.  If opened manually, the link inspector is empty.

Expected Results:  
1. That the link icon would display when the link was selected.
2. That the link inspector would show the URL.
3. That a label could be added (to create [http://example.com Example.com])

Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 53505 ***
Steps to reproduce:

1.Click on the edit button for a page where you have some images on the right of the page

2.Type something as the first line
3.Delete the first line by pressing backspace
4.When it deletes the first character of the line ,pressing backspace again still keeps the cursor in the main page
5.Now type something


Observed Result:
Though the cursor is in the main page,a pawn appears inside the caption of the image at the right.

A pawn will appear in the main document for the following steps:
5. if after step 4 , user presses backspace again 
6.While the image at the right is highlighted press the Right arrow > from the keyboard
7.When the cursor comes to the main article type something

A Pawn appears in the main document.

--------------------------
**Version**: unspecified
**Severity**: normal
Possibly got fixed by https://bugzilla.wikimedia.org/show_bug.cgi?id=57927
Cannot reproduce it now.
Created attachment 13930
Screenshot

**Attached**: {F12417}
Test Environment: production
Browser: Chrome Version FF 25
OS: MAC OS X 10. 8. 5 
Example Page:https://en.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/cancelled_edit_then_create_page&veaction=edit
Steps to reproduce:

1.Click on the edit button for a page where you have a image on the right of the page which has another image as caption

2.Type something as the first line
3.Delete the first line by pressing backspace
4.When it deletes the first character of the line ,pressing backspace again still keeps the cursor in the main page
5.Now add a reference to the empty space,which gets added to the caption of the image at the right.
6.Now type something on the second line and add a reference

Observed Result:

The dialog box for adding reference does not appear anymore.

--------------------------
**Version**: unspecified
**Severity**: normal
Test Environment: production
Browser: FF 25
OS: MAC OS X 10. 8. 5 
Example Page:https://en.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/noref?veaction=edit
Screenshot of the pawn

Steps to reproduce:

1.Click on the Edit button
2.Add an image in the caption of that media.
3.Type a text in the caption
4.Delete the text by pressing the backspace
5.When the cursor reaches the image at the right,Press the right arrow to go back to the initial position of the deleted text.
6.Type something again at that position.

Observed Result:
A Pawn (♙) appears in the Media Setting

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

**Attached**: {F12405}
This appears to be long-fixed.
Test Environment: production
Browser: FF 25
OS: MAC OS X 10. 8. 5
Example Page:https://en.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/test_field&veaction=edit
*** This bug has been marked as a duplicate of bug 48789 ***
Parsoid doesn't work when you add the visualeditor role in Labs-Vagrant setup,
clients get 404 errors. After tweaking parsoid to log the actual error (bug 57694), /var/log/upstart/parsoid.log contains

  Stack trace: DoesNotExistError: Page Fetch failure for null : Error: Invalid URI
  "undef/w/api.php?format=json&action=query&meta=siteinfo&siprop=namespaces%7Cnamespacealiases%7Cmagicwords%7Cfunctionhooks%7Cextensiontags%7Cgeneral%7Cinterwikimap%7Clanguages%7Cprotocols"

Obviously undef/w/api.php is going to give 404.

The bad URL path arises because puppet/manifests/roles.pp sets $server_url to 'undef' if forwarded_port isn't set, and it somehow isn't set in labs-vagrant. puppet/modules/mediawiki/templates/parsoid.localsettings.js.erb propagates this to /srv/parsoid/js/api/localsettings.js which contains 
  parsoidConfig.setInterwiki( 'localhost', 'undef/w/api.php' )

(Erik Bernhardson figured all this out!)

One fix is to not set $server_url to undef. Patch coming.

--------------------------
**Version**: unspecified
**Severity**: normal
Thanks for the detailed report and the patch.
Change 98060 merged by Ori.livneh:
Set $server_url to something other than undef

https://gerrit.wikimedia.org/r/98060
Change 98060 had a related patch set uploaded by Spage:
Set $server_url to something other than undef

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

Steps to reproduce:

1.Click on the "Edit" button
2.Type a text with reference in the page
3.Make it a bulleted list by selecting the option from toolbar.
4.Press Enter to entry the second item on the list but leave it blank 
5.Now click on More>References list to add a reflist to the page
6.Save the page

Observed Result:

The reflist is appearing as bulleted list

See the screenshot attached.

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

**Attached**: {F12350}
Seems to work correctly now.
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_%28WMF%29/testlive
Screenshot of the pawn

Steps to reproduce:

1.Click on the Edit button
2.Add a reference to a text
3.Select the reference icon
4.Press left arrow key to move the cursor to the left of the icon
5.Now delete all of the text on the left of the icon by pressing backspace button

Observed Result:

A pawn ♙ appears right next to the reference icon.

See the screenshot attached

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

**Attached**: {F12224}
This looks fixed to me. Not sure exactly when.
Test Environment: production
Browser: FF 25
OS: MAC OS X 10. 8. 5 
Example Page: https://en.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/sandbox
Steps to reproduce:

1.Create the Edit button
2.Select a text
3.Open the link inspector
4.Click on the clear formatting icon from the toolbar
5.While the link inspector is still open select the first matching page
6.Apply the link

Observed Result:
The link did not get applied.

--------------------------
**Version**: unspecified
**Severity**: normal
We now close the inspector when you click into the toolbar, which essentially fixes the underlying issue.
I would suggest to close the inspector as user clicks on clear formatting
Test Environment: production
Browser: FF 25
OS: MAC OS X 10. 8. 5 
Example Page: Try applying the link to page "link" to the text link on this page:
https://en.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/test_field?venotify=created
The reference for the main page

Steps to reproduce:

1.Click on the Edit button
2.Add a reference to a text
3.In the reference dialog add an image
4.Also type some text into that reference box (for example "The content" in this case.)
5.Now select the image
6.Go to Media Settings
7.Now add a reference to that image
8.Type anything for this second reference box
9.Apply changes in all three dialog boxes
10.Save the changes 
11.Reopen the editor
12.Select the reference [1]
13.Open the reference dialog box

Observed Result:
The text "The content" appears as a template with a highlighted blue box around it.Now click on the [1] reference on the image by going to the media settings of the image.
It opens the same content for the first reference and it keeps on opening the same window as you repeatedly do it for all the reference windows appears.

Expected Result:
The reference on the main page and the reference on the image should be different content.But since the reference in image [1] is pointing to the same [1] for the article ,this issue arises.

See the screenshots attached

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

**Attached**: {F12091}
Re-checked - seems that the contents of all "nested" references are displayed correctly. No repeatedly open windows appear. 

Marking as resolved.
Test Environment: production
Browser: FF 25
OS: MAC OS X 10. 8. 5 
Example Page:https://en.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/test_copy_and_paste?veaction=edit

Click on the [1] reference of this page.
Created attachment 13908
Opening the same dialog box unlimited times

**Attached**: {F12093}
Created attachment 13907
How it appears after step 13

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

1.Click on the Edit button
2. Place the cursor in the middle of a text, for example between u and r of "cursor"
3.Try different heading format and bullet or numbered list option:all of them work
4.But try formatting to Bold/Italic/No format: it does not work but the buttons are selected.

--------------------------
**Version**: unspecified
**Severity**: normal
That's supposed to do nothing initially, then when you start typing, the text you type will be bold/italic/whatever.
Test Environment: test2
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Example Page:https://test2.wikipedia.org/w/index.php?title=Testing2511&veaction=edit
Steps to reproduce:

1.Click on the "Edit" button for a page in production
2.At the beginning of the article place a template
3.Write a paragraph following that template.
4.Save the page
5.Reopen the page in Edit mode

Observed Result:
The template gets selected(blue highlight appears) automatically.However the template icon does not appear to edit the template rather a four sided drag icon appears on it.
Now if you press the delete button while the template is selected ,the following paragraph gets deleted.Pressing undo does not get it back on the page.User have to cancel this edit session and restart again to by pass the issue.

--------------------------
**Version**: unspecified
**Severity**: normal
This now [[https://en.wikipedia.org/w/index.php?title=User%3ARYasmeen_%28WMF%29%2Ftemplate_at_the_beginning&type=revision&diff=663104473&oldid=583275067|works correctly]]!
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/template_at_the_beginning
This is where the cursor shows up in the text

Might be related to https://bugzilla.wikimedia.org/show_bug.cgi?id=41064, or not.

1. Reach https://en.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&oldid=583262564 .
2. Put the cursor after the last reference.
3. Hit Enter once. A new bullet is correctly added.
4. Hit Enter again.

Possible outcomes:
1) see screenshot: the cursor blinks between two lines, on the word "cognitive" (observed in Chrome, Vector/Monobook);
2) the cursor is attached to the top right corner of the picture of Emily Deschanel (Firefox, Vector);
3) the cursor is nowhere in sight (Firefox, Monobook).

Notice that if you repeat the procedure at this point, it will work in Chrome, it will still fail in FF.

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

**Attached**: {F12043}
This was fixed a couple of weeks ago in the HandleEnter re-write work, I think.
(Sorry, please read, "it will work in Firefox, it will still fail in Chrome".)
Consider that you have an internal wiki link that doesn't use a pipe, for example "[[Danzig]]". If you edit the page in VE and change the text from "Danzig" to "Gdańsk" without using the link inspector the result will be "[[Danzig|Gdańsk]]". See the history of https://en.wikipedia.org/wiki/User:Amire80/links-nopipe .

It is not obvious to the user what is happening - does the target or does it not? The users may want to achieve one result or the other in different cases. My own hunch is that users will more frequently want to change the target as well, although that is just a guess.

If we have a reason to think that one behavior is far more common than the other, then it should be the default. If we are not sure, than some more indication about the target will be useful. The only ways to be sure before saving are to check the diff to open the link inspector.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54947
*** This bug has been marked as a duplicate of bug 54947 ***
(In reply to Amir E. Aharoni from comment #0)
> Consider that you have an internal wiki link that doesn't use a pipe, for
> example "[[Danzig]]". If you edit the page in VE and change the text from
> "Danzig" to "Gdańsk" without using the link inspector the result will be
> "[[Danzig|Gdańsk]]".

I get the opposite of this ([[Gdańsk|Danzig]]), but this bug still feels valid to me.
... Just an explanation for my guess: In the source editor changing [[Nasik]] to [[Nashik]] requires the adding one 'h'. In the current version of VisualEditor it requires adding one 'h', opening the link editor and adding the 'h' there, too.
screenshot

Steps to reproduce:

1.Create a page
2.Type something
3.From the "Edit Source" option add the following after the text:
<math>\frac{-b \pm \sqrt{b^2 - 4ac}}{2a}


</math>

4.Save the page
5.Click on Edit-beta again


Observed Result:
A Return character appears after the text in edit mode

See the screenshot attached

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

**Attached**: {F12681}
*** This bug has been marked as a duplicate of bug 48290 ***
Test Environment: production
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5 
Sample Page:https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/text_then_math?veaction=edit
Steps to reproduce:

1.Create a page with a long content first

2.Towards the end add references

Observed Result:

Every time user adds a reference it takes him to the beginning of the article making him scroll down all the way down to get to where he was adding a reference

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 58090 ***
Related to 57271?
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_%28WMF%29/ref_not_editable
The two links at the end of the third line are external unnamed links.
VE does not allow editing them.
The markup guide for en.wp says these links are "Only used within article body
for footnotes", but of course they might be used also outside ns0.

--------------------------
**Version**: unspecified
**Severity**: normal
**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=57418
https://bugzilla.wikimedia.org/show_bug.cgi?id=57420
Merging with bug 53505.

*** This bug has been marked as a duplicate of bug 53505 ***
Go to :https://en.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/table_test

See that in the VE mode and Edit source mode the reference list is showing up but in Read mode there is no reference list.

Test Environment: production
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5

--------------------------
**Version**: unspecified
**Severity**: normal
Seems to be because there are two reference list invocations on the page. The fact that the read mode only displays the first seems to be by design.
Changing the summary to a more generalized one: References list does not appear when it follows a table in a page.
Found the  the steps to reproduce:

1.Create a page
2.Add some references
3.Add a table into it with the following from the edit source mode:
{| border="2"
|+ [[my table]]

|-
|
# first cell<ref>reference</ref>
|
# [[second cell]]
|
* third cell
|-
|1[[File:Tibouchina urvilleana flower ja.jpg|thumb|150x150px|{{Like resume}}]]
|2{{Like}}
|3<references />

|}

4.Add references list at the end of the page
5.Save the page

Observed Result:
The references list does not appear in the view mode.
Created attachment 13870
In the read mode

**Attached**: {F12503}
Created attachment 13869
In the VE mode

**Attached**: {F12502}
In read mode

Steps to reproduce:

1.Click on the Edit source.

2. Type the following:

table test title

{| border="0"
|+ my table

|-
|first cell 
|second cell 
|third cell
|-
|1
|2
|3

|}

3.Save the page
4.View the page in read mode
5.Open the page in VE mode.

Observed Result:
There is not border for the table in read mode but when you open the page in VE mode it renders the table with a border=1.

See he screenshots 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_(WMF)/table_test

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

**Attached**: {F12479}
*** This bug has been marked as a duplicate of bug 57295 ***
Created attachment 13864
In VE mode

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

1.Click on the Edit mode
2.Add a reference 
3.Add the same reference 5 times in that page
4.Save the page
5.Go to Edit Source

Observed Result:
I think, due to repeated citation of the same reference with no defined name ,a name with value (:0) is added to the <ref> tags for all the references that is using the same reference

But, if user intends to change the name of the original reference to a more meaningful name for future reference purpose he might do the following steps

6. Change the name value from ":0" to "bbc" for the first references
7.Close the editor 
8.Click on Edit now.
9.Hover over other references which were using same references

Observed Result:
A message shows up this reference cannot be edited in the VE ,can only be edited in edit source mode.

Can this message be more precise to point where the problem is?For example in the read mode it says "Invalid <ref> tag; no text was provided for refs named :0"

--------------------------
**Version**: unspecified
**Severity**: normal
Not VE-specific, but a larger issue with how Cite.php "works" (hint: it doesn't).

*** This bug has been marked as a duplicate of bug 18103 ***
Created attachment 13861
Screenshot of the error

**Attached**: {F12468}
**Author:** `jhall`

**Description:**
This is a follow-up to this recent change to the VisualEditor browser tests:

https://gerrit.wikimedia.org/r/#/c/96793/

Since a user may neglect to explicitly export a value for the BROWSER_LABEL environment variable, it might be a good idea to enhance hooks.rb for the mediawiki-selenium RubyGem to add a warning where that value is undefined.  

The danger is that where the BROWSER_LABEL value is undefined, individual tests will not target the intended wiki pages, since those pages are expected to have the BROWSER_LABEL string included in the page URL.

The hooks.rb file already issues similar warnings for the MEDIAWIKI_USER and MEDIAWIKI_PASSWORD variables in the "Before('@login')" method:

https://github.com/wikimedia/mediawiki-selenium/blob/master/lib/mediawiki/selenium/hooks.rb

--------------------------
**Version**: unspecified
**Severity**: normal
**jhall** wrote:

This task is invalid now that warnings for undefined BROWSER, PLATFORM and VERSION environment variable values have been added to env.rb in the most recent versions of the mediawiki_selenium Rubygem, so closing this ticket as INVALID.
This happens in FF (both skins).
1. https://fr.wikipedia.org/wiki/Utilisateur:Elitre_%28WMF%29/Prove?veaction=edit
2. reach the Sources section.
3. copy the (en) template and paste it before "Franca C".
4. hit space.

A pawn appears.

--------------------------
**Version**: unspecified
**Severity**: normal
This appears to be long-fixed.
https://fr.wikipedia.org/w/index.php?title=Utilisateur:Elitre_(WMF)/Prove&oldid=98530979
Intention:
I want to blank a page, and add new contents.

Steps to Reproduce:
Since this does not seem to happen on each page, I'll add the steps I followed to reproduce it.

1. VEdit https://it.wikipedia.org/wiki/Utente:Elitre_(WMF)/Sandbox_VE with Firefox and Monobook. 
2. Right-click, select all, delete.
3. Click to re-gain focus.
4. Type something. A pawn will appear.
5. Review your changes. Notice that not all of the contents were actually deleted after #2. Also notice that some or all of your newly added text might be missing. 
6. Save the page. Your text (most or all of it) shouldn't be there. What you have are random chunks of old text. And your pawn :)



Actual Results:  
While reproducing, the following also occurred to me:
1. After blanking, a weird cursor (like an arrow pointing up) appeared at the beginning of the line. After typing for a while, Back Space and the keyboard navigation arrows wouldn't work. 
2. When VEditing the page created after #6, blanking it and then clicking on a line to make the cursor appear resulted in fragments of words appearing. If I tried to type, I'd also get rapidly multiplying pawns.
(All these behaviors are not new to me.)   

Expected Results:  
I expected the page to be really blank, and pawn-less :)

Reproducible: Sometimes

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=42404
Up-merging to bug 64917 (whoops)

*** This bug has been marked as a duplicate of bug 64917 ***
Original report at en.wp:
<<If I go to Plato, enter VE, right click, select all, and then press some letter or number, a pawn will appear. Also, if I review changes, there is still material left is the "your text" section. Firefox 25.0.1; Windows 7 Professional SP1 64-bit; Monobook skin. --Atethnekos>>.
Steps to reproduce:

1.Click on the edit button
2.Add some content in the page
2.Add some references in the page
3.Add references list from More>References list.
4.Now Go to More>Transclusion
5.Add the template reflist
6.Click on the "Save Page" button

Observed Result:
The save page button does not work ,user had to cancel this edit session and re-work again on the editor

There is no js error for this in the console.

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

--------------------------
**Version**: unspecified
**Severity**: normal
It is possible to save correctly now. It's still //not// possible to have a page display more than one `<references />` block for the same ref group, but that seems to be by design.
I think its better if either we do not permit them to include both and explicitly notify them or both gets added properly.
However the issue is not same when user does the vice versa.That is, if he had reflist template before and adds again a references list it does get added in the page.But,the later one does not show up in the read mode but on VE edit mode and on edit source mode where both the {{Reflist}} and <references /> are present
Steps to reproduce:

1.Open the VE editor for a page.
2.Make some edit
3.Leave the editor open for a long time (more than an hour)
4.Come back after that idle time and click the button "Save Page"


Observed Result:
The content does not get saved.Shows a js error in the console

Uncaught TypeError: Cannot read property 'saveRetries' of undefined
(anonymous function)
fire load.php:12
self.fireWith load.php:14
self.fire load.php:14
(anonymous function)
fire load.php:12
self.fireWith load.php:14
done load.php:119
callback

--------------------------
**Version**: unspecified
**Severity**: normal
This [[https://en.wikipedia.org/w/index.php?title=User%3ANeil_P._Quinn-WMF%2Fsandbox&type=revision&diff=662373500&oldid=662187275|now seems to work]]!
I am curious about how different this is from the common behavior with the wikitext editor, which will usually display a message like "Sorry! We could not process your edit due to a loss of session data. Please try again. If it still doesn't work, try logging out and logging back in." (not sure if this is the actual one though) and which "fixes" itself if you just retry to save.
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/test_reference
While testing on production , I found that when I select a specific template all the related parameters show up on the dialog box.
However, in test 2 and beta I do not see any related parameter to select.
Can those parameters be included on these environment, so that the testing can be done on it in these environment.

--------------------------
**Version**: unspecified
**Severity**: normal
Manual importing of the TemplateData is needed for this.
I might be missing something obvious here but,
the last change to the Taxobox template on test 2 was made 7 years ago, I think, so even if it worked properly, and I didn't test this, I think it's missing TemplateData (https://www.mediawiki.org/wiki/VisualEditor/Portal/TemplateData ).
If you want to use the same templates you use on en.wp, for example,
you'd need to import them and their documentation, I guess.
An example page for editing taxobox could be :https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/table_test?veaction=edit
What would be a link to edit e.g. taxobox with VE "on production"?
I tried the following templates:
reflist
citeweb
taxobox
Screenshot of the error

Steps to reproduce:

1.Click on the edit button
2.Add several references in the page
3.Add a template reflist onto it.
4.Insert an image
5.Go to the Media Settings for that image and add a reference and also add the template reflist to the image
6.Save the page

Observed Result:

The reflist that was created for the page disappears and the error appears "Cite error: There are <ref> tags on this page, but the references will not show without a {{reflist}} template (see the help page)"

Test Environment: production
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5

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

**Attached**: {F12295}
(Cool, I never used that template more than once on a page. Now I know it can be done :) https://en.wikipedia.org/wiki/Template:Reflist#Multiple_uses )
https://en.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/reflist_on_a_image
(In reply to comment #2)
> Some more issues with this action:
> 
> 1. After adding a reflist to the image the whole order of the references in
> that page gets messed up.
> 
> The reference to the image becomes reference with footnote [1] and in the
> page
> the order of the reference got changed from [1],[2],[3]  to [2],[3],[4].
> and the reference of the image gets modified to the [1] reference of the
> document. 
> 
> 
> 
> 2. Now if you switch to edit source, you will see since the reference in the
> image is taking the value of first reference of the document as a repetitive
> reference, the [1] reference of the document gets assigned with ref name=
> ":1" 
> 
> But still there is another on the page:Cite error: The named reference :1 was
> invoked but never defined (see the help page).
Created attachment 13844
flower.com got changed to facebook.com

**Attached**: {F12298}
Created attachment 13843
the changed order

**Attached**: {F12297}
Created attachment 13842
The initial order

**Attached**: {F12296}
Some more issues with this action:

1. After adding a reflist to the image the whole order of the references in that page gets messed up.

The reference to the image becomes reference with footnote [1] and in the page the order of the reference got changed from [1],[2],[3]  to [2],[3],[4].
and the reference of the image gets modified to the [1] reference of the document. 



2. Now if you switch to edit source, you will see since the reference in the image is taking the value of first reference of the document as a repetitive reference, the [1] reference of the document gets assigned with ref name= ":1" 

But still there is another on the page:Cite error: The named reference :1 was invoked but never defined (see the help page).
Example Page:https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/reference_on_a_image
As far as I remember we have agreed this will not be implemented. Please reopen if I misunderstood.
I am **strongly against** reusing browsers between scenarios, for various reasons. If speed is our problem, we should run the tests in parallel.
Screenshot of the error

Steps to reproduce:

1.Click on the edit button
2.Add few references to the page
3.Go to more>Transclusion
4.Add the template reflist
5.Delete this template
6.An icon still appears for that template click on it
7.When the dialog for that template appears cross it out.
8.Click the button "Save Page"

Observed Result:
The Save page button does not work.User cannot save the edit made so far on the page. It requires to cancel the edit and reopen the editor.

The js error that appears on the console is:
Uncaught Error: Cannot open another window while another one is active

See the screensshot attached

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

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

**Attached**: {F12289}
Think this was fixed in the re-work of how we attach to transclusions? WFM in my testing.
*** Bug 57204 has been marked as a duplicate of this bug. ***
Possibly a duplicate of bug 57204?
No indication if there is any reflist added or not

Steps to reproduce:

1.Click  on the edit button
2.Add few references to the page
3.Now click on the More>Transclusion
4.Select the template "reflist" and add it to the page

Observed Result:
The reflist template does not get added rather an icon for the template shows up on the page.
If you move your cursor that icon disappears too making user confused whether they have added any reflist or not.

See the screenshots attached.

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

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

**Attached**: {F12287}
Well, so much for not using the dedicated References list button :p

Now seriously:
with my PC/Win 7 and Chrome (both skins), I can't even see the template icon.
Under FF instead I see it, and at its left there's this character ^ in grey.
In both cases, the blinking cursor is now at the top of the page:
if I type something, the text will be added on that line (in Chrome) or where the Reflist is supposed to be (in FF: the icon is now gone).
Created attachment 13837
template icon

**Attached**: {F12288}
Screenshot of the error

Steps to reproduce:

1.Click on the edit button
2.Select a text or place your cursor in a blank space
3.Go to More>Latex/hieroglyphics option

Observed Result:
None of the inspectors open up .More over ,in one attempt they opened overlapping with each other and after that I could not close any of them.I had to cancel my editing and reopen the editor to get rid of them

It gives the following script error in the console:
Uncaught TypeError: Cannot read property '$element' of null



see the screenshot attached.

--------------------------
**Version**: unspecified
**Severity**: major

**Attached**: {F12278}
This is fixed and verified too.
(In reply to comment #5)
> should this block the next deployment?

James: ping?
should this block the next deployment?
In production the behavior is more annoying, as it opens the Latex inspector after a while and then it keeps opening everytime I select a text.And it does not go away by changing the focus/ crossing out the dialog.User have to cancel the edit and then re-open the editor.
It is my understanding that this is related to James' second answer at https://www.mediawiki.org/wiki/Talk:VisualEditor/Beta_Features/Formulae#Bugs_&_compatibility_issues.
Some more insight to the case where it opened.

1.Keep the firbug or developers tool closed
2.Click on Latex and/or hieroglyphics option
3.Open the firebug/developer tool

Observed Result:

Both the inspectors open overlapping with each other.However if you type something inside it and try to close it , it does not let you do that
Test Environment: https://test2.wikipedia.org/
Browser: Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5 
Test Page:https://test2.wikipedia.org/w/index.php?title=Verify_56274&veaction=edit
Steps to reproduce:

1.Click the button Edit
2.Quickly switch to read tab and again switch back to edit button

Observed Result:
An error appears in the console
Uncaught TypeError: Cannot call method 'getModel' of null load.php:37
ve.init.mw.ViewPageTarget.updateToolbarSaveButtonState load.php:37
(anonymous function) load.php:43
fire load.php:12
self.fireWith load.php:14
self.fire load.php:14
(anonymous function)

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 51546 ***
Also got these error once :

Uncaught RangeError: "Maximum call stack size exceeded"

Uncaught TypeError:Object #<Object> has no method 'abort'
Test Environment:Production
Test Page:https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/test_reference?veaction=edit
OS:MAC OS X 10.8.5
Browser:Chrome 26.0.1410.65
Intention:
Edit a page containing a gallery.  The gallery contains <ref> citations.

Steps to Reproduce:
1. Open the page in VisualEditor.
2. Notice the big red errors inside each gallery that contains a <ref> citation.


Actual Results:  
Big red errors are present at the bottom of each gallery that contains a <ref> citation.  Depending on whether the ref is part of a group, these are the two errors I saw:

There are <ref group=$1> tags on this page, but the references will not show without a {{reflist|group=$1}} template (see the help page).

There are <ref> tags on this page, but the references will not show without a {{reflist}} template (see the help page).


Expected Results:  
That VisualEditor would not produce an error.  (There were proper {{reflist}} templates at the bottom of the page.)

Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: normal
This has been fixed, sort of:  Instead of a big red error, it now puts a references block at the end of the gallery (re-starting the numbering, and including only refs from the gallery).
I don't think this is valid any more, is it?
Also, as seen by editing https://en.wikipedia.org/w/index.php?oldid=596381198 you cannot re-use any references that are within a gallery block.
If you change a caption in the gallery so that it contains a {{reflist}}, then VisualEditor displays the citations within the gallery (under the green can't-edit-this hash), and this error is not present.
Trying to type a word in brackets might lead to the disappearing of the opening brackets, no wikitext warning appears and no nowikis are added.

Happened to me twice in sandboxes,
see https://test.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/tests&oldid=185158 and https://it.wikipedia.org/w/index.php?title=Utente%3AElitre_%28WMF%29%2FSandbox_VE&diff=62542564&oldid=62363821 ;
it didn't happen in https://en.wikipedia.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandbox&diff=582254513&oldid=581339890 and I also don't seem able to get this bug while VEditing ns0.
All tests under Chrome and Vector.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53856
Also happening at https://test.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&oldid=203117 when trying to add a new point under "simpler".
Happening again.
In https://fr.wikipedia.org/w/index.php?title=Utilisateur:Elitre_(WMF)/Prove2&oldid=108482122 I tried to start a new line precisely under the first one (the one ending in "sdas") with a word in brackets to see if it triggered the warning.
After typing the opening square brackets, these disappear when I start typing a word.
Closing provisionally as WORKSFORME.
Is this still occurring?
I still can. VE hates me :(
I can't reproduce at https://en.wikipedia.org/wiki/User:Elitre_(WMF)/sandbox?veaction=edit&useskin=monobook with a hard-refresh. :-(
It doesn't happen in FF, but it's still there if I switch to Monobook in Chrome.
Sorry :/
Chrome, Vector, Win7:

https://en.wikipedia.org/wiki/User:Elitre_(WMF)/sandbox?veaction=edit
Cursor right under the sandbox template and above the article text,
I start typing brackets and they disappear.
I guess we'll never know, since right now it seems to work again just fine. Good for us.
I can't reproduce this after a few dozen tries. Can you give more details about how it happens? Is it on new pages only? Existing pages? Existing pages when you're editing an old revision? At the start of the document? Everywhere? Etc.
Yeah, it's probably Chrome.
I've been unable to replicate this in Mac OS 10.7.5/Safari 6/Vector or in Mac OS 10.7.5/Firefox 25.0.1/Vector, in either userspace or the mainspace.
Environment:test 2
SamplePage:
OS:MAC OS X 10.8.5

--------------------------
**Version**: unspecified
**Severity**: normal
*** Bug 57194 has been marked as a duplicate of this bug. ***
Verified this issue.
Created a separate ticket for idle time issue:https://bugzilla.wikimedia.org/show_bug.cgi?id=57314
(In reply to comment #11)
> After the fix,I am not getting that error message.
> However, after keeping the editor for a long time and then attempting to save
> the content gives the following js error.
> 
> Uncaught TypeError: Cannot read property 'saveRetries' of undefined
> (anonymous function)
> fire load.php:12
> self.fireWith load.php:14
> self.fire load.php:14
> (anonymous function)
> fire load.php:12
> self.fireWith load.php:14
> done load.php:119
> callback
> 
> Assuming it as a separate issue?

Yes, that's distinct; marking this as FIXED, but please re-open if it re-occurs.
After keeping the editor open for long time*(In reply to comment #11)
> After the fix,I am not getting that error message.
> However, after keeping the editor for a long time and then attempting to save
> the content gives the following js error.
> 
> Uncaught TypeError: Cannot read property 'saveRetries' of undefined
> (anonymous function)
> fire load.php:12
> self.fireWith load.php:14
> self.fire load.php:14
> (anonymous function)
> fire load.php:12
> self.fireWith load.php:14
> done load.php:119
> callback
> 
> Assuming it as a separate issue?
After the fix,I am not getting that error message.
However, after keeping the editor for a long time and then attempting to save the content gives the following js error.

Uncaught TypeError: Cannot read property 'saveRetries' of undefined
(anonymous function)
fire load.php:12
self.fireWith load.php:14
self.fire load.php:14
(anonymous function)
fire load.php:12
self.fireWith load.php:14
done load.php:119
callback

Assuming it as a separate issue?
I just got this error on production too.
I got the Parsoid server message as well a few minutes ago on that page.
Then I tried again (from Opera, unlogged, then from FF and Chrome while logged in) and it just saved. :/
To the best of my knowledge, test2 and mediawiki.org are using the production Parsoid instance.  Please let us know if that is not the case.
That might be a different issue, possibly with the parsoid service setup used by test2. AFAIK it is not using the Parsoid production cluster. The QA folks have been working on this recently and would know more.
Happened again on test2 . No errors in the JS console.On the dialog box there was a message:Error: Error contacting the Parsoid server
I am not getting this issue anymore.The new page creation and content saving both are working now.
Any errors in the JS console?
Sample Page: https://test2.wikipedia.org/w/index.php?title=Verify_56274&veaction=edit
Created attachment 13825
Screenshot of the error

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

1.Attempt to modify any content on any page in test2 environment .
2.Click the Save button 

Observed Result:
The spinner for saving continues for a long time but the content does not get saved .And "An error occurred" message appeared on the dialogue box
See the screenshot attached

Browser:Chrome Version 26.0.1410.65
and FF 25
When a tag <ref> is inserted in visual editor it shows a wikitext warning to user but there are few more tags which I think will be good to be added to the wikitext detection regex such as 
<s>
<math>
<poem>

None of them triggers wikitext warning right now.

--------------------------
**Version**: unspecified
**Severity**: normal
WONTFIX. The test is not intended to catch every possible mistaken attempted insertion of HTML or wikitext.
Steps to reproduce:

1.Load any page on test2
2.Take your cursor to the "Search Box" and attempt to type something in it.
3.Observe Console>Errors from Developer tool

Observed Result :
ULS: Unknown language doi.
ULS: Unknown language fonipa

Appears on this section.

Note:The selected language is English in this case

Not sure if it is expected or not.Close the bug if it is not an issue. 

Test Environment:
Browser:Chrome 26.0.1410.65
OS:MAC OS 10.8.5
Test Page:https://test2.wikipedia.org/wiki/Verify_56274

See the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: normal
Not related to VisualEditor itself, ULS spams this to the console on every page everywhere.

*** This bug has been marked as a duplicate of bug 45047 ***
AIUI, Flow no longer uses VE's API to convert from/to wikitext/html, it posts API requests to Parsoid's URL if its available.

I think this means:
* Hooks.php onSetupAfterCache() is obsolete, (and has been since we occupied namespaces?!),
* Flow should have its own parameters $wgFlowParsoidURL, $wgFlowParsoidPrefix, $wgFlowParsoidTimeout which in comments can default to the $wgVisualEditor* values.
* Clean up obsolete comments in ParsoidUtils.php

This will make it clearer that Flow can work with Parsoid even if the VisualEditor extension isn't installed.

(Is the Parsoid extension even required on MediaWiki servers in a cluster arrangement where only one machine runs the Parsoid nodejs service?)  I guess yes in order to "trigger Parsoid cache updates".)

--------------------------
**Version**: master
**Severity**: minor
Change 95605 merged by jenkins-bot:
(bug 57111)  clean up obsolete VE API dependency

https://gerrit.wikimedia.org/r/95605
Change 95605 had a related patch set uploaded by Matthias Mullie:
(bug 57111)  clean up obsolete VE API dependency

https://gerrit.wikimedia.org/r/95605
The WMF core features team tracks this bug on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/470, but people from the community are welcome to contribute here and in Gerrit.
Coincidentally, I had been working on that yesterday: https://gerrit.wikimedia.org/r/#/c/95605/

onSetupAfterCache still needs to be removed in there, though.
edit/edit source option on blank space

Steps to reproduce:

1.Click on the Edit button for a page
2.Select the option sub-heading 1 in a blank space
3.Click the button "Save Page"

Observed Result:
The Edit/Edit Source link appears in the blank space

Browser:Chrome
Page:Any
Environment:test 2

see the screenshot attached

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

**Attached**: {F12697}
This now seems to be fixed (on test2 using Chrome).
This came up while working on the new Media dialog in VisualEditor. When changing a block image type, for instance from 'thumb' to 'frameless', the new type is added onto the wikitext instead of replacing the old type tag.

Original wikitext:
[[File:image.png|thumb|right|caption goes here|466x466px]]

After changing the type of the image to frameless (including all style changes and type attribute) the resulting post-save wikitext is this:

[[File:image.png|thumb|right|caption goes here|466x466px|frameless]]

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 48665 ***
This came up while working on the new media dialog in VisualEditor. When there's a change in an image align attribute, the resulting wikitext adds the new alignment keyword instead of replacing the original.

Initial wikitext:
[[File:image.png|thumb|right|caption goes here|466x466px]]

After changing the image to right alignment (removing tright and replacing with tleft, and replacing the align attribute in the image object) -- the resulting wikitext post save is this:

[[File:image.png|thumb|right|caption goes here|466x466px|left]]

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 48665 ***
1. Edit [[mw:Manual:$wgEdititis]] in VE
2. Click the "Language" template at the bottom, to select it
3. Click in the blank space to the right of the word "places"

Notice that the template is (correctly) deselected.

4. Do steps 2 and 3 again

The template is not deselected this time. Even though the cursor is flashing in the right place (implying deselection), any typing will overwrite the template.

--------------------------
**Version**: unspecified
**Severity**: minor
Doesn't matter, seems to work now.
Seems to work for me now. Setting unconfirmed so a VE team member can check and confirm.
It would be nice to offer informative description of each parameter when filling it, to know what to fill. Some paremetr names, are not clear.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**Whiteboard**: aklapper-moreinfo
This is what the TemplateData system is for. If you fill in a <templatedata> block for the template in question, VisualEditor will show the descriptions you want.
["would be nice" => please set the "severity" field to "enhancement"]

(In reply to comment #0)
> It would be nice to offer informative description of each parameter when
> filling it, to know what to fill. 

What are exact steps that would allow me to reproduce this problem?

> Some paremetr names, are not clear.

Which exact parameter names do you refer to?
On an existing course page "Create source" is used instead of "Edit source" in the tab at the top of the page. For an example, see https://en.wikipedia.org/wiki/Education_Program:University_of_Michigan/CHEM_540_%28Fall_2013%29

--------------------------
**Version**: unspecified
**Severity**: normal
Just noting here now that this is still problematic. I'll comment on the VE bug, too. Appreciate any efforts to fix it. :)
I filed this against the VisualEditor. I'm marking it as a duplicate, but adding Andrew Green to the cc in case he can see a good way of fixing it from within the EducationProgram extension.

*** This bug has been marked as a duplicate of bug 53477 ***
Steps to reproduce:

1.Go to Preferences>Gadgets
2.Enable few gadgets.I tried enabling all the gadgets under "improved navigation" , Interface : Editing and uploads and Interface:Files and Categories

3.Now load the editor

Observed Result:
The following js error appears:

Error: JavaScript parse error: Parse error: Illegal token in file 'MediaWiki:Gadget-popups.js' on line 1221 Error {} 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)

--------------------------
**Version**: unspecified
**Severity**: normal
https://test2.wikipedia.org/w/index.php?title=MediaWiki:Gadget-popups.js&action=history is from Feb 2012.

Line 1221 is:
	/*@if (@_jscript_version >= 5)

https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-popups.js&action=history for example is from Nov 2013 (but also contains that line).

Hence wondering if it's a "real" problem or just an ancient .js file on test2.
It was found in test2 environment
That sounds like a bug in the popups gadget. Which wiki was this on?
Superscript and Subscript

Steps to reproduced:

1.Click on the "Edit" button
2.Type a text X
3.Now type "2" and make it a superscript
4.Select the text 2 and make it subscript

Observed Result:
The text "2" now appears somewhere in the middle of the preceding text X which neither superscript nor subscript.

See the screenshot attached.

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

**Attached**: {F12152}
Previously WONTFIXed. I'll reopen the original bug.

*** This bug has been marked as a duplicate of bug 53330 ***
Steps to reproduce:

1.Click on the Edit button
2.Add a Heading to the page
3.Now add a sub-heading 1
4.Add a sub-heading 2 
5.Click on "Save Page"

Observed Result:
The table of contents does not appear.Now if the user adds sub-heading 3, the table of contents show up.

--------------------------
**Version**: unspecified
**Severity**: normal
This is MediaWiki native behaviour.
Wiki markup and weird text

Steps to reproduce:

1.Click on the "Edit" button
2.Type a text and add a reference to it
3.Select the text with the reference and apply link to it by clicking on link icon or pressing command+k
4.Click on "Save Page"

Observed Result:
Some weird text along with wiki markup shows up in the editor,

See the screenshot attached.

Page:Any
Environment:Betalabs and test 2
Browser:Chrome Version 26.0.1410.65 and firefox 20
Reproducible :Yes

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

**Attached**: {F12085}
Hi ryasmeen. Thanks for taking the time to report this!
This particular problem has already been reported into our bug tracking system, but please feel free to report any further issues you find.

*** This bug has been marked as a duplicate of bug 56250 ***
https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=580632339#Space_between_.22:.22_and_characters_count_increase

Looks like this could potentially be the xhtml serializer converting &nbsp; to a nonbreaking space unicode char?

--------------------------
**Version**: unspecified
**Severity**: normal
Change 101292 merged by GWicke:
(Bug 56733) Fixed bug serialization template args containing " : "

https://gerrit.wikimedia.org/r/101292
Change 101259 merged by GWicke:
Merge "(Bug 56733) Fixed bug serialization template args containing " : ""

https://gerrit.wikimedia.org/r/101259
Change 101292 had a related patch set uploaded by GWicke:
(Bug 56733) Fixed bug serialization template args containing " : "

https://gerrit.wikimedia.org/r/101292
Change 101259 had a related patch set uploaded by GWicke:
Merge "(Bug 56733) Fixed bug serialization template args containing " : ""

https://gerrit.wikimedia.org/r/101259
Now deployed and tested fixed @ https://fr.wikipedia.org/w/index.php?title=Utilisateur%3ASsastry%2FSandbox&diff=98462286&oldid=98462267
Change 95301 merged by jenkins-bot:
(Bug 56733) Fixed bug serialization template args containing " : "

https://gerrit.wikimedia.org/r/95301
Change 95301 had a related patch set uploaded by Subramanya Sastry:
(Bug 56733) Fixed bug serialization template args containing " : "

https://gerrit.wikimedia.org/r/95301
This is caused by the template arg escaping code. Fix coming along with test case.
As seen on mediawiki.org (running 1.23wmf2 (020fe63)) in Firefox 24.

When editing in VisualEditor, the first time I click on the menu icon, the dropdown is slightly too small and a horizontal scroll bar appears inside the dropdown.

The next time I click on the icon, the dropdown's width can accommodate the text and there is no scrollbar in the dropdown itself, but a horizontal scrollbar appears at the page level to accommodate the dropdown's extra width.

Then, rinse and repeat: every other time, there's a scroll bar in the dropdown, and the next one there is one at the bottom of the page.

--------------------------
**Version**: unspecified
**Severity**: normal
I can't reproduce; do you have a screenshot?
OOJS components:

- General
  The core utilities and unsorted issues.

- EventEmitter

- Registry
  Registries and factories.


Import from:
https://github.com/trevorparscal/oojs/issues

OOJS UI components:

- General
  The base classes (Dialog, Frame, Window etc.) and unsorted issues.

- Elements
  OO.ui.Element and subclasses.

- Layouts
  OO.ui.Layout and subclasses.

- Tools
  OO.ui.Tool, ToolGroup and subclasses.

- Widgets
  OO.ui.Widget and subclasses.

No existing issue tracker (we'll gradually move over issues from VisualEditor and MediaWiki core as needed).

--------------------------
**Version**: wmf-deployment
**Severity**: normal
Per James, I've renamed the products from OOJS and OOJS UI to OOjs and OOjs UI.

Sorry if this breaks anyone's permalinks. Better now than later now that the component is still fresh.
I've created a wiki page:
 https://www.mediawiki.org/wiki/OOJS

And added a link to it in the product description:

 https://bugzilla.wikimedia.org/describecomponents.cgi?product=OOJS

See wiki page for more information.

Also, note this is all in early migration right now. Things will get clearer as things settle.
As a triager I have no idea what "Library for working with objects" might mean, where this is located in the stack, and how to identify tickets that should be moved to the new products. 
Is there a wikipage covering OOJS? 
Will https://github.com/trevorparscal/oojs/issues remain the canonical code base or will this / has this been moved to Wikimedia Git?
Created the products and some of the components.
Steps to reproduce:

1.Click on te Edit-beta button
2.Click on the "Settings" button and go to "Categories" section
3.Add a new category
4.Click on the button "Apply Changes"
5.Now click on "Save Page"

Observed Result:
The newly added category is not showing up at the end of the page unless user refreshes it.

--------------------------
**Version**: unspecified
**Severity**: normal
Merge this with bug 48560.

*** This bug has been marked as a duplicate of bug 48560 ***
The first letter goes to the newline

Steps to Reproduce:

1.Click on the Edit button in firefox
2.Go to More>Reference
3.Type something to add as a reference 

Observed Result:
In firefox, while typing on reference dialog box the first character always goes to the next line and cannot be deleted thereafter 

See the screenshot attached

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

**Attached**: {F12795}
Unsetting "VERIFIED"; we don't generally use that, and setting it will hide it from people's saved searches.
Verified for any page on https://test2.wikipedia.org/ with FireFox 25 using MAC OS X 10.8.5
Example test page:  https://test2.wikipedia.org/wiki/Verify_56274
Verified in betalabs with firefox 25*
Looks like this issue got fixed .Verified in betalabs with FireFox
This is also happening now while creating a new page in firefox 20.
added a See Also, I think this is more of the cursor RETURN/BACKSPACE problem
Text going out of border

Steps to reproduce:

1.Click on the "Edit" button
2.Now from the toolbar click on More>LaTeX
3.In the dialog box for LaTeX enter a long equation. For Example:


\frac{-b \pm \sqrt{b^2 - 4ac}}{2a}\frac{-b \pm \sqrt{b^2 - 4ac}}{2a}\frac{-b \pm \sqrt{b^2 - 4ac}}{2a}\frac{-b \pm \sqrt{b^2 - 4ac}}{2a}\frac{-b \pm \sqrt{b^2 - 4ac}}{2a}\frac{-b \pm \sqrt{b^2 - 4ac}}{2a}\frac{-b \pm \sqrt{b^2 - 4ac}}{2a}\frac{-b \pm \sqrt{b^2 - 4ac}}{2a}\frac{-b \pm \sqrt{b^2 - 4ac}}{2a}\frac{-b \pm \sqrt{b^2 - 4ac}}{2a}\frac{-b \pm \sqrt{b^2 - 4ac}}{2a}\frac{-b \pm \sqrt{b^2 - 4ac}}{2a}

4.Save the page

Observed Result:
The text is going out of the border of the page for a lengthy content in math inspector

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

**Attached**: {F12792}
This is ultimately up to the control of the user, and so not really a "bug".
tags on view mode

Steps to reproduce:
1.Click on the Edit button
2.Add a reference to the page
3.Add a reference list at the end of the page.
5.Click the button "Save" button



Observed Result:
The <ref> and <reference/> tags are showing up in the view mode

See the screenshot attached.

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

**Attached**: {F12783}
Fault due to local lack of the Cite extension; fixed.
Currently en.wikipedia.beta.wmflabs.org runs master of VisualEditor and a manually-synced version of Parsoid that is the same as production. This is great for testing VE as to whether it's good to deploy into production, and had served us reasonably well so far.

We can't just run Parsoid as master, because (a) Parsoid master is occasionally not compatible with VisualEditor master for days or even weeks at a time as the APIs change, and (b) unless Parsoid is going to be pushed live at the same time as VisualEditor (and split into a het-deploy situation for the cluster's wmfX vs. wmfX+1 deployment) we wouldn't know if VE and Parsoid were truly OK to go out.

However, bug 56583 showed that we also need to test master (and ideally also current production) of VisualEditor against *master* of Parsoid, in Labs, for automated browser testing and so on before any code goes live.

Do we need en.wikipedia.beta.wmflabs.org to have en-Parsoid-master-VE-master.wikipedia.beta.wmflabs.org and en-Parsoid-master-VE-prod.wikipedia.beta.wmflabs.org duplicates? (Eww.)

Also, are there other teams who need their multiple independent components and cross-dependencies? Wikidata, perhaps?

--------------------------
**Version**: unspecified
**Severity**: normal
I'm not sure I agree this bug is INVALID; we still can't reliably test master of VisualEditor against production of Parsoid or vice versa; instead, we test master of VisualEditor against master of Parsoid in Beta, and production VisualEditor against production Parsoid in production, and hope that we don't get into one of those situations again where one assumes things about the other…
(In reply to comment #1)
> In https://gerrit.wikimedia.org/r/#/c/93939/ I made the beta autoupdater to
> run
> `npm install` under common/php-master/extensions/Parsoid/js
> 
> Regardless, the parsoid instance is deployment-parsoid2     and runs its own
> copy of the code under /srv/deployment/parsoid . So it is still being updated
> manually by whoever has access on it.

Copied that to:

Bug 57233 - beta: Parsoid should continuously deploy master branch
What we could potentially do in Jenkins:

Whenever a change is send on VisualEditor, we could somehow boot up two Parsoid instances running master and production versions then run the VisualEditor tests against each of them.

Similarly, whenever a change is send to Parasoid, we could create an instance of it and run VisualEditor tests from master and production versions.

That should help both team figuring out potential issues and regressions.


We never achieved such integration tests on any project yet. Ideally we would use labs to boot up instances that would contains all the required dependencies and run the tests there.  The infrastructure is not ready yet :-/
Usually Parsoid master will work fine with VE. DOM spec changes have not been frequent in the past, and will get even less frequent over time. Empirically, the main source of issues has been a lack of integration testing rather than existing functionality breaking because of incompatibilities.

So if we could only set up one version for now I'd prioritize testing against master over testing against an older version of Parsoid, in particular if that is not updated automatically. Much of the VE integration testing is also still manual at this point, which makes focusing on the most likely source of errors even more important.
*** Bug 56670 has been marked as a duplicate of this bug. ***
For the sake of clarification: I am open to any solution :)
In https://gerrit.wikimedia.org/r/#/c/93939/ I made the beta autoupdater to run `npm install` under common/php-master/extensions/Parsoid/js

Regardless, the parsoid instance is deployment-parsoid2	 and runs its own copy of the code under /srv/deployment/parsoid . So it is still being updated manually by whoever has access on it.


The whole point of beta is to test the tips of master branches from all extensions.  That let us catch potential issue before all those tips are aggregated in a wmf branch.   To prevent new code from being executed, we use feature switching ($wgFeatureXXX = false) that still let us deploy the code and enable it selectively later on.

That being said, I think it would make sense to run VisualEditor and Parsoid on the tip of master. That would probably help you detect possible breakage when deploying.
Noticed on mediawiki.org, in the VisualEditor toolbar, Menu icon, last item: <visualeditor-mweditmodesource-title>. 

Special:Version says mw.o is currently running 1.23wmf2 (88c7b3f).

--------------------------
**Version**: unspecified
**Severity**: normal
Working now.
On further inspection looks like a deployment / server-side caching issue. Definitely nothing wrong with the code though.
Sounds like a caching issue with ResourceLoader.
Error message

Steps to reproduce:
Click on the edit button

Observed Result:
"Error loading data from server:parsoidserver-http-bad-status:503" shows while attempting to edit using VE

See the screenshot attached

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

**Attached**: {F12683}
Fallout from fixing bug 56583. Should be okay now.

*** This bug has been marked as a duplicate of bug 56583 ***
Video made by en user Atethnekos

As illustrated in the attached video, VE's drag and drop function has some odd quirks in Firefox.  One can select items from below the VE surface, such as the MediaWiki logo or the licensing disclaimer text, and drag them into the VE surface.  These items can only be added to the last line of an article.  Items seem to be added as bulleted items, increasing indent with each addition.

Tested on FF 24 Win 7 with Monobook, duplicated with FF 24 and Mac OS 10.6

Could not duplicate using Chrome on the above Mac OS - may be a Firefox issue.

Described here:https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_12#Moving_links_on_the_page_from_outside_the_VE_surface_into_the_VE_surface

And here:https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Drag_and_drop_redux

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

**Attached**: {F12668}
I confirm that it does not happen for me as well - I seem to be able to drag and drop items, but after I do that nothing changes, and as a matter of fact VE won't prompt me to save. In wikitext mode instead one can actually drag and drop stuff.
Can't reproduce in FF.
All in superscript/subscript format

Steps to reproduce:
-Type a text x
-Select it and make to to superscript
-Now type 1 before x (1x) and both the letters are in superscript format
-Now type "/" between these two letters (1/x) and all three letters are in superscript format
-Now keep on typing anything before or after (1/x) all the letters are in superscript format.
-Press "Enter" to go to new line
 
Observed Result:
Now the letter x and all other letters after that are in superscript format

Expected Result:
Unless selected as superscript/subscript all the texts typed before or after it should be in normal text format.

See the screenshot attached

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

**Attached**: {F12661}
The pre-annotation described here is intentional behaviour, and used for all text styles (with some special logic for links); we could not do it for some, but I think that that would be too confusing.
abnormal load.php requests

this is essentially the same problem as shown with UploadWizard in https://bugzilla.wikimedia.org/show_bug.cgi?id=56483

When run in the Sauce Labs environment, tests for VisualEditor for Chrome display many many calls to ResourceLoader that are not shown in normal operation, nor in a browser test in a local environment.  

At least some of these calls to load.php fail with javascript errors, thus causing VE to fail and the test to fail.  

One recent example is shown at https://wmf.ci.cloudbees.com/job/VisualEditor-en.wikipedia.beta.wmflabs.org-linux-chrome/117/testReport/junit/(root)/VisualEditor%20Links/Enter_non_existing_link/

Here we see two distinct calls for the same code at ext.echo.alert, the second of which fails, see screen shot.  In detail, the first call succeeds, the second fails:

[200 OK] GET http://bits.beta.wmflabs.org/en.wikipedia.beta.wmflabs.org/load.php?debug=false&lang=en&modules=ext.echo.alert%2Cbase%2Cdesktop%2Coverlay&skin=vector&version=20131021T193233Z&*

[200 OK] GET http://bits.beta.wmflabs.org/en.wikipedia.beta.wmflabs.org/load.php?debug=false&lang=en&modules=ext.echo.alert%2Cbase%2Cdesktop%2Coverlay&skin=vector&version=20131021T193233Z&*
Uncaught SyntaxError: Unexpected token ILLEGAL 

Also in this particular run of the test find VE loading up code for ArticleFeedback and for Gadget code for DelAutoDropdown.  VE loading gadget code in normal operation has been documented, see screen shot for invisible_iframe

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

**Attached**: {F12626}
This is no longer happening.
Unless you can reproduce this outside of SauceLabs, I'm inclined to believe this is simply Chrome in SauceLabs being broken.
here is an example of a test for Flow on Chrome that repeats the same GET twice for VE code.  the first succeeds, the second gives an error: 


[200 OK] GET http://bits.beta.wmflabs.org/en.wikipedia.beta.wmflabs.org/load.php?debug=false&lang=en&modules=ext.visualEditor.base%2Ccore%2Cdata%2Cicons-vector%2Cstandalone%7Cext.visualEditor.viewPageTarget.icons-vector%7Coojs%2Coojs-ui%2Crangy%7Cunicodejs.wordbreak&skin=vector&version=20131102T010844Z&*

[200 OK] GET http://bits.beta.wmflabs.org/en.wikipedia.beta.wmflabs.org/load.php?debug=false&lang=en&modules=ext.visualEditor.base%2Ccore%2Cdata%2Cicons-vector%2Cstandalone%7Cext.visualEditor.viewPageTarget.icons-vector%7Coojs%2Coojs-ui%2Crangy%7Cunicodejs.wordbreak&skin=vector&version=20131102T010844Z&*
Uncaught SyntaxError: Unexpected end of input

Ref:  https://saucelabs.com/jobs/e0b3ed7901a14cfdb56b745c6938c12d
Created attachment 13691
gadget code in VE in normal operation

**Attached**: {F12627}
Standalone VisualEditor shows all messages as the raw [visualeditor-message] strings in tooltips and in general button strings. 

"Format" dropdown, for example, has 
[visualedit-rformatdropdown-format-paragraph]
[visualedit-rformatdropdown-format-heading2]
[visualedit-rformatdropdown-format-heading3]
etc.

--------------------------
**Version**: unspecified
**Severity**: normal
Yes
Does https://gerrit.wikimedia.org/r/#/c/93480/ fix this?
On test.wikipedia.org I enabled VisualEditor through Beta Features.
Visiting a page, display:none is applied to the VE edit button (li#ca-ve-edit). This css is at the header of the page.

Since no button is shown, how anyone can use VE?
Am I missing something?

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #2)
> https://test.wikipedia.org/w/index.php?title=MediaWiki:Common.
> js&diff=184444&oldid=183093

That was a test config for en.wiki that wanted it I believe, Mz should be fine with you commenting it out.
https://test.wikipedia.org/w/index.php?title=MediaWiki:Common.js&diff=184444&oldid=183093
The button is disabled through js at MediaWiki:Common.js...

It should be removed since people are asked to test it.
Before https://gerrit.wikimedia.org/r/#/c/90449 :

<meta property="mw:PageProp/categorydefaultsort" content="Page, Main" data-parsoid='{"src":"{{DEFAULTSORT:Page, Main}}","dsr":[1800,1826,null,null]}'/>

After:

<meta property="mw:PageProp/categorydefaultsort" data-parsoid='{"src":"{{DEFAULTSORT:Page, Main}}","a":{"content":null},"sa":{"content":"Page, Main"},"dsr":[1800,1826,null,null]}'/>

This breaks editing of defaultsort in VisualEditor for obvious reasons, but it also triggers a failure mode in VisualEditor where missing content attributes aren't expected and are normalized to content="null", triggering corruption warnings and changing {{DEFAULTSORT:Foo}} to {{DEFAULTSORT:null}}. I'll fix that in VE.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 93108 merged by jenkins-bot:
Bug 56489: Allow content attribute on parsoid-generated meta tokens

https://gerrit.wikimedia.org/r/93108
Change 93108 had a related patch set uploaded by GWicke:
Bug 56489: Allow content attribute on parsoid-generated meta tokens

https://gerrit.wikimedia.org/r/93108
<ooui-toolbar-more> tag

Steps to reproduce:

-Click on the Edit button on a page in test 2 environment
-Observe the toolbar

Observed Result:

<ooui-toolbar-more> tag is showing up instead of "More" text in the toolbar in test2 environment

See the screenshot attached.

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

**Attached**: {F12443}
Unsetting "VERIFIED"; we don't generally use that, and setting it will hide it from people's saved searches.
Cant find this issue in test2 now. Therefore, changing the status to resolved.
"Error:Database query error "

Steps to reproduce:
-Click on the Edit-beta button
-Type anything to made some changes in the CE
-Click on the Save button 

Observed Result:
"Error:Database query error " is showing up while attempting to save the content for the first time in test2 environment.

However,attempting to save the content for the second time is saving the content.

See the screenshot attached.

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

**Attached**: {F12442}
Unsetting "VERIFIED"; we don't generally use that, and setting it will hide it from people's saved searches.
Yes, now it looks fixed.Can not reproduce it anymore.
Try again? I've just fixed a database error that might actually be related
WIP: 

I am seeing a number of failures in the Selenium tests when running for Chrome. The failures seem to be caused by many calls to ResourceLoader, many repeated, many seemingly unnecessary, and some of these calls fail.  Other calls to other unexpected sources are also evident, this is just a single example.  

Each failed test shows a different set of calls to load.php.  Here is one example:

A normal load of UW on beta commons has 2 calls for two jquery things, one for the spinner and one for ULS. See screen shot. 

But a failed automated test shows multiple repeated calls for jquery.ui.button. See screen shot. https://saucelabs.com/jobs/8fd3f6a483db46da9c4cfbbdcf7d2449

A reference to jquery.ui.button is found only one place in all of the UploadWizard source code, line 473 of UploadWizardHooks.php.  It seem to be a dependency for ext.uploadWizard.campaign

What causes UploadWizard to make multiple calls for a jquery feature jquery.ui.button that it would not normally need?

Under what circumstances would this happen to a normal user?

When UW makes these multiple calls, it seems that what is returned from some of those calls is corrupt, possibly truncated, since the errors tend to be 'Uncaught SyntaxError: Unexpected token ILLEGAL' and similar. 

I think VisualEditor has a similar problem, possibly indicated in https://bugzilla.wikimedia.org/show_bug.cgi?id=55801 (see screen shot there)

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56567
no longer happening as of about Nov 15
Created attachment 13659
too many calls to load.php

**Attached**: {F12435}
Created attachment 13658
normal operation

**Attached**: {F12434}
Steps to reproduce:
-Click on the button Edit-beta
-Type a text to insert the link
-Click on the link icon from the toolbar or press ctrl+k or command+k
-Now select a new page which is not yet created
-Save the content

Expected Result:
The link to a missing page should be shown as a red link as it shows in the dialog

--------------------------
**Version**: unspecified
**Severity**: normal
Merging this with bug 37901, which covers this and a little more.

*** This bug has been marked as a duplicate of bug 37901 ***
A link status indicator (red link, redirect, etc.)
during autosuggest would be great, as long as it fires asynchronously
and the user isn't blocked on actions while it's loading.
[Suggested by Erik Moeller]

--------------------------
**Version**: unspecified
**Severity**: normal
We did this using sections instead of icons, but marking as FIXED anyway.
URLs such as the following examples appear in several browser tests and cause intermittent test failures in browsers other than Firefox, for example for UploadWizard on beta commons and for AFTv5 on beta enwiki: 

http://bits.beta.wmflabs.org/commons.wikimedia.beta.wmflabs.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController%7Cext.centralauth.centralautologin.clearcookie%7Cext.uls.i18n%2Cime%2Cinit%2Cinterface%2Clanguagenames%2Cpreferences%2Cwebfonts%7Cext.uls.webfonts.repository%7Cjquery.client%2Ccookie%2CdelayedBind%2Ci18n%2CjStorage%2Cjson%2CmwExtension%2Ctipsy%2Culs%2Cwebfonts%7Cjquery.uls.data%2Cgrid%7Cmediawiki.Uri%2Capi%2Cnotify%2Cuser%2Cutil%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup%7Cskins.vector.js%7Cwikibase.client.init&skin=vector&version=20131026T061711Z&*
view data

[200 OK] GET http://bits.beta.wmflabs.org/en.wikipedia.beta.wmflabs.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController%7Cext.centralauth.centralautologin%7Cext.uls.i18n%2Cime%2Cinit%2Cinterface%2Clanguagenames%2Cpreferences%2Cwebfonts%7Cext.uls.webfonts.repository%7Cext.visualEditor.viewPageTarget.init%7Cext.wikimediaShopLink.core%7Cjquery.byteLength%2Cclient%2Ccookie%2CdelayedBind%2Ci18n%2CjStorage%2Cjson%2CmwExtension%2Ctipsy%2Culs%2Cwebfonts%7Cjquery.uls.data%2Cgrid%7Cmediawiki.Title%2CUri%2Capi%2Ccldr%2CjqueryMsg%2Clanguage%2Cnotify%2Cuser%2Cutil%7Cmediawiki.language.data%2Cinit%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup%7Cskins.vector.js%7Cwikibase.client.init%2Cnolanglinks&skin=vector&version=20131031T104306Z&*

--------------------------
**Version**: unspecified
**Severity**: normal
I guess that issue has been fixed somehow. If it is still causing browser tests to choke please reopen.
the errors seen are: 

javascript error: Uncaught SyntaxError: Unexpected token ILLEGAL

javascript error: Uncaught SyntaxError: Unexpected end of input
Wrongly ordered list

Steps to reproduce:

-Click on the "Edit" button of the Visual Editor.
-Have multiple lines to be listed in a Numbered list.
For Example:
Item One
Item Two
-Now select the first line "Item One" and click on the icon of "Numbered list" to number this item
-Now again select the both lines "Item One" and "Item Two"
-Click on the icon of "Numbered List"

Observed Result:
Both the lines are now numbered with order 1 like following:

1.Item One
1.Item Two

Expected Result:
The numbered list should maintain the continuous order if selected a previously ordered line like following:

1.Item One
2.Item Two

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

**Attached**: {F12117}
This is intentional behaviour; re-titling and marking WONTFIX.
Like, Parsoid's round-trip testing, we should do DM round-trip testing with content from Wikipedia. dirtydiffbot does this to some extent, but it tests the Parsoid output rather than the DM output and it uses the UI, which is hacky. We should have a proper service that just tests the DM HTML output is clean, which requires a test runner for that purpose in VE.

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 50513 ***
click Edit/beta, nothing happens at this size

this seems to manifest in several ways: 

* 'Edit/beta' link stops working, see screen shot
* Indent/outdent buttons disappear, see screen shot
* possibly more

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

**Attached**: {F12066}
AFAICT this is now fixed.
I tried to reproduce this on my end using FireFox and Chrome browser and what I observed is re-sizing the window distorts the visual editor toolbar placement, which was making Indent/Outdent and other buttons hide behind the search box sometimes.

But "Edit/beta" button was working fine in my browser.

See the screenshot attached
Created attachment 13626
resize window

**Attached**: {F12068}
Created attachment 13614
indent/outdent controls not loaded in page at this size

**Attached**: {F12067}
Try to VEdit
https://en.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&oldid=578251398
or
https://it.wikipedia.org/w/index.php?title=Utente:Elitre_(WMF)/Sandbox_VE&oldid=62136875 .

Place your cursor at the bottom of the page.

Hit Enter.

Expected result: a new line is created.
Actual outcome: nothing happens.

Please note that this works fine if instead you type something, and hit Enter after doing so.

It happens on both FF and Chrome with both Vector or Monobook.

--------------------------
**Version**: unspecified
**Severity**: normal
This is because the cursor in these documents is in a block slug, and so VisualEditor stops you from creating pointless blank lines that won't be saved. Marking as INVALID, but this should (hopefully) be made much clearer with the proposed changes to block slugs to make them more obviously special.
I do not know how to check if this is already happening or not. This is the list of repositories that currently contain Ruby code:

https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/selenium
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/CirrusSearch
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/Flow
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/Translate
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/TwnMainPage
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/UniversalLanguageSelector
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/VisualEditor
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/Wikibase
https://gerrit.wikimedia.org/r/#/admin/projects/qa/browsertests

--------------------------
**Version**: unspecified
**Severity**: normal
mwext-VisualEditor-ruby1.9.3lint: SUCCESS
  mwext-Wikibase-ruby1.9.3lint: SUCCESS

\O/

Thank you :-]
Change 91867 merged by jenkins-bot:
trigger rubylint for VisualEditor and Wikibase

https://gerrit.wikimedia.org/r/91867
Change 91867 had a related patch set uploaded by Hashar:
trigger rubylint for VisualEditor and Wikibase

https://gerrit.wikimedia.org/r/91867
mwext-CirrusSearch-ruby1.9.3lint: SUCCESS
  mwext-Flow-ruby1.9.3lint: SUCCESS
  mwext-Translate-ruby1.9.3lint: SUCCESS
  mwext-TwnMainPage-ruby1.9.3lint: SUCCESS

I forgot the VisualEditor and Wikibase triggers :(
Change 91862 merged by jenkins-bot:
ruby1.9.3 lint jobs for some repositories

https://gerrit.wikimedia.org/r/91862
Change 91862 had a related patch set uploaded by Hashar:
ruby1.9.3 lint jobs for some repositories

https://gerrit.wikimedia.org/r/91862
Change 91853 merged by jenkins-bot:
ruby1.9.3 lint jobs for some repositories

https://gerrit.wikimedia.org/r/91853
Change 91853 had a related patch set uploaded by Zfilipin:
Ruby lint should run after every patch set submission for all repositories that contain Ruby code

https://gerrit.wikimedia.org/r/91853
The rest:

CirrusSearch
Flow
Translate
TwnMainPage
VisualEditor
Wikibase
[2:39p] hashar:
the current jobs are:
mediawiki-selenium-ruby1.9.3lint
mwext-MobileFrontend-ruby1.9.3lint
mwext-UniversalLanguageSelector-ruby1.9.3lint
qa-browsertests-ruby1.9.3lint
Looks like this is the repo:

https://gerrit.wikimedia.org/r/#/admin/projects/integration/jenkins-job-builder-config

and this is example:

https://gerrit.wikimedia.org/r/#/c/57730/2/mediawiki-extensions.yaml
We have Code Climate set up for several repositories. Set it up for all repositories with Ruby code.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 91830 merged by jenkins-bot:
Set up Code Climate for all repositories that have Ruby code

https://gerrit.wikimedia.org/r/91830
Change 91830 had a related patch set uploaded by Zfilipin:
Set up Code Climate for all repositories that have Ruby code

https://gerrit.wikimedia.org/r/91830
Existing:

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

New:

https://codeclimate.com/github/wikimedia/mediawiki-selenium
https://codeclimate.com/github/wikimedia/mediawiki-extensions-CirrusSearch
https://codeclimate.com/github/wikimedia/mediawiki-extensions-Flow
https://codeclimate.com/github/wikimedia/mediawiki-extensions-Translate
https://codeclimate.com/github/wikimedia/mediawiki-extensions-TwnMainPage
https://codeclimate.com/github/wikimedia/mediawiki-extensions-UniversalLanguageSelector
https://codeclimate.com/github/wikimedia/mediawiki-extensions-VisualEditor
https://codeclimate.com/github/wikimedia/mediawiki-extensions-Wikibase
probably the new ruby gem.  see the video at 

https://wmf.ci.cloudbees.com/job/browsertests-en.wikipedia.beta.wmflabs.org-windows-internet_explorer_10/248/testReport/junit/(root)/Page/Move_existing_page_dialog/

--------------------------
**Version**: unspecified
**Severity**: normal
Change 91876 merged by jenkins-bot:
[browser test] Workaround for the problem when Cucumber hook executes twice

https://gerrit.wikimedia.org/r/91876
Change 91881 merged by Zfilipin:
no need to log in twice

https://gerrit.wikimedia.org/r/91881
Change 91881 had a related patch set uploaded by Zfilipin:
no need to log in twice

https://gerrit.wikimedia.org/r/91881
Change 91876 had a related patch set uploaded by Zfilipin:
[browser test] Workaround for the problem when Cucumber hook executes twice

https://gerrit.wikimedia.org/r/91876
There is a problem with running hooks twice.

See:

https://wmf.ci.cloudbees.com/job/VisualEditor-en.wikipedia.beta.wmflabs.org-linux-firefox/107/testReport/(root)/VisualEditor%20Headings/Cycle_through_headings_values__outline_example_____Paragraph_____Editing____/
2013-10-23 - 13:04:35  <marktraceur> !e VisualEditor | Svetlana
2013-10-23 - 13:04:36  <wm-bot> Svetlana: https://www.mediawiki.org/wiki/Extension:VisualEditor_%7c_Svetlana

It captured the " | Svetlana" part. That's very annoying.

The message is currently https://www.mediawiki.org/wiki/Extension:$wiki_encoded_* - maybe that's wrong?

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 51259 ***
Following on from bug 48430 and bug 56000.

--------------------------
**Version**: unspecified
**Severity**: normal
Now done.
Change 91198 merged by jenkins-bot:
enwiki: Enable VisualEditor for Portal: and Book:

https://gerrit.wikimedia.org/r/91198
Change 91198 had a related patch set uploaded by Jforrester:
enwiki: Enable VisualEditor for Portal: and Book:

https://gerrit.wikimedia.org/r/91198
As requested at https://ca.wikipedia.org/wiki/Viquip%C3%A8dia:La_taverna/Ajuda#Editor_visual_a_Viquiprojecte

Please enable VisualEditor in ca.wikipedia.org at the "Viquiprojecte" namespace.

Having it enabled in "Portal" wold be useful as well.

Currently VE is available also to anonymous users in the Main namespace at ca.wiki. The same behavior can be applied to these other namespaces. Thank you!

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
And deployed. It works. Thank you!
Now done.
Change 91197 merged by jenkins-bot:
cawiki: Enable VisualEditor for Portal: and Viquiprojecte:

https://gerrit.wikimedia.org/r/91197
Change 91197 had a related patch set uploaded by Jforrester:
cawiki: Enable VisualEditor for Portal: and Viquiprojecte:

https://gerrit.wikimedia.org/r/91197
VE works well-enough for pages that aren't signed, except for ones where the pages rely on fiddly or partial wikitext munging, like the Template and MediaWiki namespaces. Consequently, we should be OK to enable VE in a larger number of namespaces, rather than just NS_MAIN and NS_USER:

* NS_FILE	
* NS_HELP	
* NS_CATEGORY
* wgContentNamespaces generally?

Part of the fun are things like the portal namespace which is defined per-wiki.

See also bug 55792 for comments about enabling VE in all namespaces, and why I think that's a bad idea.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Now done.
Change 90923 merged by jenkins-bot:
Enable VisualEditor for NS_FILE, NS_HELP, NS_CATEGORY

https://gerrit.wikimedia.org/r/90923
(In reply to comment #2)
> How well does VisualEditor handle the non-editable portions of File and
> Category pages? Do they just disappear when VE is invoked?

Those aren't on the page, they're just composited on in read mode. See for example https://www.mediawiki.org/wiki/Category:Requests_for_comment or https://www.mediawiki.org/wiki/File:2013-08-21_Flow_prototype.png to take two pages at random from MWwiki.
How well does VisualEditor handle the non-editable portions of File and Category pages? Do they just disappear when VE is invoked?
Change 90923 had a related patch set uploaded by Jforrester:
Enable VisualEditor for NS_FILE, NS_HELP, NS_CATEGORY

https://gerrit.wikimedia.org/r/90923
Intention:  To copy a reference (copied from en.wp's article on [[Vanilla]]), using the "+" system within the transclusion editor into another article (Simple English's [[Vanilla]]).


Expectation:  That the ref dialog box would display the citation correctly.


Steps to reproduce:

1)  Click the menu item to insert a reference.

2)  Click the transclusion item to insert a template.

3)  Click the "+" and the "[ ]" to insert 'content' rather than individual parameters.

4)  Paste in the citation template, copied out of the English Wikipedia.  The citation template entered was:
{{cite web | title = FAO's Statistical Database - FAOSTAT | year = 2011 | url = http://faostat3.fao.org}}

5)  Click "Apply changes".


Result:

See https://commons.wikimedia.org/wiki/File:VisualEditor_Oct_2013_ref_dialog_box_with_oddly_formatted_citation_template.png

It should have displayed within the reference dialog box as:

"FAO's Statistical Database - FAOSTAT". 2011.

with the first part being the link.  Instead, it added a second copy of the URL at the end:

"FAO's Statistical Database - FAOSTAT". 2011.  http://faostat3.fao.org/

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed a while ago; sorry for slow triage.
Bug 59154 seems related.
Could we use the same subject heading for these emails so they grouped
into one thread? e.g. QA Report and move the current subject into the
email body itself?

Currently I am getting lots of mails in the form:
Build failed in Jenkins: MobileFrontend-en.m.wikipedia.org-linux-firefox #97

and it is very hard to group and filter them.

As a result I tend to ignore them due to too much noise which is bad :).

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**Whiteboard**: gci2013 https://www.mediawiki.org/wiki/Google_Code-In#Candidate_tasks
**URL**: https://www.google-melange.com/gci/task/view/google/gci2013/5243150582939648
I have another way to resolve.

I can generate an HTML file and send it as an email body.


```
Changing email body programmatically is possible now.

You can go to Manage Jenkins > Configure System and set Default Content as
           ${FILE,path="email-body.html"}​​​​​​​

           under Extended E-mail Notification area.


Now, you just have to generate email-body.html file programmatically directly under your workspace root.

Also, make sure that default content type is set to HTML.
```

src: https://softwaretestingboard.com/qna/2205/modify-email-subject-jenkins-using-automated-script-written
Change 106513 merged by Cmcmahon:
Use new e-mail template

https://gerrit.wikimedia.org/r/106513
Change 106513 had a related patch set uploaded by Zfilipin:
Use new e-mail template

https://gerrit.wikimedia.org/r/106513
Change 103114 merged by Cmcmahon:
Add jenkins email template for better email notifications

https://gerrit.wikimedia.org/r/103114
Change 103114 had a related patch set uploaded by Sn1per:
Add jenkins email template for better email notifications

https://gerrit.wikimedia.org/r/103114
Created attachment 14048
after

**Attached**: {F11948}
Created attachment 14047
before

**Attached**: {F11947}
As far as I am concerned, this bug is resolved. If you need more/less information in Jenkins e-mail notification, leave a comment. See attached e-mail for "before" and "after".
Asked cloudbees to upload the template:

https://cloudbees.zendesk.com/requests/14940
(In reply to comment #15)
> Created attachment 13967 [details]
> First version of jenkins template ready for testing
> 
> 1. To use this template, place it under $JENKINS_HOME/email-templates/
> 2. make sure email-ext plugin is installed
> 3. Under the job config for post-build actions, remove "email notification"
> and
> add "editable email notification"
> 4. Change default content type to html
> 5. Change body to ${SCRIPT, template="wikimedia-jenkins.template-1"}
> 6. Optional - change the subject using the token references; here is the one
> i
> used: ${PROJECT_NAME} ${BUILD_NUMBER} - ${BUILD_STATUS}
> 7. Set the recipients, etc.
> 8. Open Advanced Settings... and there you can change when an email
> notification is triggered.

If you want the subject to be constant for one build, make the subject just ${PROJECT_NAME}

//attachment wikimedia-jenkins-1.template ignored as obsolete//
(In reply to comment #26)
> If you would like to continue working on the template (making it look more
> like
> Jenkins web page) I will create another task.

Sure, I would definitely like to finish up this template.
Final email template (for now)

**Attached**: {F11946}
Geoffrey, the last e-mail that I got from your local Jenkins looked good to me! Please upload the template here so I can test it with our Jenkins and if it works I will close the task.

If you would like to continue working on the template (making it look more like Jenkins web page) I will create another task.

If you would like to work on something else, we have plenty of tasks.
(In reply to comment #24)
> Created attachment 13990 [details]
> how e-mail notification after failed test should look like

Do you want the entire table there in the email?  Right now I have the notifications working with everything and it looks pretty close to the jenkins build page.

**Attached**: {F11945}
Created attachment 13990
how e-mail notification after failed test should look like

**Attached**: {F11945}
Geoffrey,

see attached file on how an e-mail notification after failed test should look like. It is generated by this test:

https://geofbot.ci.cloudbees.com/job/test2/lastCompletedBuild/testReport/
I forgot to say, now you can test e-mail notifications using your jobs. If you have any questions, let me know.
Created attachment 13979
e-mail notification with failed tests

**Attached**: {F11944}
Geoffrey,

I did not want to mess up existing job (test), so I have created another one (test2). Short documentation on how to set up a job to run tests is available[1]. I have cloned browsertests[2] repository and the job runs tests from login.feature[3] file. I will attach e-mail that was sent after the job failed.

1: https://github.com/wikimedia/mediawiki-selenium/blob/master/docs/job.md
2: https://github.com/wikimedia/qa-browsertests
3: https://github.com/wikimedia/qa-browsertests/blob/master/features/login.feature
Example html 3

The example html for template 1.1

//attachment progress3.html ignored as obsolete//
Template v1.1

Better version with some bugs ironed out

Would be nice if someone tested out the "tests" part of it because I don't have tests set up for my local jenkins build.

//attachment wikimedia-jenkins.template ignored as obsolete//
Example html 2

I don't have tests set up on my jenkins, so unfortunately I couldn't test that aspect of the template

I replaced all of the LAN image references with a cloudbees link so they would work, but the links to the build will be broken.

//attachment progress2.html ignored as obsolete//
Geoffrey, can you attach an example e-mail, so we can see if the template does what we need?
First version of jenkins template ready for testing

1. To use this template, place it under $JENKINS_HOME/email-templates/
2. make sure email-ext plugin is installed
3. Under the job config for post-build actions, remove "email notification" and add "editable email notification"
4. Change default content type to html
5. Change body to ${SCRIPT, template="wikimedia-jenkins.template-1"}
6. Optional - change the subject using the token references; here is the one i used: ${PROJECT_NAME} ${BUILD_NUMBER} - ${BUILD_STATUS}
7. Set the recipients, etc.
8. Open Advanced Settings... and there you can change when an email notification is triggered.

//attachment wikimedia-jenkins-1.template ignored as obsolete//
Progress on email-ext customization

//attachment progress1.html ignored as obsolete//
Geoffrey, feel free to attach the e-mail to this bug, or to send it to me, so I could take a look.
Progress!

I managed to extract the first line of console output to find who started the job.  It took a lot of guesswork (I have never coded in Groovy before, especially not within a HTML :P)
Geoffrey, this might be the problematic part: "Have your Jenkins administrator place the script inside JENKINS_HOME\email-templates." (from plugin documentation[1]).

You should contact cloudbees support and ask how to do it.

1: https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin
Cloudbees URL: https://geofbot.ci.cloudbees.com/job/test/
Hi Geoffrey and welcome!

For future reference, if you get stuck you can ask questions here, at #wikimedia-qa freenode IRC channel or at QA mailing list[1].

To answer your question, start with either installing Jenkins[2] on your local machine or create a free account at a hosted Jenkins service, like Cloudbees[3].

When you have a test Jenkins instance, create a few jobs and start sending e-mail notifications to your e-mail.

Then install the plugin[4] Jeff has suggested and try changing the e-mail notifications so they look more like this report[5].

If you get stuck, or if you have any questions, let us know.

1: https://lists.wikimedia.org/mailman/listinfo/qa
2: http://jenkins-ci.org/
3: http://www.cloudbees.com/
4: https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin
5: https://wmf.ci.cloudbees.com/view/r-ve/job/VisualEditor-en.wikipedia.beta.wmflabs.org-linux-chrome/164/
Hey, I'm GEOFBOT from GCI!  I think I'll try out this task, but I have no clue how to start out.  Where should I start out?
(In reply to comment #6)
> From what I understand, the people would like the e-mail notification to look
> similar to this page:
> 
> https://wmf.ci.cloudbees.com/view/r-ve/job/VisualEditor-en.wikipedia.beta.
> wmflabs.org-linux-chrome/164/

Yeah, that would be *much* more useful. It would also be nice to still get the recent changes that were checked in like in the current mail, eg:

Changes:

[roan.kattouw] Share code between conflict resolution and the edit source
switch

[roan.kattouw] Don't build out save dialog when initializing editor

[roan.kattouw] Use InputWidget facilities in byte limit counter

[krinklemail] Remove the toolbar tracker

And if they could provide links to changesets gerrit, that would be even better :)

It would also be good if there was a direct link provided to the build in jenkins.
From what I understand, the people would like the e-mail notification to look similar to this page:

https://wmf.ci.cloudbees.com/view/r-ve/job/VisualEditor-en.wikipedia.beta.wmflabs.org-linux-chrome/164/
Created attachment 13911
typical Jenkins report

**Attached**: {F11943}
This is how a typical Jenkins report looks like (see attached file).
**jhall** wrote:

I used this plugin in a previous job and found it to be very flexible (among other things, it provides for customized e-mail subject strings):

https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin
We should find a Jenkins plugin that should allow us to customize e-mail notification messages. The default messages are not really useful.
Seen in Chrome and not Firefox: 

Sometimes initiating a VE session can take on the order of 3X the normal time (or possibly more).  This is a UX issue and also causes significant intermittent browser test failures in Chrome version 30.  Here are 10 runs of a script[*] that times how long it takes to bring up and dismiss the "Welcome..." iframe:

2.194106
2.187554
2.222601
2.226447
2.369503
2.182237
7.639938 *
2.335375
2.397571
2.271333

This is on a fast connection.  The performance issue is exacerbated on a slow connection.

Speculation as to the root cause: 

* The "Welcome..." iframe is actually the second iframe in the page.  The first, much larger iframe in the page is invisible and is a complete copy of the base VisualEditor UI.  It could be that loading both iframes could cause intermittent performance problems. 

* (Note that the invisible first iframe on the page not only contains an entire VE UI, but may also contain gadget code like HotCat or ProveIt sourced from other places like bits, see screen shot and Bug 55759.)

[*] The meat of the little Ruby timer script is: 

#CLICK EDIT
b.a(:title => /Edit this page with VisualEditor/).when_present.click
#SAVE START TIME
welcome_start_time = Time.now
#CLICK CLOSE ON THE WELCOME IFRAME WHEN IT BECOMES CLICKABLE
b.frame(:index => 1).a(:title => 'Close').when_present.click
#SAVE END TIME
welcome_end_time = Time.now
welcome_load_time = welcome_end_time - welcome_start_time
puts welcome_load_time.to_s

--------------------------
**Version**: unspecified
**Severity**: normal
probably not, closing.
I don't know what significant intermittent performance problem you are observing in Chrome, but I am fairly confident that this is not related to ProveIt, or any other gadget.
Gadgets are not and never were loaded in our iframes.

The only thing related to gadgets being applied in iframes is their stylesheets. And this is not an explicit action, but a result of the stylesheet link established between the parent and child frame to ensure content looks the same.

Afaik this should not have any significant impact in performance as 1) these styles are loaded in the same request as other styles, 2) the exact same request has been fired and cached already in the parent frame, and as such is pretty much guaranteed to be 304 cached if not already.

Also, in non-debug mode, most stylesheets actually become <style> tags which are cloned to the iframe without any intermittent load.php request (be it a 304 or not).
I also don't see a reason to load gadgets in the VE frames.  Since it's same-origin, gadgets can reach into the iframe if needed.  E.g.

$( $( '.ve-ui-frame' )[0].contentDocument ).find( '.ve-ui-labeledElement-label' )
Created attachment 13511
contents of the invisible iframe

**Attached**: {F12750}
https://integration.wikimedia.org/ci/job/mwext-VisualEditor-phpcs-HEAD/1561/console is a bogus failure. The error messages are:

14:41:05 FILE: ...orkspace/mwext-VisualEditor-phpcs-HEAD/maintenance/makeStaticLoader.php
14:41:05 --------------------------------------------------------------------------------
14:41:05 FOUND 2 ERROR(S) AFFECTING 2 LINE(S)
14:41:05 --------------------------------------------------------------------------------
14:41:05  78 | ERROR | Expected 1 space before "?"; 3 found
14:41:05     |       | (Squiz.WhiteSpace.OperatorSpacing.SpacingBefore)
14:41:05  80 | ERROR | Expected 1 space before ":"; 3 found
14:41:05     |       | (Squiz.WhiteSpace.OperatorSpacing.SpacingBefore)
14:41:05 --------------------------------------------------------------------------------

The source code doesn't have 3 spaces before the ?, only a bunch of tabs), but it does have a comment on the preceding line each time. Maybe that's what's confusing phpcs?

--------------------------
**Version**: wmf-deployment
**Severity**: normal
Looking at the code, the phpcs failure seemed correct, the ternary operators should be at end of line.
Filing this because it will eventually block https://gerrit.wikimedia.org/r/#/c/88896/ once that commit has been cleaned up and reviewed.
**Author:** `felix`

**Description:**
* Edit one section with VE
*:Example diff:
*:+ VEtext

* Provoke edit conflict in another section
*:Example diff:
*:+ ConflictText

* Click "Review your changes" in VE

* Diff shows
** the changes made in VE
** the changes of the edit conflict as reverted (!)
*:Example diff:
*:+ VEtext
*:- ConflictText

* Click "Save page"
** Both edits are successfully merged
*:Example diff:
*:+ VEtext
*:+ ConflictText

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55392
This is the same behaviour as the wikitext editor - what would you instead suggest VisualEditor (and the wikitext editor) do?
On talk pages that have titles starting with a full stop (period) such as [[talk:.mp]] and [[it:Discussione:.uk]] the button to launch VE is shown despite not being enabled in that namespace. Clicking on it gives the following error message:

Error loading data from server: novenamespace: VisualEditor is not enabled in namespace 1. Would you like to retry?

(incidentally this message is not translated for it.wp)

Possibly this bug has the same cause as bug 55493

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55493
We fixed this just this week (this is also bug 38081 - if the page starts with a '.', mw:Title fails and so the code to suppress VE doesn't work), and will be deploying it to MediaWiki.org on Thursday (10 October); assuming that all goes well, it will hit the English Wikipedia next Thursday (17 October).

*** This bug has been marked as a duplicate of bug 38081 ***
At least in Firefox 24 on Linux (not tested in other systems) VisualEditor does not load on main namespace pages whose titles begin with a full stop (period). The URL changes and the page reloads but remains in view mode.

Tested at [[.mp]], [[.uk]], [[.300]] and [[.300 Remington American Magnum]] at en.wp and at the .uk articles at it.wp, de.wp, fr.wp and es.wp

The bug does not manifest in other namespaces, e.g. [[User:Thryduulf/.100]] and [[User:.anaconda]] load correctly.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55494
We fixed this just this week (this is bug 38081), and will be deploying it to MediaWiki.org on Thursday (10 October); assuming that all goes well, it will hit the English Wikipedia next Thursday (17 October).

*** This bug has been marked as a duplicate of bug 38081 ***
TeamGale reports:

"while I was getting more down to the page, the drop down menus were getting "shorter" and sometimes disappear at the very end. I tried it to many pages to see if it was happening everywhere and it does. I don't know exactly how to describe it that's why I took screencaps from the page. All three are from the same page, in different height. See how the drop down menu of "more" can be seen entirely at the top of the page and how it gradually disappear as I get closer to the bottom. It's really weird!! The same thing happens when I am trying to add a wiki link in the article's text and to be honest, that's how I notice the gradually disappearing."

The screenshot is at [[File:Drop Down Menus.jpg]]

I can reproduce this in Firefox 24 on Linux when using the vector skin, but not when using Monobook. 

Trying to add a link after the end of the first paragraph I get no suggestions when my window is not maximised. Even when it is maximised it has completely disappeared by the end of the page. 

What seems to matter is where the view is, not where the cursor is.

--------------------------
**Version**: unspecified
**Severity**: major
*** This bug has been marked as a duplicate of bug 55343 ***
See also bug 55343
TeamGale didn't give their system details with this report, but from another report of theirs they are most likely using the latest Firefox on Windows 8.
Login at http://en.wikipedia.beta.wmflabs.org/ with VE enabled. 

Click edit on any page to invoke VE.

Page reloads, VE is not invoked. 

Javascript errors: 

Exception thrown by ext.visualEditor.viewPageTarget.init: Object function (selector,context){return new jQuery.fn.init(selector,context,rootjQuery);} has no method 'byteLength' load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.…%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130927T181331Z:151
TypeError
 load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.…%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130927T181331Z:151
Exception thrown by ext.gettingstarted.openTask: Object function (selector,context){return new jQuery.fn.init(selector,context,rootjQuery);} has no method 'byteLength' load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.…%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130927T181331Z:151
TypeError
 load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.…%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20130927T181331Z:151

--------------------------
**Version**: 1.22.0
**Severity**: critical
Change 87593 merged by jenkins-bot:
mw.Title: Add missing dependency on jquery.byteLength

https://gerrit.wikimedia.org/r/87593
Change 87593 had a related patch set uploaded by Krinkle:
mw.Title: Add missing dependency on jquery.byteLength

https://gerrit.wikimedia.org/r/87593
User report:
<<[...] The new one (for me at least, perhaps it already existed): when I edit a page in Beta (my sandbox, or a main space page), I get next to the page title two pale blue links, "edit source / edit beta", which bring me to the section editing for the lead. I don't get these pale links for other sections, only next to the title. I can't remember these being there, and I can't see the use for them (and if they have a use, they would probably be wanted for other sections as well). Fram (talk) 12:01, 4 October 2013 (UTC) >>

He uses FF 24, I can't reproduce but we have a screenshot at 
https://en.wikipedia.org/wiki/File:VE_error_Fram_1.jpg .

--------------------------
**Version**: unspecified
**Severity**: minor
(In reply to comment #5)
> I submitted a step towards potentially fixing this and other editsection and
> VE-related bugs at https://gerrit.wikimedia.org/r/#/c/87627/ (after recent
> discussion at [[WP:VPT]]).

Thanks!
I submitted a step towards potentially fixing this and other editsection and VE-related bugs at https://gerrit.wikimedia.org/r/#/c/87627/ (after recent discussion at [[WP:VPT]]).
This is caused by the "Add an [edit] link for the lead section of a page" gadget on enwiki.

As normal, because gadgets' bugs aren't tracked on Bugzilla, I'm marking this as INVALID, but please do contact the author of the gadget and ask them to fix it. :-(
Fram, the original reporter, has confirmed that he uses Vector so it does seem to be skin-specific.
I can confirm that I see this in Firefox 24/Linux/Monobook. I don't see it when using Vector skin. I don't have access to other browsers/systems to test on.

Test page: https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox4&oldid=575760261
<<Note that I only get this when the page has at least one section header. Pages without section headers don't have this behaviour. [[User:Fram|Fram]] ([[User talk:Fram|talk]]) 14:12, 4 October 2013 (UTC)>>
>>! In T56962#1051546, @jayvdb wrote:
> Is T69476 part of the scope of this task?

No, that should be handled there.

Regarding the `size` column, looking at `maintain-replicas.pl` showed that it should not be `1` for all wikis, so I filed T90084 for that.

I close this task as its original bug has been fixed.
Is T69476 part of the scope of this task?
At the moment, there are two wikis apart from `centralauth` that have `name` set to `NULL`:

```
MariaDB [enwiki_p]> SELECT * FROM meta_p.wiki WHERE name IS NULL;
+-------------+------+------+-------------+------------------------------+------+-----------+-----------+----------+-----------------+------------------+--------------+
| dbname      | lang | name | family      | url                          | size | slice     | is_closed | has_echo | has_flaggedrevs | has_visualeditor | has_wikidata |
+-------------+------+------+-------------+------------------------------+------+-----------+-----------+----------+-----------------+------------------+--------------+
| qualitywiki | en   | NULL | special     | http://quality.wikimedia.org |    1 | s3.labsdb |         1 |        1 |               0 |                0 |            0 |
| centralauth | en   | NULL | centralauth | NULL                         |    1 | s7.labsdb |         0 |        0 |               0 |                0 |            0 |
| ukwikimedia | en   | NULL | wikimedia   | http://uk.wikimedia.org      |    1 | s3.labsdb |         1 |        1 |               0 |                0 |            0 |
+-------------+------+------+-------------+------------------------------+------+-----------+-----------+----------+-----------------+------------------+--------------+
3 rows in set (0.00 sec)

MariaDB [enwiki_p]>
```

As these are closed wikis I assume that is correct?

Also, there are no wikis with `size` not being `1`:

```
MariaDB [enwiki_p]> SELECT size, COUNT(*) FROM meta_p.wiki GROUP BY size;
+------+----------+
| size | COUNT(*) |
+------+----------+
|    1 |      858 |
+------+----------+
1 row in set (0.00 sec)

MariaDB [enwiki_p]>
```

Is this column important to you, @Pietrodn?  Otherwise I'd propose to resolve this task as the main issues seem to have been fixed.
Change 160945 merged by coren:
Labs: Fix generation of meta_p.meta

https://gerrit.wikimedia.org/r/160945
Change 160945 had a related patch set uploaded by coren:
Labs: Fix generation of meta_p.meta

https://gerrit.wikimedia.org/r/160945
Now the problem seems to be fixed.
The meta_p.wiki tables now contains only one row: centralauth.

MariaDB [meta_p]> select * from wiki;
+-------------+------+------+-------------+------+------+-----------+-----------+----------+-----------------+------------------+--------------+
| dbname      | lang | name | family      | url  | size | slice     | is_closed | has_echo | has_flaggedrevs | has_visualeditor | has_wikidata |
+-------------+------+------+-------------+------+------+-----------+-----------+----------+-----------------+------------------+--------------+
| centralauth | en   | NULL | centralauth | NULL |    1 | s7.labsdb |         0 |        0 |               0 |                0 |            0 |
+-------------+------+------+-------------+------+------+-----------+-----------+----------+-----------------+------------------+--------------+
1 row in set (0.00 sec)
There was a typo that prevented the size column from being properly set.  Fixed since.
(In reply to comment #3)
> (In reply to comment #2)
> > Also 'is_closed' column is always 0, for all the wikis.
> 
> That would be because we do not currently replicate any closed wikis.  :-)
Ah, ok! Alright :)

> For the other values, things should have been corrected now.  Please check?
Now it seems ok, except for the 'size' column, is always 1 yet.
(In reply to comment #2)
> Also 'is_closed' column is always 0, for all the wikis.

That would be because we do not currently replicate any closed wikis.  :-)

For the other values, things should have been corrected now.  Please check?
Also 'is_closed' column is always 0, for all the wikis.
Yes, the URL being incorrect is likely the cause of the other errors.  Looking into it.
I am using Malayalam Inscript2 IME of ULS for typing in Malayalam Wikipedia. Problem is described here:

1. Open an article from ml.wikipedia (for eg. https://ml.wikipedia.org/wiki/%E0%B4%B8%E0%B5%82%E0%B4%AB%E0%B4%BF )
2. Edit a section using VE
3. Add a new line at the end of the section and type a word using ULS IME
4. Press Spacebar, the typed word disappears.

--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Windows 7
**Platform**: PC
**URL**: http://ml.wikipedia.org
Pretty sure that this is the same issue as bug 53700 - merging.

*** This bug has been marked as a duplicate of bug 53700 ***
As demonstrable in the last image inserted in:

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

refs inserted in the description of media, here 1), can't be edited. Report:

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

--------------------------
**Version**: unspecified
**Severity**: normal
Happily this is already fixed in the code that just went to MediaWiki.org today, and will be available on dewiki (and elsewhere) in a week's time. Merging with bug 50459.

*** This bug has been marked as a duplicate of bug 50459 ***
example of the non-float

Reproduced on Windows 7 and Mac OSX 10.8.5 — when a new template is added to an article it does not follow float:right. However, on page save and a re-entry of the VE it is properly floated.

See the attached screenshot. This really breaks the WYSIWYG nature of the VisualEditor.

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

**Attached**: {F12578}
I'm merging this with bug 49784 - agreed that it's a real product fail.

*** This bug has been marked as a duplicate of bug 49784 ***
Such as:
* Page settings
* Help/about/version
* Switch to source editing

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #0)
> Such as:
> * Page settings
> * Help/about/version
> * Switch to source editing

Err… this was already done by Trevor many months ago. See https://commons.wikimedia.org/wiki/File:VisualEditor_-_Icon_-_Menu.svg for the version on Commons, let alone the version in the repo…

(In reply to comment #1)
> https://en.wikipedia.org/wiki/%E2%98%B0
> 
> Is using Qián (☰) going to cause problems with Chinese language UI's, or will
> it require browsers to download additional fonts in order to render it?

No, we're not using a character, we'll use an SVG icon like the rest of the interface.
https://en.wikipedia.org/wiki/%E2%98%B0

Is using Qián (☰) going to cause problems with Chinese language UI's, or will it require browsers to download additional fonts in order to render it?
Edit tab titles are not consistent (on hu.wikipedia):

- If I am logged out, I see tab title "visualeditor-ca-editsource", and it opens the source edit page.
- If I am logged in, and I have opt-outed from VisualEditor, then I see "vector-view-edit", and it opens the source edit page.
- If I am logged in, and I have VisualEditor enabled (default), then I see "vector-view-edit", which opens the visual edit page, and also "visualeditor-ca-editsource", which opens the source edit page.

Some user on hu.wikipedia complained, that the same "vector-view-edit" meant source edit 2 days ago, and it now means visual edit, which is confusing. So we would like to rename both tabs, to be clear for everyone: we want to create a "Visual edit" and a "Source edit" tab, with the same text for everyone. But this structure makes impossible to set translation according to this, because opt-outed users se the same text for source edit as non-opt-outed users for visual edit.

--------------------------
**Version**: unspecified
**Severity**: normal
This is intentional - for a week, we deploy VisualEditor for logged-in users before we deploy it for logged-out users. This will be fixed for huwiki on Monday when VisualEditor is enabled by default for logged-out users too. Sorry for the disruption.

*** This bug has been marked as a duplicate of bug 49999 ***
http://git.wikimedia.org/summary/?r=VisualEditor/core.git

Seems unneeded.

--------------------------
**Version**: wmf-deployment
**Severity**: minor
We're about to fill it with content. So… no, please don't.
Hi
Just like the title, if I edit the body of the text, at every newline it enters an ♙ character, and I have to manually delete every time (by writig, going back and deleting).

Also there are many other special characters displayed, like arrows for tab and return. Don't know if it's the same issue.

The wiki is hosted on a CentOS 6.4 box, running latest versions of apache and PHP, under a virtualhost. The client is an OSX 10.9 computer.

Please tell me if you need any additional information.

Thank you.

--------------------------
**Version**: unspecified
**Severity**: normal
**Platform**: Macintosh
Hi there,

This is a break we introduced on Friday, sorry - a fix is now in gerrit 86685 and will be merged in the next few minutes. Up-merging this with bug 54791 reported by our QA team. Thanks for the bug report!

(In reply to comment #0)
> Also there are many other special characters displayed, like arrows for tab
> and return. Don't know if it's the same issue.

That's not - this is intentional as a means to differentiate different kinds of whitespace (which show up differently to the user in wikitext, but would otherwise look the same in HTML).

*** This bug has been marked as a duplicate of bug 54791 ***
Inserting media with VE

Sometimes I cant add image, because it doesnt display. This time at https://cs.wikipedia.org/wiki/Seznam_památných_stromů_v_okrese_Rokycany

adding File:Kařízský dub, pohled.jpg with FF 23.0.1

--------------------------
**Version**: unspecified
**Severity**: major
**Whiteboard**: cirrus-fixed

**Attached**: {F12341}
*** This bug has been marked as a duplicate of bug 52782 ***
(In reply to comment #2)
> Doesnt work still to me. Thats why I am opening it again. Once you will
> update search, lets talk about clossing.

This has nothing to do with VisualEditor; re-assigning.
Doesnt work still to me. Thats why I am opening it again. Once you will update search, lets talk about clossing.
This is because the old search system is slow to update (it now works for me). Happily the new search system (which is coming hopefully soon). Sorry. :-(
When you want to drag an element to the very bottom of the content editable area, the last position available for the cursor is the end of the last sentence. 

Usually you want to place elements not at the end of a line, but right after, in a new line. The behavior expected would be to see a new empty line appearing when you drag an element until the end of a page, and the possibility to drop your element in that empty line.

Tested with the {{Languages}} template at https://www.mediawiki.org/wiki/Groups 

The last cursor position possible is at the end of the sentence: "... to create your MediaWiki group." Dropping the template after the last dot puts it at the end of the page, in a new line. The end result is correct, but the behavior is unituitive.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51666
(In reply to comment #0)
> When you want to drag an element to the very bottom of the content editable
> area, the last position available for the cursor is the end of the last
> sentence. 
> 
> Usually you want to place elements not at the end of a line, but right after,
> in a new line. The behavior expected would be to see a new empty line
> appearing when you drag an element until the end of a page, and the
> possibility to drop your element in that empty line.

Merging this with bug 51666 which I've re-titled.

(In reply to comment #2)
> (In reply to comment #1)
> > Note also that for me, on
> > [https://www.mediawiki.org/wiki/Communication?veaction=edit], the "other
> > languages" template at the top is not even visible in VE mode... This is
> > probably a separate bug though.
> 
> Possibly it is or is related to bug 50284

No, this is because of the code inside the "other languages" template making assumptions which are true for read mode but not for VisualEditor - I think this is an artefact of bug 50172 and a few other issues.

*** This bug has been marked as a duplicate of bug 51666 ***
(In reply to comment #1)
> Note also that for me, on
> [https://www.mediawiki.org/wiki/Communication?veaction=edit], the "other
> languages" template at the top is not even visible in VE mode... This is
> probably a separate bug though.

Possibly it is or is related to bug 50284
**Wikifram** wrote:

Only now noticed this. For me, dropping the template after the last dot was not even possible. I could drop it before the last dot, but not after, so for me it was not simply unintuitive, it was wrong. But now, this has been solved apparently, whether by a new VE version or by a Firefox update I don't know. 

Note also that for me, on [https://www.mediawiki.org/wiki/Communication?veaction=edit], the "other languages" template at the top is not even visible in VE mode... This is probably a separate bug though.