(In reply to Alex Monk from comment #2)
> I wonder if we can just do something like this
> 
> $( newDoc )
> 	.remove( '[id=myEventWatcherDiv]' ) // Bug 51423
> 	.remove( 'object[type=cosymantecnisbfw],
> script[id=NortonInternetSecurityBF]' ) // Bug 63229
> 	.remove( 'embed[id ^= xunlei_com_thunder_helper_plugin]' ) // Bug 63121
> 	.remove( 'div[id=sendToInstapaperResults]' ) // Bug 61776
> 	.remove( 'style[id=_clearly_component__css]' ) // Bug 53252
> 	.remove( 'script[id=FoxLingoJs]' ) // Bug 52884
> 	.remove( 'embed[type=application\\/x-datavault]' ) // Bug 52791
> 	.remove( 'embed[type=application\\/iodbc]' ); // Bug 51521

Yeah I was thinking about doing something like that. We have no easy way to know in advance what that will fix, but we can try it.
I wonder if we can just do something like this

$( newDoc )
	.remove( '[id=myEventWatcherDiv]' ) // Bug 51423
	.remove( 'object[type=cosymantecnisbfw], script[id=NortonInternetSecurityBF]' ) // Bug 63229
	.remove( 'embed[id ^= xunlei_com_thunder_helper_plugin]' ) // Bug 63121
	.remove( 'div[id=sendToInstapaperResults]' ) // Bug 61776
	.remove( 'style[id=_clearly_component__css]' ) // Bug 53252
	.remove( 'script[id=FoxLingoJs]' ) // Bug 52884
	.remove( 'embed[type=application\\/x-datavault]' ) // Bug 52791
	.remove( 'embed[type=application\\/iodbc]' ); // Bug 51521
Here's a novel one: https://sv.wikipedia.org/?diff=27732757
The context menu for Basic Reference is still appearing, letting user to get stuck inside it after adding dfferent elements in it.
We need to disable it.

--------------------------
**Version**: unspecified
**Severity**: normal
The context menu for math and references list started appearing too.
This is again appearing in mobile.
Verified the fix in production.
Verified the fix in test2
Verified the fix in Betalabs
The context menu for basic reference is still appearing in Betalabs
Change 151807 merged by jenkins-bot:
Disable basic reference on mobile

https://gerrit.wikimedia.org/r/151807
Change 151807 had a related patch set uploaded by JGonera:
Disable basic reference on mobile

https://gerrit.wikimedia.org/r/151807
**Author:** `hu60.cn`

**Description:**
There is a strange trouble happen when I edit with Baidu Pinyin (a Chinese IME) on Firefox runing on Windows 8.1. Baidu Pinyin can input two or more characters once. When I input "你好" at once, display is OK. But when I save or delete some characters, the display refreshs and "你" lost, a blank instead of the character.

Example:

I input "可视化编辑器已可用。"

And save, it looks like:

 视化 辑器 可用。

The first character at each input lost.

However, when I switch IME to Microsoft Pinyin, the BUG disappear. All input works fine. Switch to Baidu Pinyin, the BUG continuing.

I don't know what happened.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Windows 8.1
**Platform**: PC
Does this block T51569?
**hu60.cn** wrote:

I made a mistake. The IME I use is Sogou Pinyin, not Baidu Pinyin.
Steps to reproduce:

1.Open a page with Mobile VE
2.Place the cursor anywhere in CE
3.Change the screen orientation to landscape
4.Again rotate the screen

Observed Result:
CE gets zoomed in each time I rotate the screen

Environment:Betalabs

--------------------------
**Version**: unspecified
**Severity**: normal
Seems to work for me now. Tested on Beta Cluster using iOS Safari 8.0 on an iPad.
Needs re-testing.
+++ This bug was initially created as a clone of Bug #68297 +++

On mediawiki.org, there is a family on fancy templates like [[mw:Template:MW 1.23]] that generate a right-floated MediaWiki version number in a frame.

These templates generate a wikitext table (starting with '{|'), which means that due to bug 529 / bug 12974 a newline is prepended before it. This behavior is incredibly annoying in practice, but it seems that we're very much wedded to it because it made Parsoid people's lives easier.

However, Parsoid rendering of this particular template is inconsistent with PHP. On [[mw:Manual:Skinning#Localisation_messages]], PHP generates an empty paragraph before the table, while Parsoid doesn't and produces an about-grouped pair of <span>\n</span><table>…</table> (the span tag only contains the prepended newline).

This rendering, that looks good in Parsoid/VisualEditor, therefore looks like crap in PHP parser.

Note that the <span> is not nested in a <p> or any other block-level element, it just sits there right in the <body>. (It is not visible since, as I mentioned, it just contains some whitespace.)

--------------------------
**Version**: unspecified
**Severity**: major
The php parser no longer seems to generate an empty paragraph and the parsoid output seems comparable. The span wrapping of the newline is to mark it as template generated for suppressing on roundtrip.

The `_rtselser/mediawikiwiki/Manual:Skinning?oldid=1072136` seems fine.

But of note,

```
echo "{{MW 1.22|and later}} MediaWiki 1.22 added support for <code>." | node parse --prefix mediawikiwiki --wt2wt
{{MW 1.22|and later}}
<nowiki> </nowiki>MediaWiki 1.22 added support for <code>.
```
Steps to reproduce:

1.Open a page with Mobile VE
2.Add few references 
3.Now open Re-use existing reference dialog
4.Try to type a reference name in the field

Observed Result: 
Nothing happens

5.Save the page
6.Reopen the page and try again typing reference name in the field,

Observed Result:
Nothing happens


7.Now select any reference from the list
8.Reopen the Re-use dialog,try typing a reference name in that dialog

Observed Result
this time it will work

--------------------------
**Version**: unspecified
**Severity**: normal
Seems to work for me now (in Citoid), but it's a bit of a mess. Tested on Beta Cluster using iOS Safari 8.0 on an iPad.
Seems to work for me now (in Citoid), but it's a bit of a mess. Tested on Beta Cluster using iOS Safari 8.0 on an iPad.
Needs re-testing.
screenshot1

Environment- 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 Language from the text style menu, closes the drop down.
5>Cursor is at the beginning of the line. Click again on the style text menu to see that the Language is selected . See screenshots.
6> Notice typing the first letter deselects the Language from the drop-down, and so the language inspector never appears.

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

**Attached**: {F14328}
Created attachment 16121
screenshot

**Attached**: {F14330}
In Chrome and FF only the Language Inspector appears out of place when launched for the first time.The steps to reproduce are the same.See screenshot.Both in test2 and beta.
Change 150738 merged by jenkins-bot:
Set a default language for ve.dm.Document if we can't guess it otherwise

https://gerrit.wikimedia.org/r/150738
This is… interesting.
Change 150738 had a related patch set uploaded by Jforrester:
Set a default language for ve.dm.Document if we can't guess it otherwise

https://gerrit.wikimedia.org/r/150738
baehavior found in betalabs.
Ed, is this fixed by gerrit 149635?
Created attachment 16089
screenshot2

**Attached**: {F14329}
screenshot

Environment- test2,betalabs, 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”. This should make the “Caption” inaccessible, but it is not. See screenshot.
Now click on Caption pane, and then into Alternative Text, this makes the toolbar in the Caption pane blurred.

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

**Attached**: {F14322}
Issue Resolved in test2 and beta.
Change 150304 merged by jenkins-bot:
Focus the caption surface on initialization

https://gerrit.wikimedia.org/r/150304
Change 150304 had a related patch set uploaded by Mooeypoo:
Focus the caption surface on initialization

https://gerrit.wikimedia.org/r/150304
Okay, I seem to have misunderstood the bug, sorry about that; I thought you were talking about the entire caption field, not just the toolbar.

I'll take care of this. Thank you for the report!
*** Bug 68809 has been marked as a duplicate of this bug. ***
This is a little more complicated than that, though. An image could absolutely have both a caption and an alternate text, and a caption can "act" like alternate text in case of inline images. 

More to the point, a block image can have both a caption under the image and an alternative text ("title" popup). An inline image doesn't have a functional caption - but the caption serves as its alternate text unless an alternate text overrides it.

In short, we need to figure out a consistent way of how to handle caption and alt text in images in general. Just disabling the caption in case of alternate text is not really representative of what is allowed under all cases.
Take this HTML:
```
<ul><li>asd
sdf</li></ul>
```
Parse to wikitext:
```
* asd
sdf
```
Parse back to HTML:
```
<ul><li>asd</li></ul>
<p>sdf</p>
```
I'm not sure what should happen here, but definitely not this.

It's rather easy to run into this in VisualEditor – take a paragraph with newlines and convert it to a list item. I ran into it making this edit: https://en.wikipedia.org/w/index.php?title=Polish_nationality_law&diff=prev&oldid=618961884 (I manually replaced the newlines with spaces before saving).

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**: {T55568}
I'm a bit confused - what was the actual list item content given in the Description of this task suppose to be -- 2 words or 1 word?
```
* asd sdf
```
OR
```
* asdsdf
```
If the desired output was the first one (2 words), then I can get that (no VE) by inserting then previewing the following:
```
<ul>
<li>asd 
sdf</li>
</ul>
```
This will need a Parsoid fix since other Parsoid users might still give it HTML that won't be preserved in the html -> wt -> html transformation. 

VE can choose to fix or not independently.
In cases like this, it would probably be reasonable to just convert newlines to spaces at some point (either in VisualEditor or in Parsoid).

Perhaps VisualEditor would be a better place to implement this from the user's perspective, but Parsoid doing what it does now would still be weird :) – maybe we should just fix this in both places?
Yes, this is a known issue. Parsoid currently cannot handle arbitrary HTML and convert it to wikitext in a way that preserves rendering on the html -> wt -> html path. But, we've talked about this issue more generally in the past and will address it including fallback mechanisms where some forms of HTML will have to get serialized as HTML tags rather than native wikitext. I thought we had a tracking or related set of bugs for this but, cannot find it right now.

We should identify any other related breakages that arise from within VE (which doesn't necessarily generate arbitrary HTML) and fix them together in Parsoid. This fix would be simpler than support for generic HTML->wt conversion that is preserved in a html2html transformation.
Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Make it thumbnail-left
4.Now while the image is selected,Open the link inspector tool
5.Without making any change, just close the link inspector by clicking on Done button
  
Observed Result:
The image gets repositioned as thumbnail-right again.

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in Production
Has been fixed in d635974160ee749a344420ca18b43b401080c346.
This is almost certainly because there's an undo in AnnotationInspector, which expects there to be a corresponding transaction, but there isn't one.
Output of the error in commons beta lab

Error: 

Could not read or write file "mwstore://local-backend/local-public/3/3d/VisualEditor_save_dialog-he.png" due to insufficient permissions or missing directories/containers.

Could not store file "/tmp/UgKpr4" at "mwstore://local-backend/local-public/3/3d/VisualEditor_save_dialog-he.png".

I had got similar error while uploading images through API: 

{    
     "servedby": "deployment-mediawiki02",     
     "error":
          {         
              "0": [             "backend-fail-usable",             "mwstore://local-backend/local-public/6/68/VisualEditor_Insert_Menu-he.png"         ],         
              "1": [             "backend-fail-store",             "/tmp/owzHOG",             "mwstore://local-backend/local-public/6/68/VisualEditor_Insert_Menu-he.png"         ],         
              "code": "internal-error",         
              "info": "An internal error occurred"     
          } 
}

Scenario: 

* I go to one of the image which I had already uploaded in commons[0].

* I click on upload new version of this file at the bottom of the page.

* I add a new image[1] by browsing my file system and I click Upload file.

* Then I get the error reported above or the image in attachment.

-
[0]: http://commons.wikimedia.beta.wmflabs.org/wiki/File:VisualEditor_save_dialog-en.png

[1]: http://commons.wikimedia.beta.wmflabs.org/w/index.php?title=Special:Upload&wpDestFile=VisualEditor_save_dialog-en.png&wpForReUpload=1

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

**Attached**: {F14238}
Resolving per:

>>! In T70760#719880, @bd808 wrote:
> Beta uses the NFS shared directory /data/project/upload7 to store images. 
> 
> I just did a permissions check on this directory for sub-directories that are not world writable and found a bunch. This is a likely cause of at least some of the failures.

Swift is: {T64835}
Beta uses the NFS shared directory /data/project/upload7 to store images. 

I just did a permissions check on this directory for sub-directories that are not world writable and found a bunch. This is a likely cause of at least some of the failures.

To check: 

  $ cd /data/project/upload7
  $ find . -type d ! -perm -o=w
    ... lots of dirs output here ...

To fix:

  $ cd /data/project/upload7
  $ sudo find . -type d ! -perm -o=w -exec chmod 0777 {} +

A hack fix would be to cron this fix somewhere in beta. A better fix would be to kill NFS and use swift for image storage.
cc'ing ori/bryan in case this was an effect of hhvm permission weirdness.
Looks like the images which were uploaded before(i.e. before we got the some problems with beta labs recently) have this problem. I tried updating the image which was uploaded yesterday and it works fine.
(In reply to Chris McMahon from comment #2)
> Let me know your user names and I can upgrade your privileges on beta labs.

LanguageScreenshotBot
(In reply to Chris McMahon from comment #2)
> Let me know your user names and I can upgrade your privileges on beta labs.

"Greg (WMF)"
Let me know your user names and I can upgrade your privileges on beta labs.
Showing my ignorance: Do you have the right permissions? I apparently don't as I see "You cannot overwrite this file." on that and other images on the beta cluster commons.
Screenshot

See screenshot, from "Barack Obama" on enwiki beta. I assume it's meant to be an entire orange circle...

This was seen in Firefox 30.

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

**Attached**: {F14125}
Fixed and deployed to wmf15 an hour ago. Sorry!
From User:Encyclopedant:

The Save dialog should have a link to open a new window to a bug report form. This is a good time to start a bug report because you have what you need at hand to write clearly about the bug.

There is no link to report a bug. There is a "leave feedback" item under the ? help link in the editor toolbar, but that's kind of hidden, and it doesn't take you to a real bug report form.

There should be a link to open a new window to a bug report form. The link should be explicit that you won't lose what you're doing and that the bug report form will open in a new window.

--------------------------
**Version**: unspecified
**Severity**: enhancement
We (now?) have a nice link in the help menu which leaves a comment on the local wiki's VE comments page.
My second solution, then. Since that template doesn't probably exist elsewhere, my guess is we could copy it onto mediawiki and centralize that kind of feedback there.
I'd assumed that such a link would be the same as the existing feedback link and go to the on-wiki feedback pages (either local or at mediawiki.org).
We can't link them to Bugzilla (or Phabricator) without:

* a detailed note about the different privacy policy there,
* and that their bug reports must be written in English,
* then the system would need to prompt them to create an account,
* (which is not part of SUL-authorisation on Bugzilla),
* then redirect back to opening a bug,

… almost all of which will be written by someone unfamiliar with bug reporting, so they will likely waste a huge amount of time for everyone in re-writing or just closing.

I'm minded to say WONTFIX…
IMHO, currently that would be https://bugzilla.wikimedia.org/enter_bug.cgi?product=VisualEditor&component=General&format=guided . (That would probably need to point to the system which replaces Bugzilla at some point.)
At en.wp there's also this link to report bugs through a template right on the feedback page https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&action=edit&section=new&watchthis=1&preload=Template:VE_Bug2/bug_template , but I think the first solution would be more desirable, especially since the future bug report system should be more user-friendly than the current one.
What is a "real bug report form"?
The version number in the help panel must be bidi-isolated so it won't mess up the date in RTL wikis.

--------------------------
**Version**: unspecified
**Severity**: normal
Now it is. :-)
Change 149656 merged by jenkins-bot:
Bidi-isolate the version in the help panel

https://gerrit.wikimedia.org/r/149656
It's not merged yet.
Thanks!
Change 149656 had a related patch set uploaded by Amire80:
Bidi-isolate the version in the help panel

https://gerrit.wikimedia.org/r/149656
1. Select a link fully
2. Type one letter
3. Press undo

Observer the first letter of the link is no longer linked.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 149633 merged by jenkins-bot:
Copy annotation indexes before returning

https://gerrit.wikimedia.org/r/149633
The cause here is that the removal data in the transaction gets modified by annotationSet.removeAt(). Now the recorded removal data doesn't match the actual data that was there. If you created that link in this session then you also have have a sequence of transactions that don't connect.
Change 149633 had a related patch set uploaded by Esanders:
Copy annotation indexes before returning

https://gerrit.wikimedia.org/r/149633
Something wrong with the browsertests role, got after http://paste.debian.net/111811/

Notice: /Stage[main]/Role::Browsertests/File[/srv/browsertests/config]/ensure: created
Notice: /Stage[main]/Role::Browsertests/File[/srv/browsertests/config/secret.yml]/ensure: defined content as '{md5}b0aa09943ae3b5df22215876b3573a05'
Error: Working directory '/srv/browsertests/tests/browser' does not exist
Error: /Stage[main]/Role::Browsertests/Browsertests::Bundle[/srv/browsertests/tests/browser]/Ruby::Bundle[/srv/browsertests/tests/browser]/Exec[bundle_install_/srv/browsertests/tests/browser]/returns: change from notrun to 0 failed: Working directory '/srv/browsertests/tests/browser' does not exist

[...]

Notice: /Stage[main]/Browsertests/Mediawiki::User[Selenium_user]/Exec[mediawiki_user_Selenium_user]/returns: include_once "$IP/extensions/WikimediaIncubator/WikimediaIncubator.php";Account exists. Perhaps you want the --force option?
Error: php5 createAndPromote.php Selenium_user vagrant returned 1 instead of one of [0]
Error: /Stage[main]/Browsertests/Mediawiki::User[Selenium_user]/Exec[mediawiki_user_Selenium_user]/returns: change from notrun to 0 failed: php5 createAndPromote.php Selenium_user vagrant returned 1 instead of one of [0]

--------------------------
**Version**: unspecified
**Severity**: normal
Change 149921 merged by jenkins-bot:
Removed browsertests role

https://gerrit.wikimedia.org/r/149921
Change 149921 had a related patch set uploaded by Dduvall:
Removed browsertests role

https://gerrit.wikimedia.org/r/149921
Someone asked about removing the role on IRC about a week back. However, it doesn't look like that ever happened.
The qa/browsertests repository has been emptied of content -- https://github.com/wikimedia/qa-browsertests. I thought there was a bug to remove the browsertests role altogether, but I'm not finding it at the moment.

The ::mediawiki::extension define now supports a `browser_tests => true` setting to setup browser test support for an individual extension. I know the visualeditor role has been updated to use this setting, but there may be other extensions that need to be updated.
At the next puppet run only the first is left:

Notice: /Stage[main]/Apt/Exec[update_package_index]/returns: executed successfully
Error: Working directory '/srv/browsertests/tests/browser' does not exist
Error: /Stage[main]/Role::Browsertests/Browsertests::Bundle[/srv/browsertests/tests/browser]/Ruby::Bundle[/srv/browsertests/tests/browser]/Exec[bundle_install_/srv/browsertests/tests/browser]/returns: change from notrun to 0 failed: Working directory '/srv/browsertests/tests/browser' does not exist
Notice: Finished catalog run in 282.18 seconds
Steps:

1. Open http://en.wikipedia.beta.wmflabs.org/wiki/7thfeb?veaction=edit
2. Scroll to bottom
3. Select the gallery
4. Cursor right
5. Press a letter.

Expected outcome: Cursor ends up in slug after the gallery, with an 'a' in it; focus stays.

Actual outcome: Focus moves to the top of the document, then restores when 'a' is typed.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://en.wikipedia.beta.wmflabs.org/wiki/7thfeb?veaction=edit
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68708
Change 151400 merged by jenkins-bot:
Set selection before focusing document

https://gerrit.wikimedia.org/r/151400
Change 151400 had a related patch set uploaded by Esanders:
Set selection before focusing document

https://gerrit.wikimedia.org/r/151400
From other reports it sounds like this may be happening for all focusable nodes, not just galleries.
Steps to reproduce:

1.Open a page with Mobile VE in Android with Chrome browser
2.Type a text in CE
3.Select the text
4.Open the link inspector

Observed Result:
The link text is not appearing inside the link inspector in the link target field, it is just empty.

Enviornment:Betalabs, test2

--------------------------
**Version**: unspecified
**Severity**: normal
This issue is not reproducible anymore.
This is issue in not reproducible anymore.
Needs re-testing.
Steps to reproduce:

1.Open a page with VE which has 4 citations 
2.Open Cite>Re-use
3.Select the first reference to re-use
4.Now again open the use existing reference dialog and observe that the last reference that you added is selected
5.Try to add it in the article


Observed Result:

It does not get added, if you select some other reference and then try to add the previous one , it will work


Environment:Betalabs, test2

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68869
Verified the fix in production
Verified the fix in test2
*** Bug 69027 has been marked as a duplicate of this bug. ***
Change 150708 merged by jenkins-bot:
Unselect currently selected item in re-use citation dialog when reopening

https://gerrit.wikimedia.org/r/150708
Change 150708 had a related patch set uploaded by Alex Monk:
Unselect currently selected item in re-use citation dialog when reopening

https://gerrit.wikimedia.org/r/150708
Is this just because the reference is selected?
Sounds like an OptionWidget/SelectWidget thing? Clear the selection when reopening the dialog?
VisualEditor: in the saving dialog, the "Watch this page" box can move to the next line with very large spacing between the lines. This happens in languages where it's longer than it is in English.

Here's a screenshot of the problem (in Russian):

{F14387}

Possible solutions include:
* Putting these boxes on separate lines form the start.
* Making the line spacing smaller. This is a bit problematic, because the text of the second box may appear under the second, and this may be confusing.
Change 231300 merged by jenkins-bot:
Convert save checkboxes to OOUI widgets

[[https://gerrit.wikimedia.org/r/231300]]
After:
{F1471410}
Change 231300 had a related patch set uploaded (by Esanders):
Convert save checkboxes to OOUI widgets

[[https://gerrit.wikimedia.org/r/231300]]
https://fr.wikipedia.org/w/index.php?title=M%C3%A9thyl%C3%A8nedioxypyroval%C3%A9rone&curid=7265462&diff=105673189&oldid=102426146

If you change anything in the template, nowiki tags will be added into the IUPAC name field. Also happens for the same article in other languages where the name is written in the same way (i.e. English or Spanish).

--------------------------
**Version**: unspecified
**Severity**: normal
I'm unable to reproduce. I suppose this was fixed in the round of `nowiki` work last quarter. Please reopen if seen again.
Investigating…
Nominating as blocker since it's a pretty nasty issue. I'm not sure if it's still happening but we should make sure.
This is slightly aggressive <nowiki>ing by #Parsoid – looks to still be an issue. Is it a part of a wider task?
Isolated brackets (with no letter nearby) in a template parameter (compulsory) are over-protected by nowiki tags on any change in the template

see : https://test2.wikipedia.org/w/index.php?title=Drong-1&diff=101272&oldid=101271

Safari - MAC OS/X
Environment-test2

steps-

1> open a page in VE and open language inspector.
2> Click upon "English" in the inspector, to open the Language Selector dialog.
3> Now click on Language selector icon on top of the page, beside the username link (This extension is used for viewing pages in the language specified by the user's preferences).
4> Notice dialog saying "Select a Language" appears and the Language Inspector gets closed.But the Language Selector dialog(with two-letter code for languages) is still open.

--------------------------
**Version**: unspecified
**Severity**: minor
Hey Ritu, Can you specify the environment where you checked the fix?
Issue Resolved.
Change 149635 merged by jenkins-bot:
[BREAKING CHANGE] Fix ve.ui.Overlay classes

https://gerrit.wikimedia.org/r/149635
Change 149635 had a related patch set uploaded by Esanders:
Make the overlay used by the language dialog global

https://gerrit.wikimedia.org/r/149635
Those links at the top shouldn't be accessible when a dialog is open. The problem is that the language dialog is launched in a slightly different way to others because it is launched from an inspector, and isn't getting a 'global' overlay which would shield those links.
Steps to reproduce:

1.Open a page with VE
2.Place the cursor after a reference note
3.Press return

Observed Result:

Uncaught TypeError: Cannot read property 'context' of undefined appears and the cursor jumps to the beginning of the document

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Fixed by https://gerrit.wikimedia.org/r/#/c/148671/ , needs an oojs release.
I tried editing a page. I pressed Save and received a little "Something went wrong" window. I pressed "Dismiss". I wanted to try saving again, but the "Save page" button was disabled.

It should probably be re-enabled.

VE Version: 234e4e6, on mediawiki.org.

--------------------------
**Version**: unspecified
**Severity**: normal
I would mark this invalid until we could find out what error it would've been. But maybe we should make it clear in the UI when an error is unrecoverable (and have related patch(es) point to this bug).
<Krenair> James_F, also, to clarify about badtoken - I was talking about saveErrorNewUser
<Krenair> for invalid session
<Krenair> it appears VE gets a new token to check whether the user ID has changed, when a badtoken error is encountered
<RoanKattouw> Yeah we don't expose a badtoken error to the error handling code unless the API gave us a badtoken error twice
<RoanKattouw> In which case the server's session storage is probably broken
Badtoken errors are automatically recovered from, though…
Hmmmm, don't remember what it could be. Possibly badtoken.
ViewPageTarget#showSaveError allows errors to be recoverable or unrecoverable (defaulting to recoverable)

The following errors should be recoverable:
abusefilter
badtoken

The following errors are not:
empty
spamblacklist
unknown

Amir, what error did you run into?
I think we only show the error message for unrecoverable errors. Maybe we should prompt the user to give up rather than just exiting to an unusable save dialog?
screenshot_chrome1

In Chrome 36-
Scenario#1-
1> Open a page in VE and select Preformatted from text style menu.
2> enter some text at the beginning and hit the spacebar till the cursor reaches the end of the line. Further pressing the spacebar takes the cursor out of the </pre> tag. See screenshot_chrome1.

Scenario#2- tried the above steps, but with some characters at the end of the line and then inserting whitespace.See screenshot_chrome2. The cursor still  moves out.

In FF 31-
Tried the above steps without any characters at the end of the line and just inserting whitespaces. The cursor moves out.

In Safari- No issue found.

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

**Attached**: {F14120}
I think my recent change 71ceef7dbb6ba95c84987c5c7ffbfecada9257f2 made this saner. Now preformatted text never wraps; if you insert more spaces than fit in the screen, you can still cursor out of the grey-bordered area, but the general behavior is saner (no weird scrolling inside the surface and no weird collapsing of spaces).
Issue found in test2 too. 
Steps-

1> Open a page in VE and select Preformatted from text style menu.
2> enter some text at the beginning and select Language inspector.Don't click any buttons on the inspector.
3> Now click anywhere inside the preformatted.This closes the inspector dialog. 
4>Now hit the spacebar till the cursor reaches the end of the line. Further pressing the spacebar takes the cursor out of the </pre> tag. See screenshot_test2.
Created attachment 16033
screenshot_test2

**Attached**: {F14122}
Test Environment:Production
Created attachment 16015
screenshot_chrome2

**Attached**: {F14121}
After using VE to edit a subpage in a namespace with subpages enabled, and saving changes, the breadcrumb link (< ParentPageName) underneath the page title does not come back.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 149351 merged by jenkins-bot:
Don't overwrite #contentSub just to try to get the correct subtitle for redirects

https://gerrit.wikimedia.org/r/149351
Change 149351 had a related patch set uploaded by Alex Monk:
Don't overwrite #contentSub just to try to get the correct subtitle for redirects

https://gerrit.wikimedia.org/r/149351
<Krenair> So what's currently broken here is how we try to deal with the 'redirect page' text under the title
<Krenair> We just do $( '#contentSub' ).text( ve.msg( 'redirectpagesub' ) ); which will overwrite the subpage breadcrumb
<Krenair> Unfortunately, core doesn't wrap that redirect text in a way which we could single it out.

Gerrit change 148883 to fix MW core
**Author:** `misc2006`

**Description:**
The most obvious way to add a non-breaking space (other than typing it, see T53045) would be the Insert -> Special Characters dialog.

--------------------------
Alternative: {T53045}
Given that https://phabricator.wikimedia.org/T53045#1947804 happened, I guess that the special character option is still more difficult to implement than the other one, even if just as a temporary workaround?
Due to various implementation details this is more difficult than it looks (it's not just a matter of adding an entry to the list of available characters). If we implement {T53045}, I'm not sure if this one will be worth it.
We already have the ability to use different label on the button than the character that will be inserted (we use it for more meaningful labels for combining characters, and in fact for invisible ones like zero-width non-joiner and joiner). We should probably make the label say "NBSP" if we do this.
Or you could somehow annotate the whole word as nowrap. Arguably <nowrap>100 °C</nowrap> would be clearer than 100&nbsp;°C
A hopefully clearer rationale for this request, from User:Gnom:

//Our typography rules call for a non-breaking space when discussing units and abbreviations ("a marathon is run over a distance of 42.195 km" calls for `42.195&nbsp;km` ; "water boils at 100 °C" requires `100&nbsp;°C` ; "Mary Shelley created the character of Dr. Frankenstein" includes `Dr.&nbsp;Frankenstein` ). I frequently use it in every law-related article in relation to the "§" sign, an example for this would be the article on Mietvertrag (Deutschland). //

(Notice the several occurrences of the NBSP in https://de.wikipedia.org/wiki/Mietvertrag_(Deutschland).)
Adding 68425 or users will have no idea what it is.
**Author:** `misc2006`

**Description:**
There are at least two dash-like characters in the "Special character" dialog. They should have a tooltip describing them, otherwise it won't be obvious to most users which character is to be used in which situation. Actually, why not add a descriptive tooltip to all special characters?

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 205558 merged by jenkins-bot:
Allow special characters with tooltip or that encapsulate text

[[https://gerrit.wikimedia.org/r/205558]]
Change 205557 merged by jenkins-bot:
ve.ui.SpecialCharacterPage: Allow providing a tooltip for characters

[[https://gerrit.wikimedia.org/r/205557]]
Change 205558 had a related patch set uploaded (by Bartosz Dziewoński):
Allow special characters with tooltip or that encapsulate text

[[https://gerrit.wikimedia.org/r/205558]]
Change 205557 had a related patch set uploaded (by Bartosz Dziewoński):
ve.ui.SpecialCharacterPage: Allow providing a tooltip for characters

[[https://gerrit.wikimedia.org/r/205557]]
For VisualEditor-MediaWiki, we're now reusing the special characters list from the wikitext WikiEditor. It has over 2000 entries and I am positive there is no point in providing and translating a tooltip for every single one of them.

However, there are at least a few which could use a tooltip. That list has them for three similar-looking characters: − (minus sign), – (en dash) and — (em dash). We currently ignore these in VisualEditor, I'm fixing it.

{F131436}

For VisualEditor standalone, it would be reasonable to add labels for these three, too, but it's probably not be necessary, since we display the list in a clearer form (proportional fonts and shorter sections). I won't be doing this for now, someone else can decide.

{F131440}
**misc2006** wrote:

(In reply to Andre Klapper from comment #1)

> Assuming you refer to − and — : Don't use and situations highly depend on
> cultures (and languages) anyway?

I guess so (and that's probably why de.wikipedia has a different dialog than en.wikipedia), but still these characters have names that at least help explain their meaning and make it possible to tell them apart.

> Any citation for "won't be obvious to most users"?

I've fixed about 2000 typos in de.wikipedia in the last few months and typographical problems (although not limited to the dash characters) are very common.

> I doubt there is a usecase for explaining every single character (and making
> translators translate them). Which actual problem to solve?

It increases confidence in what you're doing if you can see that you are actually using the right character (instead of one that maybe just looks the same - this could easily happen with then tens of thousands of unicode characters available). For translation, either use the Unicode name without translation, or an official translation (that might be available or not).
(In reply to Daniel Naber from comment #0)
> There are at least two dash-like characters in the "Special character"
> dialog. They should have a tooltip describing them, otherwise it won't be
> obvious to most users which character is to be used in which situation.

Assuming you refer to − and — : Don't use and situations highly depend on cultures (and languages) anyway? Wondering if it would be possible to generally explain at all.  Any citation for "won't be obvious to most users"?

(In reply to Daniel Naber from comment #0)
> Actually, why not add a descriptive tooltip to all special characters?

I doubt there is a usecase for explaining every single character (and making translators translate them). Which actual problem to solve?
no Message for error

"Not logged in" message has no Message text, shows placeholder id, see screen shot.

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

**Attached**: {F14425}
Change 148573 merged by jenkins-bot:
Update messages list for oojs-ui

https://gerrit.wikimedia.org/r/148573
Change 148550 merged by jenkins-bot:
Update messages list for oojs-ui

https://gerrit.wikimedia.org/r/148550
Change 148573 had a related patch set uploaded by Jforrester:
Update messages list for oojs-ui

https://gerrit.wikimedia.org/r/148573
Change 148120 abandoned by Catrope:
Declare dependency on ooui-dialog-* messages as they're needed

Reason:
Done in MW core in https://gerrit.wikimedia.org/r/148550

https://gerrit.wikimedia.org/r/148120
Change 148550 had a related patch set uploaded by Catrope:
Update messages list for oojs-ui

https://gerrit.wikimedia.org/r/148550
Change 148120 had a related patch set uploaded by Jforrester:
Declare dependency on ooui-dialog-* messages as they're needed

https://gerrit.wikimedia.org/r/148120
Pasting more than one paragraph triggers a full document re-render. This is clearly seen in the standalone client where all the paragraphs flash grey on re-render.

On en:Cat in Firefox it takes ~2s.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 147987 merged by jenkins-bot:
Fix calculation of affectedRange in transaction processor

https://gerrit.wikimedia.org/r/147987
Change 147987 had a related patch set uploaded by Esanders:
Fix marking of affected range in transaction processor

https://gerrit.wikimedia.org/r/147987
All VE items appear fixed as of a while ago. Marking as such.
Let's turn this into a mini tracking bug, then? I split off the Parsoid issue to bug 68862, together with VE bug 68733, bug 68708 and bug 58038 this seems to describe all of the problems.
The pawn, snowman and offset exception bugs should be fixed by https://gerrit.wikimedia.org/r/149920 .

The scrolling all the way up is bug 68589.

The rendering weirdness due to the span-wrapped newline is probably unique to this bug.
(In reply to Bartosz Dziewoński from comment #0)
> * Place cursor before/after one of the templates.
> * Press 'Right'/'Left' keyboard key twice.
> ** First press selects the template, as expected.
> ** Second press scrolls the page all the way up.

So if you select a node that's floating right and is half way down the page, then press left or right, you scroll all the way to the top of the page (though the cursor is positioned correctly).

> ** Place cursor after the "space" and try typing. Weird things happen,
>    sometimes I get an exception "Uncaught Error: Unbalanced set of
>    replace operations found", sometimes my input is duplicated or I
>    get snowmen and pawns.

Yeah, I get that error and other weirdness (e.g. the cursor moving around - to before/after the template I think?) when typing normally, then snowmen+pawns when I try to undo/redo things. I've also been getting some extra errors: Uncaught Error: Unbalanced input passed to document 
At one point I got this error as well: Uncaught Error: Offset could not be translated to a DOM element and offset: 77
This is causing breakage in edits (that is not being detected by VE):
https://www.mediawiki.org/w/index.php?title=Manual:Skinning&diff=1074312&oldid=1072136
**Author:** `gabrasca2`

**Description:**
The text show/hide in the right of the navbox disappear after have edited a page where there is a navbox collapsed and the navbox appears uncollapsed, until the page is refreshed.

--------------------------
**Version**: unspecified
**Severity**: minor
Please reopen if you can still reproduce this issue.
(Quoting Alex Monk from comment #6)
> Gabrasca, could you link to the page showing this issue?
**gabrasca2** wrote:

the issue appens only after it is saved from VE, if I reload the page the show/hide text returns.
Gabrasca, please respond.
Gabrasca, could you link to the page showing this issue?
**gabrasca2** wrote:

I tried on itwiki, in a personal sandbox with a navbox (example discography of a band).(In reply to Alex Monk from comment #4)
> Hm.. Doesn't seem to happen with MW's built-in collapsible functionality.
> And obviously enwiki's navbox (and related JS gadgets) is not a MediaWiki
> feature, so this bug is probably invalid.
Hm.. Doesn't seem to happen with MW's built-in collapsible functionality. And obviously enwiki's navbox (and related JS gadgets) is not a MediaWiki feature, so this bug is probably invalid.
**gabrasca2** wrote:

Edit a page with VisualEditor, add a template written with navbox, save, the template added is uncollapsed and in the right corner of the template there is not the text show/hide.
Gabrasca: Could you clarify what you mean please? Some of the language in this bug is unclear. It sounds as if some of this might be valid for MW core's collapsible elements.
There's a hook or something to call to get these to re-activate; it's already used in VPT for sortable tables or another common gadget, I believe.
Steps to reproduce:

1.Open a page with Mobile Ve in android with Chrome browser
2.Select a text such as "Text"
3.Click on link inspector tool

Observed Result:
Observe that in the link inspector, the "text" is appearing as "ext"
Needs re-testing.
Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Go to the Advanced Settings and change the image size
4.Click on Apply changes
5.Reopen the Advanced Settings panel for that image again


Observed Result:
Observe that, the size values of the image are still showing the previous ones , though the image actually got resized
If I save the page and reopen it and then check the Advanced Settings dialog , I see the updated values then.

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in test2
Change 147219 merged by jenkins-bot:
Make the image model work without a node

https://gerrit.wikimedia.org/r/147219
Change 147219 had a related patch set uploaded by Mooeypoo:
Make the image model work without a node

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

Steps to reproduce:


1.Open a page with VE
2.Go to Cite>Basic
3.Click on "Use an existing reference" button
4.Now resize down the window 

Observed Result:
The "Use Existing Reference" dialog suddenly gets squished in and if I drag the window to its original size it stays like that.
Now if you click on "Go Back" button the basic reference dialog also appears that way

See the screenshot attached

Browser: Chrome and Firefox

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

**Attached**: {F14226}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Fixed now. :-)
Change 148577 merged by jenkins-bot:
Clamp height of MWReferenceDialog to between 300 and 400px to avoid it being too small

https://gerrit.wikimedia.org/r/148577
Change 148577 had a related patch set uploaded by Jforrester:
Clamp height of MWReferenceDialog to between 300 and 400px to avoid it being too small

https://gerrit.wikimedia.org/r/148577
Created attachment 16010
Screenshot

**Attached**: {F14227}
Still happening but in a slightly different way.Also,there are now two ways of opening use existing reference dialog , but the initial size of the dialog upon opening is not same for both cases.

See the screenshot attached
Change 147710 merged by jenkins-bot:
Fix heights of Reference, ReferenceList and Template dialogs

https://gerrit.wikimedia.org/r/147710
Change 147710 had a related patch set uploaded by Jforrester:
Fix heights of Reference, ReferenceList and Template dialogs

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

The references list dialog is appearing a bit smaller in Firefox which also makes the text field for group name overlap with the border of the dialog.

See the screenshot attached

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

**Attached**: {F14204}
Verified the fix in production
Verified the fix in production
Verified the fix in test2
Change 148903 merged by jenkins-bot:
Bump the height of the references list a little

https://gerrit.wikimedia.org/r/148903
Change 148903 had a related patch set uploaded by Jforrester:
Bump the height of the references list a little

https://gerrit.wikimedia.org/r/148903
Created attachment 16027
Screenshot

This is still looking like this

**Attached**: {F14205}
Change 147710 merged by jenkins-bot:
Fix heights of Reference, ReferenceList and Template dialogs

https://gerrit.wikimedia.org/r/147710
Change 147710 had a related patch set uploaded by Jforrester:
Fix heights of Reference, ReferenceList and Template dialogs

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


1.Open a page with mobile VE
2.Select the option "USe existing reference" from Cite menu options
3.Click on the "Go Back" button on use existing reference
4.It takes you to the basic reference dialog


Issue 1: Type something in the dialog pawn appears
Issue 2: Click on "Insert Reference" nothing happens

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in test2
This issue got resolved with replacing "Go Back" button with "Cancel" button in Use Existing Reference dialog
Change 144058 merged by jenkins-bot:
Put "re-use reference" in the toolbar "Cite" menu, and give it an icon

https://gerrit.wikimedia.org/r/144058
Change 144058 had a related patch set uploaded by Jforrester:
Put "re-use reference" in the toolbar "Cite" menu, and give it an icon

https://gerrit.wikimedia.org/r/144058
Created attachment 15969
Screenshot

Issue 3: It also lets you add a template and get stuck there.

**Attached**: {F14153}
Screenshot

Steps to reproduce:

1.Select any node such as reference in mobile VE using iOS or desktop safari

2.Now open the cite menu option from the toolbar

Observed Result:
Observe that, the highlight of the reference node is appearing over the cite menu option.

See the screenshot attached

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

**Attached**: {F14137}
Verified the fix in production
Verified the fix in test2
To check…
Screenshot

Steps to reproduce:

1.Open a page with Mobile VE
2.Place the cursor in the CE
3.Open Link inspector and insert a link
4.Click on the link inspector icon again.

Observed Result:
The inspector appears a bit zoomed , which makes the title "Link" and the button "Done" on the top overlapped with the browser tabs

See the screenshot attached

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

**Attached**: {F14134}
Verified the fix in production
Verified the fix in test2
Cannot reproduce it anymore, might got fixed with windows refactor.
Created attachment 15966
cursor position

**Attached**: {F14136}
Created attachment 15965
link suggestions

Also see the other screenshots on how the cursor and the link suggestions appear when user tries to enter a link target when it appears like that.

**Attached**: {F14135}
Screenshot

See the screenshot attached
The "Remove" button in the link inspector is not styled as Red

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

**Attached**: {F14123}
Verified the fix in production
Verified the fix in test2
I've set up a new labs project for ExtensionDistributor to serve tarballs instead of using github. Example tarball: http://extdist.wmflabs.org/?version=REL1_23&ext=VisualEditor

This will provide better privacy for users, and also fix a few bugs like submodule support (bug 44022).

Yuvi is helping puppetize the setup.

I want to temporarily enable ExtensionDistributor on testwiki, point it labs, make sure there are no issues, and then turn it on on mediawiki.org.

--------------------------
**Version**: unspecified
**Severity**: normal
Should we track download counts for the tarballs? :)
Deployed, nothing looks broken! :D
This will go live tomorrow, when 1.24wmf16 hits mediawiki.org
Change 150589 merged by jenkins-bot:
Switch ExtensionDistributor to serve tarballs from extdist.wmflabs.org

https://gerrit.wikimedia.org/r/150589
Change 150589 had a related patch set uploaded by Legoktm:
Switch ExtensionDistributor to serve tarballs from extdist.wmflabs.org

https://gerrit.wikimedia.org/r/150589
New plan after talking with Chad: have ExtensionDistributor get a list of branches from Gerrit's API (I5c4ca2ee13f256260a7fe9b703af5fbdb902db66), and just assume that the tarballs exist on extdist.wmflabs.org. This way prod will never have to talk to labs.

> Yuvi is helping puppetize the setup.

I63d285612bd30d24b83718c4c8967144d146afeb 

> I want to temporarily enable ExtensionDistributor on testwiki, point it
> labs, make sure there are no issues, and then turn it on on mediawiki.org.

My half-re-write of the extension makes it so this really isn't possible :/
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Edit the page
3.Now click on the "Edit Source" tab
4.Click on the option "Discard Changes"

Observed Result:
It redirects to the edit source mode of the main page .

See the screenshot attached.

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

**Attached**: {F14497}
Verified the fix in production en.wiki
https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap is a useful reference for Wikimedia deployments
(In reply to Alex Monk from comment #7)
> Are you sure that wiki is running a version of VisualEditor with the fix for
> this bug? I'm pretty sure Wikipedia is supposed to get this change is on
> Thursday...

I see. I thought it was already deployed to all wikis. Sorry.
Are you sure that wiki is running a version of VisualEditor with the fix for this bug? I'm pretty sure Wikipedia is supposed to get this change is on Thursday...
It still redirects to the main page, if you choose some version from the history page and then do the same.

1) https://en.wikipedia.org/w/index.php?title=Test&oldid=614834396
2) click edit
3) (make some changes to the page)
4) switch to source editing
5) discard changes
and you're again editing the main page
Verified the fix in test2
Change 146956 merged by jenkins-bot:
Set title of page to use if discarding changes when changing to the wikitext editor

https://gerrit.wikimedia.org/r/146956
Change 146956 had a related patch set uploaded by Alex Monk:
Set title of page to use if discarding changes when changing to the wikitext editor

https://gerrit.wikimedia.org/r/146956
This is a fun one. Are we passing '' to the API instead of the page name?
It happens also if I switch to Edit Source mode from the Switch to Source Editing option.
Script error for each citation

Test Environment-test2
Steps to Reproduce-

Scenario#1-
1> Select the ” Cite “ drop down and add a Journal, News, Book,  one of each citations.
2> Now click on “Insert” and select “Media”. Click on any picture returned in the dialog(do not enter any search term)
3> In the Media Settings dialog click on “Insert” again and select “Media” from the Caption toolbar. Click on any picture returned in the dialog.
4> Now close all the dialogs. 
5> Repeat again steps #2,3 and 4.
6>In the main VE window  click on “Cite”  and select “Basic”. Reference dialog opens.
5> In the Reference dialog select “Use an existing reference”.
6> Script Error is shown as existing reference.

Scenario#2-
1> Go to the Media Settings dialog. 
2> While General Settings is highlighted, select the ” Cite “ drop down and add a Journal, News, Book,  one of each citations to the Caption pane.
3> Now click on “Insert “dropdown and select “Media”.
4>Click on any picture in the media search dialog. Media Settings dialog pops. Close this dialog.
5> Repeat steps 3 and 4 again.
5> Notice that the previously opened Media Settings dialog is still open with the citations in the Caption pane.
6> Click on “Cite” again and select “Basic”. Reference dialog opens.
7> In the Reference dialog select “Use an existing reference”.
8> Script Error is shown as existing reference.

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

**Attached**: {F14429}
okay, so there is no need to have a new bug on it I guess.
Probably an effect of whatever caused this?
The delay to load citations in RE-Use dialog is pretty noticeable now.Previously,it was not like that.Is it an effect of this fix?
Issue Resolved in test2.
This looks like it's now fixed.

(Note that the "re-use" list can take a few seconds to update, so if you've just created a cite it may render as "[4]" rather than "[4] Foo. Bar (Baz)" which will happen later if you wait.

Thanks, Krenair!
(In reply to Rummana Yasmeen from comment #2)
> However there is one issue here, when you first time add any reference, and
> open use existing reference dialog, the reference name will not appear but
> after that if you do any other action like adding a media, or a link or a
> reflist it appears.

That sounds like bug 67342. Is this valid?
This bugs is found in test2 so the reason why it is showing script error for the Cite News,Cite Journal,Cite Book but not Cite Web, the template data for those options are not defined in test2.
So if you just add those Cite Options and add a reflist , you will also see script errors in the reference list.


However there is one issue here, when you first time add any reference, and open use existing reference dialog, the reference name will not appear but after that if you do any other action like adding a media, or a link or a reflist it appears.
(In reply to Ritu Swain from comment #0)
> Created attachment 15949 [details]
> Script error for each citation
> 
> Test Environment-test2
> Steps to Reproduce-
> 
> Scenario#1-
> 1> Select the ” Cite “ drop down and add a Journal, News, Book,  one of each
> citations.
> 2> Now click on “Insert” and select “Media”. Click on any picture returned
> in the dialog(do not enter any search term)
> 3> In the Media Settings dialog click on “Insert” again and select “Media”
> from the Caption toolbar. Click on any picture returned in the dialog.
> 4> Now close all the dialogs. 
> 5> Repeat again steps #2,3 and 4.
> 6>In the main VE window  click on “Cite”  and select “Basic”. Reference
> dialog opens.
> 5> In the Reference dialog select “Use an existing reference”.
> 6> Script Error is shown as existing reference.

The problem here is the "re-use existing reference" code seems to rely on there being a reference list on the page (or there having been one at some point in this edit?) – if there's no reference list yet, it shows the references as blank or with a Lua script error. Is this something as simple as populating the internal list as needed?

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

1.Open the media settings dialog for an image
2.Edit something in the caption field to enable the "Apply Changes" button
3.Undo the edit from the toolbar

Observed Result:
The "Apply Changes" button still remains enabled

--------------------------
**Version**: unspecified
**Severity**: minor
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 152790 merged by jenkins-bot:
Check for changes in the model

https://gerrit.wikimedia.org/r/152790
Change 152790 had a related patch set uploaded by Mooeypoo:
[wip] Check for changes in the model

https://gerrit.wikimedia.org/r/152790
Change 150478 abandoned by Mooeypoo:
Check for changes in media dialog

Reason:
Redone in a different commit

https://gerrit.wikimedia.org/r/150478
Change 150478 had a related patch set uploaded by Mooeypoo:
Check for changes in media dialog

https://gerrit.wikimedia.org/r/150478
For repositories that we're (also) mirroring at a custom name, they are currently being mirrored twice.

For example:

* https://github.com/wikimedia/VisualEditor
  https://github.com/wikimedia/VisualEditor-VisualEditor


* https://github.com/wikimedia/oojs
  https://github.com/wikimedia/oojs-core

* https://github.com/wikimedia/puppet-kafka
  https://github.com/wikimedia/operations-puppet-kafka

This is confusing and also decentralises things like Watching and Fork tracking. But, more importantly, it also makes our Star rating and Pull requests harder to maintain.


I don't know whether we intentionally do both, or whether it was just easier to implement this way.

I'd recommend we get rid of the full names where we want to publish the repo under a different name.

If it was a conscious choice to do this I'm curious why. The only reason I can think of is to make them easier to find on GitHub, which is hardly a big issue since they have excellent search for repo names right on https://github.com/wikimedia.

Another reason might be being able to automatically generate a GitHub address for a Git repo, but I'm not sure that's a big issue.

Also note that GitHub supports renaming of repositories and automatically keeps redirects[1]. So we can remove the "unwanted" names from Gerrit replication config and have our github.com/wikimedia admins delete the repos and create a redirect (by renaming the good one to the bad one and then renaming it back).

As an example I've created a redirect from https://github.com/wikimedia/mediawiki to https://github.com/wikimedia/mediawiki-core. Eventually this should be done the other way around but this was easier to set up since Gerrit replag currently did not push to /mediawiki yet (unlike oojs and VisualEditor).


[1] https://github.com/blog/1508-repository-redirects-are-here
[2] https://help.github.com/articles/renaming-a-repository

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
Fwiw, we renamed the parsoid repository to https://github.com/wikimedia/parsoid with no ill effects. Even the travis tests kept working.
Change 167162 merged by Dzahn:
gerrit: Remove duplicate mirrors

https://gerrit.wikimedia.org/r/167162
Change 167162 had a related patch set uploaded by Krinkle:
gerrit: Remove duplicate mirrors

https://gerrit.wikimedia.org/r/167162
The redirects GitHub has in place apply both to the HTTP protocol (web interface) as well as the Git interface itself. We can simply remove the duplicate "pretty name" replications and perform the renames on GitHub. That way there's only one repo Gerrit is pushing two and both urls work.

I've gone ahead and done this with mediawiki-core as example.

From Gerrit's perspective it's a straight up replication from gerrit:mediawiki/core to github:mediawiki-core. There is no fancy-name duplicate set up for it.

On GitHub it has been renamed from mediawiki-core with a full redirect in place. Gerrit is now effectively pushing to https://github.com/wikimedia/mediawiki while all urls and logs for mediawiki-core continue to work as expected.
> If it was a conscious choice to do this I'm curious why.

We want all gerrit repos replicated on github.

We could setup replication for each repository in our gerrit
separately. That would allow full control of repository names at
github. But it is tedious, time-consuming, and has other warts too.

So in order to escape such a messy, verbose replication setup, gerrit
replicates each and every projects to github under the name that gets
used on gerrit [1]. For this replication, we do not prune leading
paths, as that would map different names on gerrit to the same names
on github [2].

However, some people felt strongly that they needed a better
repository name on github, or had a following on github that they
would not want to loose. So they had an additional, separate
replication target set up. And hence, those repositories get replicated
twice to github. Once for the canonical name. And a second time for
the custom name of their liking.

> Also note that GitHub supports renaming of repositories and
> automatically keeps redirects[...]

Thanks! That wasn't available when we added custom replication.
We could use that to solve most issues.

> As an example I've created a redirect from
> https://github.com/wikimedia/mediawiki to
> https://github.com/wikimedia/mediawiki-core. Eventually this should be
> done the other way around [...]

Not too sure about this one.
Doing it “the other way around” would make it even more confusing for
people, because the “canonical” github name would differ from the
gerrit name too much to be able to map it clearly.



[1] github does not like “/”s in repo names, so we're having them
    replaced by “-”s.

[2] For example we currently have three repositories in gerrit that
    end in “/data”.
    Or which of “analytics/kraken” and “analytics/vagrant/kraken”
    should become github's “kraken”?
    Same problems for “/Nostalgia”.
Screenshot

Open a language inspector, a scroll bar is appearing inside the inspector

See the screenshot attached

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

**Attached**: {F14372}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Tap, or tap and hold on text input field in tablet VE, expected behavior, native iOS copy/paste flag should be shown, but it us not.

--------------------------
**Version**: unspecified
**Severity**: normal
Seems to work for me now. Tested on Beta Cluster using iOS Safari 8.0 on an iPad.
Needs re-testing.
Steps to reproduce:

1.Insert an image in a page
2.Change the size of the image by going to Custom tab
3.Click on "Apply Changes"
4.Now again open the media settings dialog and switch to default tab


Observed Result:
Previously as soon as user switched to default tab, it used to set the text fields to default size, but now its keeping the custom size values.

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 158395 merged by jenkins-bot:
Set default dimensions based on original dimensions

https://gerrit.wikimedia.org/r/158395
Change 158395 had a related patch set uploaded by Mooeypoo:
Set default dimensions based on original dimensions

https://gerrit.wikimedia.org/r/158395
Still reproducible...
Change 149217 merged by jenkins-bot:
Make the image model persistent

https://gerrit.wikimedia.org/r/149217
Change 149217 had a related patch set uploaded by Mooeypoo:
Make the image model persistent

https://gerrit.wikimedia.org/r/149217
This is again happening in production for this image:https://en.wikipedia.org/wiki/File:Black_sandbox.JPG

Go to this page: https://en.wikipedia.org/w/index.php?title=User:RYasmeen_(WMF)/sandbox&oldid=619869934

Go to the Media settings>Advanced Settings for this image.Switch to default tab.

Observe that, the size values are still showing 22x17 which should be 220x165 as soon as I switch to Default tab.
If you click on Apply Changes and reopen this dialog , still you will see its showing 22x17 instead of 220x165.
If you Save the page and then reopen the page and the media settings dialog only then you will see the size value got changed to 220x165
I cant reproduce it now , the problem was after changing the custom size value, when i was clicking on default tab , it was not changing the size values into default on the size value fields.But now it seems like doing that.
I can't manage to reproduce this in master or in beta labs.

When a new image is inserted, the default behavior is that it has 'default' size. If the user goes to the size widget and just clicks the 'custom' button, it will transform the existing (default) values to custom values (so, the values are the same as the default, but they are literally expressed).

So the values are the same because the user didn't change them, but the difference is whether the image is default or limited in size (despite the fact both sizes are functionally the same)

For instance, for the image "Chef's knife grip.jpg" in beta labs:

Clicking "Custom" size will result in this wikitext:

[[File:Chef's knife grip.jpg|thumb|200x200px]]

Clicking "Default" size will result in this wikitext:

[[File:Chef's knife grip.jpg|thumb]]

That's the expected result. Is something else happening? I can't reproduce a bug.
This is happening again (!) in Betalabs now
Verified the fix in test2
Change 147219 merged by jenkins-bot:
Make the image model work without a node

https://gerrit.wikimedia.org/r/147219
Change 147219 had a related patch set uploaded by Mooeypoo:
Make the image model work without a node

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

Steps to reproduce:

1.Open a page with VE
2.Add some categories
3.Click on the newly added category to bring up the context menu for the category

Observed Result:

The context menu for the newly added category is appearing as blank with no option to specify "sort this page as if it is called" field value.

See the screeshot attached

Environment:Betalabs

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

**Attached**: {F14597}
Verified the fix in production en.wiki
Verified the fix in test2
BetaLabs gremlin. Blargh.
Works for me without debug=true...
Goes away when debug=true is called – maybe a deployment/BetaLabs gremlin issue?
[[https://en.wikipedia.org/wiki/Wikipedia:Media_Viewer/June_2014_RfC|Wikipedia:Media Viewer/June 2014 RfC]]

The consensus on the English Wikipedia is to disable Media Viewer by default.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**URL**: https://en.wikipedia.org/wiki/Wikipedia:Media_Viewer/June_2014_RfC
**See Also**:
* {T71080}
* {T71292}
(In reply to WhatamIdoing from comment #2)
> Changing default user preferences means overriding the choices of registered
> editors who actually want the feature (including thousands of editors who
> voluntarily opted-in before MediaViewer was made avaialble by default).  
> 
> It's too bad that MediaWiki doesn't have a good one-click system for
> changing prefs, like a "Click here to enable X" button or pop-up.  It'd be
> so much easier than telling hundreds of users "Go to Special:Preferences,
> click to this tab, scroll halfway down, find this item, tick the box, scroll
> all the way down, save the page."

That's an interesting idea and I've filed it as bug 67846.
(In reply to Brent Laabs from comment #10)
> MV tells users that they have to attribute CC0 and PD images (they don't).

This is https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/736

> I wanted to see the message that was in the public domain attribution message, 
> so I clicked in the message field, and pressed the right arrow to see the end 
> of the selection -- oops!  Next image.

We try to make copying the message very easy, which means the text gets focused and preselected automatically from time to time (e.g. when switching tabs). If it would capture keystrokes on top of that, that would result in a very confusing behavior (prev/next would basically stop working when you open the panel).

Opened bug 67835 about the underlying issue though, which is that it should be possible to just read these texts without copying them.
(In reply to Erik Moeller from comment #9)
> even if you are still unhappy with the result.

Erik, my level of satisfaction is irrelevant. As I expressed in the Commons RfC, "I Don't Like It"-style votes are not valuable, and should not be counted in evaluating consensus.

https://commons.wikimedia.org/w/index.php?title=Commons:Requests_for_comment/Media_Viewer_software_feature&diff=128325247&oldid=128324966

It seems that you and the Multimedia Team, though, don't take the same view on the other side. You seem to attach great importance to the fact that you reached out to some Wikipedians, and they responded "I Like It."

The "NOTCONSENT" policy cited makes it clear that WMF must act on its own discretion on legal matters, and I have no quarrel with that. Certainly there are cases where consensus has no place. But this is not one of them. On matters that involve sophisticated judgment -- is it your position that WMF is capable of evaluating what constitutes good judgment, and local communities are not?

It seems that you are quick to cite your community engagement practices when doing so serves your objective of deploying the software, but quick to dismiss community input that do not support that objective.
**bslaabs** wrote:

I have to admit that I didn't like MediaViewer at first, but I read Erik's comments, and decided to give it another try.  And it's definitely improving.  It's now at the quality level of an early beta release, rather than the alpha release level it was at when it was first implemented.

The fullscreen button was surprising at first, but I can see the use of it.  But after that, it only took me 2 minutes to find two bugs. MV tells users that they have to attribute CC0 and PD images (they don't).  I wanted to see the message that was in the public domain attribution message, so I clicked in the message field, and pressed the right arrow to see the end of the selection -- oops!  Next image.

I'm not a person with highly established workflows -- my contributions to English Wikipedia are around one edit per month, and I use other wiki software.  Media Viewer is just confusing, and feels incomplete.  It's not my workflow breaking, it's a new feature's interface being confusing.

I'm really disappointed that the WMF seems to want to force this on the community, when it's so clearly a product still in need of development.  And I'm more disappointed that the only response to the community has been based on Silent Majority arguments and a disdain for experienced members of the community.

If this bug is marked WONTFIX, where can I file a bug about the WMF?
Pete: Not at all. We've paid close attention to the requests by readers and editors throughout the development process. In fact, there are aspects of Media Viewer (like the prominent Commons links) which I believe can be directly traced to your own early feedback, even if you are still unhappy with the result. 

Recent significant changes include an off switch for readers, and an easy click-through link to the full resolution version. I think you will also appreciate the attribution hints recently added to the download tab (see here: https://www.mediawiki.org/wiki/Lightbox_demo#mediaviewer/File:Swallow_flying_drinking.jpg ). Some of these changes were made _while_ the RFC took place.

We'll continue to improve Media Viewer, but we'll also focus more attention in coming weeks on the upload process and on structured data support in partnership with Wikidata (the latter should help ensure that we can more consistently pull useful metadata into applications like Media Viewer, and potentially add some basic edit functionality to the overlay as well).
(In reply to Erik Moeller from comment #7)

Erik, the RfC is full of critiques of the methodology that led the WMF team responsible for this feature to the conclusion that it serves the reader better. Through this action you seem to be saying that the WMF team is correct by virtue of its being the WMF team, and the English Wikipedia community is wrong by virtue of its being the English Wikipedia community.
Steinsplitter:

It's longstanding WMF policy and practice to apply judgment to community RFCs and requests regarding software and configuration changes on a case-by-case basis, depending on the nature of the requested change, the level of participation, the impact on readers/editors, etc. See: https://meta.wikimedia.org/wiki/Limits_to_configuration_changes

In this case, we will keep the feature enabled by default (it's easy to turn off, both for readers and editors), but we'll continue to improve it based on community feedback (as has already happened in the last few weeks).
@Erik Moeller:
Why the Wikimedia Fondation as content provider overwrites community consensus?
Is this only a "i don't like to follow communety consensus" WONTFIX or a Office Action?

Per shellpolicy there is enough consensus to merge this change.
(In reply to WhatamIdoing from comment #2)
> It's too bad that MediaWiki doesn't have a good one-click system for
> changing prefs, like a "Click here to enable X" button or pop-up.  It'd be
> so much easier than telling hundreds of users "Go to Special:Preferences,
> click to this tab, scroll halfway down, find this item, tick the box, scroll
> all the way down, save the page."

MediaViewer does provide that functionality, actually (it's at the bottom of the metadata panel).
Closing WONTFIX per previously provided explanation:
https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Media_Viewer/June_2014_RfC&diff=prev&oldid=616407785
I see no reason in honoring this request. MediaViewer only displays media in a different way, *and* it can be disabled in your preferences. This is normal software evolution.

It is nothing like VisualEditor, which was disruptive for all editors. This is not, and editor consensus cannot dicatate how all *readers* should experience the use of media.
Changing default user preferences means overriding the choices of registered editors who actually want the feature (including thousands of editors who voluntarily opted-in before MediaViewer was made avaialble by default).  

It's too bad that MediaWiki doesn't have a good one-click system for changing prefs, like a "Click here to enable X" button or pop-up.  It'd be so much easier than telling hundreds of users "Go to Special:Preferences, click to this tab, scroll halfway down, find this item, tick the box, scroll all the way down, save the page."
Just need to set the default user option to 'false' really.
Steps to reproduce:

1.Open a page with VE which has a reference note in it
2.Now place your cursor after the reference note
3.Press backspace to select the reference note
4.Now press down key to go to the next line

Observed Result:
The cursor does not go to the next line and an error appears in the console:

Uncaught NotFoundError: Failed to execute 'selectNode' on 'Range': The node provided is null. 

Environment:Betalabs

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production en.wiki
Verified the fix in test2
Verified the fix in Betalabs
Change 146472 merged by jenkins-bot:
Don't handle up/down on focusableNodes even if backwards

https://gerrit.wikimedia.org/r/146472
Change 146472 had a related patch set uploaded by Esanders:
Don't handle up/down on focusableNodes even if backwards

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

1.Open a page with VE
2.Go to Insert>Media
3.Enter a search term
4.Select the first image that appears on the search result
4.Click on Change image immediately
5.Enter a different search term
6.Now try to select the first image on of the new search results 


Observed Result:
It throws an error:Uncaught TypeError: Cannot read property 'context' of undefined 

and cannot select that image

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in test2
Yeah, deeming this FIXED.
When I tried to reproduce this bug (before the merge of the above fix), I kept getting this error in chrome:

Uncaught TypeError: undefined is not a function commons.wikimedia.org/w/api.php?callback=jQuery1111024360889615491033_14067…set=0&prop=imageinfo&iiprop=dimensions%7Curl%7Cmediatype&iiurlheight=150:1

And this in in firefox

TypeError: jQuery111109862733512069084_1406742881657 is not a function
	
/**/jQuery111109862733512069084_1406742881657({"warnings":{"main":{"*":"Unrecogn...

And only after that I get an 'uncaught type error' that seems to be related to missing details in the image (like the caption document). It only happens right after the first API bug. I wasn't able to reproduce it after the 150054 fix was introduced. 

The API response just before the bug appears seems to suggest that the information from the API is maybe mismatch to the loaded image, which is why I thought it was related. 

The bug doesn't happen with this fix anymore (I can't reproduce it in master or in beta labs now that it's merged)
(In reply to Moriel Schottlender from comment #1)
> This seems to be the same jQuery/API issue we've had with calling the mw API
> consecutively. When the API is queried more than once the callback function
> goes haywire.
> 
> In debug mode when clicking the 'change image' (#4 in the above reproduce
> list), the console error is
> 
> "Uncaught TypeError: undefined is not a function" 
> api.
> php?callback=jQuery111109575085956603289_1404944903047&format=json&uselang=en
> &action=query&gene…:1

That undefined function error is not related in any way, that's bug 59604.
Change 150054 merged by jenkins-bot:
MWMediaSearchWidget: Use json/jsonp for local/foreign api respectively

https://gerrit.wikimedia.org/r/150054
Change 150054 had a related patch set uploaded by Mooeypoo:
MWMediaSearchWidget: Use json/jsonp for local/foreign api respectively

https://gerrit.wikimedia.org/r/150054
This seems to be the same jQuery/API issue we've had with calling the mw API consecutively. When the API is queried more than once the callback function goes haywire.

In debug mode when clicking the 'change image' (#4 in the above reproduce list), the console error is

"Uncaught TypeError: undefined is not a function" 
api.php?callback=jQuery111109575085956603289_1404944903047&format=json&uselang=en&action=query&gene…:1
Steps to reproduce:

1.Open a page with VE which has image inside it
2.Open the media settings dialog for the image
3.Edit the values for the image size
4.Without saving this change just close the Media Settings dialog
5.Reopen the media settings dialog again and check the image size values

Observed Result:
It shows the changed value even though you have not saved it.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=67684
Verified the fix in production en.wiki
Verified the fix in test2
Change 146513 merged by jenkins-bot:
Update VE core submodule to master (ad18102)

https://gerrit.wikimedia.org/r/146513
Change 146513 had a related patch set uploaded by Mooeypoo:
Work on a cloned scalable when editing images

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

1.Open a page with VE which has an image inside it
2.Open the advanced settings dialog for that image 
3.Type something in the Custom fields 

Observed Result:
The Apply changes button does not get enabled upon changing the size value, it should change the tab to custom and enable the button

Environment:Betalabs and test2

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=67687
*** Bug 68014 has been marked as a duplicate of this bug. ***
Verified the fix in production en.wiki
Verified the fix in test2
Change 146682 merged by jenkins-bot:
Listen to widget changes in MediaDialog

https://gerrit.wikimedia.org/r/146682
Change 146676 merged by jenkins-bot:
Switch to 'custom' when MediaSizeWidget updates

https://gerrit.wikimedia.org/r/146676
Change 146682 had a related patch set uploaded by Mooeypoo:
Listen to widget changes in MediaDialog

https://gerrit.wikimedia.org/r/146682
Change 146676 had a related patch set uploaded by Mooeypoo:
Switch to 'custom' when MediaSizeWidget updates

https://gerrit.wikimedia.org/r/146676
It also happens when you reopen an image which was previously has been set to a custom size and try to edit those values.
Screenshot

Steps to reproduce:


1.Open a page with mobile VE with iOS Safari
2.Tap the cursor on a link to bring up the context menu for it
3.Now tap at the end of some other text to place the cursor there

Observed Result:
The context menu for the previous link is appearing on top of the article.


Environment : Betalabs and test2
See the screenshot attached

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

**Attached**: {F14661}
Verified the fix in production
Both the cases got resolved, checked in test2
I think this is now fixed too.
Another case to get such issue could be:


If you delete the content of a page which had a link, it shows the context menu for the deleted link on a blank page, I suppose the fix for the original issue, should fix this case as well?
Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Go to the Advanced Settings of an image
4.Click on "Make full size"


Observed Result:
The "Apply Changes" button is still disabled , cannot make any image full size

Environment:test2

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in test2
This was the same issue as https://bugzilla.wikimedia.org/show_bug.cgi?id=66863
The following commit fixed it:

Apply 'original size' to images

https://gerrit.wikimedia.org/r/144637
Ni!

Since early this year we at pt.wikiversity have used the Visual Editor as an opt-in "beta feature".

After this experimental phase, we have agreed that we want the Visual Editor to be enabled as default editor for everyone on pt.wikiversity, including unregistered users.

https://pt.wikiversity.org/wiki/Wikiversidade:Esplanada#Habilitar_editor_visual_por_padr.C3.A3o

We'd really appreciate if this could happen before the end of the July, since classes in Brazil start on early August.

Cheers,
Solstag

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
(Note that it will take a 30 days for the cache to be purged, so pages that aren't edited before then will appear to only have one tab to logged-out users until the pages are purged, edited, or the cache expires.)
Now done.
Change 144476 merged by jenkins-bot:
Enable VisualEditor by default on Portuguese Wikiversity

https://gerrit.wikimedia.org/r/144476
Change 144476 had a related patch set uploaded by Jforrester:
Enable VisualEditor by default on Portuguese Wikiversity

https://gerrit.wikimedia.org/r/144476
This is a valid report.  However, as you say it is technically challenging, and we did not intend the initial version to have this support.

(In reply to Daniel Robbins from comment #0)
> A possible work-around to make things a bit more bearable in the mean-time
> would be to add some kind of icon in the page history to indicate revisions
> that have annotations, so that the maintainer of the page can go through the
> page's history and look for annotations from people.

That's a good idea.  Filed as bug 67939.
Admittedly there are no links to take you to edit the page, but navigating to New_page?action=edit gives you and error, whereas New_page?veaction=edit let's you start editing.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 144275 merged by jenkins-bot:
Give a notice if the user isn't allowed to create the page

https://gerrit.wikimedia.org/r/144275
Change 144275 had a related patch set uploaded by Alex Monk:
Give a notice if the user isn't allowed to create the page

https://gerrit.wikimedia.org/r/144275
Parsoid must produce/preserve the metadata about additional ResourceLoader modules required by extension tags. (I've heard some gossip that it falls back to PHP parser to do this, so this should be easy to do.)

For example, in PHP parser, "<syntaxhighlight lang=php>$foo</syntaxhighlight>" will add up to two modules to ParserOutput's $mModuleStyles:
* 'ext.geshi.language.php' (there is such a module for every supported language)
* 'ext.geshi.local' (if $wgUseSiteCss is true)

This information must somehow be provided by the API used by VisualEditor.

The minimum set of things that have to be provided is the ones provided by OutputPage::addParserOutputContent() in PHP, that is modules, module styles, module scripts, module messages and JS config vars. (These are available via the action=parse&prop=modules API in core.)

--------------------------
**Version**: unspecified
**Severity**: major
There were two requests at wikimania for the rest of the stuff included in this bug.  Namely:
* Link to JS necessary to render the page contents.  (Especially for maps modules, etc)
* Some sort of machine-readable enumeration of the modules required (in case you wanted to do manual loading of CSS/JS/etc).
Change 215883 merged by jenkins-bot:
Include RL style modules from parser functions in <head>

[[https://gerrit.wikimedia.org/r/215883]]
* https://gerrit.wikimedia.org/r/215874 (branch master): #mw1.26, #mw1.26wmf9
Change 215874 merged by jenkins-bot:
Expose RL modules and js config vars in action=expandtemplates

[[https://gerrit.wikimedia.org/r/215874]]
Change 215883 had a related patch set uploaded (by Marcoil):
Include RL style modules from parser functions in <head>

[[https://gerrit.wikimedia.org/r/215883]]
Change 215874 had a related patch set uploaded (by Marcoil):
Expose ResourceLoader modules in action=expandtemplates

[[https://gerrit.wikimedia.org/r/215874]]
A little status update:

What currently works:
* Parsoid correctly includes style modules from extensions present in the page that add them through ResourceLoader, so that when requesting the HTML directly from Parsoid it's presented correctly.

What doesn't:
* Style modules added by parser functions, as the expandtemplates API doesn't expose them yet. A patch similar to  @jackmcbarn's https://gerrit.wikimedia.org/r/162123, but without including non-RL modules would solve this.
* All non-style modules exposed through ResourceLoader (Javascript, global vars, messages…). Parsoid's HTML output doesn't load ResourceLoader client infrastructure, so it's difficult to correctly load those modules.

I'm not sure if it's even a good idea to load non-style modules in Parsoid's HTML <head>, tbh, given that it's not really used independently by anything right now. I like @cscott's proposal of exposing the information in data-mw so that clients can use them as they see fit.

So my proposed next steps would be:
* Expose all modules in action=expandtemplates, excluding non-RL modules.
* Add the style ones to Parsoid's <head> as we do now with extension ones.
* Expose all modules (styles and all others) through data-mw.

That way, for example, when VE receives just the body of a page for editing, it would look into the data-mw and load the modules it sees there, which would fix T69515 and related. Right now VE can't get that data directly as it's in Parsoid's <head>.
BTW, i'm trying to move TMH from it's global context into a more isolated one, but i'm guessing that due to the state of this ticket, that will also mean that when that patch lands, it will actually break TMH videos when added by VE right ? Since the global handlers would be gone and the 'local' ones are not loaded yet ?

https://gerrit.wikimedia.org/r/172556
https://gerrit.wikimedia.org/r/172421
The merged patch takes care of adding the appropriate CSS modules to the load list, but only for extensions. Some parser functions (e.g. Babel) also have CSS modules, there's a patch for MW that would allow Parsoid to know about them here:
https://gerrit.wikimedia.org/r/162123
Change 160423 merged by jenkins-bot:
Bug 67540 - Load extension CSS modules

https://gerrit.wikimedia.org/r/160423
As discussed on IRC, we'll do a first patch only for CSS support, and then expand on it with the rest of extensions' resources. We can continue using this bug for this and for C. Scott's proposal of exposing the modules in metadata.

Btw, does anyone have examples of pages where an extension CSS causes Parsoid to render differently from PHP? I'd like to test the visual diffs with this patch. Thanks!
(12:15:15 PM) gwicke: cscott: we should expose the list separately, but for browsers it's probably more efficient to still do some bundling
(12:15:29 PM) gwicke: good to unbundle the per-page modules from the global ones though
(12:15:35 PM) gwicke: right now those are all mixed afaik
(12:18:03 PM) cscott-free: gwicke: agreed.  i'm thinking of exposing the list via data-mw (for example) while still providing the resource url in a <link> tag for browsers.
I think we'll want the lowlevel information about the modules available (via data-mw?), in addition to having One True Resource Loader URL which will load them all.

In particular two of OCG backends, the ZIM writer and the future parsoid-phantomjs-PDF backend, will want to download the set of resources used by a (potentially large) set of pages.  We don't want to have to download the same resources in slight variations over and over again.  If there are N different resources used on a wiki, there are 2^N different resource loader URLs which load various combinations of the N resources.  We'd rather just load the N resources once, even if that means we have to do a little extra work ourselves to order and merge them.
There's a WIP patch now at https://gerrit.wikimedia.org/r/160423 that adds the extensions' CSS modules to the style link.

If we also want to load further extension resources, like JS or messages, I suppose we'll have to add loading ResourceLoader's client first and let it load everything else. Is this the way we should go?
Change 160423 had a related patch set uploaded by Marcoil:
WIP: Bug 67540 - Load extension CSS modules

https://gerrit.wikimedia.org/r/160423
Ex: http://en.wikipedia.org/w/api.php?action=parse&format=json&page=MathML&prop=modules 

includes

"modulestyles":["ext.rtlcite","ext.math.styles","ext.geshi.language.xml","ext.geshi.local","ext.geshi.language.html5"]

CSS modules for inclusion in the <head> would be a good start and will help reduce rendering diffs.
Screenshot

Try to open any page with mobile VE in iOS Safari on Betalabs, the page does not load in VE and it shows an error at the bottom:
"Error,can't load section"

See the screenshot attached.

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

**Attached**: {F14353}
Verified the fix in production
Verified the fix in test2
Fix by Roan unbreaking the databases.
This seems to be working now :)
Looks like this is caused by beta labs being in read-only mode. I can't edit on desktop either.
I can reproduce this on beta labs, but not in local master.
Sounds like it might be something on the MobileFrontend end.
Screenshot

Steps to reproduce:

1.Open a page with mobile VE
2.Tap on a link
3.When the context menu for that link appears tap on that
4.Try to edit the link target name in the search box for link inspector
5.No Link target page suggestions will appear inside the link inspector
6.Close the link inspector
7.Close the keyboard that is still appearing on CE

Observed Result:
The link suggestions are appearing on CE now
See the screenshot attached


This issue started happening after merging the new code for context menu on Mobile VE.

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

**Attached**: {F14100}
Verified the fix in production
Verified the fix in test2 with iOS
Verified the fix in Betalabs with iOS
Yay deployment.
This is still happening on Betalabs.
Change 143524 merged by jenkins-bot:
Use globalOverlay as the contextOverlay in MobileContext

https://gerrit.wikimedia.org/r/143524
Change 143524 had a related patch set uploaded by Catrope:
Use globalOverlay as the contextOverlay in MobileContext

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

Steps to reproduce:

1.Open a page with mobile VE
2.Do not place your cursor anywhere on CE but try to select a node 
3.Scroll down the page

Observed Result:
The toolbar also gets repositioned down while scrolling down the page.

It might get resolved with :https://bugzilla.wikimedia.org/show_bug.cgi?id=57177

Still I am filing it as a separate issue.

See the screenshot attached

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

**Attached**: {F14695}
Verified the fix in production
Verified the fix in test2
Change 145185 had a related patch set uploaded by Jforrester:
Improve fixed header in overlays on iOS

https://gerrit.wikimedia.org/r/145185
Interestingly, this bug only seems to occur in landscape mode on iPad.
This is also happening for the context menu bar in Mobile VE.When you put your cursor for the first time on a node such as link, the context menu bar appears somewhere in the middle of the screen and then scrolls down as you scroll down the page.
However, it does not happen once you close the keyboard and try it for the second time on that session.
Steps:

1. Create page with VE
2. Insert New Template
3. Enter text that is the prefix of one or more pages in the User namespace with template data

Expected result:

Suggestions show up as:
 User:Foo/Template:Example
 User:Foo/Template:Unsigned
 User:Foo/Template:Unsigned2

Actual result:

Suggestions show up as
 :User:Foo/Template:Example
 :User:Foo/Template:Unsigned
 :User:Foo/Template:Unsigned2

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to Alex Monk from comment #3)
> So this *should* be fixed this time...

Famous last words. :-)
So this *should* be fixed this time...
Change 144497 merged by jenkins-bot:
MWTitleInputWidget: Remove prefixColon option and use relative title instead

https://gerrit.wikimedia.org/r/144497
Change 144497 had a related patch set uploaded by Alex Monk:
Get rid of my prefixColon config option from TitleInputWidget, use relative title

https://gerrit.wikimedia.org/r/144497
I can't reproduce this anymore. See also:

* {b7eb243d9204a40977761fb2453070825dfeab97} 
* {T107377}

Things are now minified in smaller chunks and also better re-used as a result.
This might be improved by enabling fsc caching for the VM: `vagrant config nfs_cache yes; vagrant reload`

@dduvall and I would love feedback from power users on the pros/cons of using the fsc nfs cache.
I'm hitting this issue now in my local vagrant - this really shouldn't be taking 30 seconds to load should it even if it's a big file..?
Converting a MWNumberedExternalLinkNode to MWExternalLinkAnnotation from the UI (link inspector) loses annotations on the node, even though there is code in place that aims handle this.

See the behavior of the 'convert' variable in ve.ui.MWLinkNodeInspector.prototype.getTeardownProcess.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 143387 merged by jenkins-bot:
MWLinkNodeInspector: Actually preserve annotations when converting to link annotation

https://gerrit.wikimedia.org/r/143387
Change 143387 had a related patch set uploaded by Bartosz Dziewoński:
MWLinkNodeInspector: Actually preserve annotations when converting to link annotation

https://gerrit.wikimedia.org/r/143387
This is because the node is removed from DM before its annotations are copied. Let me just fix it while I'm at it. :)
Steps to reproduce:

1.  Make your browser window short (<400 pixels?).

2.  Open a page using the Monobook skin, e.g., https://en.wikipedia.org/wiki/Nicholas_Rigby?veaction=edit&useskin=monobook.

3.  Click the (?) button to open the Help menu.

4.  Because of the short screen, the entire menu does not fit on the screen at once.  Try to scroll down to read the last line on the Help menu.


The Help menu is not scrolling, so you can't see anything that doesn't fit on your screen.  This is not a problem in Vector.  I have confirmed this in both Safari 6.1.4 and Firefox 30.

Original report:  https://ru.wikipedia.org/w/index.php?diff=63851178 from Sunpriat

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed a while ago.
Screenshot

Steps to reproduce:

1.Rotate the screen of your iOS device to landscape
2.Open a page with mobile VE
3.Tap on a drop down menu which has lot of options under it like for now we have "Reference" menu
4.Open that menu
5.Try to select the options from the bottom of the menu such as "Use an existing reference" or "Journal"

Observed Result:
Cannot select any of those options since the keyboard is always open and overlapping with the menu,and scrolling down menu again drags the screen back to the top

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

**Attached**: {F14572}
Confirming that, it is still occurring.
I attempted to reproduce this using CrossBrowserTesting.com, but whenever I click on the "Cite" icon using it, the entire toolbar disappears. I can't tell if it's a real bug or the testing app being broken. All in all, this was a wonderful waste of time and I'm still unable to debug, much less fix, this bug (and I still believe it shouldn't be accurring anyway in the first place per comment 5).
(In reply to Roan Kattouw from comment #3)
> Juliusz explained to me that there's a bug in iOS Safari when the keyboard
> comes up: the viewport becomes smaller, but measuring the viewport does not
> take this into account. The hack Juliusz is currently using in
> MobileFrontend to compensate for this is to arrange the document such that
> the main viewport never scrolls, instead everything is wrapped in a
> scrollable <div> that's exactly the size of the viewport.

This seems to be _fixIosHeader() in /javascripts/Overlay.js in MF.


> To address this bug, we would have to have menus clip to this wrapper div
> rather than the body, and we would have to have them reevaluate their
> clipping state (by calling .clip()) every time this wrapper <div> is resized.

Why doesn't this already work? ClippableElements are supposed to be clipped to the closest scrollable element, and surely the MF overlay is closer than body.
Bumping over to Bartosz; this is an awkward three-way bug between VE, MobileFrontend and OOUI as I understand it. Fun. :-(
(In reply to Roan Kattouw from comment #2)
> Hmm, this sounds like a bug related to ClippableElement. The menu should
> automatically clip and become scrollable when there isn't enough screen
> space for it. You can see this on desktop if you resize the window. Maybe
> iOS Safari isn't emitting a resize event, or is emitting an event we're not
> listening to, or isn't giving us the correct viewport dimensions?

Juliusz explained to me that there's a bug in iOS Safari when the keyboard comes up: the viewport becomes smaller, but measuring the viewport does not take this into account. The hack Juliusz is currently using in MobileFrontend to compensate for this is to arrange the document such that the main viewport never scrolls, instead everything is wrapped in a scrollable <div> that's exactly the size of the viewport. Then he listens for focus events, and attempts to scroll the viewport down by a large amount (9999px or something?). Under normal circumstances, this has no effect, but if the keyboard is up, the viewport will be scrollable and measuring how much it scrolled by gives you the height of the keyboard. He then adjusts the sizing of the wrapper <div> so it once again fits the viewport exactly.

This is also part of why things sometimes behave very strangely when focus events are dropped or emitted at the wrong time, because then Juliusz's code may not notice that the keyboard has appeared or disappeared, and it may not adjust the size of the wrapper <div> when it should.

To address this bug, we would have to have menus clip to this wrapper div rather than the body, and we would have to have them reevaluate their clipping state (by calling .clip()) every time this wrapper <div> is resized.
Hmm, this sounds like a bug related to ClippableElement. The menu should automatically clip and become scrollable when there isn't enough screen space for it. You can see this on desktop if you resize the window. Maybe iOS Safari isn't emitting a resize event, or is emitting an event we're not listening to, or isn't giving us the correct viewport dimensions?
Yep, I can confirm this on my iPad Air (iOS 7.1) when not using an external Bluetooth keyboard.

In landscape mode with the keyboard open there is *very* little vertical space, only about 220px high, between the VE toolbar and the top of the keyboard -- vertically laid-out menus are probably not a good idea here.

iOS text-selection menus tend to be laid out horizontally like a segmented toolbar presented as a popup from the selection itself; Android 4.x uses a horizontal action bar at the top of the screen.

I would recommend going with some sort of horizontal button layout, perhaps as a second layer of toolbar.
If I go to a page that has been redirected, the URL retains the original title instead of the redirected title. So if I enter VE and then refresh, I'm taken to the editing the original page instead of the redirect page.

For example, go here: https://en.wikipedia.org/wiki/Zedonk, then click VE, then refresh the page. 

URL should be changed to: https://en.wikipedia.org/wiki/Zebroid?veaction=edit

--------------------------
**Version**: unspecified
**Severity**: minor
That change has been merged and this should therefore be magically fixed. I'd appreciate if someone could verify.
Likely to be made WORKSFORME by gerrit 143852 but isn't actually a patch for VE. :-)
Change 143852 had a related patch set uploaded by Bartosz Dziewoński:
On redirect, actually rewrite page URL to the target one with JavaScript

https://gerrit.wikimedia.org/r/143852
Note: This doesn't happen on mobile, on refresh user stays on redirect page.
(In reply to Bartosz Dziewoński from comment #2)
> (In reply to James Forrester from comment #1)
> > Ideally MediaWiki's redirects should 307 rather than 200 so we don't have
> > this problem… :-(
> 
> They shouldn't because then you can't show the "Redirected from" message
> without hacks,

I'm aware of that minor impact on users, but that info is normally duplicated by editorial templates anyway on Wikimedia wikis, at least.

> but they probably should update the URL with JavaScript instead.

> Wanna file a bug or that? (I wouldn't be surprised if there was one already.)

Yes, that looks like bug 35045.
(In reply to James Forrester from comment #1)
> Ideally MediaWiki's redirects should 307 rather than 200 so we don't have
> this problem… :-(

They shouldn't because then you can't show the "Redirected from" message without hacks, but they probably should update the URL with JavaScript instead. Wanna file a bug or that? (I wouldn't be surprised if there was one already.)
Rewriting the URL is a bit evil, but if we don't we have the issue of users having a URL they can't share/reload without the context changing.

Ideally MediaWiki's redirects should 307 rather than 200 so we don't have this problem… :-(
See https://commons.wikimedia.org/wiki/File:VE_bug-Template_name_overlaps_remove_icon_in_advanced_dialog.png

If the name of the template is very long, then it overlaps with the trashcan icon for removing it.

This may or may not remain a consideration with the upcoming change to labels (instead of icons) and the redesign of all the boxes.

--------------------------
**Version**: unspecified
**Severity**: trivial
This is wrapped correctly now
resize and size reporting issue with audio files

issue is highlighed on https://en.wikipedia.org/wiki/Iceberg

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

**Attached**: {F14397}
197.218 has provided some useful steps for reproduction here:  https://www.mediawiki.org/wiki/Topic:Ttg05p4t0hox34jh
I'm seeing it start off with the 0px size (in the display), and no way to change it.  It seems to save correctly, though.

This problem was reported after this edit was made:  https://en.wikipedia.org/w/index.php?title=Perry_DeAngelis&diff=660113505&oldid=653104203

I cannot re-size the audio box in VisualEditor.  (In the wikitext editor, I can [only] make it smaller than default.)
Detached toolbar when floating in non-HD Vector

Works fine when normally placed, but is out by ~ 30px when floating.

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

**Attached**: {F14365}
Looks like this got fixed two weeks ago.
Created attachment 15773
Non-detached static toolbar

**Attached**: {F14366}
--------------------------
**Version**: unspecified
**Severity**: enhancement
*** Bug 58245 has been marked as a duplicate of this bug. ***
Change 140813 merged by jenkins-bot:
Merge Media Edit and Media Insert dialogs

https://gerrit.wikimedia.org/r/140813
Change 140813 had a related patch set uploaded by Mooeypoo:
[wip] Merge Media Edit and Media Insert dialogs

https://gerrit.wikimedia.org/r/140813
Once more with feeling.
Steps to reproduce:

1.  Open a page containing an image in Safari.

2.  Open an image in the media dialog box.  The cursor begins in the Caption field (of General settings).

3.  Press tab (to get to the next field).


Results:

Nothing happens.  The cursor is stuck in the Caption field.

--------------------------
**Version**: unspecified
**Severity**: trivial
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=67156
Hmm. Will sling into the list, then, but this feels odd…
This works for me at Mediawiki.org (1.24wmf12) but not at the English Wikipedia on Safari 6.1.4 with Mac OS 10.8.5.  

Presumably it will work everywhere after tomorrow's update, so I'm marking it as fixed.
WFM (Safari 5.1.7 for Windows)
This is related to {T69153}, but specific to Chrome/Safari:

Whatever the dialog box, once you've tabbed through whatever links and buttons are inside that dialog (and on the tab list, which isn't always all of them), then pressing tab takes you outside the dialog box to these items:

1) the browser's URL bar
2) the main Wikipedia search box 
3) the Cancel button (on VisualEditor's toolbar)
4) the Save button (on VisualEditor's toolbar)
5) the top of the article
6) the slug at the top of the article, where it gets stuck forever.

and never lets you get back to the dialog box.  This means that if you press tab one time more than you meant to, you cannot use or close the dialog box without taking your hands off the keyboard.

**See Also**: {T69162}
Change 237505 merged by jenkins-bot:
Re-attempt I31ab2bace4: Try to stop user from tabbing outside of open dialog box

[[https://gerrit.wikimedia.org/r/237505]]
Change 237480 merged by jenkins-bot:
Rewrite isFocusableElement for performance and correctness

[[https://gerrit.wikimedia.org/r/237480]]
Change 237480 had a related patch set uploaded (by Esanders):
Rewrite isFocusableElement for performance and correctness

[[https://gerrit.wikimedia.org/r/237480]]
Change 237505 had a related patch set uploaded (by Esanders):
Re-attempt I31ab2bace4: Try to stop user from tabbing outside of open dialog box

[[https://gerrit.wikimedia.org/r/237505]]
Turns out that we have a method to find focusable elements now (6ff7e5c7ae384038b314dc90036f0a8468e7e65a), but it's a bit broken (T107343). Let's try to fix it and use it.
Some more notes:
* The previously suggested focus trap only works for tab, not for shift-tab
* a focus trap only fixes keyboard navigation, not screenreader accessibility
** You can use aria-hidden to hide everything outside the dialog, opacity does not hide things....

Suggested reading:
* http://www.w3.org/TR/wai-aria-practices/#modal_dialog
* http://www.w3.org/TR/wai-aria-practices/#dialog_modal
* http://www.w3.org/TR/wai-aria-practices/#dialog_nonmodal
* http://www.w3.org/TR/wai-aria-practices/#dialog_tooltip
Let me add links for jQuery UI's :focusable and :tabbable 

http://api.jqueryui.com/focusable-selector/
http://api.jqueryui.com/tabbable-selector/
if jQuery UI can add a selector focusable and 'tabbable' for this. Can't we mix those in ourselves ? We'd have to account for the situation where both jQueryUI and OOjs UI are loaded, but we can do that with prefixes I think...
The reverted patch did, in fact, do something like that. But we still need to find the place inside the dialog where we want to move the focus, and it used `:focusable` for this.

I did some googling and found http://accessibility.oit.ncsu.edu/training/aria/modal-window/version-2/, which uses `a[href], area[href], input:not([disabled]), select:not([disabled]), textarea:not([disabled]), button:not([disabled]), iframe, object, embed, *[tabindex], *[contenteditable]`. Sadly, I think they're wrong in both using `[disabled]` rather than `:disabled` and not checking `[tabindex='-1']`.

Note also that `:focusable` implied `:visible`, we'd need to add this filter ourselves.
Can we do it using observe and fixup, e.g.  listen to focusin on the body, and if the event originates form outside the dialog, move it back inside the dialog.
Patch was reverted, so what's the status of this? We need to do the same again, but without `:focusable`? 

I looked at the source code and `:focusable` can be reasonably approximated using `input:enabled:not([tabindex='-1']), select:enabled:not([tabindex='-1']), textarea:enabled:not([tabindex='-1']), button:enabled:not([tabindex='-1']), a[href]:not([tabindex='-1']), [tabindex]:not([tabindex='-1'])`, or even just `*:enabled:not([tabindex='-1']), a[href]:not([tabindex='-1']), [tabindex]:not([tabindex='-1'])`. If that's too nasty, then we might also do `[tabindex]:not([tabindex='-1'])` and probably no one will notice the difference (OOUI focusable elements generally have tabindex=0 set, even if that's not strictly necessary).
The applied patch throws an exception, see gerrit.
Merged. Hopefully this doesn't break anything else.
Change 159902 merged by jenkins-bot:
Try to stop user from tabbing outside of open dialog box

https://gerrit.wikimedia.org/r/159902
Change 159902 had a related patch set uploaded by Alex Monk:
Try to stop user from tabbing outside of open dialog box

https://gerrit.wikimedia.org/r/159902
So after some confusion about this I looked into it again, and I believe that there's two issues here:
* We perhaps shouldn't let tab take the focus out of the dialog box at all
* Tab definitely should not be getting lost and become unable to return to the dialog

Different browsers appear to do different things:
* Chrome on Ubuntu lets it out of the dialog, but it properly goes back and doesn't get stuck.
* Chrome and Safari on Windows just let the tabbing leave the dialog, and then it gets stuck and doesn't return to the beginning of the page
* Firefox (on Ubuntu or Windows) does not let it out of the dialog
In that case this feels like an upstream issue
Firefox lets me leave the dialog box, but it eventually tabs back into it.  Safari gets stuck.  I haven't checked Chrome; Safari and Chrome often have the same problems, so it might be anything WebKit/not Mozilla.
I don't think we do this deliberately. This happens in Chrome for me... Are you sure this is Safari-specific, Sherry?
Krenair, is this something that we do as part of the aria-role stuff (and is it something we should do)?
When adding a link inside a reference in VisualEditor, if one clicks 'apply' without first clicking outside the link inspector, the link is not added.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60837
Спасибо! Happy New Year!
Being bold and marking as resolved.

С новым годом :)
Seems to be fixed to me too - checked in betalabs/test2/production.
I believe this was fixed when Roan worked on the focus issue with inspectors. I can't reproduce this either, it works as it should now with links and language inspector both.
Can anybody reproduce this? I can't. Either I misunderstand the description, or it was fixed.
Maybe we just need to give the edit box focus when applying changes, like in bug 60837's fix?
Misaligned toolbar

The bottom of the bar is too high, the Cancel and Save buttons are at different heights.  

However, I can't reproduce it consistently, and changing the font size caused everything to realign correctly.

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

**Attached**: {F14345}
This seems to have been fixed a long time ago.
*** Bug 67071 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 67071 ***
A split button consists of a "command button" and a "dropdown button". These are two separate clickable entities. The command button behaves like a regular toolbar button, but it displays the most recent command the user invoked from the dropdown menu.

It was suggested by User:Theflyer to convert VE's list toolbar button into a split button:


> When selecting an item from the menu, like lists, I think the button should be sticky and perform the action that is currently shown rather than requiring two clicks to take an action. The example that brought this to my attention is when creating bullets. The default icon shows a traditional bullet so when I click on that, I expect it to just start a bullet. However, the action I get is to open the menu where I then have to select which bullet list option I would prefer. I think there should be a way to act on the existing icon (and it should change to whatever I had last selected) and also a way to pull down the list if I want to change to a different type of action. This is the way Microsoft Word works. There are two clickable hotspots. Thanks. Don Theflyer (talk) 15:55, 21 June 2014 (UTC)


--------------------------
**Version**: unspecified
**Severity**: enhancement
I think you're slightly misunderstanding what is meant by "split button". There is no single "primary action"; see this video [1] for an example of how the command on the "command button" part of the split button changes as different options are picked from the dropdown.

[1] http://tinypic.com/r/52jl7p/8 Sorry, it's a disgusting video hosting site, I hope you can tolerate the advertising!
Hmm. Maybe. Is bulleted list the principal structure-action people will take, over "make blockquote" or "indent" or "insert table" or "insert row" or…?
There are a few places where we use the string ', ' but in all of those cases we should really be using the comma-separator message. This requires backfilling comma-separator for standalone OOUI, since we also use commas in VE core and OOUI.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 174302 merged by jenkins-bot:
ve.ce.MWTransclusionNode: Replace last use of ', ' in VE-MW with <comma-seperator>

https://gerrit.wikimedia.org/r/174302
Change 174302 had a related patch set uploaded by Jforrester:
ve.ce.MWTransclusionNode: Replace last use of ', ' in VE-MW with <comma-seperator>

https://gerrit.wikimedia.org/r/174302
...but it gets converted. Hm.
The MW message includes HTML. Ew.
Right now we have things like mw.Title.newFromText( template ); , while really that should use something like mw.Title.newFromText( template, 10 ); or whatever. This is probably fine in practice, but theoretically matters is NS_MAIN and NS_TEMPLATE have different capitalization settings.

We also currently render the titles of {{foo}} (which points to Template:Foo, renders as Foo) and {{:foo}} (which points to Foo, also renders as Foo) the same, we should fix that.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to Roan Kattouw from comment #3)
> (In reply to Roan Kattouw from comment #0)
> > Right now we have things like mw.Title.newFromText( template ); , while
> > really that should use something like mw.Title.newFromText( template, 10 );
> > or whatever. This is probably fine in practice, but theoretically matters is
> > NS_MAIN and NS_TEMPLATE have different capitalization settings.
> > 
> This is not fixed yet, reopening.
> 
Somewhat to my surprise this is in fact fully fixed in https://gerrit.wikimedia.org/r/143685
Change 143685 merged by jenkins-bot:
Try some more to handle template namespace properly

https://gerrit.wikimedia.org/r/143685
Change 143685 had a related patch set uploaded by Catrope:
Try some more to handle template namespace properly

https://gerrit.wikimedia.org/r/143685
(In reply to Roan Kattouw from comment #0)
> Right now we have things like mw.Title.newFromText( template ); , while
> really that should use something like mw.Title.newFromText( template, 10 );
> or whatever. This is probably fine in practice, but theoretically matters is
> NS_MAIN and NS_TEMPLATE have different capitalization settings.
> 
This is not fixed yet, reopening.

> We also currently render the titles of {{foo}} (which points to
> Template:Foo, renders as Foo) and {{:foo}} (which points to Foo, also
> renders as Foo) the same, we should fix that.
This was indeed fixed by https://gerrit.wikimedia.org/r/141082
Change 141082 merged by jenkins-bot:
Normalize titles in template descriptions in context menu

https://gerrit.wikimedia.org/r/141082
Change 141082 had a related patch set uploaded by Jforrester:
Normalize titles in template descriptions in context menu

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

1.Open a page with VE
2.Insert a svg image with large size 
(I found this issue with this image: https://test2.wikipedia.org/wiki/File:MO-123.svg, which has full size of 2,543 × 2,160 pixels.
I tried with svg images of upto 2000 x 2000 pixels, but could not reproduce for them.)

3.Go to Media Settings tab of this image and go to Advanced Settings
4.Click on Make full size (it wont try to make it full size which is another bug)
5.Now again click on Make full size

Observed Result:
It changes the size values to the full size of the images but it also says "Size values are invalid"

Page:https://test2.wikipedia.org/wiki/19thjanFF?veaction=edit

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in Betalabs
Change 142380 merged by jenkins-bot:
Unimplement wgSVGMaxSize

https://gerrit.wikimedia.org/r/142380
Change 142380 had a related patch set uploaded by Mooeypoo:
Unimplement wgSVGMaxSize

https://gerrit.wikimedia.org/r/142380
Users who submit feedback through the in-VisualEditor form may not see any responses to their feedback because the page is not added to their watchlists, and there's no option to add it.

This feature comes from the `mediawiki.feedback` module in MediaWiki core.
This is pretty irritating. Not sure whether it should just respect the users' default wishes, actively add the page anyway, or give an option…
https://en.wikipedia.org/w/index.php?diff=612724427&oldid=612719708 added an invalid section heading:

===== <br>
Buses =====


VisualEditor should always strip <br> out of section headings.

--------------------------
**Version**: unspecified
**Severity**: normal
Should now be fixed thanks to the Parsoid munging magic.
I can't reproduce…
This is still happening: https://en.wikipedia.org/wiki/Special:Diff/655367592
Steps to reproduce:

1.  Open a page in VisualEditor and make a link:  [[Foo]].  Easy, right?  Select text, press Command–K, and hit return twice.  You know the page exists under that name and that it doesn't need to be piped, so you don't even need to wait for the link inspector to get the information back from search.

2.  Make another link the same way, but to a different page:  [[Bar]].

3.  Why does VisualEditor offer to point that second link to [[Foo]]?


Steps to avoid this problem:

1.  Open a page in VisualEditor and make a link:  [[Foo]].

2.  Start to make another link to a different page ([[Bar]]), but after you've opened the link inspector, just stop and wait and wait and wait.

3.  Ah, it's finally figured out that [[Bar]] is not [[Foo]] and stopped trying to tell me that I want to link this to [[Foo]].  *Now* you can hit return twice and go on with your editing.


Can we make VisualEditor "forget" the search results in between attempts to link pages?

--------------------------
**Version**: unspecified
**Severity**: normal
This is now fixed with the changed way that the search interface triggers on link creation (and about a dozen other minor changes). So… yay?
In advance of rewriting the skins system, MediaWiki 1.24 introduces a mediawiki.skinning.content.parsoid module which is a dependency of VisualEditor master.

Making it so that downstream users can use newer versions of VisualEditor but not bleeding-edge MediaWiki would be a nice improvement for them, especially for LTS versions.

However, we may want to have it settle down a bit more until now?

--------------------------
**Version**: 1.23.0
**Severity**: enhancement
This is going nowhere, and REL1_23 is EOL within the next two months. There's little point putting any effort into this
This has been in the "MediaWiki-Tarball-Backports" project for over a year now. Suggest we either close as WONTFIX, or someone proposes a way forward.
Restoring the "Backport_to_stable?" flag in Bugzilla by adding this to the MediaWiki-Tarball-Backports project in Phab.
(In reply to James Forrester from comment #4)
> There are probably more to come, but this is good enough. Given that 1.23 is
> LTS, I imagine Mark wants to support VE on it? Confused why he just rejected
> the backport he requested…

I was going through the backport request queue and didn't see anything to backport.

Replacing the flag and, hopefully, I'll have time later to go through the list of patches.
(In reply to Andre Klapper from comment #3)
> Which specific, identified commits are proposed as backport candidates here?

`git log --oneline resources/src/mediawiki.skinning/content.parsoid.less`:

4ae23e7 Fix Parsoid's span.reference styling to match PHP's output
5ada680 Remove Parsoid-specific padding and background
244e1fc Apply bidi styles to references in Parsoid styles
76a5ea6 Minor: Remove unnecessary @noflip annotation
9573eb2 Add unfloated thumb styling in Parsoid CSS
56300b6 Align image frame padding with core
4f69ebe Tweaks to Parsoid CSS styles for citations.
6f45ac4 Fix rendering of centered caption-less images
26a39ec Hide the caption of frameless or inline images in Parsoid HTML
4fe80f6 Minor: more specific parsoid image styling with child selectors
a3525f0 Bug 51245: Add auto-numbered link CSS to Parsoid styles
a6c074a Minor clarification & tweak for Parsoid render testing
7086dad Bug 66287: Proper caption styling
99f093a Make sure images that don't have an explicit alignment get aligned right
e826298 Add border and background styling to the Parsoid styles for images
295b2dc Followup dd1c7f7fd7: fix LESSification errors in Parsoid styles
dd1c7f7 Create a version of mediawiki.skinning.content for Parsoid HTML

There are probably more to come, but this is good enough. Given that 1.23 is LTS, I imagine Mark wants to support VE on it? Confused why he just rejected the backport he requested…
Which specific, identified commits are proposed as backport candidates here?
(In reply to Kunal Mehta (Legoktm) from comment #1)
> Is this still the only thing blocking VE master on 1.23? Or have there been
> new breaking things since then?

Lots of new breaking things since then, like your patches to make VE use Config, but VE-not-quite-master from a month ago or so probably would be able to go if this stuff was backported to MW REL1_23 (and more importantly, users wouldn't need to install the very confusing Parsoid PHP extension in addition to the Parsoid nodejs service).
Is this still the only thing blocking VE master on 1.23? Or have there been new breaking things since then?
On mobile devices there's the "stick" blinking cursor, and usually also another handle for moving the cursor around more conveniently. I'm not sure what is it called.

I cannot see it in the mobile VE.

I'm using ASUS Transformer with Android 4.2.1.

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

Steps to reproduce:

1.Open a page with Mobile VE
2.Select a text
3.Click on the link inspector icon from the toolbar

Observed Result:
The link inspector appears a bit zoomed, which at first glance made me feel like a failure in rendering the inspector.

See the screeshot attached

Device: Nexus 7(Android 4.4.2)
Environment:Production (en.wiki) and Betalabs

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

**Attached**: {F13925}
Not happening anymore, tested in test2 and en.wiki.
Needs re-testing.
Maybe don't let users zoom at all?
Screenshot

Steps to reproduce:

1.Open a page with mobile VE
2.Tap at the end of a link

Observed Result:
The link gets copied at the position your cursor was on and it will keep continue doing that everytime you place your cursor at the end of extended link.

See the screenshot attached

Device: Nexus 7(Android 4.4.2)
Environment:Production (en.wiki) and Betalabs

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

**Attached**: {F13918}
Needs re-testing.
https://www.mediawiki.org/wiki/Manual:Change_tag_table , no private data involved and very useful for research (public editing patterns of all sorts and now visualeditor, mobile etc.).

On wikitech-l nobody could find a reason not to do it.
http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070255.html

--------------------------
**Version**: unspecified
**Severity**: enhancement
done, tested, works. closing.
Change 242499 merged by ArielGlenn:
dump change tag table, T68700

[[https://gerrit.wikimedia.org/r/242499]]
Since change tags can now be deleted, I'm moving this along.
Change 242499 had a related patch set uploaded (by ArielGlenn):
dump change tags table, T68700

[[https://gerrit.wikimedia.org/r/242499]]
Steps to reproduce:

1.Open a page with Mobile VE
2.Tap somewhere in the middle of the article
3.Insert some text
4.Close the keypad
5.Now again tap at the end of the text that you typed in

Observed Result:
The cursor moves to the beginning of the article, not where the user wanted to start his edit.

Device: iPad Mini
iOS:7.1.1
Environment:Production and Betalabs

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in test2
The original issue that cursor jumps to the beginning of the article is resolved, but still remains issue where the page is not actually getting scrolled down to the point where the cursor is currently positioned at.I have filed a different bug on that (https://bugzilla.wikimedia.org/show_bug.cgi?id=70111) as discussed with Roan.
Change 155839 merged by jenkins-bot:
Check for selection in ve.ce.Surface#onDocumentFocus

https://gerrit.wikimedia.org/r/155839
Change 155839 had a related patch set uploaded by JGonera:
Check for selection in ve.ce.Surface#onDocumentFocus

https://gerrit.wikimedia.org/r/155839
**jgonera** wrote:

this.dragging is false because onFocusChange is called after onDocumentMouseUp.

The order of events on iOS Safari seems to be fine though:

* mousedown
* focus
* mouseup
**jgonera** wrote:

It's because we call

    this.getModel().selectFirstContentOffset();

in ve.ce.Surface#onDocumentFocus as a workaround for Firefox. I guess we'd want this.dragging to be true when someone taps on a touch device, but it's false instead.
**jgonera** wrote:

Trying to figure this one out now.

If you set hasFocus to false in ve.ce.Surface#onFocusChange, the problem goes away.

If you already have the fix for bug 68832 [1][2], then this is easier to reproduce because it happens on every tap on the CE.

[1] https://gerrit.wikimedia.org/r/#/c/155678/
[2] https://gerrit.wikimedia.org/r/#/c/155671/
**jgonera** wrote:

Might be related to bug 68832.
Might be related to the context being wrong in iOS?
As a logged in user at http://en.m.wikipedia.beta.wmflabs.org/\

With beta setting enabled

Click edit

VE never appears, user sees just a spinner. 

js error is: Uncaught Error: Unknown dependency: jquery.uls.data

--------------------------
**Version**: unspecified
**Severity**: major
The error goes away after enabling the 'uls' role in vagrant.
This is happening to me. I have latest code from master.
Checked on betalabs and test2 mobile.
Change 139484 merged by jenkins-bot:
Add mobile target for modules that VE depends on

https://gerrit.wikimedia.org/r/139484
Change 139435 merged by jenkins-bot:
Add targets missing from jquery.i18n libraries

https://gerrit.wikimedia.org/r/139435
Change 139484 had a related patch set uploaded by JGonera:
Add mobile target for modules that VE depends on

https://gerrit.wikimedia.org/r/139484
Change 139435 had a related patch set uploaded by Esanders:
Add targets missing from jquery.i18n libraries

https://gerrit.wikimedia.org/r/139435
Error introduced by I54c0a8e5816a3c81851f95f1d3062a6091a9f4a3 in VisualEditor
**bingle-admin** wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/MuQh23gb
**Author:** `oliver.buchtala`

**Description:**
Put the cursor at the end of a text node and e.g. type ``.
After short delay the selection expands to the begin of the next node.

This happens for me under OSX Chrome 35 and Safari 7.0 for  VE@356f325ab21731e0aa5c83f90fb4fa037cc60cff.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Mac OS X 10.9
**Platform**: Macintosh
Confirmed; the re-select happens on master.

When the cursor is at the start or in the middle of a paragraph and the next cursor position is text, nothing odd happens.

When the cursor is at the end of the paragraph (and the next paragraph begins with text or a node), it selects from the end of the paragraph to the start of the next. However, the selection is still n,n – it's not showing as a selection n to n+2 as it is showing.

When the cursor is at the start or in the middle of a paragraph and the next cursor position is a node (e.g. a reference or a link node), the cursor suddenly disappears (but the selection is still n,n).
**oliver.buchtala** wrote:

Animation showing the issue in Safari

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

1.Open a page with VE
2.Open the gallery inspector for an already added gallery or open the math inspector
3.Close the gallery inspector or math inspector after inserting math function

Observed Result:
The inspector closes with an animation coming from right to left

Environment:Betalabs

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60501
Fixed in gerrit 139550.
This is also on test with wmf9
**Author:** `oliver.buchtala`

**Description:**
Currently, if the menu for a FocusNode gets embedded, this also happens for the Inspector. It would be better to let the Inspector itself decide.

Details:

This gets executed when the menu for a focus node is shown. 'this.embedded' is set according to the size of the focus node:

https://github.com/wikimedia/VisualEditor/blob/356f325ab21731e0aa5c83f90fb4fa037cc60cff/modules/ve/ui/ve.ui.DesktopContext.js#L428-L435

OTOH, when the inspector gets opened, 'this.embedded' is not recomputed:

https://github.com/wikimedia/VisualEditor/blob/356f325ab21731e0aa5c83f90fb4fa037cc60cff/modules/ve/ui/ve.ui.DesktopContext.js#L420-L425

This has the consequence that the inspector is rendered over the focussed node.
IMO, at least the same embedded check should be done in the 'inspector' case.
Also the tail should be enabled accordingly.

To leave the inspector implementation even more control I would suggest to add something like this to the Inspector interface:

/**
 * @returns {boolean}
 */
Inspector.prototype.isEmbedded = function() {};

--------------------------
**Version**: unspecified
**Severity**: normal
Change 155704 merged by jenkins-bot:
Never embed the context when an inspector is present

https://gerrit.wikimedia.org/r/155704
Change 155704 had a related patch set uploaded by Esanders:
Never embed the context when an inspector is present

https://gerrit.wikimedia.org/r/155704
Regressed.
*** Bug 67306 has been marked as a duplicate of this bug. ***
Change 143393 merged by jenkins-bot:
Never embed the context when an inspector is present

https://gerrit.wikimedia.org/r/143393
Change 143393 had a related patch set uploaded by Jforrester:
Never embed the context when an inspector is present

https://gerrit.wikimedia.org/r/143393
[Bah]

(In reply to James Forrester from comment #4)
> Sorry for the slow triage here; between this and bug 67306 we think it'd be
> best to actively prevent the context menu from showing over an item that is
> inspectable (rather than just have it be a configuration), so I'm going to
> mark this one as the primary and the other as

… as possibly a WONTFIX, rather than leave it be.
Sorry for the slow triage here; between this and bug 67306 we think it'd be best to actively prevent the context menu from showing over an item that is inspectable (rather than just have it be a configuration), so I'm going to mark this one as the primary and the other as
**oliver.buchtala** wrote:


(In reply to Oliver Buchtala from comment #2)

> https://github.com/oliver----/VisualEditor/commit/
> 26baf0bf57fb3fb23ce7ae5971b25f29ac8182db
Sorry, this link was wrong.

https://github.com/oliver----/VisualEditor/commit/8c0e5acb6df5bc104165e9fbbf3f9b9959f89135
**oliver.buchtala** wrote:

(In reply to Oliver Buchtala from comment #1)

Maybe it could look like this:

https://github.com/oliver----/VisualEditor/commit/26baf0bf57fb3fb23ce7ae5971b25f29ac8182db
**oliver.buchtala** wrote:

... or better:

/**
 * @returns {boolean}
 */
Inspector.prototype.isEmbeddable = function() {
  return true;
};

A custom inspector can then override this to avoid embedding and existing implementations would not be influenced.
Screencast of the behaviour.

When I create a new article on Swedish Wikipedia with VE, the page footer is displayed above the cursor but below the title (se attached ogv).

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

**Attached**: {F13951}
This isn't happening any more, so I guess it was fixed at some point during the last three years.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Insert another image inside the caption of it.
4.Select the image and observe the position of the context menu that appears on top of the image

Observed Result:
The context menu's position is shifted few pixels to the right.
See the screenshot to compare the position of it .

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

**Attached**: {F13897}
Verified the fix in production
Verified the fix in Betalabs and test2
Change 142797 merged by jenkins-bot:
Add a ve direction class to all surfaces

https://gerrit.wikimedia.org/r/142797
Change 142797 had a related patch set uploaded by Esanders:
Add a ve direction class to all surfaces

https://gerrit.wikimedia.org/r/142797
But not for me (though the highlight is correctly aligned now).
Created attachment 15743
Demonstration in Beta Labs

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:Jdforrester_(WMF)/Sandbox&oldid=108546&veaction=edit

**Attached**: {F13898}
WFM in beta labs
There is a difference in behavior between explicitly stating "none" in the image wikitext and setting no alignment (which is usually default) This difference is especially complicated when we're dealing with switching between block to inline, as inline images basic/frameless have no initial alignment (attrs.align = undefined) but if an alignment is chosen in basic/frameless they turn into blocks.

There is no real way to choose "none" alignment for inline blocks with our current GUI.

You can see the outcome and differences between default/no alignment to 'none' and other alignments in each of the different image types in this table:
https://www.mediawiki.org/wiki/User:Mooeypoo/VE_ImageAlignment


I've tried to explore what other programs do in this case, but there doesn't seem to be a good analogy for the difference between having 'float' value and not having a float value while mixing block with inline. 

In Microsoft Word 2013, images are inserted as block image with default alignment that is the direction of the text (left for ltr, right for rtl) *BUT* without text wrapping - so no float. You can change the image to inline ("In Line with Text") or to be wrapped ("With Text Wrapping") but the wrapping options are limited to how close the text is around the image; the user is then allowed to manually drag the image wherever they want ti to be (no actual 'left' / 'center' / 'right')

We should find a working solution to let users decide between having 'none' alignment explicitly while still having the default value available for both inline and block images.

--------------------------
**Version**: unspecified
**Severity**: enhancement
The comparison to wikitext functionality should be something like:
* In line: frameless/basic without alignment
* Wrap text: thumb/frame/frameless/basic with explicit right/left alignment
* Break line: thumb/frame/frameless/basic with either "center" or "none" alignments. No float, no text wrap.

The only problem in that case would be to adjust the fine print of the behavior, but in general terms it would be more or less consistent to the user.
(In reply to Moriel Schottlender from comment #6)
> Interestingly enough, in Google Docs you seem to have three main alignment
> options:
> 
> * In line - an inline image
> * Wrap text - Block image with floating, you can then drag/drop it either
> left, center or right in the text and choose how small the margin to the
> text is.
> * Break text - this is just like our "none" option, it's an image in its own
> line that is automatically aligned to the text (so, left in LTR)
> 
> The functionality (drag/drog) and some options aren't all relevant, but
> maybe we could get some ideas from the naming of the features.

Dragging to the left/right/centre actually could be really nice, but we'd probably want both that and a way to set it in the dialog I think.

"Inline" vs. "Break text" vs. "Wrap text" seems reasonable language…
Interestingly enough, in Google Docs you seem to have three main alignment options:

* In line - an inline image
* Wrap text - Block image with floating, you can then drag/drop it either left, center or right in the text and choose how small the margin to the text is.
* Break text - this is just like our "none" option, it's an image in its own line that is automatically aligned to the text (so, left in LTR)

The functionality (drag/drog) and some options aren't all relevant, but maybe we could get some ideas from the naming of the features.
Created attachment 15627
Image alignment in Google Docs

**Attached**: {F13814}
Created attachment 15626
Word 2013 image wrap text menu

**Attached**: {F13813}
Created attachment 15625
Word 2013 image position menu

**Attached**: {F13811}
Created attachment 15624
Word 2013 image popup menu

**Attached**: {F13810}
Created attachment 15623
Word 2013 image alignment menu

**Attached**: {F13809}
Screenshot

Steps to reproduce:

1.Open a page with Image
2.Open the Media Settings dialog
3.Now quickly double click on Apply changes Button

Observed Result:
An error appears in the console:

Uncaught TypeError: Cannot read property 'getSurface' of null
Media Settings dialog for that image and all other images on that page becomes unresponsive.

This is happening in Betalabs and test , not on production(en.wiki)

See the screenshot attached

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

**Attached**: {F13637}
**Coiby.Xu** wrote:

(In reply to Roan Kattouw from comment #10)
> Right, ActionDialog.js was introduced after the 1.23 release. I thought this
> bug was introduced after the 1.23 release though, so I'm surprised to hear
> it's breaking for you.

So will the development team resolve this bug for 1.23?
Right, ActionDialog.js was introduced after the 1.23 release. I thought this bug was introduced after the 1.23 release though, so I'm surprised to hear it's breaking for you.
**Coiby.Xu** wrote:

Sorry, it's typo. I mean .js.

There are two files related to Media Seetings dialogue, ve.ui.MWMediaInsertDialog.js and ve.ui.MWMediaEditDialog.js. There's no ve.ui.ActionDialog.js.
(In reply to Coiby from comment #7)
> (In reply to Coiby from comment #6)
> > This problem still exist on snapshot 9883566
> > (https://extdist.wmflabs.org/dist/VisualEditor-REL1_23-9883566.tar.gz).
> 
> I just look through the patch, I can't find such file
> ve/ui/dialogs/ve.ui.ActionDialog.json in snapshot 9883566.

.js , not .json . Also, try looking for lib/ve/modules/ve/ui/dialogs/ve.ui.ActionDialog.js
**Coiby.Xu** wrote:

(In reply to Coiby from comment #6)
> This problem still exist on snapshot 9883566
> (https://extdist.wmflabs.org/dist/VisualEditor-REL1_23-9883566.tar.gz).

I just look through the patch, I can't find such file ve/ui/dialogs/ve.ui.ActionDialog.json in snapshot 9883566.
**Coiby.Xu** wrote:

This problem still exist on snapshot 9883566 (https://extdist.wmflabs.org/dist/VisualEditor-REL1_23-9883566.tar.gz).
Verified the fix in production (en.wiki)
Verified the fix on test2
Verified the fix on Betalabs
Change 139019 merged by jenkins-bot:
Re-enable apply button in action dialog on close

https://gerrit.wikimedia.org/r/139019
Change 139019 had a related patch set uploaded by Trevor Parscal:
Re-enable apply button in action dialog on close

https://gerrit.wikimedia.org/r/139019
To reproduce:
1. Edit an article in Arabic.
2. Move the caret forward using the arrow keys.

Observed: The Arabic letters next to which the caret moves are disconnected.

Expected: Moving the caret must only move the caret. It must not change the appearance of the text.

This works well in Firefox, but broken in Chrome.

--------------------------
**Version**: unspecified
**Severity**: normal
I cannot reproduce it in recent versions of Safari, Chrome and Firefox.
(In reply to Amir E. Aharoni from comment #3)
> Well, I reported it, and I only have Chrome on Linux, so I guess I meant
> "Chrome" or "Blink" and not "WebKit".

If it was present in Chrome at that point in time though, depending on whether it was a recent regression in Chrome, it likely still exists in WebKit/Safari (since Blink is a fork of WebKit).
Well, I reported it, and I only have Chrome on Linux, so I guess I meant "Chrome" or "Blink" and not "WebKit".
Be sure to also test in a recent version of Safari (which runs on WebKit).

Chrome hasn't been based on WebKit for almost 2 years now. It's using Chromium/Blink instead.
I am not sure what fixed it, but it works for me now in Chrome 36.0.1985.143 on Fedora 20.

Can this be tested automatically to prevent regression?
Screenshot

Steps to reproduce:

1.Open a page with VE in test2
2.Insert an image
3.Change the image type to Frameless/Basic
4.Now observe the checkbox for wrap is now unchecked
5.Try to check the checkbox

Observed Result:
It does not check the checkbox , but all the alignment tabs becomes visible .

This is happening in test2 only,

See the screenshot attached

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

**Attached**: {F14010}
Verified the fix in production (en.wiki)
Verified the fix in test2 running wmf9
Change 138122 merged by jenkins-bot:
Fixing issues in the alignment select in Media Edit dialog

https://gerrit.wikimedia.org/r/138122
This makes for a confusing bug history. :-)
Change 138122 had a related patch set uploaded by Jforrester:
Fixing issues in the alignment select in Media Edit dialog

https://gerrit.wikimedia.org/r/138122
The patchset that fixed the wrapping textbox was merged yesterday evening. That might explain the inconsistency; it's not in mw and test2 yet.

https://gerrit.wikimedia.org/r/#/c/137524/

If this isn't happening in beta labs, it should show the patchset fixed the bug. (Correct me if I'm wrong?)
Yes, it is also in MW.org , but not on Betalabs , not on en.wiki.

So, its in wmf 8, not on wmf 7 and wmf 9
This is happening in test2 and other wmf8 sites (like MW.org) but not wmf7s and Beta Labs, or just test2?
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Initially the image is Thumbnail-right
4.Now change the image type to Basic-Right-Border
5.Apply changes
6.Save the page
7.Reopen the image
8.Try to open the media settings dialog for the image

Observed Result:
Caption field is missing in the Media Settings dialog and cannot close the media settings dialog for the image.

The following error appears in the console:

TypeError: node is null appears in the console 

This is happening in en.wiki and betalabs but not for some reason in test2

See the screenshot attached

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

**Attached**: {F13991}
Verified the fix in en.wiki running wmf 8
OK, let's declare this one fixed in wmf8. :-)
This is no more reproducible in Betalabs and test2 , but only on en.wiki
I can't manage to reproduce this bug in master on both Firefox and Chrome.

Did this happen again?
Try the image on this page to reproduce: https://en.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/sandbox?veaction=edit
If the alignment of an image is not explicitly set, Parsoid does not output an alignment class for the resultant figure element. This can lead to the image not being aligned/floated.

We need to modify content.parsoid.less to apply the default right-alignment styling to all images and then override this in cases where the alignment is explicitly set.

--------------------------
**Version**: 1.24rc
**Severity**: normal
Seems like it must be fixed to me as of @Aklapper comment. @Gwicke correct me if wrong.
(In reply to Gabriel Wicke from comment #5)
> Right now this is deployed to group 1 wikis, but not yet to group 2. Lets
> keep this open until it has made its way there.

gwicke: So can this ticket be closed as FIXED?
Right now this is deployed to group 1 wikis, but not yet to group 2. Lets keep this open until it has made its way there.

Also see tracking bug 51245 for more Parsoid-specifc CSS tweaking.
*** Bug 66668 has been marked as a duplicate of this bug. ***
Change 138106 merged by jenkins-bot:
Make sure images are properly aligned in Mobile VisualEditor

https://gerrit.wikimedia.org/r/138106
Change 138106 had a related patch set uploaded by Kaldari:
Make sure images are properly aligned in Mobile VisualEditor

https://gerrit.wikimedia.org/r/138106
Change 138038 had a related patch set uploaded by Kaldari:
Make sure images that don't have an explicit alignment get aligned right

https://gerrit.wikimedia.org/r/138038
veaction is removed on save, but not vesection.

--------------------------
**Version**: unspecified
**Severity**: trivial
Change 145277 merged by jenkins-bot:
mw.ViewPageTarget: Remove vesection from URL on save/cancel

https://gerrit.wikimedia.org/r/145277
Change 145277 had a related patch set uploaded by Alex Monk:
Remove vesection from URL on save/cancel

https://gerrit.wikimedia.org/r/145277
Same for cancel.
Where the image was displayed before saving

Steps to reproduce:

1.  Open an article with a lot of images.  I started with https://en.wikipedia.org/w/index.php?title=Candy&oldid=611646505

2.  Pick a right-aligned image and switch it to left-aligned.

3.  Think, "That's weird:  it seems to have put it in the middle of a paragraph or something".

4.  Drag the image to a more appropriate location.

5.  Think, "Hey, I put it up there, so why is it all the way down there?"


NB that the diff here:  https://en.wikipedia.org/w/index.php?title=Candy&diff=611749324&oldid=611748715
also places the image in between the text and the invisible {{anchor}} template that ought to be attached to the text.

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

**Attached**: {F13861}
Created attachment 15579
Where the image was (correctly) displayed after saving

**Attached**: {F13862}
Similar to how we have ve.batchSplice for splice.apply

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 166799 merged by jenkins-bot:
Replacing push.apply in VE-MW with ve.batchPush from VE core

https://gerrit.wikimedia.org/r/166799
(In reply to Roan Kattouw from comment #5)
> (In reply to James Forrester from comment #4)
> > VE-MW patch coming or not needed?
> 
> There are two usages in VE-MW that do need to be cleaned up. Now that 166790
> was pulled through into VE-MW (a few minutes ago) that can be done.

Ugh somehow we missed the fact that there was a patch for this that was submitted three hours ago. We're both blind :S
(In reply to James Forrester from comment #4)
> VE-MW patch coming or not needed?

There are two usages in VE-MW that do need to be cleaned up. Now that 166790 was pulled through into VE-MW (a few minutes ago) that can be done.
VE-MW patch coming or not needed?
Change 166790 merged by jenkins-bot:
Replacing push.apply with newly created ve.batchPush in VE core

https://gerrit.wikimedia.org/r/166790
Change 166799 had a related patch set uploaded by SuchetaG:
Replacing push.apply in VE-MW with ve.batchPush from VE core

https://gerrit.wikimedia.org/r/166799
Change 166790 had a related patch set uploaded by SuchetaG:
Replacing push.apply with newly created ve.batchPush in VE core

https://gerrit.wikimedia.org/r/166790
This results in a quite bad outcome for the user, totally inexplicably. Instead we should just catch these errors and state them as invalid links (or have a different message?).

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=66135
Change 138016 merged by jenkins-bot:
Don't send invalid titles from the link inspector to the API

https://gerrit.wikimedia.org/r/138016
Change 138016 had a related patch set uploaded by Alex Monk:
Don't sent invalid titles from the link inspector to the API

https://gerrit.wikimedia.org/r/138016
Gerrit change 138016 should make it so that these show invalid title warnings. Though I haven't got CirrusSearch installed on my dev wiki so haven't tested it against the request_too_long Cirrus error.
OOJS(UI) has a build script which creates a dist folder with concatenated JS/CSS and copied images and i18n files. VE should have the same so that:

* We avoid IE9 stylesheet limits (31 files, 4096 rules)
* We can create an RTL stylesheet using Janus.
* We can embed small images inside the stylesheets.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 137367 merged by jenkins-bot:
Grunt: Create a distribution files for the ve module

https://gerrit.wikimedia.org/r/137367
Change 137367 had a related patch set uploaded by Jforrester:
Grunt: Create a single file stand-alone distribution for demos etc.

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

Steps to reprduce:

1.Open VE
2.Open any drop down box that comes up with a list of matching suggestions:for example:Link inspector, Category editor, template etc.
3.Type something in the text box
4.When the matching suggestions appear in the drop down box,observe that the first match which has a check mark next to it, is highlighted
5.Now mouse over that match in the drop down and 

Observed Result:
The selection loses it highlight

See the screenshot attached

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

**Attached**: {F13596}
Appears to have been fixed.
Not a shield issue.
Screenshot

Steps to reproduce:


1.Open VE
2.Go to Page options>Categories
3.Insert a new category:Ca, it appears under matching categories section according to the change on https://bugzilla.wikimedia.org/show_bug.cgi?id=49044
4.Select the first match Ca
4.Now again type Ca

Observed Result:
This time it appears under New Category section.


see the screenshot attached

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

**Attached**: {F13594}
Verified the fix in en.wiki running wmf 8
Fixed. That function is full of horrible things to do with following redirects (where a supposed category is actually a redirect to another category) and categories which are marked as hidden, mostly my fault and probably full of bugs if you want to poke around with that. Particularly in cases where we're supposed to exclude suggestions due to already having the suggestion on the list.
Change 137307 merged by jenkins-bot:
Check last existing category for whether or not we're trying to re-add it

https://gerrit.wikimedia.org/r/137307
Change 137307 had a related patch set uploaded by Alex Monk:
Check last existing category for whether or not we're trying to re-add it

https://gerrit.wikimedia.org/r/137307
This is a tracking bug for all shields/highlights/phantoms related issues.

--------------------------
**Version**: unspecified
**Severity**: normal
Tracking bug with no outstanding blockers. Closing.
This is overdue.

Various packages used by individual Grunt tasks used by local projects already throw warnings for the engine being unsupported.

These are not the packages for the legacy global tools in package.json in integration/jenkins.git:/tools aka slave-scripts, but the local package.json in projects like oojs, oojs-ui and VisualEditor.

As far as I can see these jobs seem to function fine, but it's really dangerous territory. The packages are explicitly indicated as requiring 0.10.x or higher (it's like executing a PHP application documented as requiring PHP 5.3 under PHP 5.1.x).

Both the upstream developer, their integration tests and the developers in our teams working locally already use Nodejs 0.10.x or higher, so this is waiting for something to fail.

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
Change 159224 merged by jenkins-bot:
job-templates: Move {name}-npm from Precise to Trusty

https://gerrit.wikimedia.org/r/159224
Change 159224 had a related patch set uploaded by Krinkle:
[WIP] job-templates: Move {name}-npm from Precise to Trusty

https://gerrit.wikimedia.org/r/159224
The Trusty slave is integration-slave1006-trusty.eqiad.wmflabs

The label remain unchanged:  UbuntuTrusty.


Marking this bug as fixed since npm/nodejs are available there. "Just" have to update the label in the job configuration.
We have a Trusty Jenkins slave in labs: integration-slave1004-trusty.eqiad.wmflabs

It has the label UbuntuTrusty.  The npm based jobs can be made to run on it by changing the node:  definition in Jenkins Job Builder configuration.

The node has:

$ npm --version
1.3.10
$ nodejs --version
v0.10.25
$
On contint slaves we have nodejs 0.8.2 which comes from apt.wikimedia.org.  AFAIK that is the version used on parsoid servers as well.

When I asked npm package to be backported with RT #6519 Faidon the plan is to migrate to Ubuntu Trusty (14.04) which ships 0.10.25.

wmflabs now provides a Trusty virtual image and we run npm jobs there.

So you can:
- build an instance using Trusty image
- attempt to apply the puppet manifest role::ci::slave::labs
- add the slave in Jenkins (we can pair that part)
- apply a label to the slave (ex: UbuntuTrusty) and tie some job to it


A culprit: anything running in production with nodejs 0.8 should probably be kept with nodejs 0.8 (parsoid parser tests come to mind) or we might end up missing incompatibility.  You can sync with Gabriel Wicke for that part.


Overall: yeah lets go!
This might be something that could be associated with Bug 52463:

If Search can't find an image—which happens fairly often with images that the user just uploaded—then please let the user specify the file name anyway.  Right now, if Search didn't happen to index your file yet, then you cannot add the image.  "Try again tomorrow, because maybe the search index will have caught up by then" is not an ideal user experience.

--------------------------
**Version**: unspecified
**Severity**: enhancement
I disagree with your comment about search results working fine now. I added some findings to https://bugzilla.wikimedia.org/show_bug.cgi?id=62917#c1 .
(In reply to Elitre from comment #1)
> Isn't this fixed?
> Right now I can paste the file name of the pic I want while adding a media.
> It looks like the only way to currently get to the desired image, because
> the search seems to be even worse than I remembered (try looking for a
> "European robin" image on en.wp, give up in frustration, paste
> File:Erithacus rubecula with cocked head.jpg in the dialog to put the image
> on the page after you found it on Commons).

Technically not done, but the search results generally work well enough.
Isn't this fixed?
Right now I can paste the file name of the pic I want while adding a media. It looks like the only way to currently get to the desired image, because the search seems to be even worse than I remembered (try looking for a "European robin" image on en.wp, give up in frustration, paste File:Erithacus rubecula with cocked head.jpg in the dialog to put the image on the page after you found it on Commons).
There should be links http://stats.wikimedia.org/EN/EditsRevertsIT.htm <-> http://ee-dashboard.wmflabs.org/dashboards/itwiki-metrics#reverts-graphs-tab and http://ee-dashboard.wmflabs.org/dashboards/itwiki-metrics#registrations-graphs-tab <-> http://ee-dashboard.wmflabs.org/dashboards/itwiki-metrics#registrations-graphs-tab .
Only applies to the ten Wikipedias having them: https://meta.wikimedia.org/wiki/Research:VisualEditor

--------------------------
**Version**: unspecified
**Severity**: enhancement
We're killing ee-dashboard (and have been for three years); let's not add more cruft and links to it.
>>! In T67994#1773128, @ezachte wrote:
> What's the best way to detect which language codes have new stats? (other than screen scraping https://meta.wikimedia.org/wiki/Research:VisualEditor)

I guess parsing the list of *wiki directories at https://datasets.wikimedia.org/public-datasets/
What's the best way to detect which language codes have new stats? (other than screen scraping https://meta.wikimedia.org/wiki/Research:VisualEditor)
Nemo: Are you still working on this, as this ticket is assigned to you?
Good idea Nemo. Erik -- thoughts?
This should not happen:
https://pt.wikipedia.org/w/index.php?diff=39042930

--------------------------
**Version**: unspecified
**Severity**: normal
Sample PDF

1) http://eo.wikipedia.beta.wmflabs.org/wiki/Headings_VisualEditor_Test
2) "Elŝuti kiel WMF PDF"

Result: a page with content coming from I have no idea where, see attachment.

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

**Attached**: {F13832}
I filled a bug to have an integration job that ensure puppet repo is updated before all-labs.dblist has a new wiki added. https://bugzilla.wikimedia.org/show_bug.cgi?id=68532
Change 148330 merged by Alexandros Kosiaris:
beta: update Parsoid localsettings entries

https://gerrit.wikimedia.org/r/148330
I have applied the puppet patch above on the beta cluster and restarted Parsoid that should fix the issue.
Change 148330 had a related patch set uploaded by Hashar:
beta: update Parsoid localsettings entries

https://gerrit.wikimedia.org/r/148330
Amended the add wiki documentation https://wikitech.wikimedia.org/w/index.php?title=Nova_Resource:Deployment-prep/Add_a_wiki&diff=120678&oldid=120568
Matt says PDF is using Parsoid has a backend.
C. Scott reproduces the issue with VisualEditor.

That means Parsoid is badly configured on beta and use the wrong backend.  Maybe it is fetching articles from production API?

And the winner is: Antoine! The list of wikis is hardcoded in a puppet configuration file http://git.wikimedia.org/blob/operations%2Fpuppet.git/c585887114/files%2Fmisc%2Fparsoid-localsettings-beta.js and the documentation to add a wiki is missing that step https://wikitech.wikimedia.org/wiki/Nova_Resource:Deployment-prep/Add_a_wiki
(In reply to C. Scott Ananian from comment #3)
> That is, the PDF renderer is misconfigured on eo.beta and is requesting
> pages from eowiki instead.  It is communicating its request by page id...
> with the surprising results you have noted.

cc hashar
The page you are trying to print is:
http://eo.wikipedia.beta.wmflabs.org/w/index.php?title=Headings_VisualEditor_Test&oldid=11

The content you are getting is:
https://eo.wikipedia.org/w/index.php?title=Headings_VisualEditor_Test&oldid=11

That is, the PDF renderer is misconfigured on eo.beta and is requesting pages from eowiki instead.  It is communicating its request by page id... with the surprising results you have noted.

But ultimately this is an eo.wiki misconfiguration.  Note that http://eo.wikipedia.beta.wmflabs.org/wiki/Headings_VisualEditor_Test?veaction=edit is also "surprising".
**mwalker** wrote:

It's not a problem per-se with the renderer; we're rendering what parsoid is giving us... I'm not sure what parsoid is doing.
That may have to do with FlaggedRevs (or with the wiki being empty): http://simple.wikipedia.beta.wmflabs.org/wiki/List_of_literary_terms worked
Screenshot

I dont see any option to insert gallery in the Insert medu suddenly.
Happening in betalabs and test2

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

**Attached**: {F13825}
Verified the fix in production
Yes, sorry, this was done intentionally in gerit 135965.
Steps to reproduce:

1.Click on the Edit/Edit Beta link beside a section heading of an article

Observed Result:
It places the cursor at the beginning of the document .

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to Tony Thomas from comment #11)
> This still happens. Check
> https://www.mediawiki.org/w/index.
> php?title=WYSIWYG_editor&veaction=edit&vesection=18 from chrome !

Eugh, there seems to be a regression here when clicked on the page; if you click that link it works fine… As such, rather than re-opening I've created bug 72919 for this. Thanks for the spot.
This still happens. Check https://www.mediawiki.org/w/index.php?title=WYSIWYG_editor&veaction=edit&vesection=18 from chrome !
Verified the fix in production. There is a different issue with cursor now though 
which has been reported in:
https://bugzilla.wikimedia.org/show_bug.cgi?id=67106
WFM; cache issue, it appears.
This is still happening on FireFox in Betalabs running from master.
Probably a deployment issue; fixed on MW.org and test2.
WFM in Firefox at http://en.wikipedia.beta.wmflabs.org/wiki/WikiNodes and on master
Not fixed for Firefox , there is no cursor at all pointing anywhere in the document after clicking on Edit link for section editing.
Verified the fix in Betalabs
Change 139677 merged by jenkins-bot:
Wait for onDocumentFocus to happen before setting section range

https://gerrit.wikimedia.org/r/139677
Change 139677 had a related patch set uploaded by Esanders:
Wait for onDocumentFocus to happen before setting section range

https://gerrit.wikimedia.org/r/139677
It seems like the dm.Surface's selection is getting set to the beginning of the section like it should be, but then when the ce/ui.Surface is intialized, the cursor isn't put there. It seems the surface isn't focused correctly on init anyway, and as soon as you interact with it SurfaceObserver will notice the cursor is at (1,1) and change the DM selection to that.
Steps to Reproduce:
1. Click on https://en.wikipedia.org/wiki/Sugar_candies?veaction=edit

2. Wonder why it is editing https://en.wikipedia.org/wiki/Sugar_candy (the target) instead of https://en.wikipedia.org/wiki/Sugar_candies (the redirect)?


Actual Results:  
It first redirects me to the target page, and then opens the target page for editing.  This makes it impossible to change the redirect to some other page, unless you modify the URL to say https://en.wikipedia.org/wiki/Sugar_candies?veaction=edit&redirect=no (either manually or by first visiting to the redirect page).


Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=65621
Change 138585 merged by jenkins-bot:
Suppress redirects if veaction=edit is requested

https://gerrit.wikimedia.org/r/138585
Change 138585 had a related patch set uploaded by Alex Monk:
Suppress redirects if veaction=edit is requested

https://gerrit.wikimedia.org/r/138585
https://en.wikipedia.org/w/index.php?title=Sugar_candies&redirect=no&veaction=edit works fine, but https://en.wikipedia.org/wiki/Sugar_candies?veaction=edit takes you to the target. Bah.
Steps to Reproduce:
1. Open a page that contains inline images at the start of a paragraph or list item.

2. Select the image, open the image dialog, and de-select the "Wrap text around" item.  The item will float right.

3. Change your mind.  Open the imge dialog again, and re-select the "Wrap text around" item.

Actual Results:  
The inline image appears to be, but isn't actually, on its own line.


Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: minor
Change 139269 merged by jenkins-bot:
Insert inline image inside list to the existing paragraph

https://gerrit.wikimedia.org/r/139269
Change 139064 abandoned by Mooeypoo:
Add inline images into existing paragraphs

Reason:
Moving this to the MWImageModel in a new commit

https://gerrit.wikimedia.org/r/139064
Change 139269 had a related patch set uploaded by Mooeypoo:
Don't create new paragraph for inline image inside list

https://gerrit.wikimedia.org/r/139269
Change 139064 had a related patch set uploaded by Mooeypoo:
Add inline images into existing paragraphs

https://gerrit.wikimedia.org/r/139064
(In reply to Gerrit Notification Bot from comment #8)
> Change 138114 had a related patch set uploaded by Catrope:
> [BREAKING CHANGE] Update VE core submodule to master (43a48cb) for window
> process cleanup
> 
> https://gerrit.wikimedia.org/r/138114

Whoops, not relevant; my mistake.
Change 138114 had a related patch set uploaded by Catrope:
[BREAKING CHANGE] Update VE core submodule to master (43a48cb) for window process cleanup

https://gerrit.wikimedia.org/r/138114
If we can have fixUpInsertion insert the image into an existing paragraph in the case of lists, that can be a good solution too.
Why does it always add a paragraph? Surely that's for fixUpInsertion to decide?
After further examination, this isn't an image bug per say, it is a list bug.

When the image is transformed from block to inline it goes back to being on its own paragraph (as it does always regardless of lists) letting the user decide where it should be.

The problem with the list, however, is that when the image goes back to being inline it is presented as if it is on its own line inside the list (with the text being on a different paragraph in the list item) 

However, the list itself won't allow for multi paragraphs and the resulting wikitext shows the image and followup text without the extra line space.

We could either add a <br> in between the image and the new text (in Parsoid?) or find a creative solution to make lists with multiline text behavior reflect that of the resulting wikitext in general.
Created attachment 15535
Before moving the image.  This is what it ought to look like after I move it back, too (perhaps minus the space between image and text).

**Attached**: {F13791}
Created attachment 15534
Inline image has been moved back, and displays on its own line

**Attached**: {F13789}
Look at what happens to the "laundromat" image at http://en.wikipedia.beta.wmflabs.org/w/index.php?diff=100058&oldid=100057

It was inline; I made it be a normal/non-inline image (perhaps "floating" isn't the right word?).  Then I moved it back.  When I moved it back, it displayed oddly—on its own line in the display, although it was inline when I saved.  

I'll upload some screenshots for you.
I'm a bit confused. You mentioned you need to de-select the floating value of the image, but inline images aren't supposed to have floating values at all (the checkbox should be unchecked) -- are you sure you're looking at inline images, or that you unchecked the value first?

Can you give me an example to look at? Thanks!
Screenshot

Steps to reproduce:

1.Insert an image of any type

2.Uncheck the wrap option

3.Check the wrap option again

4.Checking the wrap option automatically selects the "Right" as alignment again

5.Now click on one of the other alignment option:Centre/Left

Observed Result:

The alignment tab for "Right" is still selected, also the new one of step 5

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

**Attached**: {F13768}
Verified the fix in production (en.wiki)
Verified the fix in test2 running wmf9
Verified the fix in Betalabs
Change 138122 merged by jenkins-bot:
Fixing issues in the alignment select in Media Edit dialog

https://gerrit.wikimedia.org/r/138122
Change 138122 had a related patch set uploaded by Jforrester:
Fixing issues in the alignment select in Media Edit dialog

https://gerrit.wikimedia.org/r/138122
Change 137524 merged by jenkins-bot:
Fixing issues in the alignment select in Media Edit dialog

https://gerrit.wikimedia.org/r/137524
Change 137729 merged by jenkins-bot:
Allow programmatic selection of options while disabled

https://gerrit.wikimedia.org/r/137729
Change 137729 had a related patch set uploaded by Catrope:
Allow programmatic selection of options while disabled

https://gerrit.wikimedia.org/r/137729
Change 137524 had a related patch set uploaded by Mooeypoo:
[wip] Fixing issues in the alignment select in Media Edit dialog

https://gerrit.wikimedia.org/r/137524
Also, if you set the image type to Basic, the alignment checkbox will behave really strangely:

1. Set image type to basic
2. Checkbox is unticked, left/center/right toggle is disabled
3. Click checkbox. Checkbox is ticked and immediately unticked again, but left/center/right toggle is now enabled.
4. Click Left. Checkbox is ticked
5. Untick checkbox. Toggle is now disabled again

Go home alignment widget, you're drunk.
VisualEditor can determine if the link you are adding is a redirect or not (since Bug 50240), but it doesn't tell what the redirect page goes to. Just seeing "Redirect page" in the linking tool doesn't tell the user whether or not they're linking to the page they want to be linking to, so I think it should say "Redirect page to $1", where $1 is the destination of the redirect that's being linked.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This was fixed a while ago.
(In reply to James Forrester from comment #1)
> The idea is that it's generally a mistake to link to a redirect, and it's
> generally discouraged on most (all?) wikis. However, yes, this might be a
> nice improvement.

In that case, it'd be very helpful for editors for VisualEditor to show where the redirect goes to. If you're linking to a redirect and doing so is discouraged on that wiki, it's helpful to know what you should be linking to instead! :)
The idea is that it's generally a mistake to link to a redirect, and it's generally discouraged on most (all?) wikis. However, yes, this might be a nice improvement.
Take an image like [[File:Bigimage.png|border|right]], inspect it, and change it to a thumbnail. You get a thumbnail image of the exact same dimensions. But when you save, this serializes to [[File:Whatever.png|thumb]], which renders in read mode (and when you reopen it in VE) as a much smaller image, because it's using the default thumb size.

I would argue that, when you switch to thumb, it should use the default size for thumbs right then and there, but in any case, it's clear here that what's being displayed in CE is not an accurate reflection of what's actually going to happen when the user saves, and that's a problem.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 136981 merged by jenkins-bot:
Update image size after changing type

https://gerrit.wikimedia.org/r/136981
Change 136981 had a related patch set uploaded by Mooeypoo:
Update image size after changing type

https://gerrit.wikimedia.org/r/136981
See discussion at https://gerrit.wikimedia.org/r/#/c/135012/ . I think the SurfaceWidget constructor shouldn't use the global target, but instead take a config option telling it what kind of surface to construct, or take a surface object, or something.

--------------------------
**Version**: unspecified
**Severity**: enhancement
If the "description" field for TemplateData is empty, clicking the help/information button (an i with a circle around it) for the parameter produces a very skinny, empty box.  Nothing should be displayed when there is no description to display.

Alternatively, it's possible that some standard text could be put in the box, like "There is no description for this item".

--------------------------
**Version**: unspecified
**Severity**: minor
Change 136348 merged by jenkins-bot:
Trim description when working out whether or not we should disable the info button

https://gerrit.wikimedia.org/r/136348
Thanks!
Change 136348 had a related patch set uploaded by Alex Monk:
Trim description when working out whether or not we should disable the info button

https://gerrit.wikimedia.org/r/136348
Ah:  the TemplateData at https://en.wikipedia.org/wiki/Template:Infobox_UK_place/doc#TemplateData says,


"os_grid_reference": { "label": "os grid reference", "description": " ", "type": "string", "required": false },


If it said this instead,

"os_grid_reference": { "label": "os grid reference", "description": "", "type": "string", "required": false },

or perhaps this:

"os_grid_reference": { "label": "os grid reference", "type": "string", "required": false },

(if it's permitted to omit the description item), then this should go away.
The description is set as a single space for this parameter, so I think this is expected behaviour.
Open the infobox in https://en.wikipedia.org/wiki/Aberystwyth and look at the parameter "os_grid_reference".

The original report is at https://en.wikipedia.org/w/index.php?oldid=610519258#Info_on_template_fields
WhatamIdoing, can you perhaps give an example page where it does this?
If the parameter is required, I do get 'Field is required.' which should be shown still. But if it's not required, then the help/information button is disabled... No empty box.
I thought we had disabled these, but apparently not. Bah.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert a new image
3.Select the option "Centre" for wrapping the text around it
4.Select the type as "Frameless" or "Basic"
5.Save the page

Observed Result:

The image moves to the left side of the page 

See the screenshot attached

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

**Attached**: {F13568}
Verified the fix in production
Verified the fix in test2
Verified the fix on betalabs
Change 135729 merged by jenkins-bot:
Make sure <figure> has proper dimensions

https://gerrit.wikimedia.org/r/135729
Change 135729 had a related patch set uploaded by Mooeypoo:
Make sure <figure> has proper dimensions

https://gerrit.wikimedia.org/r/135729
This is a tracking bug for all the issues related with new Image model

--------------------------
**Version**: unspecified
**Severity**: normal
Wow. This looks nice.
On mediawiki.org in both Chrome and FF. 

Edit any page with VE, either logged in or not.  Note that you get the beta warning.

Save your edit. Edit the page again. 

See the beta warning again.

After one new VE edit, the user should never see the beta warning again.  This is controlled by setting a cookie in the browser.  No betawarning cookie is being set now.

--------------------------
**Version**: unspecified
**Severity**: major
Change 136124 merged by jenkins-bot:
Fix beta warning appearing for some users that it shouldn't.

https://gerrit.wikimedia.org/r/136124
Change 136122 merged by jenkins-bot:
Fix beta warning appearing for some users that it shouldn't.

https://gerrit.wikimedia.org/r/136122
Change 136122 had a related patch set uploaded by Alex Monk:
Fix beta warning appearing for some users that it shouldn't.

https://gerrit.wikimedia.org/r/136122
Change 136124 had a related patch set uploaded by Jforrester:
Fix beta warning appearing for some users that it shouldn't.

https://gerrit.wikimedia.org/r/136124
Change 136120 merged by jenkins-bot:
Fix beta warning appearing for some users that it shouldn't.

https://gerrit.wikimedia.org/r/136120
Change 136120 had a related patch set uploaded by Alex Monk:
Fix beta warning appearing for some users that it shouldn't.

https://gerrit.wikimedia.org/r/136120
Also getting reports of this on enwiki etc. – not great.
Yeah, this is a worrying regression, possibly due to the bug 55551 changes.

(Saw breakage for Rummana on her account on MW.org, so this is probably a timing issue related to when the accounts hit a wiki before the code changed or similar?)
Actually, this is seen on test2 only so far.
*** Bug 65710 has been marked as a duplicate of this bug. ***
/me waves with my volunteer ca.wiki tech ambassador hat on.

The Catalan Wikipedia community wants to try the TemplateData editor. Can you enable it, please? Discussion (in Catalan) at

https://ca.wikipedia.org/wiki/Viquip%C3%A8dia:La_taverna/Ajuda#VisualEditor_global_newsletter.E2.80.94May_2014

--------------------------
**Version**: unspecified
**Severity**: enhancement
This is now live.
Change 135580 merged by jenkins-bot:
Enable TemplateData GUI on Catalan Wikipedia

https://gerrit.wikimedia.org/r/135580
Change 135580 had a related patch set uploaded by Jforrester:
Enable TemplateData GUI on Catalan Wikipedia

https://gerrit.wikimedia.org/r/135580
--------------------------
**Version**: unspecified
**Severity**: normal
Change 190022 merged by jenkins-bot:
Simplify slug behaviour

[[https://gerrit.wikimedia.org/r/190022]]
Change 190022 had a related patch set uploaded (by Esanders):
Simplify slug behaviour

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

#patch-for-review
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Make it Frameless-right or Basic-Right
4.Hover over the image after that

Observed Result:
The area around the image remains highlighted but not the image itself

See the screenshot attached
Environment: Betalabs

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

**Attached**: {F13899}
Verified the fix in production
Verified the fix in test2
Change 140747 merged by Catrope:
Fix fragment after inserting an image node

https://gerrit.wikimedia.org/r/140747
Change 140747 had a related patch set uploaded by Jforrester:
Fix fragment after inserting an image node

https://gerrit.wikimedia.org/r/140747
Change 140687 merged by jenkins-bot:
Fix fragment after inserting an image node

https://gerrit.wikimedia.org/r/140687
Change 140687 had a related patch set uploaded by Esanders:
Fix fragment after inserting an image node

https://gerrit.wikimedia.org/r/140687
Change 139824 merged by jenkins-bot:
Fix selection after inserting nodes

https://gerrit.wikimedia.org/r/139824
Change 137040 merged by jenkins-bot:
[BREAKING CHANGE (ish)] Track original data position in insertion operations

https://gerrit.wikimedia.org/r/137040
Change 139824 had a related patch set uploaded by Esanders:
Fix selection after inserting nodes

https://gerrit.wikimedia.org/r/139824
Change 137040 had a related patch set uploaded by Esanders:
[BREAKING CHANGE (ish)] Track orignal data position in insertion operations

https://gerrit.wikimedia.org/r/137040
*** This bug has been marked as a duplicate of bug 65706 ***
Selection range issue, not a shield issue.
Corrected steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Make it Frameless-Left or Basic-Left
4.Now uncheck the wrapping option.
5.Hover over the image after that.

Observed Result:
The area around the image remains highlighted but not the image itself.
--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production
Verified the fix in test2
Change 140747 merged by Catrope:
Fix fragment after inserting an image node

https://gerrit.wikimedia.org/r/140747
Change 140747 had a related patch set uploaded by Jforrester:
Fix fragment after inserting an image node

https://gerrit.wikimedia.org/r/140747
Change 140687 merged by jenkins-bot:
Fix fragment after inserting an image node

https://gerrit.wikimedia.org/r/140687
Change 140687 had a related patch set uploaded by Esanders:
Fix fragment after inserting an image node

https://gerrit.wikimedia.org/r/140687
Change 139824 merged by jenkins-bot:
Fix selection after inserting nodes

https://gerrit.wikimedia.org/r/139824
DM selection issue, not a shield bug.
Change 139824 had a related patch set uploaded by Esanders:
Fix selection after inserting nodes

https://gerrit.wikimedia.org/r/139824
*** Bug 65716 has been marked as a duplicate of this bug. ***
The previous line also gets highlighted while adding an image.
This is happening in Chrome only not in Firefox
Steps to reproduce:

1.Open a page with VE
2.Go to the end of the page 
3.Insert a reference list

Observed Result:
It is highlighting the previous line while adding the reference list.
This behavior has been observed as of 23rd may
"Translation unit markers in unexpected position." can just go die in Hell. Gah.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also:** {T58451}, {T73730}, {T50891}
FWIW [[https://www.mediawiki.org/w/index.php?title=Manual:Developing_extensions&diff=2696555&oldid=2696554|this]] worked in the end.
>>! In T67653#3359087, @jeblad wrote:
> With WikitextEditor this has become critical for editing translated pages.

Can you give me some more details on what the problem is, and what the steps to reproduce are?
With WikitextEditor this has become critical for editing translated pages.
(In reply to Nemo from comment #5)
> I guess it can also be put that way. :) Does this new summary reflect the
> aim?

Not really. Putting a hack into VisualEditor to cope with another extension's model is not good. Either way, I don't care enough. :-)
I guess it can also be put that way. :) Does this new summary reflect the aim?
(In reply to Nemo from comment #3)
> (In reply to James Forrester from comment #2)
> > I don't know. You're the Translate extension expert. :-)
> 
> Ok. That error probably just means that some newline was inserted in the
> wrong place before or after <!--T:1--> and similar, IIRC.
> 
> So if you don't have a specific intention here I guess this is one bug of
> the series "make VisualEditor not touch Translate stuff which otherwise
> breaks" (bug 56451, bug 71730), and is probably blocked on bug 48891 as its
> friends.

No, this is not a parser bug.

It's just a "VE should react to stupidly vague error responses by killing stupid comments in stupid places used by a stupid extension to do critical functions that should be done better" bug. :-)
(In reply to James Forrester from comment #2)
> I don't know. You're the Translate extension expert. :-)

Ok. That error probably just means that some newline was inserted in the wrong place before or after <!--T:1--> and similar, IIRC.

So if you don't have a specific intention here I guess this is one bug of the series "make VisualEditor not touch Translate stuff which otherwise breaks" (bug 56451, bug 71730), and is probably blocked on bug 48891 as its friends.
(In reply to Nemo from comment #1)
> (In reply to James Forrester from comment #0)
> > "Translation unit markers in unexpected position." can just go die in Hell.
> > Gah.
> 
> Is this bug related to other bugs?

I don't know. You're the Translate extension expert. :-)
(In reply to James Forrester from comment #0)
> "Translation unit markers in unexpected position." can just go die in Hell.
> Gah.

Is this bug related to other bugs?
Sometimes editing a page in VisualEditor is rearranging categories so that they always end up on a single line, which is inconvenient for people looking at the wikitext source later.

See https://fr.wikipedia.org/w/index.php?title=Jean-Baptiste_Vallière&diff=prev&oldid=104017086

--------------------------
**Version**: unspecified
**Severity**: normal
Other example that also displays other problems (extra characters at the beginning, and strange characters in the text ☃☃)
https://fr.wikipedia.org/w/index.php?title=Absolom_2022&diff=104059827&oldid=96660949
Other example
https://fr.wikipedia.org/w/index.php?title=Mines_de_Ranci%C3%A9&diff=104031209&oldid=97118583
We only use the default newline spacing if the categories are actually new content. So if VE is just removing the newlines, but leaves the categories, a result as in the link is to be expected.

Round-tripping works fine with selser:

http://parsoid-lb.eqiad.wikimedia.org/_rtselser/frwiki/Jean-Baptiste_Valli%C3%A8re?oldid=95815820

Even without selser the newlines are preserved:

http://parsoid-lb.eqiad.wikimedia.org/_rt/frwiki/Jean-Baptiste_Valli%C3%A8re?oldid=95815820

This makes it very likely that this is in fact VE removing newlines.
Parsoid bug? We hopefully aren't dirtying these, but even if we are, Parsoid's default whitespace should insert a \n before each of these anyway…
Intention:
Mark almost an entire page with language (en) and direction (LTR).

Steps to Reproduce:
1.  Open the page and select almost all of the content.
 
2.  Insert > Language

3.  Set the language to English and the direction to LTR.

Actual Results:  
Only a small fraction of the page was marked with span tags.  See https://office.wikimedia.org/w/index.php?diff=112247&oldid=112246

Expected Results:  
I wanted this:

<span lang="en" dir="ltr">
Div box 
Image
Text
Image
Some text
End of div box
Lots and lots and lots of text
</span>

I got this:

Div box 
Image
<span lang="en" dir="ltr">Text</span>
Image
<span lang="en" dir="ltr">Text</span>Some te</span>xt
End of div box
Lots and lots and lots of text


Reproducible: Always

This was exactly repeatable on this page:  the last span tag always ended in the middle of the same word.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://office.wikimedia.org/w/index.php?diff=112247&oldid=112246
(In reply to WhatamIdoing from comment #2)
> When I've selected the whole page, I'd rather have the whole page marked
> with a single pair of tags, even if defining the block content as having a
> "language" is meaningless.

Tough. That's not how HTML works. :-)
When I've selected the whole page, I'd rather have the whole page marked with a single pair of tags, even if defining the block content as having a "language" is meaningless.
The language tool only covers text, not block content, so that's expected.

The not-getting-to-the-end-of-the-selection thing sounds like an odd data model bug.
When you create a redirect with wikitext, it adds redirect=no.

However, VisualEditor does not (just venotify=created), so you end up going to the target.  Besides being inconsistent, that means it's one extra step to check WhatLinksHere, etc.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=65926
Change 138631 merged by jenkins-bot:
Add redirect=no to new URL when creating a new page as a redirect

https://gerrit.wikimedia.org/r/138631
Change 138631 had a related patch set uploaded by Alex Monk:
Add redirect=no to new URL when creating a new page as a redirect

https://gerrit.wikimedia.org/r/138631
Seems to only break if you're creating a new page as a redirect. If you're replacing an existing one with a redirect, it's fine (With the exception of the 'Redirect page' text which it should be adding to #contentSub).
Ick. We shouldn't actually be refreshing the page to the extent that a redirect is triggered, however; did we change this?
Intention:
Copy a reference's contents (not including ref tags).

Steps to Reproduce:
1. Open a page in Safari.  Add a citation using the Cite tool.

2. Open the new reference in the Reference dialog via Insert > Reference.

3. Select the contents, and press Command-X to cut it.

Actual Results:  
Nothing happens.  The template is not cut.

Expected Results:  
It should be possible to copy and paste citation templates, so that you can modify them for other citations or display them on the page outside of <ref> tags.  

Reproducible: Always

This bug cannot be reproduced in Firefox.

--------------------------
**Version**: unspecified
**Severity**: normal
See attached screenshot.  On the screenshot you can see that the citation template is selected and that Edit > Cut is grayed out.  

Selecting the template and pressing Command-X does nothing, no matter how many times I press it.  The cite journal template remains stubbornly in place, despite trying to cut the entire contents repeatedly.  If my problem were with pasting, then I'd have an empty box and be complaining that I'd lost work.  Instead, I have a full box and I'm complaining that it is not possible to CUT the contents out of this ref (in Safari 6.1.2, at least).
Created attachment 17008
Screenshot showing grayed-out "Cut" item in Edit menu

**Attached**: {F13603}
It's possible to cut/copy things from references, but you can't then paste them back into VE once you shut the dialog – this is bug 51725.

*** This bug has been marked as a duplicate of bug 51725 ***
Now I can reproduce this in Firefox:


1.  Open [[Railway company]].

2.  Discover that the allegedly reliable source is a wikilink to another article.

3.  Open ref dialog.

4.  Select entire contents (one link).

5.  Be confused about why nothing appears to happen.


I can copy the link, and I can replace it with garbage, but I cannot make it be empty.  Perhaps this is intentional?  In which case, how can I first remove the unwanted contents, and then add in good contents?
It's possible to have a category bubble in the category editor for a category that doesn't have a description page. It would be useful to see that it doesn't exist.

In the source editor this can be achieved while editing by doing a preview and seeing that the link at the bottom is red, so this is a bit of a regression.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49044
Verified the fix in production
Verified the fix in Betalabs.
Change 171464 merged by jenkins-bot:
Show category items as red if they don't have description pages

https://gerrit.wikimedia.org/r/171464
Change 171464 had a related patch set uploaded by Alex Monk:
Show category items as red if they don't have description pages

https://gerrit.wikimedia.org/r/171464
*** Bug 69507 has been marked as a duplicate of this bug. ***
Right now, the way that the save button is disabled when you click it is that MWSaveDialog listens to the button's click event, in response to that it fires the 'save' event, ArticleTarget gets that event, reaches into the save dialog and disables the button.

This is only one of many insane things about the totally dysfunctional MWSaveDialog - ArticleTarget relationship; the whole way these two interact should be refactored.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 140868 abandoned by Alex Monk:
Move some stuff from ViewPageTarget to MWSaveDialog

https://gerrit.wikimedia.org/r/140868
Change 140868 had a related patch set uploaded by Alex Monk:
Move some stuff from ViewPageTarget to MWSaveDialog

https://gerrit.wikimedia.org/r/140868
Yeah, that patch wasn't really intended to fully fix this.
Mostly fixed in gerrit 135945 but Roan said there are still some outstanding issues.
This'd be lovely to get fixed properly. Alex, could you take a look at this at some point? I imagine Roan'd love to be involved in the refactor, though. :-)
--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=64711
ve-ui-mwParameterPage-actions have tabindex=-1, which makes them unreachable by keyboard, the same for the "Add parameter" button.


The text area of the fields is missing the 'required' attribute for fields that are required.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=65473
https://bugzilla.wikimedia.org/show_bug.cgi?id=62337
*** Bug 63014 has been marked as a duplicate of this bug. ***
Change 137152 merged by jenkins-bot:
Add tabindexes to template editor and required attribute where appropriate

https://gerrit.wikimedia.org/r/137152
Change 137152 had a related patch set uploaded by Alex Monk:
Add tabindexes to template editor and required attribute where appropriate

https://gerrit.wikimedia.org/r/137152
When I access
https://pt.wikipedia.org/w/index.php?title=Usuário(a):Helder.wiki/Testes&oldid=38949256&veaction=edit&debug=1
with an empty cache on Firefox 29, it takes at 5+ seconds until I see any progress bar. Sometimes this makes me click in the edit link again because it seems not to be loading at all...

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 167736 merged by jenkins-bot:
Make spinner appear immediately when clicking edit

https://gerrit.wikimedia.org/r/167736
Change 167736 had a related patch set uploaded by SuchetaG:
Fixing the delay in the spinner to appear and the change in the URL on clicking edit

https://gerrit.wikimedia.org/r/167736
**sucheta.ghoshal** wrote:

The change in the URL with veaction=edit happens late, too. Spinner appears at about the same time as that change happnes.
There are a few issues with how things are initialized. The delay until the loading animation appears is only a symptom of a larger problem: there are multiple requests being made, blocked on each other, that should really be combined.
Screenshot

Steps to reproduce:

1.Open a page with Mobile VE which has some content in it
2.Delete all the content
3.Click on the Link inspector icon from the toolbar

Observed Result:

User gets stuck at this point , cannot close the link inspector dialog anymore by tapping on "<" or trash icon

Test Environment: https://en.m.wikipedia.org/
Device: iPad Mini

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

**Attached**: {F13828}
Verified the fix in production
Verified the fix in test2
Yes, not getting this issue in Betalabs.Marking it as Fixed.
Can this be re-checked? May have been fixed.
Reproducible: Didn't try

Tables like the ones seen at https://en.wikipedia.org/w/index.php?oldid=608813235#Early_years don't display with the correct row height when editing, because VisualEditor assumes that table cells' paragraphs should be styled like other paragraphs.

--------------------------
**Version**: unspecified
**Severity**: trivial
Change 141923 merged by jenkins-bot:
Add missing TableCell CSS file and Vector-specific rule

https://gerrit.wikimedia.org/r/141923
Change 141923 had a related patch set uploaded by Esanders:
Add missing TableCell CSS file and Vector-specific rule

https://gerrit.wikimedia.org/r/141923
We should probably do a follow-up tech debt bug about margins for non-paragraphs in table cells…
Change 139676 merged by jenkins-bot:
Remove margins from paragraphs inside table cells

https://gerrit.wikimedia.org/r/139676
Change 139676 had a related patch set uploaded by Esanders:
Remove margins from paragraphs inside table cells

https://gerrit.wikimedia.org/r/139676
https://gerrit.wikimedia.org/r/#/c/139676/
Screenshot

I am not getting the VisualEditor for mobile even after enabling it through Beta-Experimental mode while trying to edit this page:https://en.m.wikipedia.org/wiki/User:RYasmeen_(WMF)/sandbox

see the screenshot attached:

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

**Attached**: {F13822}
Intentional behaviour.
VisualEditor is only loaded when you are on a screen with a resolution of 768px width / height. Thus this will currently not work on iPhone 4S as it is not a tablet...
I experienced a huge inconsistency around the precision of tapping action for Mobile VE in all kind of iOS devices I have tried so far.The devices I observed this issue are: iPad 2 with iOS 7.1.1 , iPhone 4S with iOS 7.1.1 and iPad Mini with iOS 7.0.6

Some times , to open the VE and to select a menu options like Settings/Random/Username , it literally takes me to tap twice.

--------------------------
**Version**: unspecified
**Severity**: normal
Seems to work for me well enough, now. Tested on Beta Cluster using iOS Safari 8.0 on an iPad.
Needs re-testing.
Screenshot

Steps to reproduce:

1.Open a page with Mobile
2.Attempt to edit it
3.While keyboard is still appearing tap on the "X" button on the top left of VE or just tap on the browser back button.

Observed Result:
User is redirected to Readmode but the keyboard is still appearing .

See the screenshot attached

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

**Attached**: {F13816}
Seems to work for me now. Tested on Beta Cluster using iOS Safari 8.0 on an iPad.
Yes, still happens on taping on browser back button
Is this still an issue?
Correction: Do not edit the page on step2 just tap on CE to place the cursor and cross the VE out to reproduce.
Something like `http://example.com{{deadlink}}` cannot be properly edited in VisualEditor. It should be processed as two pieces:  one external link that is followed immediately by one template.  Instead, it is presented as the text "http://example.com[]", linked to `http://example.com[]`.
URLs followed by templates are still broken. However, they now seem to be broken differently: they display as regular links with broken syntax, rather than as alienated nodes.
Supposedly the reason for this is that http://example.com{{echo|/index.php}} would produce a link to http://example.com/index.php , rather than a link followed by text. But it depends on what the template outputs; if the output starts with a space or a newline this won't happen. Maybe Parsoid is being a bit too trigger-happy with mw:ExpandedAttrs in the second case?
Caused by mw:ExpandedAttrs from Parsoid.

Input:

| http://example.com{{deadlink}}

Output:

<a data-mw="…" typeof="mw:ExpandedAttrs" about="#mwt2" rel="mw:ExtLink" href="http://example.com" data-parsoid="…">http://example.com</a>
* https://www.mediawiki.org/w/index.php?diff=prev&oldid=1002914

I performed the edit by highlighting the digit '3' with my mouse, and pressing the alphanumerical key '5' on my keyboard; my intention was only to change the date, but VE also removed the <noinclude> tag (I re-added it in a subsequent edit).

Filing this bug after a request from James on IRC.

--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://www.mediawiki.org/w/index.php?title=MediaWiki_1.24/Roadmap&diff=prev&oldid=1002914
This looks like a temporary Parsoid issue; marking as WORKSFORME as we can't reproduce.
Can't reproduce in Firefox or Chrome.
Screenshot

Steps to reproduce:


1.Open a page with Mobile VE which has some content in it
2.Scroll a bit down 
3.Tap on any text and then keep on tapping on Return until it deletes the whole line just after the toolbar 

Observed Result:
After deleting the line just after where the toolbar starts it moves over the toolbar

See the screenshot attached

Test Environment: https://en.m.wikipedia.org/
Device: iPad Mini

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

**Attached**: {F13595}
Seems to work for me now. Tested on Beta Cluster using iOS Safari 8.0 on an iPad.
Needs re-testing.
Maybe will go away if we use a different method for a sticky header.
This is not an iOS specific issue here, happens in Nexus 7 as well sadly.
A more generic way of doing https://gerrit.wikimedia.org/r/133379

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 133395 merged by jenkins-bot:
Hide PageTriage curation toolbar when VE activates

https://gerrit.wikimedia.org/r/133395
Change 133394 merged by jenkins-bot:
Fire hook when VE activates/deactivates

https://gerrit.wikimedia.org/r/133394
Change 133395 had a related patch set uploaded by Alex Monk:
Hide PageTriage curation toolbar when VE activates

https://gerrit.wikimedia.org/r/133395
Change 133394 had a related patch set uploaded by Alex Monk:
Fire hook when VE activates/deactivates

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

Steps to reproduce:

1.Open a page with VE
2.Make some edit
3.Click on Save Page on the Save page dialog
4.While loading bar is in progress click on "Review your changes"


Observed Result:
It opens up the Review section while the loading bar is still showing up above and below the dialog.

Environment:Betalabs,test2 and production

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

**Attached**: {F13552}
Change 171474 merged by jenkins-bot:
Disable review button while save dialog is pending

https://gerrit.wikimedia.org/r/171474
Change 171474 had a related patch set uploaded by Alex Monk:
Disable review button while save dialog is pending

https://gerrit.wikimedia.org/r/171474
It doesn't do anything while the dialog is pending now. Should we be marking it as disabled though?
*** Bug 65485 has been marked as a duplicate of this bug. ***
Add an item to the tab area with class "collapsible" and display none applied.

Then make the window narrow (so it moves into the vector menu), and expand again (so it becomes a tab again).

The item is now visible when it was previously hidden.

vector.collapsibleTabs.js should not override this state.

--------------------------
**Version**: unspecified
**Severity**: normal
I'm not sure that this is the right call, but I also don't really care. :-)
Bug 65292 was fixed in a different way, so let's close this.
I am tempted to WONTFIX this. This bug is actually a proposed way of solving bug 65292 in VisualEditor and not a real bug in core. If a tab is supposed to be treated as not being there, then it just should be removed from the DOM (and bug 65292 has a pending patch that does this).
Steps to Reproduce:
1.  Open a Wikipedia article in the article namespace. 

2.  Resize the window to a very small size so that the buttons overlap to the next line. 

3.  Resize the window to the original size and see that the "Edit beta" button shows up, which was previously not there.

4.  Click on the new button to open VisualEditor.

Actual Results:  
Clicking the button produces an error message:

Error loading data from server: novenamespace: VisualEditor is not enabled in namespace 4. Would you like to retry?

Clicking OK closes this dialog, but immediately pops up another one of the same kind. 

Expected Results:  
That the button wouldn't ever be visible, and that if it were, that it wouldn't give an error message about namespace 4.

Reproducible: Didn't try

--------------------------
**Version**: unspecified
**Severity**: minor
Change 133851 merged by jenkins-bot:
Remove edit tab from the DOM if it's hidden

https://gerrit.wikimedia.org/r/133851
Change 133851 had a related patch set uploaded by Alex Monk:
Remove edit tab from the DOM if it's hidden

https://gerrit.wikimedia.org/r/133851
Rephrasing bug title as bug is broader in scope.

The window resize bug is actually caused by a logic error in Vector in MediaWiki core (filed as bug 65294).

So it affects all browsers, and can bypass any soft restriction that we evaluate in javascript (browser support, namespace, content model, user preference etc.).

Because it's basically just always made to be visible regardless of why it was hidden, when doing the resize handle trick from minimum width back out.
Steps to Reproduce:
1. Open a long page in VisualEditor.  Press Ctrl-+ several times, until the toolbar is too wide to fit on a single line.

2. Press PgDn (the page down key).



Actual Results:  
The wrong number of lines is moved, so that a couple of lines is never seen.


Reproducible: Didn't try

--------------------------
**Version**: unspecified
**Severity**: minor
One more thing ... I just hit Ctrl-+ a second time (my eyes are tired) and ... holy crap, the menu bar takes 3 lines, almost half the screen.

Dan
Please see https://en.wikipedia.org/wiki/File:Screenshot1_of_Lamb_article_in_VE,_monobook,_Firefox.png (Windows 7, Firefox 28.0), and after I hit "Pgdn" once, https://en.wikipedia.org/wiki/File:Screenshot2_of_Lamb_article_in_VE,_monobook,_Firefox.png. Note that the 2-line VE toolbar takes up enough space that 3 lines from [[Lamb]] are missing between the 2 screens, which makes "Pgdn" (and anything else that does the same thing) useless for reading the whole article. Also, the VE toolbar appears to be a lot bigger than it needs to be, both because it takes up 2 lines (if the user has clicked Ctrl-+ at least once, and many do), and because the icons and letters are much larger than they need to be (that is, much larger than the text font).

I'm suggesting that this bug is particularly important because this will be your target viewer's first impression ... in the first few seconds they're exposed to VE, they'll be seeing a much smaller window to edit in (the WP menus including the 2-line VE toolbar take up a quarter of the vertical space), and that paging down is useless for reading the article. Some people make snap judgments based on first impressions.

Dan
https://en.wikipedia.org/wiki/MediaWiki:Visualeditor-cite-tool-definition.json says:

   { "name": "news", "icon": "ref-cite-news", "template": "Cite news" },


Shouldn't the "name" part determine the name that's showing in the list?

The actual tool says "newspaper" instead of "news".  I want it to say "news" (because the news might come out of a news-magazine or a news-TV show or a news-website, not just a news-paper).

--------------------------
**Version**: unspecified
**Severity**: trivial
Change 133841 merged by jenkins-bot:
Change Cite > Newspaper to Cite > News

https://gerrit.wikimedia.org/r/133841
Change 133839 abandoned by Catrope:
Change label for news citation tool from "Newspaper" to "News"

Reason:
Abandoning in favor of https://gerrit.wikimedia.org/r/#/c/133841/

https://gerrit.wikimedia.org/r/133839
Change 133841 had a related patch set uploaded by Catrope:
Change Cite > Newspaper to Cite > News

https://gerrit.wikimedia.org/r/133841
(In reply to Gerrit Notification Bot from comment #2)
> Change 133839 had a related patch set uploaded by Catrope:
> Change label for news citation tool from "Newspaper" to "News"
> 
> https://gerrit.wikimedia.org/r/133839

All done, just pending a yay/nay from James (since I don't wanna go around changing messages without talking to anyone).

Also, sorry for the long turnaround on this, most of the team was at the hackathon in Zürich last weekend and some people took some vacation time around that as well.
Change 133839 had a related patch set uploaded by Catrope:
Change label for news citation tool from "Newspaper" to "News"

https://gerrit.wikimedia.org/r/133839
(In reply to WhatamIdoing from comment #0)
> https://en.wikipedia.org/wiki/MediaWiki:Visualeditor-cite-tool-definition.
> json says:
> 
>    { "name": "news", "icon": "ref-cite-news", "template": "Cite news" },
> 
> 
> Shouldn't the "name" part determine the name that's showing in the list?
> 
Not exactly, but close. It means that the name is taken from [[MediaWiki:Visualeditor-cite-tool-name-news]]. The default translation of that message in English is "Newspaper", but we could change that to say "News" in the software. You could also edit the MediaWiki: page locally but I'd recommend changing it in the software instead to prevent enwiki diverging from the rest of the universe.
Just don't.

* https://pl.wikipedia.org/w/index.php?diff=39429954&oldid=38515622

--------------------------
**Version**: unspecified
**Severity**: major
Maybe this was invalid. There is a "Sort this page by default as" option in the Categories section of the settings dialog, so now it's pretty obvious how one can change or remove that option, but I don't know when this was introduced.
Can't reproduce this bug anymore.
(To clarify, obviously categories can be removed from an article anytime, but from the diffs it looks like the user has selected and deleted a huge part of text at the bottom of the article, and it doesn't seem that he was there to vandalize it - hence, could be a bug.)
Here https://fr.wikipedia.org/w/index.php?title=Henri_D%C3%A8s&diff=105153393&oldid=104979477 and here https://fr.wikipedia.org/w/index.php?title=Henri_D%C3%A8s&diff=next&oldid=105153476 the categories are gone as well. (Wasn't that impossible to do, as per bug 61858?)
e.g. in wiktionary semantic classes such as "distinct feature," "usage example," "syllables," "pronunciation," etc.

These would likely be more important for this community than the default preformatted styles used on wikipedia.

--------------------------
**Version**: unspecified
**Severity**: enhancement
formatting bar
To confirm, is this is asking for a tool to wrap selections in templates?
It would be good if the addition of the new text styles was as simple as eg. adding of new gadget definitions (instead of having to code long javascript code to add new items in the list)

example:

* usage example | <span class="usageexample">{{{1|usage example}}}</span>
* definition | <dfn class="definition">{{{1|definition}}}</dfn>

etc.
This would likely be a site admin task to add the site specific styles.
Please enable VisualEditor as a Beta Feature on Wikimedia Commons, not enabled by default.

Beta features are (as far as I know) completely harmless so I do not think a community discussion is necessary but I would be happy to start one if necessary.

I will post a heads-up on this on Wikimedia Commons village pump.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Now live.
Change 132409 merged by jenkins-bot:
Enable VisualEditor as a Beta Feature on Commons

https://gerrit.wikimedia.org/r/132409
(In reply to Jean-Fred from comment #2)
> James told me that by default VE will be active for File, Category, User and
> main (gallery) namespaces.
> 
> Please enable it for Creator: and Institution: too, as pages in these NS use
> one template, respectively {{Creator}} & {{Institution}}. With TemplateData
> on them it will be very convenient to use VE to edit them.

Prepared.
James told me that by default VE will be active for File, Category, User and main (gallery) namespaces.

Please enable it for Creator: and Institution: too, as pages in these NS use one template, respectively {{Creator}} & {{Institution}}. With TemplateData on them it will be very convenient to use VE to edit them.
Change 132409 had a related patch set uploaded by Jforrester:
Enable VisualEditor as a Beta Feature on Commons

https://gerrit.wikimedia.org/r/132409
Build a grunt task out of https://github.com/trevorparscal/cssjanus ?

--------------------------
**Version**: unspecified
**Severity**: minor
Change 134802 merged by jenkins-bot:
Use CSSJanus to generate RTL stylesheets

https://gerrit.wikimedia.org/r/134802
Change 134802 had a related patch set uploaded by Esanders:
Use CSS Janus to generate RTL stylesheets

https://gerrit.wikimedia.org/r/134802
The concept of a block slug from a UX POV is great, but why do we need to keep them out of the DM? It seems to be the source of far too many getOffset hacks, as you can put your cursor somewhere that doesn't have a real offset (model-view inconsistency). We already have a way of marking a paragraph as to-be-ignored-by-the-converter-if-empty ({internal:'empty'}), so let's just put them in the DM, and throw them away at convert time if they're empty.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 135131 merged by jenkins-bot:
Stage slugs

https://gerrit.wikimedia.org/r/135131
Change 135131 had a related patch set uploaded by Catrope:
Stage slugs

https://gerrit.wikimedia.org/r/135131
Change 135131 had a related patch set uploaded by Jforrester:
Stage slugs

https://gerrit.wikimedia.org/r/135131
Also if we do this we can force the SurfaceObserver to always move cursor positions to content offsets (except for FocusableNodes) which should prevent bugs like Firefox select-all giving you [0,data.length].
page title in media search box

on any page in beta labs e.g. http://en.wikipedia.beta.wmflabs.org/wiki/0.8782466280521993?veaction=edit

on first page load, select some text in the page, and then open Media

* page title may be in Media search box. see screen shot.

close the Media inspector, select text again, open Media inspector

* Media search box is now blank

** Sometimes selected text is in the Media inspector search box instead of page title.  see other screen shot.

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

**Attached**: {F13511}
Re-writing the bug title; this has nothing to do with the selection.

Fixed in gerrit 143749.
Created attachment 15319
sometimes selected text is in Media inspector search box

**Attached**: {F13512}
Intention:
Paste some plain text.

Steps to Reproduce:
1. Type a few paragraphs of plain text.  I typed mine into an Apple Mail message with rich text turned off.  My text was:

I get to play with lists.
I like to play with lists.

I wonder if this will do what I want.

What I want is for this not to be in a list.


2. Open VisualEditor.

3. Copy and paste the plain text into VisualEditor.


Actual Results:  
Instead of getting this:

I get to play with lists.
I like to play with lists.

I wonder if this will do what I want.

What I want is for this not to be in a list.


I got this:

I get to play with lists.
I like to play with lists.


I wonder if this will do what I want.


What I want is for this not to be in a list.


When it saved, there were actually three blank lines between the paragraphs.  This can be seen at http://en.wikipedia.beta.wmflabs.org/w/index.php?diff=92715&oldid=92368


Reproducible: Always

This is not the same as Bug 58283.  Also, I could not reproduce this in Firefox 29.  It happens every time in Safari 6.1.3.

--------------------------
**Version**: unspecified
**Severity**: minor
Confirmed in Safari 8.0.
As of May 6th, I am experiencing a lag in switching from VE to Edit source mode, after clicking on Ok on "Switch to source editing" dialog, for 5-6 secs, it seems like nothing is happening on my browser. 

This is happening even if I have perfect network speed and all other things loading properly.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 144505 merged by jenkins-bot:
Show pending state on action button and keep dialog open when switching to source mode

https://gerrit.wikimedia.org/r/144505
Change 144505 had a related patch set uploaded by Alex Monk:
Show pending state and block clicks when switching to source mode

https://gerrit.wikimedia.org/r/144505
Spinner? Hmm... I've been thinking perhaps mark the switch confirmation dialog as pending and just not close it.

As for blocking overlay... Not sure about what the best way to do that is yet. I assume setting pointer-events:none; on the <body> isn't great.
This is only in beta labs, probably because beta labs is just slow. We should have a spinner and a blocking overlay, though. Right now you can even interact with the surface while we switch to source mode.
From bug 50726 comment : 

| Steps to reproduce:
| 1. Load https://en.wikipedia.org/wiki/Jos%C3%A9_Cl%C3%A1udio_Ribeiro_da_Silva?veaction=edit which will place cursor at the beginning of the first line of text.
| 2. Press right arrow (or use mouse) to place cursor further right on the first paragraph relative to the position of the first reference in the first paragraph.
| 3. Press down. (the cursor should now be directly right of of the first reference)
| 4. Press down.
| 
| Result: The cursor is stuck on the first reference.
| 
| (The same result can be achieved by placing the cursor in the second paragraph and pressing up)

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/wiki/Jos%C3%A9_Cl%C3%A1udio_Ribeiro_da_Silva?veaction=edit
I don't recall when, but this is long-since fixed.
open in new tab used to work for links while in VE with CMD+Click on mac, this no longer works

Mac 10.9.2 / Chrome Version 35.0.1916.86 beta

--------------------------
**Version**: unspecified
**Severity**: normal
Turns out I was wrong and this did already exist - sorry!

*** This bug has been marked as a duplicate of bug 50321 ***
**Author:** `richlv`

**Description:**
mw 1.22.6. enabling latest visual editor from git results in :
"Fatal exception of type MWException"

after some testing, no specific error messages could be seen in apache error log.

according to James_F, "VE master needs MW 1.23, yes - but it should also fail gracefully when you try to start it, rather than have random fatal errors" :)

--------------------------
**Version**: unspecified
**Severity**: minor
This also happens with master and MW 1.23
**richlv** wrote:

master
(In reply to richlv from comment #0)
> enabling latest visual editor from git

Which branch?
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Make it frameless-left-border or basic-left-border 

Observed Result:
A straight line appears over the image.If you now move the image to center it will go away, but if you again change it to frameless-right-border or basic-right-border from center, the straight line will appear again


See the screenshot attacahed

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**: minor

**Attached**: {F13981}
This issue is not happening anymore, might got fixed by some changes with image .
Marking it as resolved .
This issue did not get resolved with new image model
Right now if you have some rich content with an image and paste it into VisualEditor, we discard the image.

However, it'd be nice to add some special handling in VisualEditor's paste for the HTML of images so that those from Commons used on a MediaWiki instance get sought out and inserted instead.

Perhaps via a special custom attribute VE would sniff for, that would make VE try to find the image from Commons (if the wiki was configured for InstantCommons), or other fileRepos?

MediaViewer's "embed" HTML looks like:

| <p><a href="http://commons.wikimedia.org/wiki/File:Beach_sand.jpg#mediaviewer/File:Beach_sand.jpg"><img src="http://upload.wikimedia.org/wikipedia/commons/c/c5/Beach_sand.jpg" alt="Beach sand.jpg" height="1200" width="1600"></a>[…]</p>

If we asked them to add an attribute, e.g. (simplified):

| <p><a href="…"><img src="…" alt="…" ve-data="ve-pastableImage" ></a>[…]</p>

… could we do this?

(Also, yes, they should be using <figure> instead of <p><img></p>.)

--------------------------
**Version**: unspecified
**Severity**: enhancement
(In reply to Tisza Gergő from comment #3)
> We tried to avoid using the description where a caption is available; the
> description is often less relevant and too verbose. Also, the caption might
> be in the right language - copy-pasting images does not necessarily happen
> across wikis. (I guess we could add a lang attribute, which is a sensible
> thing to do anyway, and then language mismatch could be detected on paste.)

Yeah, if the <figcaption> had a lang attribute it'd be a lot easier for us, and we'd use that in preference if it were in the content language of the paste target.
We tried to avoid using the description where a caption is available; the description is often less relevant and too verbose. Also, the caption might be in the right language - copy-pasting images does not necessarily happen across wikis. (I guess we could add a lang attribute, which is a sensible thing to do anyway, and then language mismatch could be detected on paste.)
(In reply to Tisza Gergő from comment #1)
> At any rate, whether it is in a figure tag figure or something else, users
> would probably expect the caption to end up inside the image wikicode, not
> as a HTML wrapper. So I suppose the caption would need special attributes as
> well?

Sure, or we could fetch the caption from Commons in the context language automatically, so users don't have to be using the right language?
Granted, MediaViewer's HTML format is total crap, but there isn't a clean, semantic way to mark up image captions that works in HTML4. Maybe browsers these days understand HTML5 tags no matter the doctype, and using figure is fine - we should look into that.

At any rate, whether it is in a figure tag figure or something else, users would probably expect the caption to end up inside the image wikicode, not as a HTML wrapper. So I suppose the caption would need special attributes as well?
mediawiki.Uri does not support IPv6 URIs:

```
> var uri = new mw.Uri( 'http://127.0.0.1/' )
undefined
> var uri = new mw.Uri( 'http://[::1]/' )
Error: Bad constructor arguments
```
On a MediaWiki installation with IPv6 URL like
http://[::1]/w/index.php
the class mw.Uri gets not created because it is initialized with

mw.Uri = mw.UriRelative( document.location.href );
Ctrl-Arrow is supposed to move the caret one word in the direction of the arrow.

In RTL wikis it moves too far. It looks like to goes to the next reference or the next sentence rather than the next word.

--------------------------
**Version**: unspecified
**Severity**: major
Change 131767 merged by jenkins-bot:
unicodejs: Update moveBreakOffset to include 'HebrewLetter' category

https://gerrit.wikimedia.org/r/131767
Presuming that the rename of this bug is correct, marking this as FIXED.
Change 131767 had a related patch set uploaded by Esanders:
Update moveBreakOffset to include 'HebrewLetter' category

https://gerrit.wikimedia.org/r/131767
This looks like just a problem with Hebrew. The new Unicode spec introduced a "HebrewLetter" group which we didn't add to the WordBreak checker.
On a Mac it's Alt-Arrow a.k.a. Option-Arrow.
Noticed on our Wikia integration, and saw that it was incorrect here: https://www.mediawiki.org/wiki/VisualEditor?veaction=edit

http://screencast.com/t/sin5AakmN0

The shortcut list shows that Command plus a number changes the heading value. This is incorrect, as it controls the browser's tabs. The correct label should be "Command".

I tested this in latest Firefox and latest Chrome.

--------------------------
**Version**: unspecified
**Severity**: minor
**OS**: Mac OS X 10.9
**Platform**: Macintosh
Change 131596 merged by jenkins-bot:
Fix command help for CTRL+1-6 on mac

https://gerrit.wikimedia.org/r/131596
Change 131596 had a related patch set uploaded by Esanders:
Fix command help for CTRL+1-6 on mac

https://gerrit.wikimedia.org/r/131596
We should adapt the save prediction / optimistic parsing logic in VisualEditor and provide it for the standard wikitext editor. See T58011 for the full description.

Adding Roan as CC since he implemented this for VisualEditor and thus may have useful feedback.

--------------------------
**Version**: 1.24rc
**Severity**: enhancement
Some things to account for:

* Account for use of rev ID parser functions (e.g. don't cache at all)
* Use of parser timestamp functions lower TTL appropriately (or don't cache in some cases too)
* Account for user prefs and options fully (they might change before the actual "save" click)
Issues right now:

* Different set of elements (e.g. #contentSub is shown in read mode, but not in edit mode. The same goes for TOC, though we do account for that one).

* Different offset (the toolbar is injected which causes an abrupt visual shift).

* Different scroll offset (same as before, but applies when you open the editor when scrolled down the page, after the transition, you're looking at a potentially very different part of the document, we should preserve it or jump to the top, not leave you somewhere randomly).

--------------------------
**Version**: unspecified
**Severity**: normal
Enough now that I'm going to call this done.
Change 131071 merged by jenkins-bot:
ve.init.mw.ViewPageTarget: Actually animate the toolbar during setup

https://gerrit.wikimedia.org/r/131071
Change 131074 merged by jenkins-bot:
ve.init.mw.ViewPageTarget: Hide #contentSub in addition to #toc when muted

https://gerrit.wikimedia.org/r/131074
Change 131074 had a related patch set uploaded by Krinkle:
ve.init.mw.ViewPageTarget: Hide #contentSub in addition to #toc when muted

https://gerrit.wikimedia.org/r/131074
Change 131071 had a related patch set uploaded by Krinkle:
ve.init.mw.ViewPageTarget: Actually animate the toolbar during setup

https://gerrit.wikimedia.org/r/131071
In Firefox

Steps to reproduce:

1.Open a page with VE in Firefox

2.Insert a media

3.Go to Media Settings of that image

4.Scroll down the dialog box 

Observed Result:

There is no gap between the textbox for Alternative text and the border of the dialog , its almost overlapped with the border as compared to how it appears in Chrome

See the screenshots attached

Test Environment:
http://en.wikipedia.beta.wmflabs.org/ and 
https://en.wikipedia.org/

Browser: FF 25
OS: MAC OS X 10. 8. 5

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

**Attached**: {F14031}
(In reply to Roan Kattouw from comment #2)
> The PageLayout has 1.5em of padding on all sides. In Chrome, the bottom
> padding is taken into account in the overflow (i.e. in determining whether
> to draw a scrollbar and how far down to allow scrolling) while in Firefox it
> is now. Using bottom margin rather than padding does appear to sort of work
> in Firefox, but it makes the vertical scroll bar end too early (as it
> correctly ends before the margin).

The Firefox people disagree that this is a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=748518
The same issue appears to be in the Reference dialog box as well ,the "Use this group" textbox overlaps with the border of the dialog in Firefox
The PageLayout has 1.5em of padding on all sides. In Chrome, the bottom padding is taken into account in the overflow (i.e. in determining whether to draw a scrollbar and how far down to allow scrolling) while in Firefox it is now. Using bottom margin rather than padding does appear to sort of work in Firefox, but it makes the vertical scroll bar end too early (as it correctly ends before the margin).
The PageLayout has 1.5em of padding on all sides. In Chrome, the bottom padding is taken into account in the overflow (i.e. in determining whether to draw a scrollbar and how far down to allow scrolling) while in Firefox it is now. Using bottom margin rather than padding does appear to sort of work in Firefox, but it makes the vertical scroll bar end too early (as it correctly ends before the margin).
Steps to Reproduce:
1. Citation > Cite web

2. Don't add any information.  Just click "Apply changes".

Result:  <ref>{{Cite web|url = |title = |date = |accessdate = |website = }}</ref>

That's pointless.  If the fields are blank, don't add it (or remove it).


Steps to reproduce, part 2:

1. Citation > Cite web

2. Don't add any information.  Delete all the parameters. 

3. Click "Apply changes".

Result:  <ref>{{Cite web}}</ref>

That's even more pointless.  If there are no parameters, don't add it (or remove it).





Reproducible: Didn't try

(The "invalid" parameter in that diff was manually created by me.  I don't think you can do anything to help the person adding invalid parameters, because there's no way to differentiate between invalid parameter names and valid names that don't happen to be defined in TemplateData.)

--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: http://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:Whatamidoing_(WMF)/Sandbox&diff=91690&oldid=91686
Whoops, sorry, wrong bug report :(
Created attachment 15573
More than one field error

**Attached**: {F14012}
Change 136436 merged by jenkins-bot:
Don't allow inserting blank citations

https://gerrit.wikimedia.org/r/136436
Change 136436 had a related patch set uploaded by Alex Monk:
Don't allow inserting blank citations

https://gerrit.wikimedia.org/r/136436
Intention:
Edit an existing citation.

Steps to Reproduce:
1.  Select an existing citation (one using a citation template).
2.  Press the return key to open it.
3.  That's odd, I'm in the Reference dialog.  Exit.  
4.  Re-select the citation.  
5.  Double-click to open it.  
6.  That's odd, I'm in the Reference dialog.  Exit.  
7.  Re-select the citation.  
8.  Click the little cite-web icon.  That opens the citation tool's simplified dialog.

This happens in both Safari and Firefox, so presumably everywhere.
@jdforrester-WMF If that sounds reasonable to you, I'd like to see this resolved as part of the citations experience work that we're doing in Q3 - it's a UI niggle that can distract from an otherwise dramatically improved experience. Obviously not an issue if made obsolete by a new UI.
(In reply to Erik Moeller from comment #3)
> As the citation experience overall has recently improved in leaps and bounds
> this is one of those issues that sticks out -- any chance we can chop it
> down soon?
It's a non-trivial problem. We have some ideas for how to do this, but I need Trevor's brain, and he's been sick all week :(
As the citation experience overall has recently improved in leaps and bounds this is one of those issues that sticks out -- any chance we can chop it down soon?
In talking with Trevor this is going to take quite some time to fix, sadly.

(In reply to WhatamIdoing from comment #1)
> Once you're inside the Reference dialog, if you double-click the citation
> template, then it takes you to the Citation tool (rather than to the generic
> template tool).  I don't know if that's intentional, but it's not obviously
> wrong.

It's intentional. :-)
Once you're inside the Reference dialog, if you double-click the citation template, then it takes you to the Citation tool (rather than to the generic template tool).  I don't know if that's intentional, but it's not obviously wrong.
first word in page text is still in link box after clicking and typing

seen in Chrome only as of 30 Apr: 

as a logged in user on beta labs, invoke VE on a page containing text

without typing or clicking anything else, click the Link icon

the first word in the page text is in the box to create the link

* problem: the text in the link box is not automatically highlighted

click in the link box to create the link text

* problem: default text in the link box that should be highlighted should also be removed when the user clicks in the box to type their own link

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

**Attached**: {F13875}
No consistent repro
I can't reproduce this in Chrome or Firefox on Beta Labs now – possibly a temporary/cached deployment bug?
In Vector/1.24wmf2, the "Edit source" tab is not highlighted when editing a page in source mode (no tab is highlighted).

Example:
http://www.mediawiki.org/w/index.php?title=Help:Preferences&action=edit

--------------------------
**Version**: unspecified
**Severity**: major
Verified the fix on Production, Betalabs and Test2
Change 130622 merged by Catrope:
Preserve pre-existing css classes on edit tab link

https://gerrit.wikimedia.org/r/130622
Change 130622 had a related patch set uploaded by Jforrester:
Preserve pre-existing css classes on edit tab link

https://gerrit.wikimedia.org/r/130622
Change 130594 merged by jenkins-bot:
Preserve pre-existing css classes on edit tab link

https://gerrit.wikimedia.org/r/130594
*** Bug 64645 has been marked as a duplicate of this bug. ***
(For the record, yes, confirmed this is broken in production and on latest master).
Change 130594 had a related patch set uploaded by Krinkle:
Preserve pre-existing css classes on edit tab link.

https://gerrit.wikimedia.org/r/130594
Caused by Ib2e6237483338c8072d5f7919c6459bf7418946a, which overides the 'class' attribute of the original edit tab with 'collapsed'. Thus blowing away the class "selected" that MediaWiki core puts there when on action=edit.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Just add a newline by pressing the return
3.Click on the "Save Page" button which got enabled 

Observed Result:
 "Unknown Error" appears on the Save dialog box

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

See the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: major
**URL**: http://en.wikipedia.beta.wmflabs.org/wiki/28thAprilChrome?veaction=edit

**Attached**: {F13652}
LGTM. Maybe this was fixed by the changes to the save dialog? Not sure…
Am I missing something or has this been fixed? http://en.wikipedia.beta.wmflabs.org/w/index.php?title=28thAprilChrome&diff=94065&oldid=91283
It also shows the following error in the console:
POST http://en.wikipedia.beta.wmflabs.org/w/api.php 500 (Internal Server Error)
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.In the caption of the image add templates/images/cite notes/math/reference
4.Click on "Apply Changes"
5.Now hover over the image

Observed Result:
The highlight boxes for templates/images/cite notes/math/references are appearing as well while highlighting the image

See the screenshot attached.


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

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

**Attached**: {F13649}
Verified the fix in production (en.wiki)
Verified the fix in test2 running wmf9
This seems to be working fine now.There is one single shield appearing over the image even if it has different nodes inside the caption
Change 134363 merged by jenkins-bot:
[BREAKING CHANGE] Merge ProtectedNode into FocusableNode

https://gerrit.wikimedia.org/r/134363
Change 134363 had a related patch set uploaded by Esanders:
[BREAKING CHANGE] Merge protected node into focusable node

https://gerrit.wikimedia.org/r/134363
This did not get resolved with the new image model.Giving it to Moriel .
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Add Heading
3.Add Subheading 1
4.Now go to Page Settings and set the option to show the TOC as Always

Observed Result:
In the TOC inside VE the link to hide the TOC appears as <hidetoc> instead of Hide

See the screenshot attached

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

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

**Attached**: {F14029}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 129852 merged by jenkins-bot:
Export showtoc and hidetoc messages

https://gerrit.wikimedia.org/r/129852
A screenshot indicating where exactly between the VisualEditor toolbar and the content being edited with VisualEditor the 'Insert' menu becomes hidden under such content being edited

As shown in the attached screenshot, attempting to open VisualEditor's 'Insert' menu causes it to open behind the content of the page that you have opened within VisualEditor.  This occurs when VisualEditor is used in Safari 6.1.3 under OS X 10.8.5 'Mountain Lion' when this OS is run on a mid-2007 aluminum iMac with a 2.4-GHz Intel Core 2 Duo processor, 4 GB of 667-MHz DDR2 SDRAM, and an ATI Radeon HD 2600 Pro with 256 MB of dedicated VRAM.  For some reason, though, this bug has been somewhat intermittent over the past month or so (it showed up for a while at first, then appeared as if it had been fixed before whatever patch that fixed it was reverted or otherwise messed with.)  Is my bug a duplicate of another one even though I couldn't find a similar one via Bugzilla's search mechanism?  If so, have there been notices in the comments of this other bug about its status?

--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Mac OS X 10.9
**Platform**: Macintosh

**Attached**: {F13846}
This issue went away for me shortly before I updated my system to OS X 10.10.x 'Yosemite' and Safari 8.0.x and has not resurfaced since then.  I'm assuming that somebody fixed this by resolving a related issue and am, as such, closing it as 'Invalid' since it no longer describes behavior under the currently used versions of MediaWiki.
@WhatamIdoing:  Methinks that the problem is highly exacerbated by the use of Safari Extensions (see comment 2 for the full list of stuff I had on my computer when this bug first appeared for me.)
Assuming that the steps to reproduce are:

1.  Read Wikipedia article in Safari.  Zoom in at least twice (Command-+).

2.  Open page in VisualEditor.

3.  Click on drop-down menus (e.g., the character formatting menu).

then I cannot reproduce this today in Safari 6.2 on Mac OS 10.8.5.
Ah, I see; that *would* be a problem since Apple no longer supplies current versions of Safari to Windows users.  It seems to me, however, that this bug has been fixed for users of Safari 7.1 (9537.85.10.17.1), to which I updated a little while back, by recent changes to either WebKit or the MediaWiki software.  Since I no longer have either Safari 6.1.3 or Safari 7.0.5, could anybody check to see if this bug still exists for those versions of Safari?
I'd love to help but I don't own a Mac. :(
Any progress on fixing the zooming issue?
P. P. S.:  It turns out that VisualEditor's menus load properly if you reset Safari's zoom level before clicking on 'Edit [beta]' even if you then zoom in afterwards!  Crazy, right?
P. S.:  I just looked at the duplicate bug, number 67741, and I realized that I *always* zoom in by two levels when I use Wikipedia!  I will therefore check to see if VisualEditor works normally when I'm not zoomed in at all before you guys have me do any deeper testing, all right?
*** Bug 67741 has been marked as a duplicate of this bug. ***
(In reply to Bryce Glover from comment #21)
> I'm still seeing this bug with Safari 6.1.4, guys; maybe it's more serious
> than we all think?  It would be really nice if we could figure out what's
> going on here, because it's really annoying for me to not be able to use
> VisualEditor since it's such a great product (I can't even access the
> 'Switch to Source Editing' command since the menus hide behind page content!)

Hey, sorry, please re-open bugs if you think more work needs to be done on them. This bug was lost to the mists of time (bugs marked RESOLVED/VERIFIED are only looked at by happenstance). :-(

Unfortunately I don't have access to Safari 6.1.x here, and I still can't replicate in Safari 6.0.5 or 7.0.4/5 – and given that only security updates and a sidebar were added, it seems almost certain that the issue is specific to your setup somehow. Re-opening but I'm not sure if there's anything we can do…
I'm still seeing this bug with Safari 6.1.4, guys; maybe it's more serious than we all think?  It would be really nice if we could figure out what's going on here, because it's really annoying for me to not be able to use VisualEditor since it's such a great product (I can't even access the 'Switch to Source Editing' command since the menus hide behind page content!)
Created attachment 15289
Safari 6.1.3 JavaScript Console Logs for https://en.wikipedia.org/wiki/Foobar?veaction=edit

As this title says, this attachment contains the JavaScript console logs which Safari 6.1.3 running on OS X 10.8.5 'Mountain Lion' provided for the URL 'https://en.wikipedia.org/wiki/Foobar?veaction=edit'.

**Attached**: {F13848}
(In reply to Andre Klapper from comment #18)
> The "Add an attachment" link should work, unrelated to bug status.

Oh, wait; I see it, but it moved from below the 'Additional Comments:' dialog box to below the list of attachments to this bug at the top of the page.  Stupid me; I should have looked first!
The "Add an attachment" link should work, unrelated to bug status.
(In reply to Bryce Glover from comment #16)
> (In reply to Bryce Glover from comment #15)
> > Maybe I should disable my Extensions and then turn them back on one by one
> > to figure out which one is causing the problem?  That way, I could contact
> > that plug-in's developer and discuss the bug with him or her.
> 
> Okay, guess what?  It's apparently *Apple's* fault since this bug occurs for
> me with Extensions enabled (it goes away when they aren't — yay!) but (get
> this!) *no extensions enabled*.  I'll attach what my error console gives me
> to this bug in a sec.

Sorry about changing the bug status; I thought that doing so would bring back the 'UNRESOLVED' option so that I could attach a picture of my browser's console logs for that page to which you sent me a link.  Could somebody un-'RESOLVED WONTFIX' this for me so that I can do this, or am I on my own here?
(In reply to Bryce Glover from comment #15)
> Maybe I should disable my Extensions and then turn them back on one by one
> to figure out which one is causing the problem?  That way, I could contact
> that plug-in's developer and discuss the bug with him or her.

Okay, guess what?  It's apparently *Apple's* fault since this bug occurs for me with Extensions enabled (it goes away when they aren't — yay!) but (get this!) *no extensions enabled*.  I'll attach what my error console gives me to this bug in a sec.
Maybe I should disable my Extensions and then turn them back on one by one to figure out which one is causing the problem?  That way, I could contact that plug-in's developer and discuss the bug with him or her.
(In reply to Bryce Glover from comment #12)
> OK, I know that the version of Firefox which I mentioned (17.0.1) works just
> fine even when I'm logged in to Wikipedia as myself (I didn't see the
> 'Edit^[beta]' link when I wasn't,) so it's got to be something in Safari
> 6.1.3 that's going wrong.

That's unfortunate. I've tried it with Safari 6.0.5 and it works as expected; this is either a very odd problem with a sub-version of Safari (which is unlikely) or caused by a browser plugin. I don't really like to close such bugs as "WORKSFORME" but there's nothing much I can offer at this point, sadly…
Created attachment 15283
Screenshot of no issue in Safari 6.0.5

**Attached**: {F13847}
(In reply to Bryce Glover from comment #11)
> (In reply to James Forrester from comment #10)
> > (In reply to Bryce Glover from comment #9)
> > > (In reply to James Forrester from comment #6)
> > > > Would it be possible for you to visit
> > > > https://en.wikipedia.org/wiki/Foobar?&veaction=edit whilst logged out in
> > > > Safari, and/or in a different browser, and see if it recurs?
> > > 
> > > Yup; it still occurs even while I'm logged out of Wikipedia.  I've also
> > > confirmed that all of the other menus ('Paragraph' — that's a styling menu,
> > > right? — and the ones labeled with a question mark inside of a circle —
> > > 'Help', maybe? — , a triangular warning sign — could this be 'Report a
> > > Problem?' — , and a column of stacked lines — I'm assuming that this means
> > > 'More Options') open with their menus tucked under the content of the page
> > > that is being edited with VisualEditor.
> > 
> > Thanks. I take it this is still with Safari 6.1.3 with all your plugins,
> > whilst logged out?
> 
> That's right.  Hold on, though; I forgot to check Firefox 17.0.1 (yeah, I
> know; I'll remind my dad to update it as soon as I can…)

OK, I know that the version of Firefox which I mentioned (17.0.1) works just fine even when I'm logged in to Wikipedia as myself (I didn't see the 'Edit^[beta]' link when I wasn't,) so it's got to be something in Safari 6.1.3 that's going wrong.
(In reply to James Forrester from comment #10)
> (In reply to Bryce Glover from comment #9)
> > (In reply to James Forrester from comment #6)
> > > Would it be possible for you to visit
> > > https://en.wikipedia.org/wiki/Foobar?&veaction=edit whilst logged out in
> > > Safari, and/or in a different browser, and see if it recurs?
> > 
> > Yup; it still occurs even while I'm logged out of Wikipedia.  I've also
> > confirmed that all of the other menus ('Paragraph' — that's a styling menu,
> > right? — and the ones labeled with a question mark inside of a circle —
> > 'Help', maybe? — , a triangular warning sign — could this be 'Report a
> > Problem?' — , and a column of stacked lines — I'm assuming that this means
> > 'More Options') open with their menus tucked under the content of the page
> > that is being edited with VisualEditor.
> 
> Thanks. I take it this is still with Safari 6.1.3 with all your plugins,
> whilst logged out?

That's right.  Hold on, though; I forgot to check Firefox 17.0.1 (yeah, I know; I'll remind my dad to update it as soon as I can…)
(In reply to Bryce Glover from comment #9)
> (In reply to James Forrester from comment #6)
> > Would it be possible for you to visit
> > https://en.wikipedia.org/wiki/Foobar?&veaction=edit whilst logged out in
> > Safari, and/or in a different browser, and see if it recurs?
> 
> Yup; it still occurs even while I'm logged out of Wikipedia.  I've also
> confirmed that all of the other menus ('Paragraph' — that's a styling menu,
> right? — and the ones labeled with a question mark inside of a circle —
> 'Help', maybe? — , a triangular warning sign — could this be 'Report a
> Problem?' — , and a column of stacked lines — I'm assuming that this means
> 'More Options') open with their menus tucked under the content of the page
> that is being edited with VisualEditor.

Thanks. I take it this is still with Safari 6.1.3 with all your plugins, whilst logged out?
(In reply to James Forrester from comment #6)
> Would it be possible for you to visit
> https://en.wikipedia.org/wiki/Foobar?&veaction=edit whilst logged out in
> Safari, and/or in a different browser, and see if it recurs?

Yup; it still occurs even while I'm logged out of Wikipedia.  I've also confirmed that all of the other menus ('Paragraph' — that's a styling menu, right? — and the ones labeled with a question mark inside of a circle — 'Help', maybe? — , a triangular warning sign — could this be 'Report a Problem?' — , and a column of stacked lines — I'm assuming that this means 'More Options') open with their menus tucked under the content of the page that is being edited with VisualEditor.
(In reply to James Forrester from comment #6)
> Would it be possible for you to visit
> https://en.wikipedia.org/wiki/Foobar?&veaction=edit whilst logged out in
> Safari, and/or in a different browser, and see if it recurs?

Doing now…
(In reply to Andre Klapper from comment #5)
> (In reply to Bryce Glover from comment #4)
> > Has this been fixed yet
> 
> If it was fixed, the status of this ticket was RESOLVED FIXED.
> 
> As long as only one user has ran into this issue and steps to reproduce are
> unclear, it's likely not a high priority.

Ah, sorry; I was getting a little impatient, not to mention worried!  I'm relatively new to Bugzilla, so, duh:  I should have thought, "Oh!  It hasn't been marked as 'RESOLVED FIXED' yet."  Now I feel ignorant…heh, heh.  (sheepish smile)
Sorry for the brief delay.

I am unable to reproduce this for default-setup users on the English Wikipedia in Safari 7.0.3, in default Vector or Monobook, or whilst logged in with fewer gadgets switched on.

Though it's theoretically possible that there's a rendering difference between Safari 6.1.3 and 7.0.3 in this respect, it's very unlikely, and I would assume the bug is caused by a browser plugin or a gadget.

Given that you're getting the same behaviour on a different site (meta as well as enwiki), it's most likely to be a browser plugin issue (though none of your plugins look suspicious at first glance).

Would it be possible for you to visit https://en.wikipedia.org/wiki/Foobar?&veaction=edit whilst logged out in Safari, and/or in a different browser, and see if it recurs?
(In reply to Bryce Glover from comment #4)
> Has this been fixed yet

If it was fixed, the status of this ticket was RESOLVED FIXED.

As long as only one user has ran into this issue and steps to reproduce are unclear, it's likely not a high priority.
Has this been fixed yet, or did everybody forget about me?
I've just found out that this bug also occurs for another menu (the 'Formatting' one — that's what the menu with an icon that looks like an underlined capital 'A' is called, right?) at en:meta under my user environment.  I'll update this bug with my results as I try and use other menus in VisualEditor at other wikis.
What skin are you using, and do you have any gadgets or local user scripts or styling that might be competing?
cite icon not having any layout

Steps to reproduce:


1.Open a page with VE in Firefox
2.Insert a media file
3.Now go the media settings for this image
4.Add some cite options and reference inside media settings icon

Observed Result:

Just after adding the cite options and references, observe that the icon layouts for cite options and reference are missing

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

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

**Attached**: {F13698}
Probable browser bug. Fun.
Needs investigation as to the cause.
Template parameter input with one line of text

If I am entering text for a template parameter and then I press enter to start a new line, the input box remains the same (small) vertical size and the first line of text disappears. A very small scroll handle appears at the right, but it is not obvious that this is what it is.

Press enter again to add a third line will enlarge the input box so that both the second and third lines are visible, and the dark grey scroll handle disappears (but the light grey slot for it remains. Once it gets to four lines it starts working as expected.

This input box should expand enough with the first few lines, at least, that no scrolling is even necessary. By the time it becomes necessary, it should already be large enough that the scroll handle will be recognizable to users.

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

**Attached**: {F13516}
Maybe a browser bug. It happens to me (still) in Iceweasel (Debian Jessie), but not in Chromium.
This is very odd. Browser bug, maybe? This isn't the behaviour for me in Chrome, Safari, Opera or Firefox here…
Created attachment 15164
Template parameter input with four lines of text

**Attached**: {F13519}
Created attachment 15163
Template parameter input with three lines of text

**Attached**: {F13518}
Created attachment 15162
Template parameter input with two lines of text

**Attached**: {F13517}
Related to bug 48560?
IP editor reports that when he removed categories from this category https://it.wikipedia.org/w/index.php?title=Categoria%3AMarketing&diff=65461531&oldid=60402800 , all he could see after he saved was the category description.
The category tree and the list of the categories at the bottom only appeared after refreshing the page.

His setup: Firefox 28.0 , Vector, Windows 7
I reproduce the same issue with that setup in this edit: https://it.wikipedia.org/w/index.php?title=Categoria%3AVisualEditor&diff=65497855&oldid=64118006 .

--------------------------
**Version**: unspecified
**Severity**: normal
Change 136311 merged by jenkins-bot:
On category pages, only replace category description when saving

https://gerrit.wikimedia.org/r/136311
Change 136311 had a related patch set uploaded by Alex Monk:
On category pages, only replace category description when saving

https://gerrit.wikimedia.org/r/136311
Presumably this is pretty trivial?
*** Bug 65925 has been marked as a duplicate of this bug. ***
Sounds like the same problem as for File: pages.
>>! In T66214#3256693, @Tgr wrote:
> We'll also need a way to display old versions of images. Clients can encounter old versions without expecting to due to FlaggedRevs hiding unreviewed image changes.

{T149847} is designed to provide this ability, but it looks like that will still take a while. MediaWiki currently seems to prefix a timestamp to request old revisions, as in 20161203102219%21Kyoto_Station_November_2016_-02.jpg.

Either version will work with this API, since the "name" portion is treated as an opaque identifier.
We'll also need a way to display old versions of images. Clients can encounter old versions without expecting to due to FlaggedRevs hiding unreviewed image changes.
>>! In T66214#2981032, @Gilles wrote:
> Accept headers and Vary: Accept are missing from the current task description.

I added a section on this, but proposed to defer this question for now. As far as I am aware we don't need content negotiation right away, and the API proposal leaves all options open for a follow-up RFC.
>>! In T66214#2981032, @Gilles wrote:
> Accept headers and Vary: Accept are missing from the current task description.

I added a section on this, but proposed to defer this question for now. As far as I am aware we don't need content negotiation right away, and the API proposal leaves all optiones open for a follow-up RFC.
I think the discussion about restricting thumbnail sizes is orthogonal to this RFC. Nothing in this RFC limits our ability to later a) prefer specific sizes in a client side library, or even b) enforce the use of a limited set of sizes by returning a standard size instead of the non-standard requested size.
>>! In T66214#3030371, @cscott wrote:
> The one exception is that the current thumbnail code arbitrarily quantizes sizes in order to reduce cache overhead.  I'm not sure that is necessary to pull forward into the new service, but presumably the original quantization was added to reduce a particular cache-exhaustion DoS.  Limiting the size query to a limited set of "thumbnail sizes" (or "media styles") might be one way of avoiding a blowup in the number of different versions of a thumbnail.

The current API prefers some sizes over others but does not limit clients (IIRC sizes are rounded to the closest multiple of 5px but that's not much of a limitation). That preference manifests in three ways:
* certain sizes are pre-rendered at upload (`$wgUploadThumbnailRenderMap`)
* for huge images, a thumbnail of some intermediary size is used as the source for scaling, not the original (see [[https://www.mediawiki.org/wiki/Manual:$wgThumbnailBuckets|`$wgThumbnailBuckets`]])
* thumbnail rendering for non-standard sizes is throttled more aggressively.
Mostly this is meant to improve performance for clients which limit themselves to predefined sizes (MediaWiki HTML pages and MediaViewer); to a smaller extent to help against accidental DOS by a combination of bot uploads of huge files + getting lots of thumbnailing requests in parallel when someone visits a category/gallery of said files. Cache exhaustion attacks were AFAIK not considered.
The cache invalidation in Varnish is currently not intelligent about standard vs. nonstandard sizes (and in Swift there is no invalidation - every thumbnail is kept forever), but if that were feasible it would certainly be nice.
Ah nevermind, it's only the md5 of some form of the filename, not the file contents? I've only been working with the consuming side, not the producing side of that hash.

I remember that the temp path was an exception based on the filename, but didn't realize that the general hash was based on the filename as well.

Not sure why we don't just compute it in Swift's rewrite.py instead of passing it along the whole pipepline. At any rate, you can ignore my previous remark.
Ah nevermind, it's only the md5 of some form of the filename, not the file contents? I've only been working with the consuming side, not the producing side of that hash.

I remember that the temp path was an exception based on the filename, but didn't realize that the general hash was based on the filename as well.

Not sure why we don't just compute it in Swift's rewrite.py instead of passing it along the whole pipepline.
Ah nevermind, it's only the md5 of some form of the filename, not the file contents? I've only been working with the consuming side, not the producing side of that hash.

I remember that the temp path was an exception based on the filename, but didn't realize that the general hash was based on the filename as well.
Ah nevermind, it's only the md5 of some form of the filename, not the file contents? I've only been working with the consuming side, not the producing side of that hash.
Ah nevermind, it's only the md5 of some form of the filename, not the file contents?
You might not have access to the file contents when you generate a URL. What I'm saying is that you can't just drop that information from the URL, Swift needs it in some form, to hit the right shard. Because it, too, can't guess the contents of the original when you ask it to look for a thumbnail in a certain shard. And when the thumbnail is missing, it also needs to hit the right shard to fetch the original.

While some wikis don't have sharding for their originals/thumbnails storage and don't need that information, any attempt at defining a new API should take that information into account. Right now none of the new URL examples provided in the task description contain storage sharding information.
>>! In T66214#2981357, @Gilles wrote:
> Something that's missing in the current plan, however, is the swift sharding information that is currently part of the thumb URL in production.

Do you mean [the md5 of the file name](https://github.com/wikimedia/mediawiki/blob/9ac29c74edda2f457814a1ed634a19f9a44fd0a5/includes/filerepo/FileRepo.php#L685)? Calculating this on the fly is not that expensive. OpenSSL does 7248416 md5s over 16 byte data per second on my machine, which works out to about 0.1ms per md5.
I'll pitch {T90914} as a better solution to the "name for different thumbnail sizes", as it generalizes that requirement and lets wikis come up with names for arbitrary groups of image properties.  But I agree that should be mostly abstracted from the thumbnail service.  The one exception is that the current thumbnail code arbitrarily quantizes sizes in order to reduce cache overhead.  I'm not sure that is necessary to pull forward into the new service, but presumably the original quantization was added to reduce a particular cache-exhaustion DoS.  Limiting the size query to a limited set of "thumbnail sizes" (or "media styles") might be one way of avoiding a blowup in the number of different versions of a thumbnail.

But better would probably be to be semi-intelligent about cache strategy, so that 1,000 different versions requested of a certain image each requested once, (a) don't necessarily push other images out of the cache (cache slots are per-image, not shared), and (b) don't necessarily push out the highest-frequency cached thumbnails of that image (ie, not just LRU strategy).
@Tgr, the concerns you raise are primarily about the implementation, and not really about the API. I think it is important to separate the two, and avoid relatively minor implementation concerns dictate our API design. Public APIs will stay around & affect a lot of users, while implementations can be replaced transparently.

We can definitely avoid duplication of the vast majority of thumbnails by rewriting "simple" thumbnails in Varnish (see migration strategy section). Similarly, thumbnail serving performance for small third party installs is something we can optimize by mapping requests to file names, for example as part of the container-based distribution project.

Edit: I forgot to mention that client side size selection won't work with purely static file serving in any case. At a minimum, a 404 handler would need to be configured, which is something we can do for either API, but is more complex than using thumb.php.
@Tgr, the concerns you raise are primarily about the implementation, and not really about the API. I think it is important to separate the two, and avoid relatively minor implementation concerns dictate our API design. Public APIs will stay around & affect a lot of users, while implementations can be replaced transparently.

We can definitely avoid duplication of the vast majority of thumbnails by rewriting "simple" thumbnails in Varnish (see migration strategy section). Similarly, thumbnail serving performance for small third party installs is something we can optimize by mapping requests to file names, for example as part of the container-based distribution project.
@Tgr, the concerns you raise are primarily about the implementation, and not really about the API. I think it is important to separate the two, and avoid relatively minor implementation concerns dictate our API design. Public APIs will stay around & affect a lot of users, while implementations can be replaced transparently.

We can definitely avoid duplication of the vast majority of thumbnails by rewriting "simple" thumbnails in Varnish (see migration strategy section). Similarly, thumbnail serving performance for small third party users is something we can optimize by mapping requests to file names, for example as part of the container-based distribution project.
>>! In T66214#2988556, @GWicke wrote:
>>>! In T66214#2988550, @Tgr wrote:
>>>>! In T66214#2982093, @Fjalapeno wrote:
>>> One piece of feedback we have been discussing is having a higher level abstraction in addition to specifying actual width.
>> 
>> A similar proposal on the wikitext side is {T90914}. IMO it's an interesting issue but too complicated and vaguely understood to include in the current RfC which has largely orthogonal concerns anyway.
> 

I don't think its a problem addressing outside of the current RFC.

> Agreed. Such a higher-level abstraction could always be implemented in a client side library, which would select the right pixel size based on the desired high-level thumbnail type (and possibly other criteria, like device properties).


I would like to consider not putting this type of logic in a client side library. One of the advantages of sharing an API is to prevent clients form needing to implement the same logic in multiple languages/platforms.
^ Captured in {T156910}.
>>! In T66214#2988556, @GWicke wrote:
> Agreed. Such a higher-level abstraction could always be implemented in a client side library, which would select the right pixel size based on the desired high-level thumbnail type (and possibly other criteria, like device properties).

I was one of the engineers that discussed this higher level of abstraction with @Fjalapeno. I do believe that the Reading Web team should pursue this abstraction in the projects they maintain, which are predominantly clients, and continue to discuss pushing the abstraction further down the stack when it's better understood.
>>! In T66214#2988550, @Tgr wrote:
>>>! In T66214#2982093, @Fjalapeno wrote:
>> One piece of feedback we have been discussing is having a higher level abstraction in addition to specifying actual width.
> 
> A similar proposal on the wikitext side is {T90914}. IMO it's an interesting issue but too complicated and vaguely understood to include in the current RfC which has largely orthogonal concerns anyway.

Agreed. Such a higher-level abstraction could always be implemented in a client side library, which would select the right pixel size based on the desired high-level thumbnail type (and possibly other criteria, like device properties).
>>! In T66214#2982093, @Fjalapeno wrote:
> One piece of feedback we have been discussing is having a higher level abstraction in addition to specifying actual width.

A similar proposal on the wikitext side is {T90914}. IMO it's an interesting issue but too complicated and vaguely understood to include in the current RfC which has largely orthogonal concerns anyway.
Thank you all for pushing this forward! This is really great for the reading platforms where we have had lots of ambiguity with thumbnails.

I'm gathering input from the platform teams (Web, Android, iOS) on the current proposal, I want to make sure we have all existing use cases covered.

One piece of feedback we have been discussing is having a higher level abstraction in addition to specifying actual width. Some potential examples:

- thumbnail-small
- thumbnail-large
- preview
- preview-hi-resolution 
- inline
- inline-mobile
- original

This could have a couple advantages:
# This allows us to evaluate sizes for each use case and specify an approbate size and canonize it in the API
# Helps control cache fragmentation by discouraging specific size requests
# When technology/needs change, we can update the sizes without requiring clients to update code.


Any thoughts here?
I don't think that the existing requirements are to be touched at first. I.e. thumbnails would still be width-based only.

Some adaptation of rewrite.py will probably be required, but I think for the most part it would pass along the new request format to the backend (Mediawiki or Thumbor).

Something that's missing in the current plan, however, is the swift sharding information that is currently part of the thumb URL in production.
WRT deployment strategy note that ATM all thumb accesses after varnish go through our [[https://github.com/wikimedia/operations-puppet/blob/production/modules/swift/files/SwiftMedia/wmf/rewrite.py | custom swift rewrite middleware]], how would that (if?) change? Would all thumbs with arbitrary height be stored alongside existing thumbs?
Accept headers and Vary: Accept are missing from the current task description.

Standardizing entry point to thumb.php (and I guess img_auth.php) sounds great to me.

Looking at existing parameters between the various handlers that we'll likely reuses as-is, I think it could be nice to use this as an opportunity to merge "seek" and "page" which are essentially the same thing in different contexts.
> The simplest solution would be to just move all thumb accesses to thumb.php (or an api module)

I note thumb.php could probably use `MW_NO_SESSION` (see T127233), while an action API module cannot.
@Tgr and I discussed some more details in the office today.

- General syntax: We both see general consensus around using query strings, and the (subset of) existing thumb.php parameters generally look like a sane starting point already.
- Communicating original dimensions: We both have a preference for using the URL, with a slight preference for the hash variant (`/someimage.jpg?w=100#oh=1024&ow=768`).
- Versioning: We expect a need to migrate the API format in the future (to content-based hashes, for example). To ensure that we can do this cleanly, we propose to prefix the thumb path with `/v1/`.
- Third party support: We explored options for migrating third party users to the new thumb API in the future. The simplest solution would be to just move all thumb accesses to thumb.php (or an api module), but there would be a slight performance cost, which can however be addressed. Overall, we expect to be able to offer a smooth migration path.

Next steps:

1) Wrap up the bikeshedding on the general syntax choices & versioning. <- This is where you can contribute here & now.
2) Audit & document the official thumb.php API. This is largely covered in {T153497}.
3) Meet with the main stakeholders to detail an implementation plan.
4) Finalize the RFC in a last call period.
5) Implement.
>>! In T66214#2970912, @GWicke wrote:
> Are those key-value parameters already supported by all media handlers, or is support limited to built-in ones?

`f` is magic and does not get passed to the media handlers (they receive the file as a `File` object). There are a few similar parameters, see T153497 (the "unset..." parts) for details.
Apart from that, media handlers are free to do whatever. `width`/`page` is convention and supported by everything for which it makes sense, the other parameters only make sense for a single handler. (See the other task for parameters; I only reviewed the handlers which are hosted in gerrit.)
>>! In T66214#2970912, @GWicke wrote:
> Are those key-value parameters already supported by all media handlers, or is support limited to built-in ones?

`f` is magic and does not get passed to the media handlers (they receive the file as a PHP argument). There are a few similar parameters, see T153497 (the "unset..." parts) for details.
Apart from that, media handlers are free to do whatever. `width`/`page` is convention and supported by everything for which it makes sense, the other parameters only make sense for a single handler. (See the other task for parameters; I only reviewed the handlers which are hosted in gerrit.)
@Tgr: That is great news. This means that we already have a means of feeding generic key-value parameters to the thumb machinery. Are those key-value parameters already supported by all media handlers, or is support limited to built-in ones?

Looking at [thumb.php](https://github.com/wikimedia/mediawiki/blob/master/thumb.php#L98), it seems that some of this interface is currently considered deprecated (including the `w` and `p` shorthands). We should make a pass over this API to see if everything makes sense as-is.

> That would result in URLs like https://commons.wikimedia.org/w/thumb.php?f=Camera2_mgx.svg&w=100&lang=fr, which is a bit uglier than https://commons.wikimedia.org/thumb/Camera2_mgx.svg?w=100&lang=fr but no difference in functionality

The 404 handler already [tries to pull the thumb name from the path info](https://github.com/wikimedia/mediawiki/blob/master/thumb.php#L60), so it should not be that hard to support requests of the form /thumb.php/Sometitle.jpg?w=100&p=10. In production, we would probably use a prefix like /thumb/. Either way, clients would see a slightly cleaner separation between the thumb name & its parameters that is consistent between large & small installs.
After thinking more about this and looking at the code I am getting more and more confused about what exactly we are trying to do. Media handlers already use two representations: a parameter array (which can be passed to `File::transform`, or by an external client to `thumb.php` - so we do have an API with sane parameters, it's just not used because there isn't any caching in front of it) and a filename prefix; `MediaHandler::makeParamString` and `MediaHandler::parseParamString` can be used to convert between the two. All that's needed for a Wikimedia thumbnail API is to set up Varnish to cache the `thumb.php` responses, and disable the `transformVia404` config flag if we also want to use query-string-style URLs in the generated HTML. That would result in URLs like [[https://commons.wikimedia.org/w/thumb.php?f=Camera2_mgx.svg&w=100&lang=fr|https://commons.wikimedia.org/w/thumb.php?f=Camera2_mgx.svg&w=100&lang=fr]], which is a bit uglier than `https://commons.wikimedia.org/thumb/Camera2_mgx.svg?w=100&lang=fr` but no difference in functionality (and it's not hard to add a wrapper if needed). Since we want to use a separate domain for uploads, we would probably change `$wgThumbnailScriptPath` to point to `https://upload.wikimedia.org/<project>/<language>/thumb.php` and use a multiwiki dispatcher script, like we used to do with bits/`load.php`. Or it could point to a RESTBase or Thumbor installation; in any case, I don't see any changes that would be needed to MediaWiki internals.
>>! In T66214#2850204, @Ciencia_Al_Poder wrote:
>>>! In T66214#2827486, @GWicke wrote:
>> Since the need for explicit control should be rare, I think using the Accept header offers the better trade-offs overall.
> 
> If I understand correctly, you propose to potentially send different image formats under the same request URL. That would require cache varying depending on the Accept: header (and I'm not sure about the implications of this), otherwise a cached webp response might be served to clients not supporting that format.

Yes, the proposal includes setting a `Vary: accept`, and normalizing the `Accept` header value on thumb requests in Varnish. At least in the foreseeable future, the number of format variations will be very low, which keeps the normalization logic simple.
Not sure if it is helpful to examine, but here is a commercial image service API:

https://docs.imgix.com/setup/serving-images
https://docs.imgix.com/apis/url

They do in fact pass the extension back but most other options are in query parameters (including format)
>>! In T66214#2827486, @GWicke wrote:
> Since the need for explicit control should be rare, I think using the Accept header offers the better trade-offs overall.

If I understand correctly, you propose to potentially send different image formats under the same request URL. That would require cache varying depending on the Accept: header (and I'm not sure about the implications of this), otherwise a cached webp response might be served to clients not supporting that format.
@gilles, the client can communicate the exact format(s) it prefers using either the URL, or via the Accept header. 

For the vast majority of browser use cases, the Accept header has the advantage of doing the right thing implicitly, without the user needing to do anything. Advanced clients can still express their format preferences in a custom Accept header, which makes this scheme future-proof. 

The downside of using Accept headers is that advanced clients would need to manually request images to control the Accept header, which will have performance disadvantages vs. native image loading.

Since the need for explicit control should be rare, I think using the Accept header offers the better trade-offs overall.
I think it might be just a little misunderstanding. If you're talking about describing to the client what kind of media the original is, yes, a general category is probably fine. But the client needs to retain control of which mime type the thumbnail will be in. In order to avoid formats it might not support, etc. Since you bring up the Accept header, I assume that you're fine with that idea. What I think is a bad idea is the client only being able to request "bitmap" and getting a JPG, a PNG or a WEBP depending on criteria that only we know about without any way to control that.
> you could pass it through an anchor that wouldn't make it back server side. I.e. restbase or the API would give this to the client:  /someimage#o=vec&oh=1024&ow=768 This way we would avoid having to strip that context in Varnish and generally polluting the logs and information server-side with client-passed context that might actually not match the real values stored.

I really like this idea. It retains the advantage of encoding the information in a standard way in the URL, but avoids sending back unnecessary bits to the server. It follows the precedent of using url-encoded anchors in [media fragments](https://www.w3.org/TR/media-frags/). They are still straightforward to parse.

> Formats of the same "type" have fundamental differences already and you can't predict what new formats we'll support in the future. Knowing something is "vector" is of little use to the client if depending on the actual source file type one might not be able to convert it into some thumbnail types, etc.

I believe the conversion from vector (or video) to bitmap will always be possible, and is the conversion that is interesting to clients. Do you have concrete use cases in mind that would *require* more exotic format conversions, and aren't covered by the combination of Accept header, format selector, size & quality?

> Our current set of supported file types is too limited to know with certainty that this level of abstraction makes sense in a future-proof manner, and things will get very sketchy if we want to break an existing group like "vector" into subgroups in the future. If we start off with mime types, that never changes.

We could add an exact mime type in addition to the vector / bitmap / video distinction later (ex: `om=image/svg+xml`), if we find an actual use case that requires it. For current use cases, dealing with the low-level file types mostly seems to add unnecessary complexity to clients, and reduces flexibility for phasing in new formats on the server.
> you could pass it through an anchor that wouldn't make it back server side. I.e. restbase or the API would give this to the client:  /someimage#o=vec&oh=1024&ow=768 This way we would avoid having to strip that context in Varnish and generally polluting the logs and information server-side with client-passed context that might actually not match the real values stored.

I really like this idea. It retains the advantage of encoding the information in a standard way in the URL, but avoids sending back unnecessary bits to the server. It follows the precedent of using url-encoded anchors in [media fragments](https://www.w3.org/TR/media-frags/). They are still straightforward to parse.

> Formats of the same "type" have fundamental differences already and you can't predict what new formats we'll support in the future. Knowing something is "vector" is of little use to the client if depending on the actual source file type one might not be able to convert it into some thumbnail types, etc.

I believe the conversion from vector (or video) to bitmap will always be possible, and is the conversion that is interesting to clients. Do you have concrete use cases in mind that would *require* more exotic format conversions, and aren't covered by the combination of Accept header, format selector, size & quality?

> Our current set of supported file types is too limited to know with certainty that this level of abstraction makes sense in a future-proof manner, and things will get very sketchy if we want to break an existing group like "vector" into subgroups in the future. If we start off with mime types, that never changes.

We could add an exact mime type in addition to the vector / bitmap / video distinction later, if we find an actual use case that requires it. For current use cases, dealing with the low-level file types mostly seems to add unnecessary complexity to clients, and reduces flexibility for phasing in new formats on the server.
> you could pass it through an anchor that wouldn't make it back server side. I.e. restbase or the API would give this to the client:  /someimage#o=vec&oh=1024&ow=768 This way we would avoid having to strip that context in Varnish and generally polluting the logs and information server-side with client-passed context that might actually not match the real values stored.

I really like this idea. It retains the advantage of encoding the information in a standard way in the URL, but avoids sending back unnecessary bits to the server. It follows the precedent of using url-encoded anchors in [media fragments](https://www.w3.org/TR/media-frags/). They are still straightforward to parse.

> Formats of the same "type" have fundamental differences already and you can't predict what new formats we'll support in the future. Knowing something is "vector" is of little use to the client if depending on the actual source file type one might not be able to convert it into some thumbnail types, etc.

I believe the conversion from vector (or video) to bitmap will always be possible, and is the conversion that is interesting to clients. Do you have concrete use cases in mind that would *require* more exotic thumbnail conversions?

> Our current set of supported file types is too limited to know with certainty that this level of abstraction makes sense in a future-proof manner, and things will get very sketchy if we want to break an existing group like "vector" into subgroups in the future. If we start off with mime types, that never changes.

We could add an exact mime type in addition to the vector / bitmap / video distinction later, if we find an actual use case that requires it. For current use cases, dealing with the low-level file types mostly seems to add unnecessary complexity to clients, and reduces flexibility for phasing in new formats on the server.
> you could pass it through an anchor that wouldn't make it back server side. I.e. restbase or the API would give this to the client:  /someimage#o=vec&oh=1024&ow=768 This way we would avoid having to strip that context in Varnish and generally polluting the logs and information server-side with client-passed context that might actually not match the real values stored.

I really like this idea. It retains the advantage of encoding the information in a standard way in the URL, but avoids sending back unnecessary bits to the server. It follows the precedent of using url-encoded anchors in [media fragments](https://www.w3.org/TR/media-frags/). They are still straightforward to parse.

> Formats of the same "type" have fundamental differences already and you can't predict what new formats we'll support in the future. Knowing something is "vector" is of little use to the client if depending on the actual source file type one might not be able to convert it into some thumbnail types, etc.

I believe the conversion from vector (or video) to bitmap will always be possible, and is the only one that's interesting to clients. Do you have concrete use cases in mind that would *require* more exotic thumbnail conversions?

> Our current set of supported file types is too limited to know with certainty that this level of abstraction makes sense in a future-proof manner, and things will get very sketchy if we want to break an existing group like "vector" into subgroups in the future. If we start off with mime types, that never changes.

We could add an exact mime type in addition to the vector / bitmap / video distinction later, if we find an actual use case that requires it. For current use cases, dealing with the low-level file types mostly seems to add unnecessary complexity to clients, and reduces flexibility for phasing in new formats on the server.
> you could pass it through an anchor that wouldn't make it back server side. I.e. restbase or the API would give this to the client:  /someimage#o=vec&oh=1024&ow=768 This way we would avoid having to strip that context in Varnish and generally polluting the logs and information server-side with client-passed context that might actually not match the real values stored.

I really like this idea. It retains the advantage of encoding the information in a standard way in the URL, but avoids sending back unnecessary bits to the server. It follows the precedent of using url-encoded anchors in [media fragments](https://www.w3.org/TR/media-frags/). They are still straightforward to parse.

> Formats of the same "type" have fundamental differences already and you can't predict what new formats we'll support in the future. Knowing something is "vector" is of little use to the client if depending on the actual source file type one might not be able to convert it into some thumbnail types, etc.

I believe the conversion from vector (or video) to bitmap will always be possible, and is the only one that's interesting to clients. Do you have concrete use cases in mind that would *require* more exotic conversions?

> Our current set of supported file types is too limited to know with certainty that this level of abstraction makes sense in a future-proof manner, and things will get very sketchy if we want to break an existing group like "vector" into subgroups in the future. If we start off with mime types, that never changes.

We could add an exact mime type in addition to the vector / bitmap / video distinction later, if we find an actual use case that requires it. For current use cases, dealing with the low-level file types mostly seems to add unnecessary complexity to clients, and reduces flexibility for phasing in new formats on the server.
> you could pass it through an anchor that wouldn't make it back server side. I.e. restbase or the API would give this to the client:  /someimage#o=vec&oh=1024&ow=768 This way we would avoid having to strip that context in Varnish and generally polluting the logs and information server-side with client-passed context that might actually not match the real values stored.

I really like this idea. It retains the advantage of encoding the information in a standard way in the URL, but avoids sending back unnecessary bits to the server. It follows the precedent of using url-encoded anchors in [media fragments](https://www.w3.org/TR/media-frags/). They are still straightforward to parse.

> Formats of the same "type" have fundamental differences already and you can't predict what new formats we'll support in the future. Knowing something is "vector" is of little use to the client if depending on the actual source file type one might not be able to convert it into some thumbnail types, etc.

I believe the conversion from vector to bitmap will always be possible, and is the only one that's interesting to clients. Do you have concrete use cases in mind that would *require* more exotic conversions?

> Our current set of supported file types is too limited to know with certainty that this level of abstraction makes sense in a future-proof manner, and things will get very sketchy if we want to break an existing group like "vector" into subgroups in the future. If we start off with mime types, that never changes.

We could add an exact mime type in addition to the vector / bitmap / video distinction later, if we find an actual use case that requires it. For current use cases, dealing with the low-level file types mostly seems to add unnecessary complexity to clients, and reduces flexibility for phasing in new formats on the server.
>>! In T66214#2816123, @GWicke wrote:
> - Supply original format and size in the URL or metadata, and let the client choose between SVG originals & bitmap thumbs. Example using URL syntax: `/someimage?o=vec`
>   - `o=vec` or `o=vid` (metadata): Original is a vector image or video. Can consider omitting this for bitmaps (default).
>   - `oh=1024&ow=768` (metadata): Original width & height. Absent for SVGs when API or HTML use case recommends using SVG original.

I don't understand the obsession with passing context through useless query parameters. Clients already obtain the minimum information about the file in some way (image name/hash) they can fetch more context about the file from that same source before making a thumbnail request. It's not like we're running out of bits when we inform a client of a thumbnail and its corresponding file. There is absolutely no constraint forcing it to all be in a single field. And if there were, you could pass it through an anchor that wouldn't make it back server side. I.e. restbase or the API would give this to the client:  `/someimage#o=vec&oh=1024&ow=768` This way we would avoid having to strip that context in Varnish and generally polluting the logs and information server-side.

I still see the video/bitmap/vector abstraction in this latest example as misguided. Formats of the same "type" have fundamental differences already and you can't predict what new formats we'll support in the future. Knowing something is "vector" is of little use to the client if depending on the actual source file type one might not be able to convert it into some thumbnail types, etc. Our current set of supported file types is too limited to know with certainty that this level of abstraction makes sense in a future-proof manner, and things will get very sketchy if we want to break an existing group like "vector" into subgroups in the future. If we start off with mime types, that never changes.
@gilles, let me try to summarize how you see this working:

- We supply the exact original image format (svg, pdf, png, gif, tiff, jpg, webp-lossy, webp-lossless, videos) in URL or metadata.
- The client maintains some mapping of original to target format & quality, and rewrites URLs to match (or manually loads images, so that it can set Accept headers). For example, it would need to know that tiff & png originals are likely line art, and might map those to webp-lossless, but only if the client supports webp-lossless well.

Is this understanding correct?

Do you have a concrete use case in mind that requires this level of client-side control over which format to use? Would control over SVG vs. bitmap, quality & content negotiation for support issues be sufficient to cover the same use case?
@gilles, let me try to summarize how you see this working:

- We supply the exact original image format (svg, png, gif, tiff, jpg, webp-lossy, webp-lossless, videos) in URL or metadata.
- The client maintains some mapping of original to target format & quality, and rewrites URLs to match (or manually loads images, so that it can set Accept headers). For example, it would need to know that tiff & png originals are likely line art, and might map those to webp-lossless, but only if the client supports webp-lossless well.

Is this understanding correct?

Do you have a concrete use case in mind that requires this level of client-side control over which format to use? Would control over SVG vs. bitmap, quality & content negotiation for support issues be sufficient to cover the same use case?
@gilles, let me try to summarize how you see this working:

- We supply the exact original image format (svg, png, gif, tiff, jpg, webp-lossy, webp-lossless, videos) in URL or metadata.
- The client maintains some mapping of original to target format & quality, and rewrites URLs to match (or manually loads images, so that it can set Accept headers). For example, it would need to know that tiff & png originals are likely line art, and might map those to webp-lossless, but only if the client supports webp-lossless well.

Do you have a concrete use case in mind that requires this level of client-side control over which format to use? Would control over SVG vs. bitmap, quality & content negotiation for support issues be sufficient to cover the same use case?
If you're looking for hardware acceleration/battery saving, JPG is probably your best bet. If you want the most lightweight file, then Webp. Should the device you're working with be slow or buggy when dealing with a certain format, you might want to avoid it by requesting another one.

The majority of our content is on Commons where editors already use file formats according to the image contents. Eg. PNG is preferred for diagrams and JPG for photos. If you upload a diagram as a JPG you'll generally be advised to reupload it as PNG. The policy is well followed for photos and has allowed the community to put in place conditional sharpening parameters for JPGs that works well on photos but would make diagrams look terrible.
I don't see the search for the right granularity as a contradiction, but more as a search for the best set of trade-offs along a continuum. On one end, we have no client control & possibly server-side negotiation, while on the other end we have fine-grained client control without any content negotiation. The best set of trade-offs might not lie at the extremes of this spectrum. Lets continue to evaluate options against our use cases, and add use cases to the list in case any are missing.

> If you're going to override the automatic behavior, you should have precise control.

Can you think of use cases that would benefit from directly selecting jpg vs. png vs. webp lossy / lossless, rather than just vector vs. bitmap & quality level? Would those use cases need more information about the image contents (ex: line art vs. photo) to usefully pick the right format?
I don't see the search for the right granularity as a contradiction, but more as a search for the best set of trade-offs along a continuum. On one end, we have no client control & possibly server-side negotiation, while on the other end we have fine-grained client control without any content negotiation. The best set of trade-offs might not lie at the extremes of this spectrum. Lets continue to evaluate options against our use cases, and add use cases to the list in case any are missing.

> If you're going to override the automatic behavior, you should have precise control.

Can you think of use cases that would benefit from directly selecting jpg vs. png vs. webp lossy / lossless? Would those use cases need more information about the image contents (ex: line art vs. photo) to usefully pick the right format?
I don't see the search for the right granularity as a contradiction, but more as a search for the best set of trade-offs along a continuum. On one end, we have no client control & possibly server-side negotiation, while on the other end we have fine-grained client control without any content negotiation. The best set of trade-offs might not lie at the extremes of this spectrum. Lets continue to evaluate options against our use cases, and add use cases to the list in case any are missing.

> If you're going to override the automatic behavior, you should have precise control.

Can you think of use cases that would benefit from such fine-grained control? Would those use cases need more information about the image contents (ex: line art vs. photo) to usefully pick the right format?
There is contradiction here. You want to serve what's best for the client "automatically", but you want the client to retain some control just in case, but not too much as they can't pick the specific file format they're interested in. I think that while making some options more semantic makes sense, in the case of file formats it does not. Webp, JPG, PNG have very different properties and a client should be able to specifically pick one of those if it wants to. If you're going to override the automatic behavior, you should have precise control. Especially since something as simple semantically as "bitmap" can already contain webp, which definitely won't work on all devices. If the only thing the client can tell us about what it accepts is "bitmaps" we won't be able to tell if we can serve it a webp image.

As for the Accept header, if the client is using the native image fetching functions, said functions should advertise Accept headers that represent file types the device is capable of displaying. Having to use lower-level functions would only be necessary if the client wants to do something custom, like wanting a specific file format and no other. I think that's acceptable. You're point is full of assumptions about what people would implement and how they would go about it, I think it's a weak argument against dismissing a mechanism that's been a standard for decades for a client to declare what file types it can consume.
>>! In T66214#2805495, @Gilles wrote:
>>>! In T66214#2803304, @GWicke wrote:
>> However, in order to be able to select such a conversion where needed, clients will either need to know the original type before making the request, or will have to indicate a fixed desired type every time in order to avoid fragmentation (avoid optional default parameter).
> 
> How about Accept HTTP headers? That's a standard way for a client to advertise which MIME types it wants without knowing the content in advance.

I think Accept headers as great for selecting supported formats (such as jpg vs webm), but they aren't very usable for client-driven decisions around SVG vs. bitmaps, or bitmap thumb vs. video. To control the accept header, clients would need to use `fetch` or `xhr` to fetch images, instead of highly optimized native image loading. It might work better for video, but at the same time video needs more control over quality (adaptive streaming) than accept headers alone are intended to provide.

Generally, outside of video it seems that the main use case for client code driven format selection / behavior change are around vector vs. bitmap (without caring about the exact bitmap format), and quality. Something like `?f=bmp`, `?f=vec`, `?f=vid` should be sufficient to provide this information, and allow clients to choose between retrieving a vector original vs. requesting a bitmap thumbnail.
>>! In T66214#2805495, @Gilles wrote:
>>>! In T66214#2803304, @GWicke wrote:
>> However, in order to be able to select such a conversion where needed, clients will either need to know the original type before making the request, or will have to indicate a fixed desired type every time in order to avoid fragmentation (avoid optional default parameter).
> 
> How about Accept HTTP headers? That's a standard way for a client to advertise which MIME types it wants without knowing the content in advance.

I think Accept headers as great for selecting supported formats (such as jpg vs webm), but they aren't very usable for client-driven decisions around SVG vs. bitmaps, or bitmap thumb vs. video. To control the accept header, clients would need to use `fetch` or `xhr` to fetch images, instead of highly optimized native image loading. It might work better for video, but at the same time video needs more control over quality (adaptive streaming) than accept headers alone can provide.

Generally, outside of video it seems that the main use case for client code driven format selection / behavior change are around vector vs. bitmap (without caring about the exact bitmap format), and quality. Something like `?f=bmp`, `?f=vec`, `?f=vid` should be sufficient to provide this information, and allow clients to choose between retrieving a vector original vs. requesting a bitmap thumbnail.
>>! In T66214#2805495, @Gilles wrote:
>>>! In T66214#2803304, @GWicke wrote:
>> However, in order to be able to select such a conversion where needed, clients will either need to know the original type before making the request, or will have to indicate a fixed desired type every time in order to avoid fragmentation (avoid optional default parameter).
> 
> How about Accept HTTP headers? That's a standard way for a client to advertise which MIME types it wants without knowing the content in advance.

I think Accept headers as great for selecting supported formats (such as jpg vs webm), but they aren't very usable for client-driven decisions around SVG vs. bitmaps, or bitmap thumb vs. video. To control the accept header, clients would need to use `fetch` or `xhr` to fetch images, instead of highly optimized native image loading. For video, 

Generally, to me it seems that the main use cases for client code driven format selection / behavior change are around vector vs. bitmap (without caring about the exact bitmap format), and quality. Something like `?f=bmp`, `?f=vec`, `?f=vid` should be sufficient to provide this information, and allow clients to choose between retrieving a vector original vs. requesting a bitmap thumbnail.
>>! In T66214#2805495, @Gilles wrote:
>>>! In T66214#2803304, @GWicke wrote:
>> However, in order to be able to select such a conversion where needed, clients will either need to know the original type before making the request, or will have to indicate a fixed desired type every time in order to avoid fragmentation (avoid optional default parameter).
> 
> How about Accept HTTP headers? That's a standard way for a client to advertise which MIME types it wants without knowing the content in advance.

I think Accept headers as great for selecting supported formats (such as jpg vs webm), but they aren't very usable for client-driven decisions around SVG vs. bitmaps, or bitmap thumb vs. video. To control the accept header, clients would need to use `fetch` or `xhr` to fetch images, instead of highly optimized native image loading.
>>! In T66214#2803304, @GWicke wrote:
> However, in order to be able to select such a conversion where needed, clients will either need to know the original type before making the request, or will have to indicate a fixed desired type every time in order to avoid fragmentation (avoid optional default parameter).

How about Accept HTTP headers? That's a standard way for a client to advertise which MIME types it wants without knowing the content in advance.
>>! In T66214#2804824, @Tgr wrote:
> Re: type selection, we should use real file extensions (`/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12.png` instead of `/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?f=png`) otherwise we are probably going to trigger some mime type guessing bug in some obscure browser when used in HTML pages (thumbnails must work for [[https://www.mediawiki.org/wiki/Compatibility#Browsers|Grade C]] browsers).

Unless we have a specific list of UAs affected by a concrete problem, this is paranoia. I recall problems with URLs that would cause a mismatch (i.e. /foo-thumb.pdf but actually returning a jpeg), but not extension-less URLs.
Would the API cover `img_auth.php`? How about stashed uploads and thumbnails thereof (a horrible pile of hacks currently)? Or more generally the whole "zones" feature of FileRepo?
Re: original size in URL, beside feeling a bit hacky, there are some (minor) disadvantages: generating the URL to the original file based on the filename becomes more complicated (less of an issue if we use context-based addressing anyway), and B/C becomes more limited (for a MediaHandler which has not been updated, we probably want to use the old-style URL so that we prefer breaking clients doing URL rewriting over breaking displaying the file at all; and clients expecting the size to be in the URL would be more likely to break). Also, keep in mind that size information might get more complex than two numbers (e.g. SVGs have a nominal original size but can be scaled beyond that without loss of quality and we probably want to tell the client that).

Re: type selection, we should use real file extensions (`/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12.png` instead of `/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?f=png`) otherwise we are probably going to trigger some mime type guessing bug in some obscure browser when used in HTML pages (thumbnails must work for [[https://www.mediawiki.org/wiki/Compatibility#Browsers|Grade C]] browsers).

Re: format selection use cases, there is also language selection. But I don't think the API has to be aware of formats - they are just parameters to pass through.
In the same conversation, @Pchelolo brought up a potential issue around image format conversion / selection. We do have a need to support format conversions, for example a conversion from SVG to PNG. However, in order to be able to select such a conversion where needed, clients will either need to know the original type before making the request, or will have to indicate a fixed desired type every time in order to avoid fragmentation (avoid optional default parameter).

This requirement is similar to informing the client about original dimensions, except that the desired file type also //needs// to be sent to the API to avoid default parameter fragmentation. Since we also need to support uses without any rewriting (ex: HTML), including the file type in the URL (for example, as a query parameter) seems to make the most sense.

Example original URL, using query string syntax:
`/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?f=png`

Another (possibly prettier) option would be to use a custom file extension syntax, but the downside of this would be slightly more effort for parsing.

Edit: Thinking about this some more, I think we should detail a bit more which kind of control over the format we need. Aspects that come to mind:

- Quality selection (esp. for bitmaps). Coarse granularity (high, normal, low) is probably all we want to expose.
- Bitmap vs. vector graphics. Clients might want to load the original image in case it is an SVG. Specifying the size does not make sense for SVGs in general.
- Selecting a specific bitmap format. This seems questionable, but it's conceivable that there could be client support limitations that would make this useful.

Can we write down some use specific use cases for format / quality selection?
In the same conversation, @Pchelolo brought up a potential issue around image format conversion / selection. We do have a need to support format conversions, for example a conversion from SVG to PNG. However, in order to be able to select such a conversion where needed, clients will either need to know the original type before making the request, or will have to indicate a fixed desired type every time in order to avoid fragmentation (avoid optional default parameter).

This requirement is similar to informing the client about original dimensions, except that the desired file type also //needs// to be sent to the API to avoid default parameter fragmentation. Since we also need to support uses without any rewriting (ex: HTML), including the file type in the URL (for example, as a query parameter) seems to make the most sense.

Example original URL, using query string syntax:
`/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?f=png`

Another (possibly prettier) option would be to use a custom file extension syntax, but the downside of this would be slightly more effort for parsing.
@Anomie thanks… The explanation makes sense. 

@GWicke and I spoke at the Reading Services meeting and we are good to go - the content type is enough for the client to make decision on how to render the image - along with being able to deterministically request a specific file format.
@Fjalapeno, could you say a bit more about why knowing the content type *ahead of time* would be useful to you?
>>! In T66214#2799548, @Fjalapeno wrote:
> I was reading over some of the Strawman API  was wondering, is the response going to specify the file type? I couldn't quite tell.

The thumb API being discussed here serves the file data. It should include an appropriate Content-Type header in the HTTP response.

The details of other APIs that might return a pointer to the thumb API are probably out of scope here, even though such other APIs are mentioned.
I was reading over some of the Strawman API  was wondering, is the response going to specify the file type? I couldn't quite tell.

I ask, because for instance, the iOS app would need to handle SVGs differently than it handles handle PNGs (though it could handle both). So knowing the file type ahead of time would be convenient.
@Gilles, I mostly care about providing original dimensions in a uniform and convenient way across different formats (JSON and HTML). From my point of view, both a standardized JSON structure / HTML attributes, as well as URL parameters are workable, and both have advantages and disadvantages. Overall, I see URL parameters as slightly easier to use, easier to extend & more consistent across contexts, while separate attributes are conceptually cleaner, and avoid sending unnecessary information to the server.
As for face recognition to guide focused cropping, this is a functionality Thumbor provides out of the box. It even supports doing the computation remotely with a service called remotecv. Which can be useful for example if you want to run that part on servers that have GPUs, which can greatly accelerate face detection.

It's a project of its own to enable that in the Thumbor setup we have, though. This update of the thumbnail URL would probably be a blocker for it, as enabling this new functionality would require at least one new thumbnail parameter.
Passing context like the original dimensions seems like a hack. The thumbnailing server doesn't need it.

The API should be agnostic of specific use cases. This was easily solved in Media Viewer, I don't see why it couldn't be solved the same way in the API calls the apps get their thumb URLs from. Instead of only passing a thumb URL, also pass the original dimensions in additional properties. This is solvable right now, without the need for a thumbnail URL overhaul, the same way this problem was solved for Media Viewer almost 3 years ago.

Not every consumer of the API needs to rewrite existing thumbnail URLs. However, API calls that currently only provide the thumbnail URL as "information about a thumbnail" should be able to easily provide original dimensions as well. And any other additional context defined by specific use cases of that API call in the future.

Shoving all functional parameters in a single URL is crowded enough already, let's not add context that could be passed differently to the client and that the server rendering thumbnails doesn't care about.

I think you're conflating your specific needs and the API's needs, as if the thumbnail URL is the only thing that can be touched to achieve your goals.

And the extra metadata APIs should provide about thumbnails in addition to the thumbnail URL could be standardized or even defined in code.
The main potential benefit I see in encoding the original dimensions in the URL would be consistency across formats, and some ease of use from only having to pass the URL to a re-scale function. That said, with some effort we could probably get away with two alternate formats:

- HTML <img> tag: `data-file-{width,height}`, as used by MediaViewer.
- JSON: A structure like `{ src: "...", height: 1024: width: 768 }`, as proposed in the task description.

Compared to a URL only, it is slightly more work to pass those values into a scaling function.
The main benefit of encoding the original dimensions in the URL would be consistency across formats, and some amount of ease of use. That said, with some effort we could probably get away with two alternate formats:

- HTML <img> tag: `data-file-{width,height}`, as used by MediaViewer.
- JSON: A structure like `{ src: "...", height: 1024: width: 768 }`, as proposed in the task description.

Compared to a URL only, it is slightly more work to pass those values into a scaling function.
>>! In T66214#2787573, @Tgr wrote:
> Is there any situation where that information could not be easily provided alongside in a more structured way (HTML attribute or API reply field)?

Probably not. At least none that comes to mind right now. This idea came up since I was struggling a bit with also providing an answer for T149450#2783012.
>>! In T66214#2786657, @bearND wrote:
> Requirements for a long term solution should include, in addition to scaling, the ability to crop based on a focus area[1].

Cropping is {T9757}. (There are experimental services which do it: IIIF (T89552) and #imagetweaks. That's less useful than thumb URL integration of course.)

>>! In T66214#2786655, @bearND wrote:
> Another idea I brought up with GWicke on IRC yesterday is to embed the original dimensions in the URL (either as query parameters or in the path).

Is there any situation where that information could not be easily provided alongside in a more structured way (HTML attribute or API reply field)?
>>! In T66214#2786657, @bearND wrote:
>> look into which users rely on the current thumb format
> 
> The apps and MCS rely on the current thumb format to resize thumbnails downwards. If we could solve T75935 or T74328 the we could also use it to resize thumbnails upwards. That alone would solve our immediate needs.

Do you already have access to original dimensions in all cases? If not, then all this scaling (and especially scaling up) is likely to result in rounding errors when calculating the actual dimensions, which would lead to distorted / ugly display.

> Requirements for a long term solution should include, in addition to scaling, the ability to crop based on a focus area[1].
> 
> [1] That area is ideally user selectable but defaults to something based on face-detection. The apps could provide the face-detection and upload the desired coordinates to a server somewhere.

In the API requirements, this is covered by general key-value support. Adding the functionality is mostly a matter of implementing it in the backend, and adding the parameter.
>>! In T66214#2786655, @bearND wrote:
> Another idea I brought up with GWicke on IRC yesterday is to embed the original dimensions in the URL (either as query parameters or in the path). I don't want to call it a requirement at this time. Just something that could be useful to avoid having to also provide the original dimensions in other places, like the `data-file-*` attributes in HTML or additional width/height properties for the JSON case.

I think this is an intriguing possibility. This would encapsulate all information needed for scaling an image in just the URL. Example, using query string syntax:

`/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?oh=768&ow=1024`
More compact, but slightly custom syntax:
`/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?o=1024x768`

To avoid cache fragmentation, we would need to require these parameters in requests, and could also check that they do indeed match the original dimensions.

The main downside I see is slightly larger image URLs being sent back to the server. It's only a few bytes though, which seems unlikely to make a measurable performance difference in practice.
>>! In T66214#2786655, @bearND wrote:
> Another idea I brought up with GWicke on IRC yesterday is to embed the original dimensions in the URL (either as query parameters or in the path). I don't want to call it a requirement at this time. Just something that could be useful to avoid having to also provide the original dimensions in other places, like the `data-file-*` attributes in HTML or additional width/height properties for the JSON case.

I think this is an intriguing possibility. This would encapsulate all information needed for scaling an image in just the URL. Example, using query string syntax:

`/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?oh=768&ow=1024`
More compact, but custom syntax:
`/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?o=1024x768`

To avoid cache fragmentation, we would need to require these parameters in requests, and could also check that they do indeed match the original dimensions.

The main downside I see is slightly larger image URLs being sent back to the server. It's only a few bytes though, which seems unlikely to make a measurable performance difference in practice.
>>! In T66214#2786655, @bearND wrote:
> Another idea I brought up with GWicke on IRC yesterday is to embed the original dimensions in the URL (either as query parameters or in the path). I don't want to call it a requirement at this time. Just something that could be useful to avoid having to also provide the original dimensions in other places, like the `data-file-*` attributes in HTML or additional width/height properties for the JSON case.

I think this is an intriguing possibility. This would encapsulate all information needed for scaling an image in just the URL. Example, using query string syntax:

`/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?oh=768&ow=1024`

To avoid cache fragmentation, we would need to require these parameters in requests, and could also check that they do indeed match the original dimensions.

The main downside I see is slightly larger image URLs being sent back to the server. It's only a few bytes though, which seems unlikely to make a measurable performance difference in practice.
> look into which users rely on the current thumb format

The apps and MCS rely on the current thumb format to resize thumbnails downwards. If we could solve T75935 or T74328 the we could also use it to resize thumbnails upwards. That alone would solve our immediate needs.

Requirements for a long term solution should include, in addition to scaling, the ability to crop based on a focus area[1].

[1] That area is ideally user selectable but defaults to something based on face-detection. The apps could provide the face-detection and upload the desired coordinates to a server somewhere.
Another idea I brought up with GWicke on IRC yesterday is to embed the original dimensions in the URL (either as query parameters or in the path). I don't want to call it a requirement at this time. Just something that could be useful to avoid having to also provide the original dimensions in other places, like the `data-file-*` attributes in HTML or additional width/height properties for the JSON case.
Related: {T74328}, {T67383}, {T75935}
IRC meeting notes discussing this RFC: E355

Next steps:

1) look into which users rely on the current thumb format
2) investigate effort needed to clean up the mediahandler parameter parsing
3) discuss possible migration strategies with the traffic team
4) reconvene with the results.
> Maybe you didn't get it after all. There's nothing special about the "page" parameter, you could have the same problem with "t=0s" and several other options.

I think you'd agree that we shouldn't allow `q=default` or `crop=none` as an alias of omitting those parameters completely.
> and (generally) avoid specifying default values explicitly. (Exception might be the page parameter.)

Maybe you didn't get it after all. There's nothing special about the "page" parameter, you could have the same problem with "t=0s" and several other options.

> Server side requirements:
> 
> - Query string order normalization in Varnish (vmod)
> 
> *Cons*
> 
> - Familiar query string syntax, but has ordering requirement to avoid cache fragmentation.
>   - Need custom query string serialization in clients to avoid client cache fragmentation.
> - Need for query string normalization in Varnish (but would be generally useful).

You said the same thing ("query string normalization") four times. Either have Varnish do it and don't even check in the API, or just make the API either error or redirect.

BTW, your "/{size}{/bandwidth}" format is easy to misuse too, it could easily wind up with "/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/220/330/square if a client gets the "original spec" confused, and it'd be possible to get confused if someone's percent-encoder is tuned to not encode characters like ";" and "/" that aren't typically required to be encoded in the query portion of a URI when they're implementing special code to handle your custom format.
I would once again recommend that you write code that would parse, generate and cover a few known use cases for all considered schemes, in a language with decent URL parsing libraries. Limiting to bare bones string manipulation would skew things in favor of the custom formats, which I think is not a good benchmark based on modern development practices.

And I mean writing that code for the existing URI scheme and the two prototype versions discussed. A lot of judgement is made here about what is practical, what is easy, what mistakes are possible, without code consuming those schemes to demonstrate those hypothetical issues.

Between subjective calls on how "hard" something would be for client developers, to extreme examples of languages that have terrible hash behavior defaults in the context of URLs, I think the debate of the quality of each option is veering into very subjective and undemonstrative territory based on a growing army of straw men.

I think future-proofness is what matters most here, but the debate of which format is best in terms of developer perspective seems hard to avoid as it keeps coming up. I just don't see a resolution coming out of people arguing that one is best based on a very hypothetical scenario.
I would once again recommend that you write code that would parse, generate and cover a few known use cases for all considered schemes, in a language with decent URL parsing libraries. Limiting to bare bones string manipulation would skew things in favor of the custom formats, which I think is not a good benchmark based on modern development practices.

And I mean writing that code for the existing URI scheme and the two prototype versions discussed. A lot of judgement is made here about what is practical, what is easy, what mistakes are possible, without code consuming those schemes to demonstrate those hypothetical issues.

Between subjective calls on how "hard" something would be for client developers, to extreme examples of languages that have terrible hash behavior defaults in the context of URLs, I think the debate of the quality of each option is veering into very subjective and undemonstrative territory based on a growing army of straw men.
"Easy to select size and thumb type." How is it not easy in the second example? What constitutes "mis-use"?
I'm sorry but the pros and cons you've entered are completely biased and focus on very subjective properties.
The pros and cons of the current URI scheme should be included in the same matrix. Because you'll find that almost all of the upsides you're bringing up for the scheme currently in the task description also apply to the current scheme.
The point is that a custom ordered-querystring serialization function will be needed, while in the path-based API regular path manipulation functions will do the right thing wrt order.

I think it's time to start collecting pros & cons like these for the different options, and then discuss the overall tally. API design is about finding the best trade-offs between frequently conflicting requirements. Ease of use for the most common use cases is just one of those criteria.
You can look at any two formats and make up a use case that would be easier in one than the other. I don't think that should be the starting point of what the format is. That use case isn't very relevant in the infinite number of ways people might parse, transform and generate those URLs.
In both cases you need to parse a string and insert the value in the right place. I hope we're not going to design an API a certain way because we'd like a hypothetical developer to be able to deal with strings directly with explodes and appends rather than use a URL parsing method which nowadays should be available in all languages. If anything parsing and modifying a custom string format requires more lines of code than parsing a url and changing a value using a library designed for that.

And you're making such a specific use case a first class citizen. It can't be what defines the whole format. By definition an API can be used in many ways, including many we can't foresee.
@gilles: Having such author-supplied parameters in a query string means that changing the size is not just a matter of adding a *single* query parameter. This means that clients need to deal with the ordering issue, even if all they care about is the size.

Compared to a URL scheme where "advanced" (typically author-supplied) parameters are separate from the common width & thumb type, this complicates clients and makes using the API harder.
@gilles: Having such author-supplied parameters in a thumb means that changing the size is not just a matter of adding a *single* query parameter. This means that clients need to deal with the ordering issue, even if all they care about is the size.

Compared to a URL scheme where "advanced" (typically author-supplied) parameters are separate from the common width & thumb type, this complicates clients and makes using the API harder.
Provided by editors in the context of wikitext, yes. I thought you meant the media's author was somehow able to set default parameters.

That just means those parameters are optional. I don't see how that impacts ordering. In fact all parameters are optional if in the new scheme a lack of query parameters returns the original.
Provided by editors in the context of wikitext, yes. I thought you meant the media's author was somehow able to set default parameters.

That just means those parameters are optional. I don't see how that impacts ordering. In fact all parameter are optional if in the new scheme a lack of query parameters returns the original.
Provided by editors in the context of wikitext, yes. I thought you meant the media's author was somehow able to set default parameters.

That just means those parameters are optional. I don't see how that impacts ordering. In fact all parameter are optional if in the new scheme lacks of query parameters returns the original.
>>>! In T66214#2782454, @GWicke wrote:
>> This is because any thumbnail can have any number of author-supplied parameters already
> 
> Can you provide a concrete example? I don't think I'm familiar with that feature.

Many advanced parameters are mostly author-supplied. Examples: page number, video thumb offset, content language for SVGs

See brion's comment in T66214#1743938.

Regarding API versioning & stability: Of course we can't predict the future perfectly & need mechanisms for cleanly evolving our APIs without breaking existing clients. This doesn't mean though that we should throw all caution in the wind, and ignore versioning and validation rules, or make no effort to design APIs in a thoughtful way based on our best knowledge.
>>>! In T66214#2782454, @GWicke wrote:
>> This is because any thumbnail can have any number of author-supplied parameters already
> 
> Can you provide a concrete example? I don't think I'm familiar with that feature.

Many advanced parameters are mostly author-supplied. Examples: page number, video thumb offset, content language for SVGs

See brion's comment in T66214#1743938.
>>! In T66214#2782454, @GWicke wrote:
> The bigger issue I see with query strings is that (contrary to what I thought earlier) all clients really need to implement sorted query string serialization if they want to avoid fragmenting client-side caches.

I'm not opposed to this, although it does make it harder for humans to test it by putting URLs into the browser. But we'd also have to specify exactly which characters must and must not be percent-encoded (e.g. [a-zA-Z0-9._~-] must never be encoded and all others must always be) and clearly specify the sorting method (e.g. ASCIIbetical sort on encoded key=value pairs).

> This is because any thumbnail can have any number of author-supplied parameters already, and changing the size of the thumb will require rewriting the query string, preserving the order. This is a loss in usability compared to separating author-supplied parameters from size & quality parameters.

If size and quality are specified sanely as unique query parameters such as `size=$ABC` (or even `s=$ABC`) and `q=$XYZ`, I can't see any way that changing the specific values of $ABC or $XYZ would change the ordering of the parameters.
>>! In T66214#2782384, @Gilles wrote:
> In regards to the client cache fragmentation, I think most clients are consistent with themselves and that's what matters.

Not necessarily. A naive query-string builder based on a python dict or a perl hash, for example, is liable to have a random parameter ordering. Perl, in particular, [[http://perldoc.perl.org/perlsec.html#Algorithmic-Complexity-Attacks|intentionally randomizes the order of hash entries for security reasons]].
> Currently the Varnish task seem to only focus on parameter reordering, when this is already an early sign that as the URL scheme evolves we'll want more parsing and rewriting to happen than just reordering in order to avoid cache fragmentation through future updates of the URL scheme.

Maintaining all kinds of specific parameter validation and rewrite rules in Varnish, and keeping them in sync with the actual backend service does not sound very practicable. If we do our job of designing APIs right, then we shouldn't need to resort to such band-aids. For the case brought up by @anomie, there should really be little reason to bother stripping `page=1`. If we want to avoid that fragmentation internally, then we can return a redirect from the backend service for one of those, and set up a generic Varnish rule to follow those redirects on behalf of the client, avoiding round-trip penalties.

The bigger issue I see with query strings is that (contrary to what I thought earlier) all clients really need to implement sorted query string serialization if they want to avoid fragmenting client-side caches. This is because any thumbnail can have any number of author-supplied parameters already, and changing the size of the thumb will require rewriting the query string, preserving the order. This is a loss in usability compared to separating author-supplied parameters from size & quality parameters.
> Currently the Varnish task seem to only focus on parameter reordering, when this is already an early sign that as the URL scheme evolves we'll want more parsing and rewriting to happen than just reordering in order to avoid cache fragmentation through future updates of the URL scheme.

Maintaining all kinds of specific parameter validation and rewrite rules in Varnish, and keeping them in sync with the actual backend service does not sound very practicable. If we do our job of designing APIs right, then we shouldn't need to resort to such band-aids. For the case brought up by @anomie, there should really be little reason to bother stripping `page=1`.

The bigger issue I see with query strings is that (contrary to what I thought earlier) all clients really need to implement sorted query string serialization if they want to avoid fragmenting client-side caches. This is because any thumbnail can have any number of author-supplied parameters already, and changing the size of the thumb will require rewriting the query string, preserving the order. This is a loss in usability compared to separating author-supplied parameters from size & quality parameters.
>>! In T66214#2781793, @GWicke wrote:
> @anomie, I see- "page 1" being the default is indeed one way where there could be fragmentation. It might indeed make sense to make an exception to the "no fragmentation" rule in this case, and either return an identical thumbnail, or a HTTP redirect to the canonical version of this thumb.

Good. I don't really care about identical thumbnail versus HTTP redirect, I was just concerned that an HTTP error as you seemed to be saying would turn out to be problematic.

> In any case, existing clients wouldn't break, as none of them would be using the (new) page parameter.

They would if you added it as a non-optional parameter, per your earlier statement that optional parameters wouldn't be allowed.


>>! In T66214#2782399, @Gilles wrote:
> I think redirects should be a last resort. An extra round trip can be very costly for users in terms of performance. Even as a mechanism to encourage clients to update their code, it's an unnecessary punishment on users who don't know how to or can't update their dated clients. 

I think redirects are probably //essential//. You say that the performance impact of redirects as a mechanism to encourage clients to update their code is bad, but throwing fatal errors at them is far, far worse.

Sure, put a Varnish layer in front of the API as deployed for WMF to canonicalize the URLs as much as possible so the API itself doesn't have to return redirects. [[https://phabricator.wikimedia.org/T149408#2759693|But don't make a complicated Varnish layer be required for the API to be easily usable by clients of low-traffic installations.]]
>>! In T66214#2781793, @GWicke wrote:
> @anomie, I see- "page 1" being the default is indeed one way where there could be fragmentation. It might indeed make sense to make an exception to the "no fragmentation" rule in this case, and either return an identical thumbnail, or a HTTP redirect to the canonical version of this thumb.
> 
> In any case, existing clients wouldn't break, as none of them would be using the (new) page parameter.

I think redirects should be a last resort. An extra round trip can be very costly for users in terms of performance. Even as a mechanism to encourage clients to update their code, it's an unnecessary punishment on users who don't know how to or can't update their dated clients. Imho solving that at the URL sanitation level in Varnish is the way to go. Which means it should be part of the requirements for the software solution to that problem (which so far looks like a vmod, either bringing Etsy's up to date for Varnish 4 or writing a custom one). Currently the Varnish task seem to only focus on parameter reordering, when this is already an early sign that as the URL scheme evolves we'll want more parsing and rewriting to happen than just reordering in order to avoid cache fragmentation through future updates of the URL scheme.
The reason the current thumb URL format does not allow larger-than-original (and in most cases same-as-original) sizes is to avoid cache fragmentation (which could be circumvented in the reverse proxy but not in the client). If we decide dropping that optimization to be able to skip some imageinfo API calls is a good tradeoff, then we can keep the current URL syntax and make the original file some simple variation of that syntax (say `orig` instead of `123px`). That's a simple change, and would capture most benefits of the proposal. Granted the current URL format looks horrible, and the proposed one looks nice, but what the migration would entail is rewriting file URL generation/parsing in MediaWiki, updating every media handler extension, updating every client (or forcing their maintainers to update them), forcing everyone to change URL rewrite rules, changing VCL rules... That seems like a pretty high price to pay for aesthetics.
The reason the current thumb URL format does not allow larger-than-original (and in most cases same-as-original) sizes is to avoid cache fragmentation (which could be circumvented in the reverse proxy but not in the client). If we decide dropping that optimization to be able to skip some imageinfo API calls is a good tradeoff, then we can keep the current URL syntax and make the original file some simple variation of that syntax (say `orig` instead of `123px`). That's about ten lines of PHP changed, and would capture most benefits of the proposal. Granted the current URL format looks horrible, and the proposed one looks nice, but what the migration would entail is rewriting file URL generation/parsing in MediaWiki, updating every media handler extension, and updating every client (or forcing their maintainers to update them). That seems like a pretty high price to pay for aesthetics.
@anomie, I see- "page 1" being the default is indeed one way where there could be fragmentation. It might indeed make sense to make an exception to the "no fragmentation" rule in this case, and either return an identical thumbnail, or a HTTP redirect to the canonical version of this thumb.

In any case, existing clients wouldn't break, as none of them would be using the (new) page parameter.
@anomie, I see- "page 1" being the default is indeed one way where there could be fragmentation. It might indeed make sense to make an exception to the "no fragmentation" rule in this case, and either return an identical thumbnail, or a HTTP redirect to the canonical version of this thumb.

In any case, existing client wouldn't break, as none of them would be using the (new) page parameter.
Say we didn't already have a parameter to select the page of a PDF. Then we add the parameter. Either the parameter needs to be optional, so probably "/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?w=220" and "/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?page=1&w=220" return the same thing, or every client that doesn't know about the new page parameter (and so uses the first URL) starts getting errors. Or, I suppose, the interface could be strange and throw an error for page=1 but not any other (valid) page.
@anomie, adding parameters without changing the semantics of existing parameters won't break any existing clients, as none of those would be using the new parameter yet. In fact, this is another benefit of strict validation.

It's possible I misunderstood you, though. If so, could you elaborate?
>>! In T66214#2781285, @GWicke wrote:
> 2) Validate parameters in the backing service strictly, so that each unique thumb can only be accessed through one unique set of query parameters. No ignored or optional-default parameters can be allowed.

That could be problematic if at any point in the future we want to add additional parameters, since if you don't allow optional parameters then you'll be breaking every client in existence every time you do so.

For example, if we didn't already have a time-index parameter for thumbnailing videos, or a language parameter for SVGs, or a page parameter for PDFs, etc.
> the description mentions the response containing JSON

This is about other APIs, such as pageinfo & other references to thumbnails providing original dimensions along with the base thumb URL. It is not about the thumb API itself, which returns thumbnails.

> There is no example URL of the orthogonal case. Bandwidth is mentioned, but no example of its use is provided and even the path spec contradicts the "square" example.

The current strawman combines quality and format in a "type" parameter. Some examples for illustration:

```
# Low resolution (for mobile)
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/220/lowres
# Low resolution + square crop
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/220/lowres-square
# Extra high quality thumb
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/220/highres
# Default quality, square crop
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/220/square
```

If we used query strings in general for anything but the base image, this could look like this:

```
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?q=low&w=220
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?crop=square&q=low&w=220
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?q=high&w=220
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?crop=square&w=220
```

To make this work without fragmenting caches, we'd need:

1) Query string order normalization in Varnish: T138093
2) Validate parameters in the backing service strictly, so that each unique thumb can only be accessed through one unique set of query parameters. No ignored or optional-default parameters can be allowed. Only a single size spec can be used to select a given thumbnail size (`w` parameter bounding the width).
3) Query string order normalization in clients, to avoid client cache fragmentation.

Points 1) and 2) are very doable I think, but the third point somewhat complicates basic tasks like selecting the thumb size. However, if we assume that most clients *only* need to select the size & thus only need a single parameter, then this should be workable.
> the description mentions the response containing JSON

This is about other APIs, such as pageinfo & other references to thumbnails providing original dimensions along with the base thumb URL. It is not about the thumb API itself, which returns thumbnails.

> There is no example URL of the orthogonal case. Bandwidth is mentioned, but no example of its use is provided and even the path spec contradicts the "square" example.

The current strawman combines quality and format in a "type" parameter. Some examples for illustration:

```
# Low resolution (for mobile)
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/220/lowres
# Low resolution + square crop
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/220/lowres-square
# Extra high quality thumb
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/220/highres
# Default quality, square crop
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/220/square
```

If we used query strings in general for anything but the base image, this could look like this:

```
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?q=low&w=220
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?crop=square&q=low&w=220
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?q=high&w=220
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?crop=square&w=220
```

To make this work without fragmenting caches, we'd need:

1) Query string order normalization in Varnish: T138093
2) Validate parameters in the backing service strictly, so that each unique thumb can only be accessed through one unique set of query parameters. No ignored or optional-default parameters can be allowed. Only a single size spec can be used to select a given thumbnail size.
3) Query string order normalization in clients, to avoid client cache fragmentation.

Points 1) and 2) are very doable I think, but the third point somewhat complicates basic tasks like selecting the thumb size. However, if we assume that most clients *only* need to select the size & thus only need a single parameter, then this should be workable.
> the description mentions the response containing JSON

This is about other APIs, such as pageinfo & other references to thumbnails providing original dimensions along with the base thumb URL. It is not about the thumb API itself, which returns thumbnails.

> There is no example URL of the orthogonal case. Bandwidth is mentioned, but no example of its use is provided and even the path spec contradicts the "square" example.

The current strawman combines quality and format in a "type" parameter. Some examples for illustration:

```
# Low resolution (for mobile)
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/220/lowres
# Low resolution + square crop
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/220/lowres-square
# Extra high quality thumb
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/220/highres
# Default quality, square crop
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/220/square
```

If we used query strings in general for anything but the base image, this could look like this:

```
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?q=low&w=220
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?crop=square&q=low&w=220
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?q=high&w=220
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?crop=square&w=220
```

To make this work without fragmenting caches, we'd need:

1) Query string order normalization in Varnish: T138093
2) Validate parameters in the backing service strictly, so that each unique thumb can only be accessed through one unique set of query parameters. No ignored or optional-default parameters can be allowed. Only support one size spec for a given thumbnail size.
3) Query string order normalization in clients, to avoid client cache fragmentation.

Points 1) and 2) are very doable I think, but the third point somewhat complicates basic tasks like selecting the thumb size. However, if we assume that most clients *only* need to select the size & thus only need a single parameter, then this should be workable.
> the description mentions the response containing JSON

This is about other APIs, such as pageinfo & other references to thumbnails providing original dimensions along with the base thumb URL. It is not about the thumb API itself, which returns thumbnails.

> There is no example URL of the orthogonal case. Bandwidth is mentioned, but no example of its use is provided and even the path spec contradicts the "square" example.

The current strawman combines quality and format in a "type" parameter. Some examples for illustration:

```
# Low resolution (for mobile)
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/220/lowres
# Low resolution + square crop
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/220/lowres-square
# Extra high quality thumb
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/220/highres
# Default quality, square crop
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/220/square
```

If we used query strings in general for anything but the base image, this could look like this:

```
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?q=low&w=220
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?crop=square&q=low&w=220
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?q=high&w=220
/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?crop=square&w=220
```

To make this work without fragmenting caches, we'd need:

1) Query string order normalization in Varnish: T138093
2) Validate parameters in the service strictly, so that each unique thumb can only be accessed through one unique set of query parameters. No ignored or optional-default parameters can be allowed. Only support one size spec for a given thumbnail size.
3) Query string order normalization in clients, to avoid client cache fragmentation.

Points 1) and 2) are very doable I think, but the third point somewhat complicates basic tasks like selecting the thumb size. However, if we assume that most clients *only* need to select the size & thus only need a single parameter, then this should be workable.
There is no example URL of the orthogonal case. Bandwidth is mentioned, but no example of its use is provided and even the path spec contradicts the "square" example.

I'm now noticing something strange that I missed before, as the description mentions the response containing JSON? I would have expected that the response body would be the binary image, so that browsers can consume it directly in the no-JS case. Extra information like original URL path and original image dimensions can be passed via HTTP headers in the response, no need for JSON.

I like the idea of ensuring the ordering in Varnish, if it is possible. I haven't seen how that works in VCL, have you checked how that would be implemented? That would allow us to maintain flexibility on the client side, as the URL scheme could simply be the classic &= separated URL format we all know, for example. Which would allow many clients to leverage existing libraries to construct and parse URLs in that format (which I believe is just a very old convention). It would be the client's responsibility to have sensible consistency in ordering across requests for client caches' sake, but cache fragmentation on our end is entirely avoided and I think that's all we should worry about, as all the clients we'll be responsible for will follow best practices in that respect.
There is no example URL of the orthogonal case. Bandwidth is mentioned, but no example of its use is provided and even the path spec contradicts the "square" example.

I'm now noticing something strange that I missed before, as the description mentions the response containing JSON? I would have expected that the response body would be the binary image, so that browsers can consume it directly in the no-JS case. Extra information like original URL path and original image dimensions can be passed via HTTP headers in the response, no need for JSON.

I like the idea of ensuring the ordering in Varnish, if it is possible. I haven't seen how that works in VCL, have you checked how that would be implemented? That would allow us to maintain flexibility on the client side, as the URL scheme could simply be the classic &= separated URL format we all know, for example. Which would allow many clients to leverage existing libraries to construct and parse URLs in that format (which I believe is just a very old convention). It would be the client's responsibility to have sensible consistency in ordering across requests for client caches' sake, but cache fragmentation is entirely avoided and I think that's all we should worry about, as all the clients we'll be responsible for will follow best practices in that respect.
@gilles, there are several examples illustrating page and media thumbnails, as well as the (orthogonal) selection of size and thumb type / quality. The ordered key-value syntax can be used to encode rotation, cropping, effects, or other features we have not thought of yet. I'm happy to iterate through a couple of permutations if that would help to allay doubts. Dividing the API in an original spec (typically author-controlled) vs. the basic size & thumb type / quality selection was proposed by @brion earlier in this thread: T66214#1743938.

I don't have overly strong opinions on the exact separators used to encode the original spec. For example, we could also use query string syntax, following the example of [media fragments](https://www.w3.org/TR/media-frags/). As long as the format is hard to abuse, and avoids cache fragmentation, a lot of options can work. If we use query strings, then we might want to strongly consider normalizing the order of parameters in Varnish, as most query string libraries don't provide any order guarantees.
No examples of what rotation, cropping or effects would look like are provided.

No complex examples of current capabilities are provided either, like a PDF page in low quality. Which would bring up whether the proposed format enforces optional parameter ordering. This is a property that the current scheme has and ensure good caching. At the moment it seems like things aren't thought through enough. There is no edge against the status quo, because you mention upsides that are theoretical, with no examples to back them up.

To demonstrate sensibility of the proposed format, the most extreme example should be considered, just to get an idea of what it looks like to construct and parse such a URL.

For example I think that using 3 different separator characters in the examples needlessly complexities parsing those URLs. Writing PoC code that generates and parses those URLs would help guide the thinking here, imho. Even better if comparing that to functions that generate and parse the current URLs. Especially if we're going to enforce ordering to ensure caching that's as good as now. Which we probably should, with the anticipated expansion of available features.
> It seems to me like the goal is to simplify what's currently available, with no plan to add new features

The design is providing flexibility and extensibility in the specification of originals. I believe this covers the kind of extensions you mentioned when we last spoke about this, including rotation, cropping, or potentially effects. In order to avoid cache fragmentation, it defines simple deterministic rules for constructing the URL, and requires clients to adhere to them.

Most clients don't need to manipulate the more complex original specs, and we should aim to keep API usage for the common size & thumb type / quality selection as simple as possible. In the proposal, this is done by encoding those parameters in separate path components.

> You're basically solving your own problem and leaving a considerable technical debt project on mediawiki's doorstep for someone to be determined to care about. I.e. it will be some future person's job to migrate mediawiki, its extensions, etc. to use the new URL scheme.

Once we decide to switch to an official thumb API, then we should clearly switch over all uses of thumbnails in MediaWiki & other services. The fact that current thumb URLs are private implementation details helps us here, as we are free to change their structure at any time. To make this happen, we need to establish a roadmap & clear ownership of different parts of the migration process. This RFC is intended to move us closer to an agreement on how a proper thumb API will look, and should be the starting point for the development of a migration roadmap.

> Re-reading the older parts of the task description mentioning imageinfo, you don't need to call imageinfo to generate a thumbnail URL.

Current thumbnail URLs are private to MediaWiki, and are explictly not intended or designed to be used as APIs. Clients can ignore this rule, but will break once we change our private thumb URL structure, for example by introducing a documented, stable thumb API.
> It seems to me like the goal is to simplify what's currently available, with no plan to add new features

The design is providing flexibility and extensibility in the specification of originals. I believe this covers the kind of extensions you mentioned when we last spoke about this, including rotation, cropping, or potentially effects. In order to avoid cache fragmentation, it defines simple deterministic rules for constructing the URL, and requires clients to adhere to them.

Most clients don't need to manipulate the more complex original specs, and we should aim to keep API usage for the common size & thumb type / quality as simple as possible. In the proposal, this is done by encoding those parameters in separate path components.

> You're basically solving your own problem and leaving a considerable technical debt project on mediawiki's doorstep for someone to be determined to care about. I.e. it will be some future person's job to migrate mediawiki, its extensions, etc. to use the new URL scheme.

Once we decide to switch to an official thumb API, then we should clearly switch over all uses of thumbnails in MediaWiki & other services. The fact that current thumb URLs are private implementation details helps us here, as we are free to change their structure at any time. To make this happen, we need to establish a roadmap & clear ownership of different parts of the migration process. This RFC is intended to move us closer to an agreement on how a proper thumb API will look, and should be the starting point for the development of a migration roadmap.

> Re-reading the older parts of the task description mentioning imageinfo, you don't need to call imageinfo to generate a thumbnail URL.

Current thumbnail URLs are private to MediaWiki, and are explictly not intended or designed to be used as APIs. Clients can ignore this rule, but will break once we change our private thumb URL structure, for example by introducing a documented, stable thumb API.
> It seems to me like the goal is to simplify what's currently available, with no plan to add new features

The design is providing flexibility and extensibility in the specification of originals. I believe this covers the kind of extensions you mentioned when we last spoke about this, including rotation, cropping, or potentially effects. In order to avoid cache fragmentation, it defines simple deterministic rules for constructing the URL, and requires clients to adhere to them.

Most clients don't need to manipulate the more complex original specs though, and we should aim to keep API usage for the common size & thumb type / quality as simple as possible. In the proposal, this is done by encoding those parameters in separate path components.

> You're basically solving your own problem and leaving a considerable technical debt project on mediawiki's doorstep for someone to be determined to care about. I.e. it will be some future person's job to migrate mediawiki, its extensions, etc. to use the new URL scheme.

Once we decide to switch to an official thumb API, then we should clearly switch over all uses of thumbnails in MediaWiki & other services. The fact that current thumb URLs are private implementation details helps us here, as we are free to change their structure at any time. To make this happen, we need to establish a roadmap & clear ownership of different parts of the migration process. This RFC is intended to move us closer to an agreement on how a proper thumb API will look, and should be the starting point for the development of a migration roadmap.

> Re-reading the older parts of the task description mentioning imageinfo, you don't need to call imageinfo to generate a thumbnail URL.

Current thumbnail URLs are private to MediaWiki, and are explictly not intended or designed to be used as APIs. Clients can ignore this rule, but will break once we change our private thumb URL structure, for example by introducing a documented, stable thumb API.
> It seems to me like the goal is to simplify what's currently available, with no plan to add new features

The design is providing flexibility and extensibility in the specification of originals. I believe this covers the kind of extensions you mentioned when we last spoke about this, including rotation, cropping, or potentially effects. In order to avoid cache fragmentation, it defines simple deterministic rules for constructing the URL, and requires clients to adhere to them.

Most clients don't need to manipulate the more complex original specs though, and we should aim to keep API usage for the common size & thumb type / quality as simple as possible. In the proposal, this is done by encoding those parameters in separate path components.

> You're basically solving your own problem and leaving a considerable technical debt project on mediawiki's doorstep for someone to be determined to care about. I.e. it will be some future person's job to migrate mediawiki, its extensions, etc. to use the new URL scheme.

Once we decide to switch to an official thumb API, then we should clearly switch over all uses of thumbnails in MediaWiki & other services. The fact that current thumb URLs are private implementation details helps us here, as we are free to change their structure at any time. To make this happen, we need to establish a roadmap & clear ownership of different parts of the migration process. This RFC is intended to move us closer to an agreement on how a proper thumb API will look, and should be the starting point for the development of a migration roadmap.
>>! In T66214#2767815, @Gilles wrote:
> These issues have been decoupled. Thumbor is currently set to be a drop-in replacement for image scalers in Wikimedia production for public wikis. No functional, thumbnail URI change, etc. set to happen with Thumbor's initial deployment. "Just" switching from an open-source piece of stack to another, so to speak.

Projects which can get away with being Wikimedia-only (such as the mobile apps) could just use the Thumbor API directly, though. That seems like a much less ambitious project than replacing the MediaWiki thumb API.
> In the current examples, I think it's unfortunate that height-constraining isn't considered. Not as a feature that would be available immediately, but as something to take into account in the proposed URI format. The current examples perpetuate the idea of implied width-constraining always being present.

We could clearly allow arbitrary limits on width, height, or both. However, if we did this with different URLs, then this would fragment caches. Avoiding cache fragmentation is one of the explicit goals for this API.

The API strawman still supports limiting on either of those dimensions, provided that the original image's dimensions (or exact aspect ratio) are available to the client. This information is fairly easy to provide, and is in fact already provided in MediaWiki HTML for the benefit of the media viewer (see `data-file-{width,height}`).

Additionally, knowledge of original image dimensions enables the client to pre-calculate the exact thumb dimensions, which is important to avoid content jumping around during HTML rendering.

I added this explicitly in the strawman description. @gilles, thanks for bringing this up, it's a very good point!
> In the current examples, I think it's unfortunate that height-constraining isn't considered. Not as a feature that would be available immediately, but as something to take into account in the proposed URI format. The current examples perpetuate the idea of implied width-constraining always being present.

We could clearly allow arbitrary limits on width, height, or both. However, if we did this with different URLs, then this would fragment caches. Avoiding cache fragmentation is one of the explicit goals for this API.

The API strawman still supports limiting on either of those dimensions, provided that the original image's dimensions (or exact aspect ratio) are available to the client. This is information is easy to provide, and is in fact already provided in MediaWiki HTML for the benefit of the media viewer (see `data-file-{width,height}`).

Additionally, knowledge of original image dimensions enables the client to pre-calculate the exact thumb dimensions, which is important to avoid content jumping around during HTML rendering.

I added this explicitly in the strawman description. @gilles, thanks for bringing this up, it's a very good point!
> In the current examples, I think it's unfortunate that height-constraining isn't considered. Not as a feature that would be available immediately, but as something to take into account in the proposed URI format. The current examples perpetuate the idea of implied width-constraining always being present.

We could clearly allow arbitrary limits on width, height, or both. However, if we did this with different URLs, then this would fragment caches. Avoiding cache fragmentation is one of the explicit goals for this API.

The API strawman still supports limiting on either of those dimensions, provided that the original image's dimensions (or exact aspect ratio) are available to the client. This is information is easy to provide, and is in fact already provided in MediaWiki HTML for the benefit of the media viewer (see `data-file-{width,height}`).

Additionally, knowledge of original image dimensions enables the client to pre-calculate the exact thumb dimensions, which is important to avoid content jumping around during HTML rendering.
> In the current examples, I think it's unfortunate that height-constraining isn't considered. Not as a feature that would be available immediately, but as something to take into account in the proposed URI format. The current examples perpetuate the idea of implied width-constraining always being present.

We could clearly allow arbitrary limits on width, height, or both. However, this would fragment caches, and avoiding cache fragmentation is one of the explicit goals for this API.

The API strawman still supports limiting on either of those dimensions, provided that the original image's dimensions (or exact aspect ratio) are available to the client. This is information is easy to provide, and is in fact already provided in MediaWiki HTML for the benefit of the media viewer (see `data-file-{width,height}`).
In the current examples, I think it's unfortunate that height-constraining isn't considered. Not as a feature that would be available immediately, but as something to take into account in the proposed URI format. The current examples perpetuate the idea of implied width-constraining always being present.

In a way, the square example is a special case of defining both height and width constraints.

This is the sort of thing that might be more obvious by looking at other thumbnail URI schemes for inspiration, such as Thumbor's (probably a good idea to look at that considering it will be backing it) or IIIF. Thumbor in particular offers some features that will likely be the first requested additions to be publicly exposed, like smart cropping.

In we only consider existing features for the design of the new URI scheme, we risk reproducing the same mistaking of not planning enough for the future and ending up with something awkward-looking for the sake of backwards compatibility.

I've been considering as a follow-up project to the Thumbor deployment extracting Swift's rewrite.py into its own service to facilitate URI rewriting and Swift/Thumbor coordination. It would be the natural place to live for code to handle a new URI scheme such as what is proposed here. I.e. a service that would sit between varnish and swift/thumbor/mediawiki/whatever comes next.
In the current examples, I think it's unfortunate that height-constraining isn't considered. Not as a feature that would be available immediately, but as something to take into account in the proposed URI format.

In a way, the square example is a special case of defining both height and width constraints.

This is the sort of thing that might be more obvious by looking at other thumbnail URI schemes for inspiration, such as Thumbor's (probably a good idea to look at that considering it will be backing it) or IIIF. Thumbor in particular offers some features that will likely be the first requested additions to be publicly exposed, like smart cropping.

In we only consider existing features for the design of the new URI scheme, we risk reproducing the same mistaking of not planning enough for the future and ending up with something awkward-looking for the sake of backwards compatibility.

I've been considering as a follow-up project to the Thumbor deployment extracting Swift's rewrite.py into its own service to facilitate URI rewriting and Swift/Thumbor coordination. It would be the natural place to live for code to handle a new URI scheme such as what is proposed here. I.e. a service that would sit between varnish and swift/thumbor/mediawiki/whatever comes next.
>>! In T66214#2762226, @bearND wrote:
> In addition to that I'd like to know what the relationship between this task and the Thumbor project is. I don't see it tagged here.

These issues have been decoupled. Thumbor is currently set to be a drop-in replacement for image scalers in Wikimedia production for public wikis. No functional, thumbnail URI change, etc. set to happen with Thumbor's initial deployment. "Just" switching from an open-source piece of stack to another, so to speak.
>>! In T66214#2762226, @bearND wrote:
> In addition to that I'd like to know what the relationship between this task and the Thumbor project is. I don't see it tagged here.

These issues have been decoupled. Thumbor is currently set to be a drop-in replacement for image scalers in Wikimedia production for public wikis. No functional, thumbnail URI change, etc. set to happen with Thumbor's initial deployment.
I have refactored this RFC to focus on the public thumb API, and moved content hash based thumb naming to a sub-task.

We would like to tackle the public thumb API first, and expect to be able to move to content hash based thumb naming transparently at a later point.
In addition to that I'd like to know what the relationship between this task and the Thumbor project is. I don't see it tagged here.
We are continuing to bump into the basic issue of letting clients select thumb sizes, so would really like to start tackling that part of the problem soon.

@brion, has there been any movement on this during the off-site?
@GWicke Yes, I think we should revive it as part of a concerted effort between Editing/Parsing and Reading to improve image & multimedia handling. In particular we need to sync up parameter handling between the classic parser, parsoid, and things that use that output and then do other things (like media viewer widget) that want to be able to manipulate media parameters with fewer API roundtrips...

This'll go easier if I can get another engineer or two on board, we'll see. :) But I think the priority should be raising soon. (Editing dept offsite is next week, I will be lobbying people with specific ideas. ;)
@brion, this task looks pretty stalled by now. Do you see a chance for reviving it any time soon?
Discussed in {E148}.  Releve

3:00 PM <wm-labs-meetbot`> Minutes:        https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-03-16-21.00.html
3:00 PM <wm-labs-meetbot`> Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-03-16-21.00.txt
3:00 PM <wm-labs-meetbot`> Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-03-16-21.00.wiki
3:00 PM <wm-labs-meetbot`> Log:            https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-03-16-21.00.log.html

  * topic discussed: where we add extra parameters (page, time,
    language, etc) is the format sufficiently clearly specified?
    (robla, 21:04:13)
  * to discuss in future: implementation details for small/large
    installs (backlog)  (brion, 21:05:47)
  * avoiding cache fragmentation will require normalization of
    parameters (deterministic serialization of hashmap or other
    ordering)  (brion, 21:19:50)
  * daniel suggests having the failed-validation case be a redirect,
    gwicke warns they're expensive  (brion, 21:20:24)
  * normalizing parameters within varnish would be painful  (brion,
    21:20:43)

Log from this portion:
{P2778}
I have updated the task description to more clearly separate out use cases and requirements, especially for the API portion.
> What problem would such a VCL rule solve?

We need both a good long-term API design, as well as a migration strategy that lets us gradually move towards an API without throwing away existing caches. Such a VCL rule could potentially help with the migration.

I think we should first try to work out the requirements and at least a solid outline of a longer-term solution. While the migration path is important, it should not be the single concern dictating the design of the final API.
>>! In T66214#2114121, @GWicke wrote:
> This depends on how much information is available in the opaque id. For example, we could consider using the current thumb URL as the ID until we introduce hashes, which would leave the VCL to fill in the width parameter (if supplied). Format selection support could then be added at a later stage.

That seems somewhat pointless, given that the current thump URL is already an API capable of interpreting itself. What problem would such a VCL rule solve?
> Also, a 100% compatible VCL-layer mapping of nice URLs to old URL is just not gonna happen. For example the URL to a full-sized JPEG thumbnail is different depending on whether the JPEG has an EXIF rotation.

This depends on how much information is available in the opaque id. For example, we could consider using the current thumb URL as the ID until we introduce hashes, which would leave the VCL to fill in the width parameter (if supplied). Format selection support could then be added at a later stage.

It is also good to remember that the reason for doing this in VCL is performance for the common case. If there is a small percentage of requests that requires more complex rewriting during a transition period, then falling through to a backend service for those can be okay.
> What data is fetched and used before knowing what thumbnail to request?

Normally, no separate request should be needed beyond the original HTML or API request referencing the image:

- In a page, data attributes already indicate original dimensions.
- In API end points such as summary, relatedpages or imageinfo itself, we will provide at least:
  - the base thumb path
  - the original dimensions

Combined knowledge of a generally supported list of formats / qualities this is sufficient to build up the appropriate thumb URL by:

1) appending the size, and, optionally
2) appending the preferred format / quality parameter.
>>! In T66214#2106026, @Gilles wrote:
> Which means that a default implementation in mediawiki would have no use in production, as it's inefficient to query mediawiki for some translation before trying to hit swift if the thumbnail already exists.

Given that the old format is based on filenames and the new one on content hashes, MediaWiki would have to be queried anyway as there is no way to do that translation without a DB lookup.

Also it's generally best to keep frontend layers simple: forward misses to the MediaWiki API, and have the API set up the appropriate redirect in the frontend. Swift apparently has a [[ https://specs.openstack.org/openstack/swift-specs/specs/in_progress/symlinks.html | symlink API ]], not sure what's the equivalent in Varnish.
>>! In T66214#2106020, @Gilles wrote:
> What data is fetched and used before knowing what thumbnail to request?
* original size (cannot really be helped by the API, indeed)
* extension (e.g. .svg -> .svg.png) and whether this file type can be scaled beyond the original size (also cannot be helped, and is a global one-time lookup anyway)

Other info that's not required for looking up a thumbnail URL given a thumbnail URL of different size, but is required for looking up a thumbnail URL given a filename:
* filename hash (can be computed, but that's not the kind of thing you want to require a client to do)
* per-repo configuration (hash level, URL prefix, initial capital), based on which repo the file is in (which is typically not known by the client)
* content hash (in the future)

There are some idiosyncrasies which also prevent guessing the thumbnail URL but could be solved within the current system:
* the full URL, if requesting a size larger than or equal to the original
* knowing whether a thumbnail or the full URL must be requested when asking for the exact same size as the original (specifically for JPEG files, knowing whether they have an EXIF rotation)
* name reduction if the filename is longer than `abbrvThreshold`
>>! In T66214#2105215, @brion wrote:
>similar to how not-yet-cached thumbnail URLs are routed through MW's thumb.php and friends the first time.

The thumbnail URLs are passed verbatim to Swift, which does some translation inside a Swift plugin, checks whether it has a copy of the thumbnail, and then hits mediawiki if it doesn't have a copy.

This logic would have to be extracted out of Swift into its own service sitting in front of it, then that service extended for new things. Adding to the existing Swift plugin or to VCL are both undesirable.

Which means that a default implementation in mediawiki would have no use in production, as it's inefficient to query mediawiki for some translation before trying to hit swift if the thumbnail already exists.
>>! In T66214#2105215, @brion wrote:
>similar to how not-yet-cached thumbnail URLs are routed through MW's thumb.php and friends the first time.

The thumbnail URLs are passed verbatim to Swift, which does some translation inside a Swift plugin, checks whether it has a copy of the thumbnail, and then hits mediawiki if it doesn't have a copy.

This logic would have to be extracted out of Swift into its own service sitting in front of it, then that service extended for new things. Adding to the existing Swift plugin or to VCL are both undesirable.
>>! In T66214#2105088, @brion wrote:
> Currently this requires either an extra HTTPS round-trip for the 'imageinfo' API

What data is fetched and used before knowing what thumbnail to request? Original width? The API won't solve not knowing the original size. If it's a matter of always getting something back even when the original is smaller than the requested size, that's something that can be fixed now.
>>! In T66214#2105138, @Tgr wrote:
> IMO the two main questions here are:
> # is this going to be supported by MediaWiki or just by some external service (or Varnish hack)?

I think it would have to be supported by MediaWiki core (though as with many things, could be / will be in our usage enhanced by scary services/vasnish hacks). A default implementation could use a PHP endpoint similar to the existing img_auth.php and thumb.php

> # is it going to support all image parameters or just some common subset?

I think it would have to support all parameters that can affect the output image, otherwise you'd need to expose a second URL scheme for the actual generated thumbnails.

> Some considerations:
> * if we want to support all parameters, that should probably involve a new parameter specification/parsing interface for media handlers as the existing one is quite insane (basically just "get full thumbnail name, read/write your parameters" which in practice ends up in walking up the inheritance chain and throwing regexes at the string while trying to take the regexes used by all ancestors into account).

Agreed it's pretty awful at present.


>>! In T66214#2105146, @Tgr wrote:
> Also, a 100% compatible VCL-layer mapping of nice URLs to old URL is just not gonna happen. For example the URL to a full-sized JPEG thumbnail is different depending on whether the JPEG has an EXIF rotation.

I suspect this is another case where an initial mapping has to run through a service with some logic, similar to how not-yet-cached thumbnail URLs are routed through MW's thumb.php and friends the first time. Once the proper source file or internal redirect has been found it should be able to stay cached...

(Might make sense to do the mapping the other way as well; letting accesses of the old URLs map to their new locations.)
Also, a 100% compatible VCL-layer mapping of nice URLs to old URL is just not gonna happen. For example the URL to a full-sized JPEG thumbnail is different depending on whether the JPEG has an EXIF rotation.
IMO the two main questions here are:
# is this going to be supported by MediaWiki or just by some external service (or Varnish hack)?
# is it going to support all image parameters or just some common subset?

Some considerations:
* if the answer to #1 is no, the answer to #2 will be likewise, as MediaWiki extensions can add new thumbnail URL parameters.
* if this ends up WMF-only, we will have to support old-style URLs forever in MediaWiki and all tools that want to remain usable outside of WMF wikis - not a happy prospect in my opinion.
* if we end up not supporting all image parameters, then even WMF-specific tools might end up having to support both formats.
* if we want to support all parameters, that should probably involve a new parameter specification/parsing interface for media handlers as the existing one is quite insane (basically just "get full thumbnail name, read/write your parameters" which in practice ends up in walking up the inheritance chain and throwing regexes at the string while trying to take the regexes used by all ancestors into account).
Quick note from IRC regarding the thumb-URL needs for mobile apps/web:

The primary use case for mobile apps/web here is loading an appropriately-sized thumbnail of a given image as quickly as possible. Currently this requires either an extra HTTPS round-trip for the 'imageinfo' API, or rewriting the existing thumb URLs on the client and then working around the various edge cases (having to know that .svg thumbnails to .svg.png; handling failure cases when asking for a too-big size, knowing that very long filenames in thumbnail paths are sometimes rewritten to fit a length limit, etc). A cleaner, more consistent URL-based API will allow leaving the formatting and sizing questions to the server end.

Secondary use case: local caching of those images is simplified if the caching properties of those thumbnail URLs are more predictable.

Tertiary use case: there's a lot of use on mobile of squared-off images in lists/menus, and specially-cropped 'hero' images on articles. Having a cleaner thumb URL API should make it easier to extend it to move more of that cropping to the server-side, simplifying client code and reducing the amount of data transferred over mobile networks by pre-cropping unseen edges before download.
> What's the caching strategy for this API? Will it simply redirect/proxy

The most efficient option for introducing a thumb API is to rewrite requests in Varnish to directly map to the existing cached thumbs, thereby avoiding a duplication of cache entries. Given the simple URL structure, this should be relatively straightforward to do.

As with any API design, we need to consider future needs carefully, while also avoiding to get stuck forever by worrying about unknown unknowns. We know that we have a concrete need to let clients select thumb sizes and optionally the quality in a sane and cacheable manner, and this RFC discusses possible solutions. I personally think that the present design is also reasonably future-proof, allowing a future use of content-negotiation for both the size and density if client-side selection doesn't end up dominating.

@Gilles, do you have specific concerns or improvement ideas that you could share?
> What's the caching strategy for this API? Will it simply redirect/proxy

The most efficient option for introducing a thumb API is to rewrite requests in Varnish to directly map to the existing cached thumbs, thereby avoiding a duplication of cache entries. Given the simple URL structure, this is relatively straightforward to do.

As with any API design, we need to consider future needs carefully, while also avoiding to get stuck forever by worrying about unknown unknowns. We know that we have a concrete need to let clients select thumb sizes and optionally the quality in a sane and cacheable manner, and this RFC discusses possible solutions. I personally think that the present design is also reasonably future-proof, allowing a future use of content-negotiation for both the size and density if client-side selection doesn't end up dominating.

@Gilles, do you have specific concerns or improvement ideas that you could share?
> What's the caching strategy for this API? Will it simply redirect/proxy

The most efficient option for introducing a thumb API is to rewrite requests in Varnish to directly map to the existing cached thumbs, thereby avoiding a duplication of cache entries. Given the simple URL structure, this is relatively straightforward to do.

As with any API design, we need to consider future needs carefully, while also avoiding to get stuck forever by worrying about unknown unknowns. We know that we have a concrete need to let clients select thumb sizes and optionally the quality in a sane and cacheable manner, and this RFC discusses possible solutions. I personally think that the present design is also reasonably future-proof, allowing a future use of content-negotiation for both the size and density if client-side selection doesn't end up dominating.

@Gilles, do you have specific proposals for improving the API strawman?
We plan to discuss this in {E147}.  Based on the [2016-03-02 ArchCom meeting](https://www.mediawiki.org/wiki/Architecture_committee/2016-03-02) and what he said in T66214#2087161, I believe @GWicke hopes we can reach consensus on the format of a thumb API, possibly putting that aspect into last call.
> Do you think we should do them in a particular order?

From a user and API design perspective, I think the public thumb API is more urgent. It is also relatively easy to implement in a way that maps to our existing thumb caching & storage systems.

Moving to content hashes will require more serious backend work, as well as a translation layer. @Gilles and @aaron are working on this, but my understanding is that content hashes are still some ways out.

So, my proposal is to tackle the API first, and then move to hashes in a second step.
>>! In T66214#2087098, @GWicke wrote:
> This task is really discussing two separate issues, which can be tackled in separate phases:
> 
> 1) Define a thumb API, which lets clients easily select thumb size and quality. Define the image identifier as an opaque string. Examples: `/thumb/{id}/{size}{/quality_format}`, value `/thumb/Wiki.png/640`.
> 
> 2) Switch from name-based identifiers to hash + selector based IDs. Example value: `/thumb/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/640`.

Do you think we should do them in a particular order?
This task is really discussing two separate issues, which can be tackled in separate phases:

1) Define a thumb API, which lets clients easily select thumb size and quality. Define the image identifier as an opaque string. Examples: `/thumb/{id}/{size}{/quality_format}`, value `/thumb/Wiki.png/640`.

2) Switch from name-based identifiers to hash + selector based IDs. Example value: `/thumb/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12/640`.
Per T125865 and the [2016-02-10 ArchCom meeting](https://www.mediawiki.org/wiki/Architecture_committee/2016-02-10), I'm assigning this to @brion
@GWicke: how would you like to move forward on this?  This seems like a natural candidate for you to be the shepherd on per T125865, no?
The lack of a stable / simple thumb API is a serious issue for cacheable REST end points that contain a reference to a thumbnail, such as [the page summary end point](https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_summary_title), and an upcoming "related pages" end point.

We (#services) would like to make progress on the API portion along the lines of the task summary soon, and are willing to implement this in a way that maps to existing thumbnail backends. If there are no objections I am going to push for this RFC to be discussed soon.
@Tgr, less sophisticated clients shouldn't need to select more than size and quality in any case, which both are easy enough to get right.
The new thumbnail api, at least on Wikimedia, needs to support one more parameter (`qlow`), as I've found in T119797#1839787, which complicates things, unless we discard it in favor of something else, like a dedicated domain, a different entry point, etc

>>! In T119797#1839787, @tstarling wrote:
> JPEG thumbnails already support a quality parameter "qlow", which was added to support zero, for example with Arcimboldo_Librarian_Stokholm.jpg:
> 
> * [[https://upload.wikimedia.org/wikipedia/commons/thumb/7/76/Arcimboldo_Librarian_Stokholm.jpg/200px-Arcimboldo_Librarian_Stokholm.jpg|200px standard quality: 14,618 bytes]]
> * [[https://upload.wikimedia.org/wikipedia/commons/thumb/7/76/Arcimboldo_Librarian_Stokholm.jpg/qlow-200px-Arcimboldo_Librarian_Stokholm.jpg|200px low quality: 6,080 bytes]]
The new thumbnail api, at least on Wikimedia, needs to support one more parameter (`qlow`), as I've found in T119797#1839787, which complicates things, unless we discard it in favor of something else, a dedicated domain

>>! In T119797#1839787, @tstarling wrote:
> JPEG thumbnails already support a quality parameter "qlow", which was added to support zero, for example with Arcimboldo_Librarian_Stokholm.jpg:
> 
> * [[https://upload.wikimedia.org/wikipedia/commons/thumb/7/76/Arcimboldo_Librarian_Stokholm.jpg/200px-Arcimboldo_Librarian_Stokholm.jpg|200px standard quality: 14,618 bytes]]
> * [[https://upload.wikimedia.org/wikipedia/commons/thumb/7/76/Arcimboldo_Librarian_Stokholm.jpg/qlow-200px-Arcimboldo_Librarian_Stokholm.jpg|200px low quality: 6,080 bytes]]
I don't think there is much overlap between the people who use broken clients and those for whom performance matters to such an extent that an extra redirect becomes problematic.
> redirects are expensive

Much more expensive is terminating once-valid URLs. Still looking for an answer to:

>>! In T66214#1855231, @Nemo_bis wrote:
> Yes, but content of an image can vary and so will the hash-based URL. Will every single hash-based URL keep working forever?

To the benefit of the mass of MediaWiki users it would also be nice to explicitly know whether this feature will cater to:
* wikis running on Windows, which naturally have issues with filenames (T3780, already in blocked tasks);
* wikis for which it's too hard to set up a thumb handler with the current mechanism  (https://www.mediawiki.org/wiki/Manual:Thumb.php), ideally by making thumbnails fully work in vanilla MediaWiki (cf. {T58926}, {T27958}, {T67220}; things got better now with {T114098}).
@Anomie, redirects are expensive, and are easy to overlook by broken clients. Failing fast & loudly makes sure that broken clients are fixed quickly, rather than creating a hidden performance regression. The number of advanced clients with a need to manipulate `hash_spec` should be very small in any case.
>>! In T66214#1867845, @GWicke wrote:
> Requests with `hash_spec`s not conforming to this would be rejected as invalid by the API.

That doesn't seem particularly user-friendly. Any reason not to 301 redirect to the canonical ordering instead of a 500?
> What if you have a format that supports both animation/pagination and i18n (e.g. an animated SVG or a multi-language PDF)? At that point, why have the size as "/200" instead of ";size=200"?

@Anomie, most clients want to select the size and image quality, so we should make it extra easy to do so. The `hash_spec` with options like time selection on the other hand needs to follow very strict rules to be deterministic, and will generally be supplied by the server / API. If there are multiple parameters, they will need to be specified in a deterministic order and syntax. Requests with `hash_spec`s not conforming to this would be rejected as invalid by the API.

> To use a newly-uploaded version of an image, the page would have to be reparsed to reference the hash of the newly-uploaded version.

Pages are already re-parsed when images referenced in them are re-uploaded. This is to make sure that image dimensions and other metadata is correct.

> Why do you only want to support square bounding boxes?

Of all the fixed bounding boxes, the square one has the advantage of offering reasonably-sized images independent of aspect ratio. It is also the typical choice in other APIs such as [flickrs](https://www.flickr.com/services/api/misc.urls.html).

As mentioned earlier, most clients have access to the original image dimensions from an API response, or the data attributes in HTML. This means that they can select arbitrary image sizes for their application with some simple math, independent of the bounding box scheme used.
> What if you have a format that supports both animation/pagination and i18n (e.g. an animated SVG or a multi-language PDF)? At that point, why have the size as "/200" instead of ";size=200"?

@Anomie, most clients want to select the size and image quality, so we should make it extra easy to do so. The `hash_spec` with options like time selection on the other hand needs to follow very strict rules to be deterministic, and will generally be supplied by the server / API. If there are multiple parameters, they will need to be specified in a deterministic order and syntax. Requests with `hash_spec`s not conforming to this would be rejected as invalid by the API.

> To use a newly-uploaded version of an image, the page would have to be reparsed to reference the hash of the newly-uploaded version.

Pages are already re-parsed if images referenced in them are re-uploaded. This is to make sure that image dimensions and other metadata is correct.

> Why do you only want to support square bounding boxes?

Of all the fixed bounding boxes, the square one has the advantage of offering reasonably-sized images independent of aspect ratio. It is also the typical choice in other APIs such as [flickrs](https://www.flickr.com/services/api/misc.urls.html).

As mentioned earlier, most clients have access to the original image dimensions from an API response, or the data attributes in HTML. This means that they can select arbitrary image sizes for their application with some simple math, independent of the bounding box scheme used.
> What if you have a format that supports both animation/pagination and i18n (e.g. an animated SVG or a multi-language PDF)? At that point, why have the size as "/200" instead of ";size=200"?

@Anomie, most clients only care about the size and image quality, so we should make it easy to change that. The `hash_spec` with options like time selection on the other hand needs to follow very strict rules to be deterministic, and will generally be supplied by the server / API. If there are multiple parameters, they will need to be specified in a deterministic order and syntax. Requests with `hash_spec`s not conforming to this would be rejected as invalid by the API.

> To use a newly-uploaded version of an image, the page would have to be reparsed to reference the hash of the newly-uploaded version.

Pages are already re-parsed if images referenced in them are re-uploaded. This is to make sure that image dimensions and other metadata is correct.

> Why do you only want to support square bounding boxes?

Of all the fixed bounding boxes, the square one has the advantage of offering reasonably-sized images independent of aspect ratio. It is also the typical choice in other APIs such as [flickrs](https://www.flickr.com/services/api/misc.urls.html).

As mentioned earlier, most clients have access to the original image dimensions from an API response, or the data attributes in HTML. This means that they can select arbitrary image sizes for their application with some simple math, independent of the bounding box scheme used.
> What if you have a format that supports both animation/pagination and i18n (e.g. an animated SVG or a multi-language PDF)? At that point, why have the size as "/200" instead of ";size=200"?

@Anomie, most clients only care about the size and image quality, so we should make it easy to change that. The `hash_spec` with options like time selection on the other hand needs to follow very strict rules to be deterministic, and will generally be supplied by the server / API. If there are multiple parameters, they will need to be specified in a deterministic order (like alphabetically). Other orders need to be rejected as invalid.

> To use a newly-uploaded version of an image, the page would have to be reparsed to reference the hash of the newly-uploaded version.

Pages are already re-parsed if images referenced in them are re-uploaded. This is to make sure that image dimensions and other metadata is correct.
> What if you have a format that supports both animation/pagination and i18n (e.g. an animated SVG or a multi-language PDF)? At that point, why have the size as "/200" instead of ";size=200"?

@Anomie, most clients only care about the size and image quality, so we should make it easy to change that. The `hash_spec` with options like time selection on the other hand needs to follow very strict rules to be deterministic, and will generally be supplied by the server / API. If there are multiple parameters, they will need to be specified in a deterministic order (like alphabetically). Other orders need to be rejected as invalid.

> To use a newly-uploaded version of an image, the page would have to be reparsed to reference the hash of the newly-uploaded version.

This is already the case, as aspect ratios often change on re-upload.
> What if you have a format that supports both animation/pagination and i18n (e.g. an animated SVG or a multi-language PDF)? At that point, why have the size as "/200" instead of ";size=200"?

@Anomie, most clients only care about the size and image quality, so we should make it easy to change that. The `hash_spec` with options like time selection on the other hand needs to follow very strict rules to be deterministic, and will generally be supplied by the server / API. If there are multiple parameters, they will need to be specified in a deterministic order (like alphabetically). Other orders need to be rejected as invalid.
@jhobs, @yurik: another one that may interact with https://github.com/wikimedia/mediawiki-extensions-ZeroBanner/blob/e21286bf61f454a106cea5b9c728247ae2dbbc0c/includes/PageRendering.php#L1104.

Reading apps and web crew: this is probably for tracking, but it's worth tracking in case there are any assumptions (e.g., regexes) about URL format for media.

This is a tentative Q3 goal per https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q3_Goals#Performance.
>>! In T66214#1862573, @Anomie wrote:
> Why do you only want to support //square// bounding boxes? It doesn't seem particularly unlikely that a client has a rectangular bounding box to fill. If you only support square boxes, the client has to separately query the image's dimensions to decide what square bounding box to supply to the thumbnailer.

I guess the client can get the dimensions when it requests the sha of the image. I mean, any particular client would already need to query the api to get the sha of the image to use it in the thumb URL
Thanks @GWicke for your thorough explanation. I was wondering why not pick the same semantics as wikitext, but it makes sense to use bounding box dimensions for the api.
this would effectively make 2 identical files with different name to get the same URL in this scenario. That's pretty good.

As for the size parameter, it's the width of the bounding box (with variable height depending on the dimensions of the image) or just a maximum width and height?. I'd expect the first, since that will provide room for, at a later date, extend it to specify height only (`/x150`) or maximum width and height (`/200x150`), following the current thumbnail syntax in wikitext.
>>! In T66214#1854334, @ori wrote:
>>>! In T66214#1854329, @Nemo_bis wrote:
>> How would permalinks work in such a scenario? It's very important for URLs to keep functioning forever, unless the file (or file revision) is deleted.
> 
> There would be a mapping of old URLs to content-based URLs, which we'd just keep around forever.

Yes, but content of an image can vary and so will the hash-based URL. Will every single hash-based URL keep working forever?
Based on the earlier discussion with @brion (especially T66214#1743938), @BGerstle-WMF, @Tgr and others, I extended the task description with a section describing a possible stable thumb API layout that lets clients dynamically select thumb size and format/quality.
Based on the earlier discussion with @brion (especially T66214#1743371), @BGerstle-WMF, @Tgr and others, I extended the task description with a section describing a possible stable thumb API layout that lets clients dynamically select thumb size and format/quality.
Based on the earlier discussion with @brion (especially T66214#1743938), @BGerstle-WMF, @Tgr and others, I extended the task description with a section describing a possible stable thumb API layout that lets clients dynamically select thumb size and format/quality.
Based on the earlier discussion with @brion (especially T66214#1743938), @BGerstle-WMF, @Tgr and others, I extended the task description with a section describing a possible stable thumb API layout that lets clients dynamically select thumb size and format/quality.
Based on the earlier discussion with @brion, @BGerstle-WMF, @Tgr and others, I extended the task description with a section describing a possible stable thumb API layout that lets clients dynamically select thumb size and format/quality.
>>! In T66214#1854329, @Nemo_bis wrote:
> How would permalinks work in such a scenario? It's very important for URLs to keep functioning forever, unless the file (or file revision) is deleted.

There would be a mapping of old URLs to content-based URLs, which we'd just keep around forever.
How would permalinks work in such a scenario? It's very important for URLs to keep functioning forever, unless the file (or file revision) is deleted.
This doesn't really **block** T89971, but if the sort of thing being discussed here happens then one of the more nebulous bits of that (fixing iiurlwidth/iiurlheight/iiurlparam into something multi-valued but still sane) would just go away since we could just point to the "/api/rest_v1/media/img/{original-sha1}" bit and let the client fill in the width/height/page/seek-time/language/etc. when it talks to that endpoint.

But that, of course, depends on (1) someone actually working on this any time soon and (2) the end result actually existing for all MediaWiki installations and not just as an optional bespoke service like too many things seem to be planned as these days.
T117082 is an example for how better support for client-side thumb size selection would simplify the API design for end points like page previews.
Imageinfo responses are perfectly cacheable (apart from invalidation when the file changes, but that's a generic problem with the action API (or, rather, with varnish) and not easy to solve). That said, they are a distraction. Most of the time, clients want the image, not information about the image. IIRC when we were writing MediaViewer, using the API to fetch image URLs would have been a 200ms delay for the median user. I'm sure it's much less after the HHVM switch but even cutting down a few dozen ms is a win.
We recently considered making imageinfo responses cacheable in T116840, but in a subsequent discussion @tstarling made good points about the current response & associated APIs not facilitating client-side decisions on dimensions, format or quality. There are a lot of irregularities around multi-page images, vector and video formats etc that are currently left to the client to figure out, and all this is ignoring that our thumb urls are not considered a public API.

To address the need for more client-side control over thumb parameters, as well as improved caching of image metadata responses, it seems that we'll need to address the thumb URL as API question raised in the discussion on this task. The move to content-based addressing seems to provide a good opportunity to do this.
@brion: In your distinction, the 'author-supplied' parameters are all closely related to selecting the base image for a thumb. I wonder if we could leverage a syntax similar to section identifiers for this:

- `p=20` for page selection
- `t=20` for time offset selection (following the HTML5 temporal fragment standard)
- `lang=en` for the language

Example URL, using `;` as delimiter: `/api/rest_v1/media/img/90edff310ba1420a7b6e2e5f49a0820c96450a35;t=20/{size}`

Instead of using the width, we could also consider interpreting the size parameter as a square bounding box. This would be more useful for preview applications where the image has to fit in a limited space, and would still support retrieval of exact widths / heights if the client has information about the original dimension and thus the aspect ratio. This is for example true for Parsoid HTML, which provides the original dimensions in data attributes.
 
> With sizes we also have the question of whether to again support every size under the sun or specific size steps. 

We have discussed limiting thumb sizes a couple of times before, without a clear consensus. I don't think that this is necessarily an issue for the API, though. If we determine that client-side re-scaling quality is acceptable, we can start to return approximate (rounded) thumbs in response to requests for odd numbers later.

> Video derivatives are produced at specific size steps... but per video convention, based on a max height, not a specific width. If this is an API, then either we need to accept any input parameter and return a sensible file, or clients have to know what the acceptable set of sizes they can specify is.

I think it makes sense to focus on the thumb use case first, as the considerations for video are quite different. For example, we might want to move to manifest files for adaptive streaming with MPEG-DASH (see T44591), which could again be stored using the original video file's hash.
@brion: In your distinction, the 'author-supplied' parameters are all closely related to selecting the base image for a thumb. I wonder if we could leverage a syntax similar to section identifiers for this:

- `p=20` for page selection
- `t=20` for time offset selection (following the HTML5 temporal fragment standard)
- `lang=en` for the language

Example URL, using `;` as delimiter: `/api/rest_v1/media/img/90edff310ba1420a7b6e2e5f49a0820c96450a35;t=20/{size}`

Instead of using the width, we could also consider interpreting the size parameter as a square bounding box. This would be more useful for preview applications where the image has to fit in a limited space, and would still support retrieval of exact widths / heights if the client has information about the original dimension and thus the aspect ratio. This is for example true for Parsoid HTML, which provides the original dimensions in data attributes.
 
> With sizes we also have the question of whether to again support every size under the sun or specific size steps. 

We have discussed limiting thumb sizes a couple of times before, without a clear consensus. I don't think that this is necessarily an issue for the API, though. If we determine that client-side re-scaling quality is acceptable, we can start to return approximate (rounded) thumbs in response to requests for odd numbers later.

> Video derivatives are produced at specific size steps... but per video convention, based on a max height, not a specific width. If this is an API, then either we need to accept any input parameter and return a sensible file, or clients have to know what the acceptable set of sizes they can specify is.

I think it makes sense to focus on the thumb use case first, as the considerations for video are quite different. For example, we might want to move to manifest files for adaptive streaming with MPEG-DASH, which could again be stored using the original video file's hash.
@brion: In your distinction, the 'author-supplied' parameters are all closely related to selecting the base image for a thumb. I wonder if we could leverage a syntax similar to section identifiers for this:

- `p=20` for page selection
- `t=20` for time offset selection (following the HTML5 temporal fragment standard)
- `lang=en` for the language

Example URL, using `;` as delimiter: `/api/rest_v1/media/img/90edff310ba1420a7b6e2e5f49a0820c96450a35;t=20/{size}`

Instead of using the width, we could also consider interpreting the size parameter as a square bounding box. This would be more useful for preview applications where the image has to fit in a limited space, and would still support retrieval of exact widths / heights if the client has information about the original dimension and thus the aspect ratio.
 
> With sizes we also have the question of whether to again support every size under the sun or specific size steps. 

We have discussed limiting thumb sizes a couple of times before, without a clear consensus. I don't think that this is necessarily an issue for the API, though. If we determine that client-side re-scaling quality is acceptable, we can start to return approximate (rounded) thumbs in response to requests for odd numbers later.

> Video derivatives are produced at specific size steps... but per video convention, based on a max height, not a specific width. If this is an API, then either we need to accept any input parameter and return a sensible file, or clients have to know what the acceptable set of sizes they can specify is.

I think it makes sense to focus on the thumb use case first, as the considerations for video are quite different. For example, we might want to move to manifest files for adaptive streaming with MPEG-DASH, which could again be stored using the original video file's hash.
It probably makes sense to conceptually separate the params into author-supplied and client-selectable portions:

Author-supplied:
* page (if relevant - PDF/DjVu/TIFF)
* seek time (if relevant - WebM/Ogg)
* text rendering language (if relevant - localizable SVGs)

Client-selectable:
* target size (width and/or height?)
* output format (potential to override default .png/.jpg output with .webp or other formats in future)

With sizes we also have the question of whether to again support every size under the sun or specific size steps. Video derivatives are produced at specific size steps... but per video convention, based on a max height, not a specific width. If this is an API, then either we need to accept any input parameter and return a sensible file, or clients have to know what the acceptable set of sizes they can specify is.

Ditto with output formats -- if we support only .png for SVG rasterization, but either .png or .jpg (or .png or .jpg or .webp someday?) as options for PDF .... how does the client know which to safely select from?
@brion, that is indeed a long list of optional parameters, and will require some thinking to accommodate in a clean and cacheable API. 

Generally, I think the APIs we are defining for media are public in any case; cached and stored content relies on those APIs being reasonably stable. It's worth using an opportunity like the move to content-addressable media to clean them up.
We know we already have parameters for width (base images), page (SVG, PDF, etc), thumbtime (TimedMediaHandler), and language (SVG). Custom handlers, or additional extensions, could add more.

Additionally we have the format conversions, where we currently add a second extension ('.svg.png', '.djvu.jpg', whatever); we may want to add additional output formats such as .webp.

Further, we have derivative files for TimedMediaHandler -- transcodes to various output formats at various bitrates and resolutions, which are currently stashed in similar infrastructure to the thumbnail images but not in the same place.

So if we're going to make those URLs predictable instead of extensible, we need to at least cover all that territory...?
@GWicke +1, having a RESTful interface for requesting thumbnails would be nice.  Your suggestion, however, assumes prior knowledge of the "prefix," which might not always be at hand.  IMHO, ideally, the interface would only require clients to specify the filename/hash/identifier and (optionally) desired width.  That way clients can:

- Prevent automatic downloads of images—even when offscreen
- Have more control over image thumbnails that are downloaded, which allows for: 
  - taking advantage of high-bandwidth, high DPI situations
  - requesting lower-res thumbnails initially in case the user is on a slow connection
  - rendering images at the width of the device w/o scaling artifacts
New thumb paths should ideally follow a very regular structure worthy of a public API. Clients might want to rewrite the thumb dimensions (and possibly, quality / format, page, ...), so having the width and other parameters in a deterministic and easy-to-parse / replace location would be useful.

Strawman url for a basic thumb: `/api/rest_v1/media/img/{original-sha1}/{width}`

Edit: Modified strawman URL to clarify that the 'prefix' is a path to a stable API entry point.
New thumb paths should ideally follow a very regular structure worthy of a public API. Clients might want to rewrite the thumb dimensions (and possibly, quality / format, page, ...), so having the width and other parameters in a deterministic and easy-to-parse / replace location would be useful.

Strawman url: `/api/rest_v1/media/img/{original-sha1}/{width}`

Edit: Modified strawman URL to clarify that the 'prefix' is a path to a stable API entry point.
New thumb paths should ideally follow a very regular structure worthy of a public API. Clients might want to rewrite the thumb dimensions (and possibly, quality / format), so having the width parameter in an easy-to-parse / replace location would be useful.

Strawman url: `/api/rest_v1/media/img/{original-sha1}/{width}`

Edit: Modified strawman URL to clarify that the 'prefix' is a path to a stable API entry point.
New thumb paths should ideally follow a very regular structure worthy of a public API. Clients might want to rewrite the thumb dimensions (and possibly, quality / format), so having the width parameter in an easy-to-parse / replace location would be useful.

Strawman url: `/api/rest_v1/media/img/{original-sha1}/{width}`
New thumb paths should ideally follow a very regular structure worthy of a public API. Clients might want to rewrite the thumb dimensions (and possibly, quality / format), so having the width parameter in an easy-to-parse / replace location would be useful.

Strawman url: `/prefix/{original-sha1}/{width}`
New thumb paths should ideally follow a very regular structure worthy of a public API. Clients might want to rewrite the thumb width, so having the width parameter in an easy-to-parse / replace location would be useful.

Strawman url: `/prefix/{original-sha1}/{width}`
New thumb paths should ideally follow a very regular structure. Clients might want to rewrite the thumb width, so having the width parameter in an easy-to-parse / replace location would be useful.

Strawman url: `/prefix/{original-sha1}/{width}`
New thumb paths should ideally follow a very regular structure. Clients might want to rewrite the thumb width, so having the width parameter in an easy-to-parse / replace location would be useful.

Example url: `/prefix/{original-sha1}/{width}`
@Subfader, in Parsoid HTML [the image name is already provided in an RDFa `resource` attribute](https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Images). @Prtksxna is also [working on](https://gerrit.wikimedia.org/r/#/c/196532/) bringing the PHP thumb HTML structure closer to the Parsoid output. We should make sure to include the resource attribute there as well.
@Subfader, in Parsoid HTML [the image name is already provided in an RDFa `resource` attribute](https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Images). There is also [work by @Prtksxna ongoing](https://gerrit.wikimedia.org/r/#/c/196532/) to bring the PHP thumb HTML structure closer to the Parsoid output. We should make sure to include the resource attribute there as well.
@Subfader, in Parsoid HTML [the image name is already provided in an RDFa `resource` attribute](https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Images). There is also [work ongoing](https://gerrit.wikimedia.org/r/#/c/196532/) to bring the PHP thumb HTML structure closer to the Parsoid output. We should make sure to include the resource attribute there as well.
Some JS scripts in extensions rely on the image name as they grab it from the src-URL to pass it to the API or thumb.php.

So if this comes, please make sure to provide the proper image name in a data parameter at least.
Some JS scripts in extensions rely on the image name as they grab it to pass it to the API or thumb.php.

So if this comes, please make sure to provide the proper image name in a data parameter at least.
See also T1210.
(In reply to Tisza Gergő from comment #1)
> By content-based thumbnail URL do you mean the URL is based on the content
> of the thumbnail, or on the content of the original file? 

Definitely the latter. Example: <sha1 of orig>-300.jpg
(In reply to Bawolff (Brian Wolff) from comment #2)
> I believe there is already a bug for this, but cant find it.

Bug 44428 comment 0?
We already have support for content disposition headers on files (for swift backend anyways). I imagine we could still use htcp for quick purging.

There are very definite advantages here related to caching. Among other things, It would also let us set more aggresive cache headers for the client.

File moving would also become much "better".

I believe there is already a bug for this, but cant find it.
By content-based thumbnail URL do you mean the URL is based on the content of the thumbnail, or on the content of the original file? None of the advantages seem to apply to the former, it makes quick purging even harder, and makes it impossible to guess the URL needed for resizing the image (which can be used for some fairly significant speed improvements).
Visual editor adds accesskey 'v' for visual edit in namespaces where the editor is not enabled. For example (in Firefox) pressing alt+shift+v in [[sv:Diskussion:Stockholm]] shows the error message:

"Error loading data from server: novenamespace: VisualEditor is not enabled in namespace 1. Would you like to retry?"

It should be possible to avoid getting an error message by removing the access key. (Also, if Visual editor is not enabled there is no point in asking users to retry.)

--------------------------
**Version**: unspecified
**Severity**: minor
Change 133851 merged by jenkins-bot:
Remove edit tab from the DOM if it's hidden

https://gerrit.wikimedia.org/r/133851
Change 133851 had a related patch set uploaded by Alex Monk:
Don't add ve-edit tab in namespaces where it's not available

https://gerrit.wikimedia.org/r/133851
**Author:** `admin`

**Description:**
Greetings,
Please add the VisualEditor extension - and any related elements - to the AffCom wiki (chapcom.wikimedia.org).

Thank you!
-greg aka varnent

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
Looks like that would've been done in https://gerrit.wikimedia.org/r/#/c/174793/ - sorry this bug was missed.
Looks like that would've been done in https://gerrit.wikimedia.org/r/#/c/174793/ - sorry it was missed.
**admin** wrote:

Whoops - sorry - meant to close a different one - my bad.  :/
Div tags like the ones seen in https://meta.wikimedia.org/wiki/Grants:IdeaLab cause "alienated content"/prevent people from editing the page.  VisualEditor should support div tags.

--------------------------
**Version**: unspecified
**Severity**: normal
Filed {T139388}
This is definitely not new, but this looks like a Parsoid problem with the selective serializer. I think the bug is different from the request in the title of the page. The bug here is that if you edit the content of a div that has a templated style, the edits are being lost. This is a bug with the DOM diff algorithm which probably is mistakenly ignoring edits in nodes marked mw:ExpandedAttrs (as far as I can tell), and has been around since the very beginning. I'll open a new bug report for this and let this task be for the original request (which is allowing edits of <div>s with templated attributes).
I can confirm this problem exists at least for some months.
Eurgh, that's not good. Was there a Parsoid change recently-ish, or is it breakage at our end?
Confirmed, this now silently fails to save your edits, which is VERY confusing for an end user.
Unfortunately, it seems this has regressed from 'cannot edit' to 'can edit, but changes do not show up'. Could the priority be increased to reflect that?
<div> tags work just fine, and have for nearly a year. The problem here is a <div> tag with a template in its style attribute.
Steps to reproduce:
* go to https://test.wikipedia.org/wiki/Page466?veaction=edit
* select the whole article content (Ctrl + A)
* from the format menu, select one of the options (except "Paragraph")
* go to "Save page" > "Review your changes"

No matter if you selected "Heading", "Preformatted" or something else, all existing categories would get that format. So one can accidentally put a category in a header.

However, if you add one or more categories in VE using the dedicated menu, then (without saving) repeat those steps, you will see that the newly added categories are left out of the formatting change.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://test.wikipedia.org/w/index.php?diff=197978
Any updates?
I edited https://www.mediawiki.org/w/index.php?title=MediaWiki-Vagrant&oldid=946962 with VisualEditor.  Everything after the "Quick Start" section appeared in monospace.

I repro'd with the smaller test page https://www.mediawiki.org/wiki/User:S_Page_(WMF)/VE_span_bug

I think the issue lies in

 <p style="font-size: 1.2em; margin-top: 1.2em;">When Vagrant is done configuring your machine, browse to <span class=plainlinks>http://127.0.0.1:8080/</span> to find your MediaWiki instance. The admin password is <code>vagrant<code>.</span>

Note its incorrect second opening <code> instead of closing the code, and a second closing </span>. Yet regular wiki parsing can handle it.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/User:S_Page_(WMF)/VE_span_bug
Tidy is on the way to being removed next year. Parsoid and RemexHTML will handle broken HTML markup much more similarly since they both using HTML5 tree building to fix up broken markup.
>>! In T65699#1694336, @MarkAHershberger wrote:
> fwiw, one of the people behind tidy-html5 says [[ https://github.com/htacg/tidy-html5/issues/277#issuecomment-144808830 |  he tested ]]  and found that this issue was fixed.

Thanks @MarkAHershberger. What we are getting at with the Tidy replacement and which applies here as well is that we really don't need Tidying or any such thing in mediawiki. What we need is a HTML5 parser (something that takes a string and parses it according to the well-specified HTML5 parsing algorithm). 

We don't need all the extra things that the old Tidy did. So, if the new tidy-html5 project implemented what we needed, it would simply be a HTML5 tree builder that takes a string, and builds a DOM. If we needed (for backward compatibility reasons) to implement additional post-processing on the DOM (to do some of the things the old/in-production Tidy does), then we would need a full DOM API. But, if we determine as part of the work in T89331 that we can drop all the extra things the old Tidy does, then we may be able to not bother with the DOM API, as long as the tool generated a faithful serialization of the parsed DOM tree.

T89331 does not mandate an external HTML5 parsing service. If we determine that tidy-html5 is "good enough", then, it would be an acceptable fallback for mediawiki installations that are happy with it. In fact, wikis don't even need to replace the "old tidy" if they don't care about all the bugs filed against it. Part of the impetus to T89331 is to pay down technical debt. It also moves PHP parser and Parsoid output closer. It also brings us closer to reducing complexity in Parsoid, and eventually in the glorious future, to maybe have a simple bidirectional parser entirely in core without need for an external service. We can chat more on IRC if you have more questions. I didn't add this explanation to T89331 since that ticket is already very long with a lot of discussion.
fwiw, one of the people behind tidy-html5 says [[ https://github.com/htacg/tidy-html5/issues/277#issuecomment-144808830 |  he tested ]]  and found that this issue was fixed.
*** Bug 63798 has been marked as a duplicate of this bug. ***
(In reply to spage from comment #0)
 
> Note its incorrect second opening <code> instead of closing the code, and a
> second closing </span>. Yet regular wiki parsing can handle it.

This is Tidy doing the cleanup. PHP parser does not do the fixup automatically. This is a known issue -- we have a bunch of these scenarios now where Parsoid and Tidy fixup broken code differently. We'll never match Tidy behavior (which is not always the desired behavior in any case). But, as for this specific scenario, fixing this will require us to use heuristics in the tokenizer and more complexity. At this time, it is not clear if the additional complexity is worth it, except for easy to auto-fix scenarios.
Turning on debugging in IE9 and then hitting "Edit" ends up with this in the console:

  SCRIPT16389: Unspecified error. 
  load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cdata%2Cicons-
  vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=vector&
  version=20140408T180250Z&*, line 642 character 159


The line that is highlighted (running with "Format JavaScript" checked) is:

  this.nativeSelection.addRange(getNativeRange(range).cloneRange());

--------------------------
**Version**: unspecified
**Severity**: normal
IE9 loads fine now, just not in debug mode.
When adding templates such as https://fr.wikipedia.org/wiki/Mod%C3%A8le:E (which adds a superscripted "e" to words), the letter will need further formatting to match the surrounding text if that is italic, bold, ... .

--------------------------
**Version**: unspecified
**Severity**: normal
1. Log in at http://en.wikipedia.beta.wmflabs.org
2. Enable VE
3. Visit http://en.wikipedia.beta.wmflabs.org/wiki/File:ButtonsReversed.png
   (or any foreign file with no local description page)

You see the following views (tabs):
    Read
    View on Wikimedia Commons
    Create source
    Add local description ^beta

4. Visit http://en.wikipedia.beta.wmflabs.org/wiki/File:Button_hover.svg
   (or any foreign file with an existing local description page)

You see:
    Read
    View on Wikimedia Commons
    Edit source
    Edit local description ^beta
    View history

The tab name "Create/Edit source" does not sit well next to "Add/Edit local description ^beta". The wikitext-editing tab needs a better name when viewing foreign files.

Admittedly these tabs were altered in core [1] without consulting the VE people, but of course, it is the responsibility of extension authors to catch up to new core functionality.

[1] Gerrit change 104182

--------------------------
**Version**: unspecified
**Severity**: minor
Change 124775 merged by jenkins-bot:
Use updated tab labels on description pages for files in foreign repos

https://gerrit.wikimedia.org/r/124775
Change 124775 had a related patch set uploaded by Alex Monk:
Use updated tab labels on description pages for files in foreign repos

https://gerrit.wikimedia.org/r/124775
(In reply to Alex Monk from comment #2)
> So "Edit source" or "Create source" should become "Edit local description
> source" or "Add local description source" on file description pages for
> files in foreign repositories?

I guess. It's verbose, but then that's really my fault...
So "Edit source" or "Create source" should become "Edit local description source" or "Add local description source" on file description pages for files in foreign repositories?
Sorry that we missed this.

BTW, changes to major MediaWiki semantics (even good ones like this) should really be highlighted on wikitech-l and/or ideally design-l before being implemented and merged. I have a bunch of ideas about how this could have been done more cleanly that it's now too late to try out. :-(
This is related to bug 50996.

Open a page that contains hieroglyphics, like https://www.mediawiki.org/w/index.php?oldid=942532#Hieroglyphics

You should be able to open the hieroglyphics "node" by double-clicking, but it isn't working.

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in test2
Verified the fix on betalabs
Change 124469 merged by jenkins-bot:
Actually actually fix double-clicking on hieroglyphics nodes

https://gerrit.wikimedia.org/r/124469
Change 124469 had a related patch set uploaded by Catrope:
Actually actually fix double-clicking on hieroglyphics nodes

https://gerrit.wikimedia.org/r/124469
https://gerrit.wikimedia.org/r/#/c/121514/
I think Trevor fixed this in an unrelated recent commit, let me find it.
**Author:** `richlv`

**Description:**
visual editor from git f8d56e6804a12248b485c2d3b49d4ff0ffa7220c

edit a page with opera 12.16 on linux, place cursor on an empty line, hit 'esc' - 
symbol ♙ is inserted.

bug #51140 was about this symbol being inserted in a different situation and is supposed to be fixed.

reproducible at https://www.zabbix.org/wiki/Docs/visual_editor_test (if you would like to create a test account, "real name" is mandatory)

--------------------------
**Version**: unspecified
**Severity**: normal
Change 143322 merged by jenkins-bot:
ve.ce.Surface: Prevent incorrect pawning in Opera 12

https://gerrit.wikimedia.org/r/143322
Change 143322 had a related patch set uploaded by Bartosz Dziewoński:
ve.ce.Surface: Prevent incorrect pawning in Opera 12

https://gerrit.wikimedia.org/r/143322
Seems like it wouldn't be a problem if you just filtered out those keycodes.
This is probably a regression from 4e377629e39a4af9405a5ea8972bdeb1af37ddf6
(fix for bug 48335).
So, Opera 12 sends the events for the keypresses of Esc and Tab. These events reach ve.ce.Surface.prototype.onDocumentKeyPress and eventually ve.ce.Surface.prototype.handleInsertion, which decides to insert the pawn, which will not be overwritten because neither Esc not Tab produce any text.

onDocumentKeyPress attempts to filter out non-character keypresses by discarding ones where the charCode is 0; Opera's event for Esc has charCode == 27,
for Tab charCode == 9. I guess other browsers use 0 here for some weird reason and you depend on this behavior.
Yes. I don't have time right now, but I'll try to get around to this sooner or later.
MatmaRex, you still interested in taking on Opera 12 bugs?
**richlv** wrote:

(1) another way to get that symbol with opera - hit 'tab' on an empty line.

both of these also "work" in an empty table cell
Both enwiki and frwiki (at least) use {{FULLPAGENAME}} in [[MediaWiki:newarticletext]], which is unusable, because it is replaced by “API” in VisualEditor.

So the warnings contain texts like
 — “You can also start your new article at Special:Mypage/API.” (https://en.wikipedia.org/wiki/Nawak?veaction=edit)
 — “Comment faire pour créer l'article API ?” (https://fr.wikipedia.org/wiki/Nawak?veaction=edit)

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=59608
*** Bug 63673 has been marked as a duplicate of this bug. ***
Change 127388 merged by jenkins-bot:
Set context title when rendering edit notices and checkboxes

https://gerrit.wikimedia.org/r/127388
*** Bug 63811 has been marked as a duplicate of this bug. ***
Change 127388 had a related patch set uploaded by Catrope:
Set context title when rendering edit notices

https://gerrit.wikimedia.org/r/127388
Presumably we're not passing the 'title' parameter to the URL to give it context?
*** Bug 63631 has been marked as a duplicate of this bug. ***
Some icons need to be flipped for RTL languages. Here's what I found till now:

In lib/ve/lib/oojs-ui/images/icons:
* help.svg - This is a question mark in a circle. This should be flipped for all RTL languages, but *not* for Hebrew (he) and Yiddish (yi).

In lib/ve/modules/ve/ui/styles/images/icons:
* external-link.svg

In modules/ve-mw/ui/styles/images/icons:
* gallery.svg
* parameter.svg
* parameter-set.svg
* ref-cite-book.svg
* ref-cite-journal.svg
* ref-cite-news.svg
* reference.svg
* references.svg

--------------------------
**Version**: unspecified
**Severity**: normal
Except for the remaining technical issue in OOjs UI, this was done 6 months ago. Closing, and follow-up for OOUI is in T76540.
(In reply to Ed Sanders from comment #4)
> (In reply to James Forrester from comment #3)
> > No; OOUI only understands RTL and LTR, not specific languages. The bold icon
> > isn't from OOUI but from VE itself, which does. Oy.
> 
> Actually the per-language icon format is in OOUI (IconedElement.js line 42).
> You need to define the language overrides every time you specify the icon
> instead of just making it a 'feature' of the icon like directionality.

Oh, interesting. OK, so we'd need to use that in downstream tools if particular languages want over-rides? Ick. See gerrit 143407 for the easy part.
(In reply to James Forrester from comment #3)
> No; OOUI only understands RTL and LTR, not specific languages. The bold icon
> isn't from OOUI but from VE itself, which does. Oy.

Actually the per-language icon format is in OOUI (IconedElement.js line 42). You need to define the language overrides every time you specify the icon instead of just making it a 'feature' of the icon like directionality.
(In reply to Amir E. Aharoni from comment #2)
> (In reply to James Forrester from comment #1)
> > (In reply to Amir E. Aharoni from comment #0)
> > > Some icons need to be flipped for RTL languages. Here's what I found till
> > > now:
> > > 
> > > In lib/ve/lib/oojs-ui/images/icons:
> > > * help.svg - This is a question mark in a circle. This should be flipped for
> > > all RTL languages, but *not* for Hebrew (he) and Yiddish (yi).
> > 
> > This should (a) be an OOUI bug, and (b) is really quite hard for us to do as
> > our build system only supports LTR or RTL, it doesn't do language-specific
> > builds. How high priority is this?
> 
> Pretty important for people who write Arabic, Persian and Urdu.
> Can't it be done the same way it's done for Bold and Italic?

No; OOUI only understands RTL and LTR, not specific languages. The bold icon isn't from OOUI but from VE itself, which does. Oy.
(In reply to James Forrester from comment #1)
> (In reply to Amir E. Aharoni from comment #0)
> > Some icons need to be flipped for RTL languages. Here's what I found till
> > now:
> > 
> > In lib/ve/lib/oojs-ui/images/icons:
> > * help.svg - This is a question mark in a circle. This should be flipped for
> > all RTL languages, but *not* for Hebrew (he) and Yiddish (yi).
> 
> This should (a) be an OOUI bug, and (b) is really quite hard for us to do as
> our build system only supports LTR or RTL, it doesn't do language-specific
> builds. How high priority is this?

Pretty important for people who write Arabic, Persian and Urdu.
Can't it be done the same way it's done for Bold and Italic?
(In reply to Amir E. Aharoni from comment #0)
> Some icons need to be flipped for RTL languages. Here's what I found till
> now:
> 
> In lib/ve/lib/oojs-ui/images/icons:
> * help.svg - This is a question mark in a circle. This should be flipped for
> all RTL languages, but *not* for Hebrew (he) and Yiddish (yi).

This should (a) be an OOUI bug, and (b) is really quite hard for us to do as our build system only supports LTR or RTL, it doesn't do language-specific builds. How high priority is this?

> In lib/ve/modules/ve/ui/styles/images/icons:
> * external-link.svg

Not currently used, but done in gerrit 143240.

> In modules/ve-mw/ui/styles/images/icons:
> * gallery.svg
> * parameter.svg
> * parameter-set.svg
> * ref-cite-journal.svg
> * ref-cite-news.svg
> * reference.svg
> * references.svg

Done in gerrit 143241.

> * ref-cite-book.svg

Not now needed (no LTR/RTL variance). Similarly for ref-cite-web.
Try to open math inspector, it does not open up.
Not showing any error in the console

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix on production:
https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/sandbox
Verified the backported fix on test2: https://test2.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/sandbox&veaction=edit
Verified the fix on betalabs: http://en.wikipedia.beta.wmflabs.org/wiki/9thaprilChrome?veaction=edit
Change 125023 merged by jenkins-bot:
Update tool to use a command

https://gerrit.wikimedia.org/r/125023
Change 125023 had a related patch set uploaded by Jforrester:
Update tool to use a command

https://gerrit.wikimedia.org/r/125023
Change 125017 merged by jenkins-bot:
Update tool to use a command

https://gerrit.wikimedia.org/r/125017
Apparently the Gerrit bot is broken? Trevor submitted https://gerrit.wikimedia.org/r/#/c/125017/ for this and I +2ed it. Now we're waiting for Jenkins/Zuul to stop being broken so it'll actually get merged.
It would be nice if the new typography (e.g. serifed fonts for headlines) were reflected in VisaulEditor's "format paragraph" menu.

--------------------------
**Version**: unspecified
**Severity**: trivial
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63985
Change 130771 merged by jenkins-bot:
Style the FormatTool to be more like Vector's new look

https://gerrit.wikimedia.org/r/130771
Change 130771 had a related patch set uploaded by Jforrester:
Style the FormatTool to be more like Vector's new look

https://gerrit.wikimedia.org/r/130771
`mw.util.$content` from module `mediawiki.util` seems to be needless.

```lang=js
	$( function () {
		mw.util.$content...
	} );
```
can be replaced by
```lang=js
	mw.hook( 'wikipage.content' ).add( function ( $content ) {
		$content...
	} );
```
`mw.hook()` is necessary to support [[https://www.mediawiki.org/wiki/Manual:Live_preview|Live Preview]].
Change 123559 abandoned by Krinkle:
Deprecate mw.util.$content

Reason:
Superseded by I30bdd893e0a0a340076.

https://gerrit.wikimedia.org/r/123559
Thanks for explanation.

What about a new hook 'wikipage.body'?

In mediawiki.page.startup.js fire
	mw.hook( 'wikipage.body' ).fire( mw.util.$content ) );

In mediawiki.notification.js replace
	$( function () {
		mw.util.$content...
	} );
by
	mw.hook( 'wikipage.body' ).add( function ( $body ) {
		$body...
	} );
Closing as won't fix per discussion between Daniel Friesen and myself at https://gerrit.wikimedia.org/r/123559.

Although the naming is unfortunate, these are different things for different use cases.

mw.hook( 'wikipage.content' ) is to get a reference to #mw-content-text (the true wiki page content, no skinning around it). It is different from $( '#mw-content-text' ) in that:

* It can be asynchronous (you can register the hook without needing to explicitly wait for document-ready).
* It is more semantically correct if your intent is "change content" because it will re-fire when the content changes dynamically (e.g. after saving an edit with VisualEditor, or when ajax live previewing wikitext, or in some hypothetical "ajax navigation" feature).

mw.util.$content is to get a reference to the body content wrapper (the element containing #mw-content-text, usually indicated by .mw-body). Because mw.util.$content has been around since before mw.hook, it is likely that there are existing uses out there that would benefit from using mw.hook instead. However there remain uses for mw.util.$content where mw.hook is not a suitable alternative.

Having said that, I still think we should deprecate mw.util.$content because it sucks (retrieving its value is tricky because it is asynchronously initialised without a clear callback for when that happens). However until we have an alternative for it, let's keep it.

Ideally we'd just mandate that all skins follow the convention to use mw-body class and then just document that as an API (similar to how addPortletLink's html structure has become more or less skin independent, though not quite there yet) that people use by waiting for domready and querying mw-body or mw-body-primary.
Change 123559 had a related patch set uploaded by Gerrit Patch Uploader:
Deprecate mw.util.$content

https://gerrit.wikimedia.org/r/123559
Screenshot of excessive whitespace on top of an in-content dialog with h2 heading

Since inner padding of the dialog container and top margin of the header don't collapse, they get stacked and now have an excessive amount of whitespace (see screenshot).

The margin-top of 'div#content h2' should be safe to remove. We didn't have it in the past, and in any regular text flow context it is already spaced away from the preceding element by the bottom margin of block level elements (like paragraphs and tables).

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

**Attached**: {F13341}
>Could we tweak it to have a !firstChild or something on H2s so it only triggers
>for the H2s that we actually want to style?

I can't think of any way to do this that would be reliable. We could do something like...
#content h2(:not( .dialogHeader ))
but that would still require making sure that all headers in dialogs included that class. (And if we're updating those headers anyway, we might as well convert them from h2s into something else.)

We could also use jQuery to try to guess which h2s are actually section headers and which ones aren't, but that would cause a style change flash.

I still haven't heard any evidence that this bug actually affects more than a single dialog box. If it's just one dialog, is it really that hard to fix, even though the code is unmaintained? What extension generates that dialog box?
(In reply to Ryan Kaldari from comment #11)
> What James says is true, although there currently isn't any way to have
> large margins between the sections on desktop without increasing the margins
> on ".content h2", so unless design agrees to reduce those margins, the fix
> will have to be to the unmaintained code (at least until the desktop DOM
> includes some sort of section elements).

Could we tweak it to have a !firstChild or something on H2s so it only triggers for the H2s that we actually want to style?
What James says is true, although there currently isn't any way to have large margins between the sections on desktop without increasing the margins on ".content h2", so unless design agrees to reduce those margins, the fix will have to be to the unmaintained code (at least until the desktop DOM includes some sort of section elements).
(In reply to Jared Zimmerman (WMF) from comment #9)
> This is as designed, as Steven said, if there are 1 one off cases where the
> padding is too large within specific features or use cases (not articles or
> content pages) the feature teams should write modifications to the style for
> those cases.

This is a complaint about the breakage of unmaintained code that was written with the expectation that people wouldn't unexpectedly change these, though. There are no "feature teams" to fix the breakage for you…
This is as designed, as Steven said, if there are 1 one off cases where the padding is too large within specific features or use cases (not articles or content pages) the feature teams should write modifications to the style for those cases.
CCing Jared since this is really a design issue.
Change 123024 abandoned by Krinkle:
vector: Remove margin-top from 'div#content h2'

Reason:
Implementing something in a hacky way that breaks expectations about how page layout works and then putting the burden on other maintainers to make it work well with the rest of the web is imho not ideal practice. But I can't invest in this now, so snafu. You're welcome.

https://gerrit.wikimedia.org/r/123024
Because the discussion here clearly points to a lack of consensus, I'm removing the 1.23.0 target.
>I think you might've missed that I said the margin-top can be safely removed 
>because it is ineffective. It isn't "increasing" the visible whitespace between 
>sections...

I don't think that's accurate. Having "h2 { margin-top: 1em; }" is definitely increasing the whitespace significantly between sections. With that rule in place, the whitespace is effectively 21 pixels (0.875em x 1.5em x 1em x 16px). Without it, in most cases, the whitespace is only 7 pixels (0.875em x 0.5em x 16px). That's a big difference.

If we want to change the amount of whitespace between sections, we need to get input from design on this. If we don't want to change the amount of whitespace between sections, we need to find a different way to implement the whitespace. Currently, however, I don't see any better way to implement the whitespace between sections.

As the bug is currently defined, I recommend WONTFIX.
Rephrasing bug to reflect the two most common problem cases:

* Using a heading as first element on page (e.g. the first section, as opposed to between two sections).

* Using a heading inside a container that isn't the root of the page (e.g. inside a bubble such as on [1], or any other kind of sub container).


[1] https://www.mediawiki.org/w/index.php?title=Help:VisualEditor/User_guide&oldid=984581#toc
**swalling** wrote:

I think this is probably something where special UI elements like dialogs should be adding/changing their own H2 styles, rather than reusing styles intended for content pages.

Repeating Kaldari's comment on the patch:

"The 1em margin was implemented on purpose by the design team. As mentioned in the FAQ, they wanted to significantly increase the whitespace between sections. Unfortunately on desktop we don't have any "section" DOM element, so adding top margin to h2s is the best way to accomplish that.

Since dialogs don't often belong to the content div, it seems like better solutions to bug 63390 would be:

1. Move the dialog outside the content div;
2. Don't use h2s in that dialog, or...
3. Override the h2 style in that case.
Is there more than 1 dialog affected by this bug?"
Change 123024 had a related patch set uploaded by Krinkle:
vector: Remove margin-top from 'div#content h2'

https://gerrit.wikimedia.org/r/123024
Intention:
Add a value to an empty cell in a table using VE

Steps to Reproduce:
1. You need a page with a table with at least one empty cell (e.g. https://en.wikipedia.beta.wmflabs.org/wiki/User:ESanders_(WMF)/sandbox/T65356)
2. Open page for VE editing
3. Double click on the empty cell, then add some text
4. Show the wikitext diff in the save dialog

Actual Results:  
In addition to the entered text a line-break is added

Expected Results:  
No additional line-break

Reproducible: Always

Note that this does not happen for cells which already contains a value

--------------------------
**Version**: unspecified
**Severity**: normal
Hmm, the difference seems to be that if you click once on the empty cell and start typing, VE doesn't wrap the text in a `<p>`,

```
<td data-parsoid="{&quot;stx_v&quot;:&quot;row&quot;,&quot;autoInsertedEnd&quot;:true,&quot;dsr&quot;:[38,41,2,0]}">haha</td>
```

However, doubling clicking and then typing does,

```
<td data-parsoid="{&quot;stx_v&quot;:&quot;row&quot;,&quot;autoInsertedEnd&quot;:true,&quot;dsr&quot;:[38,41,2,0]}"> <p>haha</p></td>
```

Serializing the paragraph introduces a newline which would break the row syntax, so Parsoid switches the other format.  I suppose we could be smarter about the p/td nl constraints, or VE maybe avoid introducing the paragraph to begin with?
*** Bug 73215 has been marked as a duplicate of this bug. ***
Created attachment 14994
Screenshot

Screenshot showing the result to the source of editing a filled and an empty cell using VE.

**Attached**: {F13280}
Intention:
Linking to a file using visual editor

Steps to Reproduce:
1. Edit page on using VE
2. Click add link
3. Enter a filename with File-prefix (e.g. File:Foo.svg)
4. Press enter
5. Press enter again

The same thing happens for categories or if the preceding colon is added manually.


Actual Results:  
4. Inserted text is changed to :File:Foo.svg
5. Inserted text is changed to ::File:Foo.svg

Expected Results:  
4. As result
5. No change

Reproducible: Sometimes

The same thing happens for categories or if the preceding colon is added manually. I can get this to happen repeatedly but occasionally VE will correctly know not to add the second colon (have not identified when though.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63355
Dupe of 50279 (and now fixed).

*** This bug has been marked as a duplicate of bug 50279 ***
Here's a variation:

1.  Edit page on using VisualEditor.

2.  Type the file name you want (with or without the colon prefix that you want):  File:Example.jpg

3.  Open the link inspector, which will offer to link these files (at least on en.wp):

:File:Example.jpg
File:Example.jpg
File:Example.JPG

4.  Choose the first.  Press enter.  Now it has changed the link target to "::File:Example.jpg" and says "Invalid page title".  (Saving this link will work correctly anyway.)

5.  Alternatively, choose the second, and press enter.  This also works and does not produce the error message.
Also happening with FF, Win8.
The resulting wikilink works, though.
Created attachment 14992
Screencast

Added video since this is not 100% reproducible

**Attached**: {F13270}
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Template
3.Click on Show Options
4.Click on the trash icon.
5.Click on "Add Content"

Observed Result:
The "Insert transclusion" button becomes enabled and an empty transclusion with empty content gets added upon clicking on it.


See the screenshot attached

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

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

**Attached**: {F13225}
Verified the fix in production
Verified the fix in test2
Change 169638 merged by jenkins-bot:
MWTransclusionModel: Exclude parts serialising to '' from the plain object

https://gerrit.wikimedia.org/r/169638
Change 169638 had a related patch set uploaded by Alex Monk:
MWTransclusionModel: Exclude parts serialising to '' from the plain object

https://gerrit.wikimedia.org/r/169638
See also bug 63340, which was duped to this one but is actually subtly different: it's about when the only part is a TemplatePlaceholderPage
*** Bug 63340 has been marked as a duplicate of this bug. ***
Also, there is an error in the console:
Uncaught TypeError: Cannot read property 'length' of null
Created attachment 14990
Screenshot

**Attached**: {F13226}
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Open the transclusion add dialog box by going to Insert>Template
3.Click on the "Show Options" button
4.Now click on the "Add template" button

Observed Result:
The "Insert Transclusion" button becomes enabled and clicking on that does nothing 


See the screenshot attached

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

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

**Attached**: {F13220}
*** This bug has been marked as a duplicate of bug 63341 ***
Yeah , this one I filed for adding empty template and bug 63341 was specifically for adding empty content,but they might get fixed at one shot.In that case I guess we should merge these two?
Is this the same as bug 63341?
Right now, there is no keyboard function to exit the Math Inspector and Gallery inspector.

--------------------------
**Version**: unspecified
**Severity**: minor
Escape works for me…
The media selector (both in WikiEditor and Visual Editor) does not find local images in a private wiki. When the same wiki is set to public, it works.

I've tried this with 3 different installations (1.22 and 1.23wmf20) on two different servers, both with Visual Editor and WikiEditor. 

The relevant setting is

$wgGroupPermissions['*']['read'] = false;

When this is set to false, when a user (logged in and registered) edits a page and starts typing the name of an existing file in the media selector, the input box remains empty and does not suggest existing file names. 

When the read permission is set to true, then it works as expected (giving a list of suggestions in the input box) - but of course then the wiki is no longer private.

On the other hand, the link selector finds the files when I type "File:Filename..". Also, the image is actually shown in the article when I insert it with Wiki markup, or when I type in the correct filename in the selector and click on "insert".

So somehow the media selector (but not the link selector) does not understand the permission correctly for a logged-in user.

--------------------------
**Version**: unspecified
**Severity**: normal
See also T63151 and https://www.mediawiki.org/wiki/Topic:Rb7adzuz9pt6ifno
I could not reproduce the error on officewiki (a private wiki which is about a week behind master). Both your examples return a `readapidenied` error (which is a bug on its own right, reported as T106425). The VE media selector works fine, with or without an asterisk.

You could try to reproduce the bug in a controlled environment by using [[ https://www.mediawiki.org/wiki/MediaWiki-Vagrant | MediaWiki-Vagrant ]] with the `private` and `visualeditor` roles.
Yes, this is the API request that fails to find the image:

```
api.php?callback=jQuery1113038504008506424725_1437475882811&action=query&format=json&iiurlheight=200&generator=search&gsrnamespace=6&continue=&iiprop=dimensions%7Curl%7Cmediatype%7Cextmetadata%7Ctimestamp&prop=imageinfo&gsrsearch=Server&iiurlwidth=300&gsroffset=0&gsrlimit=30
```
It results in: 

```
/**/jQuery1113038504008506424725_1437475882811({"batchcomplete":""})
```

If I add an astericks at the end of the search-term, it works:


```
api.php?callback=jQuery1113038504008506424725_1437475882811&action=query&format=json&iiurlheight=200&generator=search&gsrnamespace=6&continue=&iiprop=dimensions%7Curl%7Cmediatype%7Cextmetadata%7Ctimestamp&prop=imageinfo&gsrsearch=Server*&iiurlwidth=300&gsroffset=0&gsrlimit=30
```

Results in:

```
/**/
jQuery1113038504008506424725_1437475882811({
    "continue": {
        "iistart": "2015-06-23T05:30:36Z",
        "continue": "||"
    },
    "query": {
        "pages": {
            "6672": {
                "pageid": 6672,
                "ns": 6,
                "title": "Datei:Server\u00dcbersicht.png",
                "index": 1,
                "imagerepository": "local",
                "imageinfo": [{
                    "timestamp": "2015-06-23T05:31:57Z",
                    "size": 188839,
                    "width": 3000,
                    "height": 1606,
                   ....
                    "mediatype": "BITMAP"
                }]
            }
        }
    }
})
```

When using the astericks, the VE request works, but is repeated endlessly:

{F203227}
Presumably some permission is missing. Can you post the exact API requests and responses?
I've got the same problem (on a private wiki).

I've tryed the permission fix. Still no effect on the first glance.

However, If i type "*" or the complete name (including the namespace), it finds my image, if I type the only the name (or a part of the name) nothing appears.

This seems to be an issue with the MediaWiki API. It's search algorithm is so strict, that you already need to know the exact name in order to get a result.

Appending / prepending an astericks helps, though. Maybe VE should do that by default?

VisualEditor-REL1_25
MediaWiki	1.25.1
PHP	5.5.9-1ubuntu4.9 (apache2handler)
I've got the same problem (on a private wiki).

Couldn't change that with the proposed permission fix.

Interestingly, If i type "*", it finds my image, if I type the name (or part of the name) nothing appears.
I still have the same problem in version 1.25wmf17 (d70b751)
e.g. typing "l" shows only two images, adding an "e" shows only one, other(!) image.
In order to find a file, I have to enter the complete name, including the extension :-( 
Even worse, some files cannot be found at all. They can only be inserted using the text-editor.
I cannot find the file "At_venice.jpg". The file appears as "At_venice.jpg" in the images-directory, but as "At venice" on the wiki-page describing the image.
Anyway, I can't find the file Koala.jpg either, no spaces or underscores there :-( (but a capital letter...)

Still the same issues as described earlier: I can find the file "test_lego.jpg" by typing "test", but not by typing "lego".

It's getting better: I upload a file as "jorun.jpg" but cannot find it, unless by typing the complete name. I upload the same file as "jorun test.jpg". I can find this photo by typing 'jorun'.

Still looks like a bug to me!
In 1.25wmf8, it works now correctly without the (unsecure) workaround. I guess some other things with permissions were fixed which solved this one as a side effect too.
**gabriel_stelmach** wrote:

Hello there,

I just face this issue in my installation. There are any news about solution for this?

In time. Thank you Stephan for the workaround.

[]s
(In reply to Bawolff (Brian Wolff) from comment #3)
> Actually that can be exploited to get around read protection everywhere
> (including normal web requests). Any url can have that string in it.

Of course, and I don't recommend it. It was just meant as an indication that it's a bug in this specific api call for image searches and that other api calls are ok, so it's not a disabled api.
(In reply to Stephan Matthiesen from comment #2)
> (In reply to Bawolff (Brian Wolff) from comment #1)
> > Maybe private only wikis cause api to be disabled.
> 
> API is not disabled completely. All other API calls seem to work, only image
> search is affected.
> 
> The following workaround in LocalSettings.php also works:
> 
> if ( strpos($_SERVER['REQUEST_URI'], "prop=imageinfo") > 0 ) {
>     $wgGroupPermissions['*']['read'] = true;
> }
> 
> This disables read protection selectively for the image search.

Actually that can be exploited to get around read protection everywhere (including normal web requests). Any url can have that string in it.
(In reply to Bawolff (Brian Wolff) from comment #1)
> Maybe private only wikis cause api to be disabled.

API is not disabled completely. All other API calls seem to work, only image search is affected.

The following workaround in LocalSettings.php also works:

if ( strpos($_SERVER['REQUEST_URI'], "prop=imageinfo") > 0 ) {
    $wgGroupPermissions['*']['read'] = true;
}

This disables read protection selectively for the image search.
Maybe private only wikis cause api to be disabled.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert a Cite reference like Cite>Web/Book/Newspaper/Journal

Observed Result:
The selection highlight box is appearing a bit above the reference note


See the screenshot attached

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

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

**Attached**: {F12974}
Yes, this looks like it was fixed a while ago.
Is this still broken?
Guillemets, French quotation marks (https://en.wikipedia.org/wiki/International_variation_in_quotation_marks#French), are now available through the special characters tool in VE on fr.wiki.
When you select a word and then add the guillemets in the wikitext editor, the word gets wrapped in them.
This is not the case in VE - the symbols appear, the word gets deleted.

--------------------------
**Version**: unspecified
**Severity**: normal
Oh, great. I was wondering that quotation marks have disepeard with new charset.
The pairs of quotes appropriate for various languages can be inserted now (“” „“ „” «»), from the "Symbols" section, and if you do it while you have text selected, they will wrap it instead of replacing it.

{F154006}

If you wish to add items supporting this functionality to "Often used" characters list (https://www.mediawiki.org/wiki/VisualEditor/Special_characters#Adding_often_used_characters), the required syntax is (replace "A" and "B" with appropriate characters):

```
  "AB": {
    "action": {
      "type": "encapsulate",
      "options": {
        "pre": "A",
        "post": "B"
      }
    }
  },
```

(Per https://www.mediawiki.org/wiki/MediaWiki_1.26/Roadmap, this change will be deployed on Wikipedias on Wednesday, 06 May 2015.)
Change 205558 merged by jenkins-bot:
Allow special characters with tooltip or that encapsulate text

[[https://gerrit.wikimedia.org/r/205558]]
Change 205556 merged by jenkins-bot:
ve.ui.SpecialCharacterDialog: Allow encapsulation of selected content

[[https://gerrit.wikimedia.org/r/205556]]
Change 205558 had a related patch set uploaded (by Bartosz Dziewoński):
Allow special characters with tooltip or that encapsulate text

[[https://gerrit.wikimedia.org/r/205558]]
Change 205556 had a related patch set uploaded (by Bartosz Dziewoński):
ve.ui.SpecialCharacterDialog: Allow encapsulation of selected content

[[https://gerrit.wikimedia.org/r/205556]]
I confirm this at cs.wp. For the Czech „“ its common, to select a word click on spacial character button and insert quotatin marks arround.
Screenshot

Steps to reproduce:

1.Open a page with
2,Add a bullet list or numbered list
3.Add an empty bullet item 
4.Add indentation to it
5.Select the previous item
6.Change the paragraph style of the previous item


Observed Result:
An error appears in the console
Uncaught Error: Unbalanced set of replace operations found 

Now press enter to add another item :
Uncaught Error: Unbalanced input passed to document 

Press undo:
Uncaught Error: Offset could not be translated to a DOM element and offset

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

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

**Attached**: {F12902}
Verified the fix in:https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/sandbox?veaction=edit
Verified the fix on test 2
Change 124493 merged by jenkins-bot:
Exclude insertions in ve.dm.SurfaceFragment#isolateAndUnwrap

https://gerrit.wikimedia.org/r/124493
Change 123892 abandoned by Catrope:
Adjust range manually in isolateAndUnwrap()

Reason:
Superseded by https://gerrit.wikimedia.org/r/#/c/124493/

https://gerrit.wikimedia.org/r/123892
Change 124493 had a related patch set uploaded by Catrope:
Exclude insertions in ve.dm.SurfaceFragment#isolateAndUnwrap

https://gerrit.wikimedia.org/r/124493
Change 123892 had a related patch set uploaded by Catrope:
Adjust range manually in isolateAndUnwrap()

https://gerrit.wikimedia.org/r/123892
I've figured out why this bug happens and I know how to fix it. I have to go now but I'll write a patch when I get back (~1.5 hours)
It suffices to do a format change on any list item that has a nested list item directly beneath it. In other words, if you have the list

* Foo
* Bar
** Baz

then changing "Bar" to a heading will break. It doesn't matter if "Baz" is empty, it just has to be at a deeper list level than "Bar".
Screenshot

Steps to reproduce:

1.Open this page: https://en.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/sandbox?veaction=edit

2.Select all the content 

3.Delete it.

4.A link inspector icon appears in the page.

5.Open the link inspector

6.Close it 

Observed Result:
The links inspector gets all blank and an error appears in the console:
Uncaught Error: Offset could not be translated to a DOM element and offset: 65

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

**Attached**: {F12901}
Change 122556 merged by jenkins-bot:
Fix handlesOwnChildren check in getRelativeOffset

https://gerrit.wikimedia.org/r/122556
Change 122556 had a related patch set uploaded by Esanders:
Fix handlesOwnChildren check in getRelativeOffset

https://gerrit.wikimedia.org/r/122556
Deleting everything results in an empty document but for the internalList, i.e. [{'type':'internalList'...}, ...]. The popup tool is then look for annotations at range 0 which is then going inside the internal list and finding the link.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Add a text
3.Add a gallery right after that.
4.Select the text by selecting whole line
5.Click on the link inspector

Observed Result:
The link inspector opens after the gallery 

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

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

**Attached**: {F12878}
I /think/ Ed fixed this with his changes last fortnight. Maybe.
Consequently to the success of VisualEditor on the French Wikipedia and Wikiversity, the French Wiktionary and Wikibooks have voted in favor of its utilization:

https://fr.wiktionary.org/wiki/Wiktionnaire:Prise_de_d%C3%A9cision/Installation_de_l%27%C3%A9diteur_visuel

https://fr.wikibooks.org/wiki/Wikilivres:Prise_de_d%C3%A9cision/Installation_de_l%27%C3%A9diteur_visuel

So, thank you to deploy it on fr.wikt and fr.b please.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This was done yesterday; sorry for not noting this then.
Change 121439 merged by Mwalker:
Enable VisualEditor by default on French Wiktionary & French Wikibooks

https://gerrit.wikimedia.org/r/121439
We will get this setting turned on this afternoon (Pacific time), in the usual deployment.
Change 121439 had a related patch set uploaded by Jforrester:
Enable VisualEditor by default on French Wiktionary & French Wikibooks

https://gerrit.wikimedia.org/r/121439
[Moving to "Wikimedia" product as this request is about settings / configuration of the website, not about the codebase of VisualEditor extension itself.]
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Transclusion
3.Insert a template for example : The Cite web
4.Click on "Show options"
5.Keep on clicking on trash icon until you delete all the parameters and the template itself

Observed Result:

Observe that, even if there is no template in the dialog box , the add parameter button remains enabled , it should be disabled if there is o template.

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**: minor

**Attached**: {F13393}
Verified the fix in production
Change 168379 merged by jenkins-bot:
Disable parameter add icon when there's no transclusion parts

https://gerrit.wikimedia.org/r/168379
Confirmed in betalabs and test2.
Change 168379 had a related patch set uploaded by Alex Monk:
Disable parameter add icon when there's no transclusion parts

https://gerrit.wikimedia.org/r/168379
On beta features tab in your user preferences http://de.wikipedia.org/wiki/Spezial:Einstellungen?useskin=modern&uselang=de#mw-prefsection-betafeatures visualeditor shows a red requirement warning if the current skin is not supported. But this warning uses not available system messages:

This feature only works with the following skins:
    Vector
    &lt;skinname-apex&gt;
    MonoBook
    &lt;skinname-minerva&gt; 

The problem on wikimedia wikis is that both skins, apex and minerva, are not installed and so the system messages skinname-apex and skinname-minerva are missing.

I think there are two options how to fix this bug:
1. add these two messages to localisation files used by wmf
2. test if a skin is available before adding it to the skin list of the warning message

--------------------------
**Version**: master
**Severity**: normal
**URL**: http://de.wikipedia.org/wiki/Spezial:Einstellungen?useskin=modern#mw-input-wpvisualeditor-enable
*** This bug has been marked as a duplicate of bug 58623 ***
I don't know what it should be, but the following is not very clear:

Error loading data from server: error. Would you like to retry?

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=39057
https://bugzilla.wikimedia.org/show_bug.cgi?id=43147
With the above patch, the former message:

    Error loading data from server: parsoidserver-http-bad-status:
    500. Would you like to retry?

… turns into:

    Error loading data from server: parsoidserver-http-bad-status:
    500: Page Fetch failure for "BADURL": Error: getaddrinfo
    ENOTFOUND. Would you like to retry?

Which is not ideal, but at least describes things a bit. Marking this as FIXED.
Change 157775 merged by jenkins-bot:
Add debugging help to VisualEditor

https://gerrit.wikimedia.org/r/157775
Change 157775 had a related patch set uploaded by Jforrester:
Add debugging help to VisualEditor

https://gerrit.wikimedia.org/r/157775
(In reply to Roan Kattouw from comment #0)
> I don't know what it should be, but the following is not very clear:
> 
> Error loading data from server: error. Would you like to retry?

Maybe:

| The editor's contact with the server failed (5xx). Would you like to retry?

?
The icons for the new citation tool don't all appear to be the same weight.  The book icon looks darker than the others, which makes it seem like it's more important than other others, or perhaps that the others are non-functional/grayed out.  Perhaps it could be a dark gray?

--------------------------
**Version**: unspecified
**Severity**: trivial
Fixed with the new icons.
Intention:
Add a citation with the new citing tool

Steps to Reproduce:
1. Add a citation.

2. Look at the dirty diff that results.



Actual Results:  
The new cite tool produces this

<ref>{{Cite web|url = http://example.com|title = Example Title|date = 2014|last = Expert|first = Alice}}
</ref> 

(on two lines) rather than one line that it should:

<ref>{{Cite web|url = http://example.com|title = Example Title|date = 2014|last = Expert|first = Alice}}</ref> 



Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: enhancement
This may possibly have been fixed? Seems to now work correctly (on one line) for me, see e.g. http://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:Jdforrester_(WMF)/Sandbox&diff=92409&oldid=91378
Do you have a link to an example diff? I'm trying to reproduce this locally but I can't, in neither Chrome nor Firefox.
That's not the meaning of the term "dirty diff". :-) But yes.
When adding an item to a list, VisualEditor is stripping the first indent (colon in wikisyntax) when adding a new one in the list.

Example:
https://www.mediawiki.org/w/index.php?title=User%3AKeegan_%28WMF%29%2Fsandbox&diff=939610&oldid=939609

Steps to reproduce:
1. Create an indented list, save
   :*a
   :*b
   :*c
2. Add a new item to the list, looks fine before saving
   :*a
   :*b
   :*q
   :*c
3. Save, and the result is
   *a
   :*b
   :*q
   :*c

Windows 7/Chrome 33.0.1750.154 m & Firefox 28.0

--------------------------
**Version**: unspecified
**Severity**: major
...adding an item to *a bullet* list...
This happen when you're editing a template, or, if you're just adding it instead, once you add the parameter as well.
For example of very long names try to change Infobox settlement in https://en.wikipedia.org/wiki/Ames,_Iowa?veaction=edit .
Since some of these parameters only differ at the very end, like Fram noted, the user can be confused when seeing what is apparently the same parameter just repeated. Some of them also lack a description, so the description alone wouldn't solve the problem.
While he suggests that "a pop-up that displays the full name may be some initial solution", I think adjusting the character size or window size might work better.

--------------------------
**Version**: unspecified
**Severity**: normal
We fixed this by making them not on the side but above.
See reproduction below
```
[subbu@earth:~/work/wmf/parsoid] cat /tmp/wt
[[Imagem:Ellipse PLS en.png|256px|thumb|Parâmetros de uma elipse.]]
[subbu@earth:~/work/wmf/parsoid] php bin/parse.php --wt2wt < /tmp/wt
[[Imagem:Ellipse PLS en.png|256px|thumb|Parâmetros de uma elipse.]]

[subbu@earth:~/work/wmf/parsoid] php bin/parse.php --domain pt.wikibooks.org < /tmp/wt > /tmp/old.html
[subbu@earth:~/work/wmf/parsoid] cp /tmp/old.html /tmp/new.html

... edit new.html and change the image ...

[subbu@earth:~/work/wmf/parsoid] php bin/parse.php --domain pt.wikibooks.org --html2wt < /tmp/new.html 
[[Ficheiro:Ellipse_PLS_en.snv|256px|thumb|Parâmetros de uma elipse.]]
```

----------
On this edit
https://pt.wikibooks.org/wiki/Matem%C3%A1tica_elementar/Trigonometria/Arcos_e_%C3%A2ngulos?diff=270018
VisualEditor replaced the good namespace "Imagem" by "Ficheiro", which is worse.
The word "Ficheiro" is not appropriated here:
* It is not used in the pt-BR variant, so per discussion in the community it should be avoided whenever it is possible[1][2]. And it is always possible to be avoid this word if the file is an image (because "Imagem" is a common word in pt-BR and pt-PT);
* It replaced a precise description of the file by a generic one. There is nothing wrong in saying that "Foo.PNG" is a image.

[1] https://pt.wikipedia.org/wiki/WP:Esplanada/propostas/Incentivar_o_uso_de_%22Imagem%22_em_vez_de_%22Arquivo%22_ou_%22Ficheiro%22_(12mar2011)
[2] http://sourceforge.net/p/pywikipediabot/bugs/1323/

--------------------------
**Version**: unspecified
**Severity**: normal
This is still happening:
https://pt.wikipedia.org/w/index.php?diff=42819013
https://pt.wikipedia.org/w/index.php?diff=42819531
https://pt.wikipedia.org/w/index.php?diff=42819605
https://pt.wikipedia.org/w/index.php?diff=42819868
This is still happening:
https://pt.wikipedia.org/w/index.php?diff=42819013
https://pt.wikipedia.org/w/index.php?diff=42819531
https://pt.wikipedia.org/w/index.php?diff=42819605
This is still happening:
https://pt.wikipedia.org/w/index.php?diff=42819013
https://pt.wikipedia.org/w/index.php?diff=42819531
This is still happening:
https://pt.wikipedia.org/w/index.php?diff=42819013
https://pt.wikibooks.org/w/index.php?title=Matem%C3%A1tica_elementar/Trigonometria/Arcos_e_%C3%A2ngulos&oldid=264430&veaction=edit

http://parsoid-lb.eqiad.wikimedia.org/_rt/ptwikibooks/Matem%C3%A1tica_elementar/Trigonometria/Arcos_e_%C3%A2ngulos?oldid=264430

I tried a vedit on that version and ran rt on it, for good measure. The issue seems to be resolved but please reopen if I'm mistaken.
Sorry for the slow triage here; I'm not sure if this is still an issue in Parsoid?
Steps to reproduce:

1.Open a page with VE
2.Add a numbered or bullet list
3.Edit the first item of the list
4.Add indentation to it
5.Place the cursor just before the list
6.Press delete

Observed Result:
Instead of unindenting it, it rather merges it with the previous line .

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

**See Also**: {T63863}
screenshot 1

Steps to reproduce:

1.Go to the media settings of an image
2.Create a slug 
3.Try to insert a special character/link/reference in the slug


Observed Result:

It shows an error in the console: Uncaught Error: Offset could not be translated to a DOM element and offset: 63
Also if it is an inspector it goes all blank


See the screenshot attached

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

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

**Attached**: {F13082}
Verified the fix in production
Verified the fix in test2
This is now fixed with latest slug work I guess.
Huh. Darn.
Nope, this bug must have a different cause because it occurs in test2 and production as well.
That was bug 71825, now fixed.
This issue has resurfaced with error as "Uncaught Error: offset -1 out of bounds" when trying to insert a link/special character in a slug.
I believe/hope this is now fixed…
Try the first image on this page:http://en.wikipedia.beta.wmflabs.org/wiki/24thMarchrome?veaction=edit
Created attachment 14893
screenshot 2

**Attached**: {F13083}
Screenshot

Steps to reproduce:]


1.Open a page with VE
2.Select the whole line just preceding a Heading
3.Insert a gallery with some invalid code: for example:


An example image. It has flowers and flowers It has flowers and flowersIt has flowers and flowersIt has flowers and flowersIt has flowers and flowersIt has flowers and flowers


Observed Result:
1. The text inside gallery inspector gets overlapped with the heading 
2. After saving you will see the gallery code got inserted in the TOC 
3.The heading got converted to paragraph format
4.The gallery code is appearing just beside the heading in paragraph format ( in addition to appearing inside the gallery)

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=Newpagetocheck62934

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

**Attached**: {F12890}
For example, action=visualeditor is an internal API for the VisualEditor client to talk to its server, isn't really useful for third parties, and isn't remotely stable. However, because it's a built-in assumption that APIs are for third-party use rather than every tool being the first client of its API, this isn't possible. Boo.

--------------------------
**Version**: 1.23.0
**Severity**: normal
Change 160798 merged by jenkins-bot:
API: HTMLize and internationalize the help, add Special:ApiHelp

https://gerrit.wikimedia.org/r/160798
Taken over by Brad.
Change 158546 abandoned by Legoktm:
API: Implement concept of 'internal' API modules

Reason:
Superseded by Ib14c00df06d85c2f6364d83b2b10ce34c7f513cc

https://gerrit.wikimedia.org/r/158546
Change 160798 had a related patch set uploaded by Anomie:
API: HTMLize and internationalize the help, add Special:ApiHelp

https://gerrit.wikimedia.org/r/160798
Change 158546 had a related patch set uploaded by Alex Monk:
Make it possible for API modules to hide their documentation behind an 'includeinternal' parameter

https://gerrit.wikimedia.org/r/158546
Brainstorming:

Add a method, something like "isInternalApi", to ApiBase that by default returns false.

Add a boolean "includeinternal" parameter to ApiHelp, which when specified would include these internal API modules.

Adjust ApiBase::makeHelpMsg() to take a boolean indicating whether internal API modules should be shown (i.e. whether "includeinternal" was given to action=help).

Then ApiHelp::execute(), if not passed a "modules" parameter explicitly, would check the flag and isInternalApi() to decide whether to include each module in the output. Modules like ApiQuery that have submodules would use the new parameter to their ::makeHelpMsg() methods to do the same.

The help output should also include indication of whether a module is internal, much like it now does for stuff like "This module only accepts POST requests".

I'm not sure whether we should also try to adjust the output of getAllowedParams() to omit these internal modules from the valid values for "action", or if that would be too expensive for too little gain (if we did do that, we'd need to do like how ApiPageSet handles generators). We certainly should be sure not to omit the internal modules for action=paraminfo though.


(In reply to James Forrester from comment #0)
> For example, action=visualeditor is an internal API for the VisualEditor
> client to talk to its server, isn't really useful for third parties, and
> isn't remotely stable. However, because it's a built-in assumption that APIs
> are for third-party use rather than every tool being the first client of its
> API, this isn't possible. Boo.

Ideally a tool's API would be perfectly usable by third parties, not something overly specific to the one tool's internal implementation, although that may not always be possible. I don't know which is the case for VE's API or if it's just that it's not yet stable.
Maybe we should have not deprecated the ajax interface.
Steps to reproduce:

If you drag a page down which contains an image large enough to go beyond the border of developer tool and has the developer tool open ,the image seems to flicker and appear again while the shield stays in the same position.

Try this page.
See the Video Capture attached

--------------------------
**Version**: unspecified
**Severity**: minor
Yes, this is not happening anymore
I think this is now working.
Page:https://test2.wikipedia.org/wiki/Wmf19?veaction=edit
screenshot attached

Steps to reproduce:

1.Open a page with VE
2.Insert a small default sized SVG image for example a SVG image with 50x50px :https://en.wikipedia.org/wiki/File:Gnome-fs-home.svg

3.Now Save the page

Observed Result:
The image size that appears after saving is much larger (200x200px) 

See the screenshot attached.

Test Environment: production
Browser: Chrome Version 26.0.1410.65
Page:https://en.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/sandbox

See the screenshot attached

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

**Attached**: {F13403}
Verified the fix in en.wiki running wmf 8
Change 137442 merged by jenkins-bot:
Followup to small SVG default size

https://gerrit.wikimedia.org/r/137442
Change 137442 had a related patch set uploaded by Mooeypoo:
Followup to small SVG default size

https://gerrit.wikimedia.org/r/137442
Change 137054 merged by jenkins-bot:
Small SVG images should still adhere to default thumb size

https://gerrit.wikimedia.org/r/137054
Change 137054 had a related patch set uploaded by Mooeypoo:
Small SVG images should still adhere to default thumb size

https://gerrit.wikimedia.org/r/137054
Since Parsoid already runs an API call for each image given to it in wikitext, it would be extremely helpful for the editing in terms of user experience if the call also asked for the original dimensions.

At the moment, VisualEditor asks for details from the API on each edited image to get its original dimensions. When this is done for the edit dialog the asynchronous call works fine because we don't mind letting the user wait the seconds it takes the async call to finish.

But when the user resizes images with the mouse (with the resize handles) the information about original dimensions usually comes too late. The user may (and often does) resize the image to above its limits, and by the time VE gets the API response, the user is already done resizing. On top of that, calculating aspect ratio from original size is a lot more accurate than calculating it from the given (usually smaller) size, though, granted, this is a lot less crucial.

We have some fall backs and we are considering an after-the-fact user experience ideas to make this work, but it would be extremely helpful if the information was already available when it comes from Parsoid -- especially since Parsoid already asks for information from the API.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Disregard, this was already closed
Chiming in from iOS, we'd love to know the current thumbnail and original size so we can handle scaling up to higher resolutions elegantly.  Is it worth making which properties to include configurable?  Maybe some clients don't want it, maybe some do?
@esanders, @jdforrester-WMF: perhaps you VE guys should add one?  I think @mooeypoo was doing the original work here (a year ago!).
Is there a task for VE to use this now?
This will go out on Monday. Roan confirmed that there are no VE changes that are required. Also for a while, VE should be prepared to accept HTML with / without these attributes till all the revisions turn over in RESTBase.
Change 195666 merged by jenkins-bot:
T64881: Add original dimension information for images.

[[https://gerrit.wikimedia.org/r/195666]]
Change 195798 abandoned by Cscott:
T64881: Add original dimension information for images to data-mw.

Reason:
Abandoned in favor of https://gerrit.wikimedia.org/r/195666

[[https://gerrit.wikimedia.org/r/195798]]
Should missing/error images have `data-file-width`/`data-file-height` attributes?  Right now I'm not adding them.
Restating subbu's (b) slightly, for more accuracy: Mediaviewer already adds it (to PHP parser output), and so other gadgets might expect it.
Summary of IRC conversation:

So, if we had to add this info, it makes sense to add data-file-width and data-file-height attributes because (a) it is read only (b) mediaviewer and other gadgets already expect it and when Parsoid html is used for read views, those applications don't break suddenly (c) most pages have few images relative to the size of the DOM itself, so the DOM bloat is expected to be minor.

Parsoid is probably already handling HTML invalidation (via parsoid cache update jobs, to be confirmed for sure) and so there are no new cache invalidation issues that crop up from this change.
Change 195798 had a related patch set uploaded (by Cscott):
T64881: Add original dimension information for images to data-mw.

[[https://gerrit.wikimedia.org/r/195798]]
Uploaded a patch ^ which uses `data-file-width` and `data-file-height` to match the PHP HTML output created by the MediaViewer extension.

Perhaps this bloats the DOM, and we should use data-mw instead.  I don't have a strong opinion here.  My hand-wavy argument is that data-mw should be used for properties which are important/signficiant for editors in terms of defining a particular wikitext serialization.  These new `data-file-*` properties are not consulted for WTS, they are just ignored.

(But perhaps we should consult these in order to serialize upright images correctly?)
Change 195666 had a related patch set uploaded (by Cscott):
T64881: Add original dimension information for images.

[[https://gerrit.wikimedia.org/r/195666]]
What do we want to happen if the target image doesn't exist?  Presumably leave off the attributes, right?
That comes from Multimedia Viewer or some such.
Mediawiki core seems to use `data-file-width` and `data-file-height` on `<img>` tags for this.  I wonder when that was added to core?
Per conversations last week this should be reprioritised.
The size concern also matters less once we move data-mw out of the DOM. There's still the minor nuisance of having some read-only attributes in data-mw, which is otherwise a read-write interface.

Maybe it would make sense to group dimensions & image type in a separate 'imageinfo' sub-object inside data-mw that is documented to be read-only. The grouping & naming should make it clearer that this is read-only info only, even without looking at the docs.
On top of the dimensions, it would also be helpful to get the 'mediatype' property of images, separating them between "DRAWING" and "BITMAP". The two types behave differently, especially with size considerations.

It is useful for VE to know (we request this now with our separate api call) but it might actually make sense to categorize the difference between the images for other purposes.
We have a new strategy for serializing square bounding boxes that will be helped by having original image size hanging around, so we will probably put original image size in data-mw.
I do agree we should be careful, but I think this is worth including. It's really useful and costs very little.
(In reply to C. Scott Ananian from comment #1)
> I'm not convinced we should be bloating our Parsoid DOM representation with
> original size information which can easily be obtained from the imageinfo
> API.  In order to do a proper resize, you are probably going to have to
> fetch the original image anyway so that things don't get blurry when you
> scale up.
> 
> But I'm interesting in hearing other thoughts.

We don't fetch the original image unless the new size is the image's original dimensions – we ask MW for the thumbnail of that size. We certainly don't ask e.g. for a 10MiB original 5000x4000px image when the user is just resizing from 250x200px to 300x240px. Also, we fetch the new image /after/ the image is resized.
I'm not convinced we should be bloating our Parsoid DOM representation with original size information which can easily be obtained from the imageinfo API.  In order to do a proper resize, you are probably going to have to fetch the original image anyway so that things don't get blurry when you scale up.

But I'm interesting in hearing other thoughts.
1. Open save dialog. It animates normally to small size.
2. Click Review changes. Dialog animates to medium size.
3. Close dialog.
4. Open dialog again.

When the dialog opens again, it's still medium size from last time, which we animate back to small. But this animation is concurrent with the scale 0.5->1.0 opening animation, and the result of the two animations combined is pretty strange-looking.

--------------------------
**Version**: unspecified
**Severity**: minor
Verified the fix in production (en.wiki)
Yay Trevor. :-)
screenshot-1

Steps to reproduce:

1.Open a page with VE
2.Insert an image 
3.Go to Media Settings>General Settings 
4.Click outside the caption textbox
5.Click on link inspector icon

Observed Result:
The link inspector opens outside the textbox.
See the screenshot attached


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

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

**Attached**: {F13306}
Verified the fix in production (en.wiki)
Verified the fix in test2 running wmf9
I believe that this one is now fixed courtesy of Ed's changes this week or last.
Created attachment 14866
screenshot

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

1.Open a page with VE
2.Now change the image settings to Right,Basic and Border 
3.Save the page

Observed Result:
In the wikitext the options "Right" and "Border" are missing

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

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in test2
Verified the fix in Betalabs
Skipping right (and just using default) is OK for thumb and frame (but not frameless or basic).
So, this is still happening.In addition to that, for all Right aligned Images regardless of its type the alignment options gets missing from the wikitext
CE responds correctly to the type and alignment shifts, and yet something seems to goes awry in the DM. I'm checking into the issue.
Parsoid does the right thing with the input giving the expected output:

<figure class="mw-default-size mw-halign-right mw-image-border" typeof="mw:Image" data-parsoid="{&quot;optList&quot;:[{&quot;ck&quot;:&quot;thumbnail&quot;,&quot;ak&quot;:&quot;thumb&quot;},{&quot;ck&quot;:&quot;left&quot;,&quot;ak&quot;:&quot;left&quot;},{&quot;ck&quot;:&quot;caption&quot;,&quot;ak&quot;:&quot;Foo&quot;}],&quot;dsr&quot;:[0,35,2,2]}"><a href="./File:Example.png" data-parsoid="{&quot;a&quot;:{&quot;href&quot;:&quot;./File:Example.png&quot;},&quot;dsr&quot;:[2,null,null,null]}"><img resource="./File:Example.png" src="//upload.wikimedia.org/wikipedia/en/thumb/7/70/Example.png/220px-Example.png" height="238" width="220" data-parsoid="{&quot;a&quot;:{&quot;resource&quot;:&quot;./File:Example.png&quot;,&quot;height&quot;:&quot;238&quot;,&quot;width&quot;:&quot;220&quot;},&quot;sa&quot;:{&quot;resource&quot;:&quot;File:Example.png&quot;}}"></a><figcaption data-parsoid="{&quot;dsr&quot;:[null,33,null,null]}">Foo</figcaption></figure>

->

[[File:Example.png|Foo|right|border]]
Created attachment 14864
Screenshot

**Attached**: {F13291}
Screenshot

Steps to reproduce:

This issue was found specifically on this page for the second image:

http://en.wikipedia.beta.wmflabs.org/wiki/19thMarChrome?veaction=edit

The original settings for the image was Right,Basic and Border.

When I changed the image position to "Centre", it appeared distorted with irregular highlight box for the image

See the screenshot attached:


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

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

**Attached**: {F13287}
No, definitely still happening.

Issue seems to be that the centre-floated image is moved down by the lack of space to below the right-floated image, but the document's length is not extended (so it runs off the edge of the window) and the shield remains in place (so you can click on the image and go to the File: page)…
This should be fixed now.
This doesn't happen when the image is by itself on the page (or inside a bunch of paragraphs) so I am pretty sure this is due to the fact the image is within two PRE tags.
Right now, MWLinkInspector needs to know exactly how to construct a new link annotation with the right attributes. This pattern is repeated (albeit somewhat less egregiously) for every single annotation and node created by any UI component anywhere. This is horrible. The DM should provide helpers so UI classes can much more easily create linmod elements from data.

----

Update, 2015-08-25: We now have a bespoke method for the MW link inspector, but the general pattern across VE's UI is still there.
Change 233727 merged by jenkins-bot:
Use new internal link builder

[[https://gerrit.wikimedia.org/r/233727]]
Change 233727 had a related patch set uploaded (by Esanders):
Use new internal link builder

[[https://gerrit.wikimedia.org/r/233727]]
Change 231155 merged by jenkins-bot:
Builder for ve.dm.MWInternalLinkAnnotation

[[https://gerrit.wikimedia.org/r/231155]]
From IRC:
> James_F: RoanKattouw says that for T64816 something that every UI tool can call (name not really thought of; #constructMe() or whatever) was what he was thinking.

The patch in https://gerrit.wikimedia.org/r/231155 is just a tiny start, it makes it a little easier to construct correct `ve.dm.MWInternalLinkAnnotation` objects given a `mw.Title`.  It doesn't address the bigger picture, since I don't really have  a solid grasp on the bigger picture.
Change 231155 had a related patch set uploaded (by Cscott):
Builder for ve.dm.MWInternalLinkAnnotation

[[https://gerrit.wikimedia.org/r/231155]]
Duplicated logic is bad.

--------------------------
**Version**: unspecified
**Severity**: enhancement
>>! In T64803#3380142, @Esanders wrote:
> Red link code is now in Parsoid so can be removed from VE

Will need us to round-trip new links, though. Right now we pick how to render them with local code which is pretty speedy.
Red link code is now in Parsoid so can be removed from VE
(In reply to Gabriel Wicke from comment #2)
> For static pages we should be able to do this with CSS retrieved from an
> API. We'll provide this API for normal pages.

*nods*


> For dynamic hints during editing we'd still need to inject styles
> dynamically. The latter would probably remain VE-specific.

Yeah, but Flow/etc. may want to style too.
For static pages we should be able to do this with CSS retrieved from an API. We'll provide this API for normal pages.

For dynamic hints during editing we'd still need to inject styles dynamically. The latter would probably remain VE-specific.
(In Parsoid or whatever; the point is, this code should be re-useable by Flow, OCG and anyone else rather than buried inside VE.)
1. Create a page with just a table
2. Focus the top slug (it animates)
3. Focus the bottom slug

Expected:
Top slug collapses, bottom slug expands

Observed:
Nothing

The logic for adding animation classes only checks to see if we've gone from in a slug to not in a slug, so we'll need to check if the slug has changed as well.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 119287 merged by jenkins-bot:
Check if newly focused slug is different to previous slug

https://gerrit.wikimedia.org/r/119287
Change 119287 had a related patch set uploaded by Esanders:
Check if newly focused slug is different to previous slug

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

1.Open a page with VE
2.Insert an external link in the VE so that it prompts to enter a captcha 
3.Click on the Save Page button
4.Click on the Save Page button on the Save dialog
5.Fill up the textbox for the captcha
6.Click on "Review Your Changes"
7.Return to the save form


Observed Result:
It again asks you to fill up a new captcha

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in Betalabs
Change 129830 merged by jenkins-bot:
Call clearAllMessages in setup instead of swapPanel on the save dialog

https://gerrit.wikimedia.org/r/129830
Change 129830 had a related patch set uploaded by Alex Monk:
Call clearAllMessages in setup instead of swapPanel on the save dialog

https://gerrit.wikimedia.org/r/129830
Kenan reports some sluggishness on iPads, and will update this bug with more details.

--------------------------
**Version**: unspecified
**Severity**: normal
Not actionable as a task; this is a tracker.
Is this a bug or a tracker?
In ve.ce.MWTreferenceListNode we do something quite evil, which is creating a one-off CE node, adding it's $element to the DOM, then destroying it. This happens to work because destroy doesn't abort async rendering processes, but in the future this may change. It's also quite messy to do things this way, and all we really need is a simple way to get a rendering from a model.

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

Steps to reproduce:


1.Open a page with VE
2.Add a caption to it
3.Save the page 
4.Reopen the page
5.Go to the Media Settings of that image and change the image type to thumbnail/frame


Observed Result:
The image highlight box does not appear properly, caption also gets missing

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/14thmarchwmf18

Try the image in this page

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

**Attached**: {F12893}
(In reply to ryasmeen from comment #7)
> Created attachment 15871 [details]
> Screenshot
> 
> Making an image frame-right or frame-left makes the highlight of the image
> too big to go beyond the CE, not sure if this should be tagged with this bug
> or not.
> 
> See the screenshot attached

I think that's a distinct issue. :-(

**Attached**: {F12897}
bug* not bag :|
Created attachment 15871
Screenshot

Making an image frame-right or frame-left makes the highlight of the image too big to go beyond the CE, not sure if this should be tagged with this bag or not.

See the screenshot attached

**Attached**: {F12897}
This now appears to be working fine?
Edited wrong bug, ignore change 137040 and above comment.
Issue is with dm selection, not shields/highlights.
Change 137040 had a related patch set uploaded by Esanders:
[BREAKING CHANGE (ish)] Track orignal data position in insertion operations

https://gerrit.wikimedia.org/r/137040
This issue did not get resolved with new image model.
Created attachment 15299
Screenshot april 5th

**Attached**: {F12895}
Moved out of bug 38129's wishlist into its own bug.

--------------------------
**Version**: unspecified
**Severity**: normal
Moved out of bug 38129's wishlist into its own bug.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Moved out of bug T40129's wishlist into its own bug.

--------------------------
**Version**: unspecified
**Severity**: enhancement
I think that whatever solution is reached, it should comply with relevant policies on the Wikipedias that are affected by it. On enwiki, (https://en.wikipedia.org/wiki/Wikipedia:Image_use_policy#Displayed_image_size), the following policy is in place:

"**Except with very good reason, do not use** px (e.g. thumb|300px), **which forces a fixed image width.** In most cases upright=scaling factor should be used, thereby respecting the user's base preference (which may have been selected for that user's particular devices)."

Additionally, respecting a user's preference for image size is an accessibility issue, and needs careful consideration before any attempt is made to change or eliminate it.
>>! In T64671#3130642, @Schnark wrote:
>>>! In T64671#1734077, @Trizek-WMF wrote:
>> So the message we have to spread is "don't use upright anymore" ? 
> Is somewhere work going on  to implement a replacement for "upright" which will be supported in VE?

It looks to me like this is being blocked by T351 and T65904. Discussion above appears to indicate that implementing what `upright` //does// is being held up by a desire to redefine what it //should// do, or even to //deprecate// it.
>>! In T64671#1734077, @Trizek-WMF wrote:
> So the message we have to spread is "don't use upright anymore" ? 

Are there any updates on this? Is somewhere work going on  to implement a replacement for "upright" which will be supported in VE?
So the message we have to spread is "don't use upright anymore" ?
Change 238855 had a related patch set uploaded (by Cscott):
WIP: Allow serialization of images which scale the default thumbnail size.

[[https://gerrit.wikimedia.org/r/238855]]
The `upright` option suffers from some severe problems.  Consensus was reached on replacing it, see https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes  -- unfortunately, the replacement agreed upon had to be reverted due to some unexpected interactions with page layout.  We need to revisit the RFC and select one of the other proposed options for implementation.

But at the moment, authoring new content using the `upright` flag is discouraged.  There is a separate bug (T112710) that currently affects resizing images tagged with `upright`; that will be fixed.  But that will result in a serialization with an explicit bounding box, not the upright flag, and we have no current plans to emit an `upright` flag in newly-authored content.  Any existing use cases should be dealt with as part of the {T351} process (go comment over there!), so that we can come up with a way to solve these problems which doesn't rely on a broken feature.
[[https://fr.wikipedia.org/w/index.php?title=Wikip%C3%A9dia:%C3%89diteurVisuel/Avis&diff=118625212&oldid=118570520|New feedback]] concerning upright.
A user on frwp [[ https://fr.wikipedia.org/w/index.php?title=Wikip%C3%A9dia:%C3%89diteurVisuel/Avis&diff=116008432&oldid=115979310 | explains ]] that having a number of pixels instead of an upright (configurable) is an accessibility problem.
A user on frwp [[ https://fr.wikipedia.org/w/index.php?title=Wikip%C3%A9dia:%C3%89diteurVisuel/Avis&diff=116008432&oldid=115979310 | explains ]] that having rough pixels instead of an upright is an accessibility problem.
A user on frwp [[ https://fr.wikipedia.org/w/index.php?title=Wikip%C3%A9dia:%C3%89diteurVisuel/Avis&diff=116008432&oldid=115979310 | explains ]] this upright issue is an accessibility problem.
So the blocking status for T64666 is a little misleading here.  AFAIK, Parsoid parses the 'upright' option properly, and emits DOM with the correct size set.

But we're not clear at all that we want to support *authoring* images with the 'upright' option, because we'd rather deprecate that option and replace it with something better.

So, can we reset the discussion a little bit: what is the *current* behavior when you edit an image which has the 'upright' option.  What (if anything) is actually broken?
(In reply to Spinningspark from comment #8)
> One point about the upright parameter is that it does something sensible
> with a portrait image by default without the user having to think about what
> scaling factor he wants to use.  The scale parameter per se is a good thing
> to have, but being forced to calculate a scale factor to get the equivalent
> of the old upright parameter is a step backwards in my opinion (its a step
> forward from the current two-steps-backward position of not having anything
> at all but is still a step backwards from what we had before.)

I think you're making assumptions here. :-) The idea was that we'd default to the usual value of 75% (and make it clear that this is the preferred value).
One point about the upright parameter is that it does something sensible with a portrait image by default without the user having to think about what scaling factor he wants to use.  The scale parameter per se is a good thing to have, but being forced to calculate a scale factor to get the equivalent of the old upright parameter is a step backwards in my opinion (its a step forward from the current two-steps-backward position of not having anything at all but is still a step backwards from what we had before.)
(In reply to C. Scott Ananian from comment #6)
> Mm.  Now I'm thinking the mw option might be `square` so that Parsoid emits:
> 
> [[Figure:Foobar.jpg|200px|square]]
> [[Figure:Foobar.jpg|thumb|square]] <!-- equivalent to upright=1 -->
> [[Figure:Foobar.jpg|upright=0.5|square]]
> 
> That would provide the same functionality but address James' concern in
> comment 2.

I'm not a fan of adding more work-arounds that modify older work-arounds. If we can fix this up cleanly with something like scale & square bounding box by default then we should do so IMO. That would result in cleaner wikitext like this:

[[Figure:Foobar.jpg|200px]]
[[Figure:Foobar.jpg|thumb]]
[[Figure:Foobar.jpg|scale=0.75]]

An automatic conversion that preserves existing image sizes is very much possible if the community agrees that going for a square bounding box by default makes sense. But again, lets not get ahead of ourselves to much here & focus on the Parsoid interface for now.
Mm.  Now I'm thinking the mw option might be `square` so that Parsoid emits:

[[Figure:Foobar.jpg|200px|square]]
[[Figure:Foobar.jpg|thumb|square]] <!-- equivalent to upright=1 -->
[[Figure:Foobar.jpg|upright=0.5|square]]

That would provide the same functionality but address James' concern in comment 2.
200x200px is what we already emit.  That's been the case for a while.

Current thinking is that the new PHP image option will be called 'scale' (not 'thumbscale'), and that parsoid will mark its use with a 'mw-scale' class on the image wrapper, not a data-mw attribute.
(In reply to James Forrester from comment #2)
> That seems bad. [[Figure:Foobar.jpg|200px]] is vastly-preferred and
> [[Figure:Foobar.jpg|200x200px]] is considered broken wikitext except in rare
> cases.

We could also omit this if we don't care about size stability on image aspect ratio change. Alternatively we could also change the default behavior to use a square bounding box. Lets make that decision when we get there. For now we'll just use upright.
Related: https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails_sizes

We could encourage users to use a limited set of pre-defined scaling factors. This could potentially let us handle some user pref based scaling in CSS instead of JS.

For now the plan is to add a data-mw.scale factor which corresponds to a default-sized image. If the format is 'thumb' or 'frameless', the default image size is given by a *square bounding box* of the default thumb size.
(In reply to C. Scott Ananian from comment #1)
> Parsoid will *only* generate wikitext of the form:
> 
> [[Figure:Foobar.jpg|200x200px]]
> or
> [[Figure:Foobar.jpg|thumb|thumbscale=1]]

That seems bad. [[Figure:Foobar.jpg|200px]] is vastly-preferred and [[Figure:Foobar.jpg|200x200px]] is considered broken wikitext except in rare cases.
The parsoid plan is to support only square bounding boxes.

Unfortunately, PHP core doesn't have a way to specify 'a square bounding box of the default thumbnail size' yet.  So for purposes of discussion let's assume there's a wikitext option named 'thumbscale' which enforces a square bounding box of (an appropriate factor of) the default thumbnail size (then quantized to nearest 10px, like upright does, in order to avoid creating lots of odd-sized thumbs).

So Parsoid will *only* generate wikitext of the form:

[[Figure:Foobar.jpg|200x200px]]
or
[[Figure:Foobar.jpg|thumb|thumbscale=1]]

We will attempt to round-trip other wikitext forms ('upright', 'x200px', 'thumb' by itself (which is a width restriction only), etc) if the image is not edited.  But if the image is edited, we will emit only a square bounding box.

In the short term, we might use:

[[Figure:Foobar.jpg|thumb|upright=<number>]]

as an approximation to the 'thumbscale' factor, where we compute <number> as <aspect ratio>*<thumbscale>.  But this is viewed as a short term hack only.

The VE UI should present this as something like 'use default thumbnail size', rather than explicitly mentioning the 'upright' parameter.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert a template
3.Click on Add Parameter
4.But do not add any parameter just click on "Apply Changes"
5.Reopen the template

Observed Result:
An undefined parameter appears inside the template dialog box

See the screenshot attached


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_(WMF)/sandbox&veaction=edit

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

**Attached**: {F13443}
Verified the fix in test2 : https://test2.wikipedia.org/wiki/Wmf19?veaction=edit
Change 119699 merged by jenkins-bot:
Ignore placeholder parameters in serialization

https://gerrit.wikimedia.org/r/119699
Change 119699 had a related patch set uploaded by Catrope:
Ignore placeholder parameters in serialization

https://gerrit.wikimedia.org/r/119699
It's technically not corrupting wikitext, just inserting oddness, but yes.
This is causing wikitext corruption on the wikis, upping severity.
*** Bug 62827 has been marked as a duplicate of this bug. ***
Screenshot of MediaWiki rendering

Wikitext:

=== Example ===
Foo <code>bar</code> baz.
You'll want to add <source lang="javascript">
        "predef": [
                "OO",
        ]
</source> x y.


In MediaWiki's PHP parser:

  <h3>..</h3>
  <p>Foo <code>bar</code> baz.</p>
  <p>You'll want to add</p>
  <div> .. syntax highlgiht ..
  <p>x y.</p>

In Parsoid:

  <h3>..</h3>
  <p>Foo <code>bar</code> baz.</p>
  You'll want to add
  <div> .. syntax highlgiht ..
  x y.

Notice the lack of paragraphs from the Parsoid DOM, though this is odd, it still renders fine visually in browsers.

In VisualEditor:

  <h3 class="ve-ce-branchNode">Naming</h3>
  <p class="ve-ce-generated-wrapper ve-ce-branchNode">
    You'll want to add&nbsp;
    <span class="ve-ce-leafNode ve-ce-generatedContentNode ve-ce-mwExtensionNode ve-ce-mwAlienExtensionNode ve-ce-protectedNode" contenteditable="false">
      <div dir="ltr" class="mw-geshi mw-code mw-content-ltr" typeof="mw:Extension/source" data-mw=".." about="#mwt24">..</div>
    </span>
    &nbsp;x y.
  </p>

It renders as an inline-block within a paragraph, that's where it goes wrong.

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

**Attached**: {F13385}
Created attachment 14805
Screenshot of Parsoid rendering and Parsoid DOM

**Attached**: {F13389}
Created attachment 14804
Screenshot of VisualEditor rendering

**Attached**: {F13387}
* Latest mediawiki and VisualEditor master locally
* Chrome incognito
* Sandbox?veaction=edit

Shows:

 1 notice                      X
 ----
 Warning: You are not logged in.
 Your IP address will be recorded
 in this page's edit history.

When hovering over the [X], the text "1 notice" and "Warning: .. " go down 1px and then back up again.

Not sure what it causing it, could be a browser rendering bug.

--------------------------
**Version**: unspecified
**Severity**: minor
Change 121279 merged by jenkins-bot:
Don't use transitions for opacity on hover for now

https://gerrit.wikimedia.org/r/121279
Change 121279 had a related patch set uploaded by Catrope:
Don't use transitions for opacity on hover for now

https://gerrit.wikimedia.org/r/121279
Cause of the wiggling seems to be a transition on the opacity. Going to work around this by just commenting out that transition, because it's such a minor detail.

I'll also try to isolate a test case and file a bug upstream with Chrome.
*** Bug 63020 has been marked as a duplicate of this bug. ***
Widening scope, the "back" button of the inspector context is affected as well.

Screen capture of "Toolbar notice close button"
: http://cl.ly/2O3c2F072a02


Screen capture of "Inspector context back button"
: http://cl.ly/2S3g0V0y2O1J
Screen capture: http://cl.ly/2O3c2F072a02
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Save the page
4.Reopen the page
5.Open the media settings for the image 

Observed Result:
The following error appears in the console and Media Settings dialog box cannot be closed:

Uncaught TypeError:Cannot read property 'width' of null
Uncaught TypeError:Cannot call method 'getItemFromData'of undefined.


See the screenshot attached

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 
Page:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=12thmarchchrome

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

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

https://gerrit.wikimedia.org/r/118601
(In reply to James Forrester from comment #4)
> Still occurring after the above patch. :-(

Belay that, now working. Probably browser cache issues. *sigh*

(Thanks, Moriel!)
Still occurring after the above patch. :-(

I've re-worded the bug title based on my understanding. The issue is probably in the binding of the variable – note that everything is fine as soon as you refresh the page, the problem is when you re-load VE on the same page (so re-using a lot of the VE running code).
Change 118427 merged by jenkins-bot:
Fix regression bug 'default size' change on alignment

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

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

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

Steps to reproduce:

1.Open a page in VE
2.Insert a reference
3.Open the reference dialog 
4.Insert another reference inside it
5.Save the page

Observed Result:
In read mode :Cite error: Closing </ref> missing for <ref> tag appears
Inside VE: for the reference that is inside another reference, the wikitext appears in the reflist section

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

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

**Attached**: {F13271}
Verified the fix in test2:https://test2.wikipedia.org/w/index.php?title=Wmf19&veaction=edit
Change 119704 merged by jenkins-bot:
Followup 861d097: actually exclude reference tool in reference dialog toolbar

https://gerrit.wikimedia.org/r/119704
(In reply to Roan Kattouw from comment #2)
> Adding references inside of references shouldn't be possible. That toolbar
> button is supposed to be hidden. Repurposing bug.
> 
Turned out to be an accidental overcorrection from fixing bug 62286.
Change 119704 had a related patch set uploaded by Catrope:
Followup 861d097: actually exclude reference tool in reference dialog toolbar

https://gerrit.wikimedia.org/r/119704
Adding references inside of references shouldn't be possible. That toolbar button is supposed to be hidden. Repurposing bug.

However, we should verify that we deal correctly with cases where this has already been done in wikitext.
Created attachment 14794
Wikitext in the reflist

**Attached**: {F13272}
I learned today from Rob Lanphier that it has recently become possible to do this reliably in every extension repo as well as mw core: 

$ git checkout wmf/1.23wmf17


For example: 

/VisualEditor$ git checkout wmf/1.23wmf17
Branch wmf/1.23wmf17 set up to track remote branch wmf/1.23wmf17 from origin.
Switched to a new branch 'wmf/1.23wmf17'

The current branch of each wiki is tracked in https://git.wikimedia.org/blob/operations%2Fmediawiki-config/HEAD/wikiversions.json

The current branch of core (which should be consistent across all extensions also) is available on https://test2.wikipedia.org/wiki/Special:Version (and theoretically in the API somewhere)

It would be good if we could change our Jenkins builds with test2 as a target to pull the current wmf branch instead of master. 

In the short term, we could update the build config manually every Thursday. 

In the slightly longer term it should be possible to read Special:Version or the wikiversions.json file in order to determine at run time the proper version of the tests appropriate for test2 (and any other target environment not beta labs, e.g. enwiki or commons)

--------------------------
**Version**: unspecified
**Severity**: enhancement
I think this was implemented entirely back in May 2014.  The fix was to have MediaWiki API the branch it runs then have the browser test checkout the matching branch, fall backing to master if the branch is not found.
Gilles from the Multimedia team reported an issue with the browser tests running some outdated version of the code.   Turns out the repo was not reset to origin/master but to local master branch.

Fixed up with https://gerrit.wikimedia.org/r/#/c/134576/
I tested it on a few change and it seems to be working fine.

The qa/browsertests.git is missing wmf branches, so I have added a fallback to the 'master' branch.

Lets see what happens tomorrow :)
Change 134483 merged by jenkins-bot:
Fallback to master branch when test repo miss branch

https://gerrit.wikimedia.org/r/134483
Change 134483 had a related patch set uploaded by Hashar:
Fallback to master branch when test repo miss branch

https://gerrit.wikimedia.org/r/134483
Change 134236 merged by jenkins-bot:
Get mw branch from target URL and check it out

https://gerrit.wikimedia.org/r/134236
Change 134376 merged by jenkins-bot:
mw-sort-wmf-branches: sort wmf branchs numerically

https://gerrit.wikimedia.org/r/134376
Change 134376 had a related patch set uploaded by Hashar:
mw-sort-wmf-branches: sort wmf branchs numerically

https://gerrit.wikimedia.org/r/134376
Change 134236 had a related patch set uploaded by Hashar:
Get mw branch from target URL and check it out

https://gerrit.wikimedia.org/r/134236
The lame mw-api-siteinfo.py is now deployed.  We can use to query the target MediaWiki installation to grab the branch and attempt to check it out before running the browser tests.

Should do git checkout -f  iirc.
Change 131861 merged by jenkins-bot:
mw-api-siteinfo: fetch siteinfo from MW API

https://gerrit.wikimedia.org/r/131861
Change 131936 abandoned by Hashar:
API: Expose git branch in siteinfo

Reason:
No urgency to have this deployed in 1.24wmf3 since commit is in the branch wmf/1.24wmf4 which is going to be deployed on the remaining production wikis on May 15th ( https://wikitech.wikimedia.org/wiki/Deployment ).

https://gerrit.wikimedia.org/r/131936
Change 131935 abandoned by Reedy:
API: Expose git branch in siteinfo

Reason:
1.24wmf2 is not used now

https://gerrit.wikimedia.org/r/131935
I will try to get it included in the currently deployed wmf installations, else the patch will land under the next two weeks.

The tiny python script will let us easily get the branch of a target wiki. Knowing it, we can then git checkout that branch before starting the browsertests.

I might be able to handle that during this week hackaton, no promise though.
Change 131936 had a related patch set uploaded by Hashar:
API: Expose git branch in siteinfo

https://gerrit.wikimedia.org/r/131936
Change 131935 had a related patch set uploaded by Hashar:
API: Expose git branch in siteinfo

https://gerrit.wikimedia.org/r/131935
Change 131768 merged by jenkins-bot:
API: Expose git branch in siteinfo

https://gerrit.wikimedia.org/r/131768
The mw-api-siteinfo.py script will let us do something like:

 $ mw-api-siteinfo.py http://test2.wikipedia.org/ git_branch
 1.24wmf2
 $

We can then checkout that branch in the extensions to run the matching set of browser tests.
Change 131861 had a related patch set uploaded by Hashar:
mw-api-siteinfo: fetch siteinfo from MW API

https://gerrit.wikimedia.org/r/131861
Change 131768 had a related patch set uploaded by Hashar:
Api: expose git branch in siteinfo

https://gerrit.wikimedia.org/r/131768
I am pretty sure I have a good idea about fixing this :-]
From bug 64611:

When browsertests hit the production wikis, we should fetch the extension wmf branch that match the targeted website.  The mapping of wiki vs wmf branch can be found via the dblist files in operations/mediawiki-config.git

Instead of using the Jenkins git plugin, we will have to use a script to find out which branch to check.
*** Bug 64611 has been marked as a duplicate of this bug. ***
In this page https://fr.wikipedia.org/w/index.php?title=Utilisateur:Elitre_(WMF)/Prove2&oldid=101942635, if you click Enter twice after the last sub-item of the list and then select Titre de section (Heading), that item and the Portal template below disappear, and results from the Undo action may vary (the French user who found this reports that a couple of CTRL+Z blank the page for him; for me, nothing happens, or the item comes back but the template doesn’t). 
Nothing changes if the list is unordered or ordered, but it does seem to matter that it features sub-items and not just items (as a matter of fact I couldn't reproduce with a simple list here http://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:Elitest&oldid=82999).

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://fr.wikipedia.org/wiki/Utilisateur:Elitre_%28WMF%29/Prove2?oldid=101942635&veaction=edit
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50250
Appears to be fixed
We'll see if the patch for that works :)
Not sure if this is related to bug 50250?
As reported by NicoV on fr.wp, 
unrelated edits remove the syntax for an image from an external wikilink.
See tests at https://fr.wikipedia.org/w/index.php?title=Utilisateur%3ANicoV%2FTest&diff=101782688&oldid=101782616 , https://www.mediawiki.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandboxVE&diff=924704&oldid=924702 .

--------------------------
**Version**: unspecified
**Severity**: major
(In reply to Elitre from comment #1)
> PS: the edit summary window correctly displays the warning that something's
> wrong.

Now that you say there's a warning, I see it, but unless you're looking for it, it's almost invisible, lost among other texts, without any highlighting. And nothing more is said when you save.
PS: the edit summary window correctly displays the warning that something's wrong.
Some (many) templates do not use any parameters (e.g., hundreds of templates like https://en.wikipedia.org/wiki/Template:Stub).  However, if you add those templates, VisualEditor will ask you for parameters, just like it does for any other template.  It would be nice to have a TemplateData setting for "no parameters here, so don't bother asking".

--------------------------
**Version**: unspecified
**Severity**: enhancement
Here's another example for the list of use cases:  The sole contents of
{{userboxbottom}} is the table-closing wikitext code `|}`.  There are
dozens of similar templates on enwiki.  Adding parameters to these is
pointless at best.
But @Krinkle  why shouldn't we have a way to signal that there are no parameters in the template?

Yes, it could be wrong.  There could also be incorrectly incomplete TemplateData blocks added (probably far more common, actually).  

I'm not saying that you'd have to prevent the addition of parameters.  But could you **just tell me** that adding a parameter to {{France-university-stub}} is probably a bad idea?  Just a friendly note, not something that's going to break the workflow if the TemplateData is wrong.  Just a note that says something like "According to the template documentation, this template doesn't normally use any parameters."
I don't think we should have a property specifically to indicate that there are no parameters. I agree there needs to be room for TemplateData being wrong or outdated and VisualEditor's advanced transclusion editor would always allow for parameters to be added.

However I think it'd be fine to remove the ability to add parameters from the simple editor that loads by default in VisualEditor - for cases where TemplateData data //did// exist but had no parameters specified.
Maybe something like that, although I'd be happy to to restrict it to an empty array (=the case when it is least likely to be wrong).

Even a "warning" note would be an improvement.  We could probably reduce confusion if we could have it display a sentence that says,  "This template uses no parameters.  It is technically possible to add parameters here, but they will be ignored by the template".
So maybe something like a "This TemplateData definition is complete, don't allow any undocumented parameters." (not necessarily restricted to an empty array of parameters).

I'm not sure this is a direction we want to go in though - IIRC we want to allow  for TemplateData being wrong and therefore able to be overridden inside VE.
I think I wasn't quite clear earlier.  T53429 is about saying (nicely) that no parameters have been listed in TemplateData.  I'm glad that we made that improvement, but that's not what I want here.  Instead of a nice message, I want to **define, in TemplateData, that this template actually does not accept or use any parameters**.  This is "no parameters in the //template//", not "no parameters currently typed into the //TemplateData//".

When a template is so marked, I'd also like VisualEditor disable the 'field name' search box, so that people can't insert any made-up or invalid parameters.  I want TemplateData to be able to stop editors from trying to add pointless parameters.
*** This bug has been marked as a duplicate of bug 51429 ***
Screenshot

Steps to reproduce:


1.Open a page with VE which has an image inside it.
2.Now open the Media Settings for the image
3.Type something for the Alternative Text
4.Select the text and click on the Link Inspector icon 

Observed Result:
The link inspector opens up in the Alternative text textbox as it appears in the screenshot.However, it does get placed inside the caption textbox

Test Environment: https://test2.wikipedia.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=59868

**Attached**: {F12881}
Change 117658 merged by jenkins-bot:
Disable MW tools when surface loses focus

https://gerrit.wikimedia.org/r/117658
(In reply to Gerrit Notification Bot from comment #1)
> Change 117658 had a related patch set uploaded by Catrope:
> Disable MW tools when surface loses focus
> 
> https://gerrit.wikimedia.org/r/117658

This commit addresses a different issue, but once it lands this bug will be impossible to trigger.
Change 117658 had a related patch set uploaded by Catrope:
Disable MW tools when surface loses focus

https://gerrit.wikimedia.org/r/117658
Intention:
Read the description from TemplateData


Actual Results:  
The description of the parameter from TemplateData is too pale.  People with poor eyesight, lower quality monitors, in sunlight on their mobile devices, etc. will not be able to read it.


Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: minor
Please open a new task. This was work done in mid-2015.
Could anybody point out in a screenshot what's meant by parameter descriptions? The dialog has several minor issues, I've tried to catch some of them:
{F5470647 width=703}
I think this is from an old version of the template dialog. Template parameter descriptions are now black for existing fields, and #555 in the search list.
The options are "practically white" (when you've clicked on something else) and "extremely pale gray" (when you've clicked inside that parameter).

I hate them both.
Do you mean when it's faded out or when it's faded up?
VisualEditor uses pushState to add veaction=edit to the URL when you click the VE edit tab, without causing a true reload.  However, this does not cause a true reload.  Similarly, when you click Read, the same happens to go back to read mode.

Unfortunately, this does not update the returnto and returntoquery in the login and signup links.  So if you click the tab for VE, then go to login and signup in the top right, you will no longer be in VE when you get back.

VE could make a custom solution for this, but a general method might be nice.  

It's possible to listen to user-initiated navigation (e.g. back/forward) with the popstate event.  That could solve the problem for back and forward.

However, that doesn't tell you about pushState.  So perhaps there should be a mw.pushState that updates these links, then calls the underlying browser method.
<Krinkle> [15:50:38] Krenair: Sounds like a good reason to have our page managed by a composition of embedded data-bound dom-based template objects. This'd be trivial there.
<Krinkle> [15:50:52] Krenair: But that's still a year or so away, with neccecary pushback..
I have a feeling that we might need to support extensions doing things when a mw.pushState is called...
Screenshot of bug (incl. console error)

Encountered in IE9 using BrowserStack "Windows 7/IE9" using latest MediaWiki and VisualEditor master via a tunnel. Could either be a browser bug we have to work around, or something on our end applicable to other browsers as well.


* Put the cursor at the end of the second paragraph in a simple document
* Removing the last character (e.g. full stop)

It suddenly removes the entire paragraph and then throws an uncaught exception:

> “Offset could not be translated to a DOM element and offset: 112”

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

**Attached**: {F13344}
Can't reproduce in IE9. CE offset code has changed a lot in the last 18 months.
When VisualEditor deactivates itself after Parsoid fails, this exceptions thrown because the property never got set.



  ve.init.mw.ViewPageTarget.prototype.deactivate = function(override) {
    if (..) {
      if (..) {
        this.deactivating = true;
        if (ve.msg('accesskey-save') !== '-' && ve.msg('accesskey-save') !== '') {
          this.elementsThatHadOurAccessKey.attr('accesskey', ..);
                        ^

ve.init.mw.ViewPageTarget.prototype.setupToolbarButtons = function () {
  ..
    if (ve.msg('accesskey-save') !== '-' && ve.msg('accesskey-save') !== '') {
      this.elementsThatHadOurAccessKey = $( .. );


The code in deactivate() shouldn't be repeating conditions like that as they're no longer semantically relevant, and in this case even incorrect. Instead the top one (which usually runs after setupToolbarButtons) should limit its interest to elementsThatHadOurAccessKey itself which we either set to null or to a jQuery object.

--------------------------
**Version**: unspecified
**Severity**: major
Change 117228 merged by jenkins-bot:
mw.ViewPageTarget: Check elementsThatHadOurAccessKey before accessing

https://gerrit.wikimedia.org/r/117228
Change 117230 merged by jenkins-bot:
mw.ViewPageTarget: Check elementsThatHadOurAccessKey before accessing

https://gerrit.wikimedia.org/r/117230
Change 117230 had a related patch set uploaded by Jforrester:
mw.ViewPageTarget: Check elementsThatHadOurAccessKey before accessing

https://gerrit.wikimedia.org/r/117230
Change 117228 had a related patch set uploaded by Alex Monk:
mw.ViewPageTarget: Check elementsThatHadOurAccessKey before accessing

https://gerrit.wikimedia.org/r/117228
Change 117224 merged by jenkins-bot:
mw.ViewPageTarget: Check elementsThatHadOurAccessKey before accessing

https://gerrit.wikimedia.org/r/117224
Change 117224 had a related patch set uploaded by Krinkle:
mw.ViewPageTarget: Check elementsThatHadOurAccessKey before accessing

https://gerrit.wikimedia.org/r/117224
Screenshot of image dialog

1.  Go to page with images nested iside captions, e.g., the sandboxes at http://en.wikipedia.beta.wmflabs.org/w/index.php?&oldid=82442

2.  Open the images and look at the caption for the first one.  The second image is displayed there, with its own caption centered.

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

**Attached**: {F13240}
1. Click in a block slug
2. The slug expands
3. Click in another paragraph
4. The slug contracts, as expected
5. Click in the slug again
6. The slug expands
7. Click on a FocusableNode (reference, template, etc.)
8. The slug doesn't contract
9. Click in a paragraph somewhere
10. Now the slug does contract

This is because contracting the slug when it's unfocused happens in pollOnceInternal, which is not invoked when selecting FocusableNodes (and only invoked by accident when changing the selection programmatically). onModelSelect in ce.Surface should probably clear the focusedness of the focused slug.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 117214 merged by jenkins-bot:
Fix application of slug focus classes

https://gerrit.wikimedia.org/r/117214
Change 117214 had a related patch set uploaded by Esanders:
Fix application of slug focus classes

https://gerrit.wikimedia.org/r/117214
Phantoms appearing in wrong position

Steps to reproduce:


1.Open a page with VE
2.Insert an image which has large enough original size to go beyond the page say for example: http://en.wikipedia.beta.wmflabs.org/wiki/File:Ho-Ho-Kus_Inn.jpg

3.Make it full size 
4.Save the page

5.Reopen the editor
6.Select the image by clicking on a but further from the border of the image

Observed Result:
The phantom for selection is appearing in the wrong position

See the screenshots attached

Now to observe some additional behavior:
Set the image size back to default size and observe the shield is still appearing in the previous position in the page

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

**Attached**: {F13227}
I think this issue is fixed now, the only issue I see now is, for image with too big size which goes beyond CE, the phantom is also going beyond the page.Not sure if that is something we can fix or not.
Yeah, this looks fixed to me.
I can't replicate this. I think this was fixed after the refactor of the phantoms.
(In reply to ryasmeen from comment #5)
> I am not getting the phantom appearing at wrong position issue anymore ,but
> what I am see now is, it takes two clicks to select that image when you have
> made it full size.
> If it is an unrelated issue , i will file a separate bug.

Let's keep it in this one.
I am not getting the phantom appearing at wrong position issue anymore ,but what I am see now is, it takes two clicks to select that image when you have made it full size.
If it is an unrelated issue , i will file a separate bug.
This also happens when I change the image position from Left to Center
It the phantom remains in the previous position even if I close the editor and reopen it .

Selecting the phantom also selects the image below it.

Please go to this page to better understand the issue:
http://en.wikipedia.beta.wmflabs.org/w/index.php?title=5thfebchrome&veaction=edit
Created attachment 14750
Phantom appearing in previous position after reverting it to default size

**Attached**: {F13229}
Created attachment 14749
How it appears when you select by clicking close to the border of the image

**Attached**: {F13228}
https://www.mediawiki.org/wiki/Help:Images#Size_and_frame says:

> An image with frame always ignores the size specification, the original image
> will be reduced if it exceeds the maximum size defined in user preferences.

However, as bug 53514 describes, the actual behavior seems to have regressed at some point.  The code in includes/Linker.php to check the user preference for size (which seems to be the same as the thumbnail size preference) is unreachable.  As presently written, framed images are always rendered at their "natural" size, *unless a height* is specified, in which case the height is honored (and the width, if any, ignored).

It's not entirely clear what the proper fix should be.  There are three options:

1. Leave the code as is, and update the spec on the wiki.
2. If a height is specified, honor the height *and* width (conservative, should change few pages)
3. Implement what I think was the original idea: *always* ignore the width and height, and limit the maximum image size with the user's thumbnail size preference.

--------------------------
**Version**: 1.23.0
**Severity**: normal
I checked image documentation on mw as well as enwiki and other language-specific wikis, as well as reading the code.  It was clear that the intent was as documented -- framed images were original size.  They even called getUnscaledThumb in the code.  However, getUnscaledThumb had a bug so that it did not always return unscaled thumbs.  This affected a miniscule number of pages, all of which (upon examination) were really trying to do something else (usually 'thumb' not 'frame').  We fixed most of those pages, and fixed the bug.  This bug has been merged and closed for over a month now and is already live on all the wikis.  (See https://en.wikipedia.org/wiki/User:Cscott/framed )

I think you are actually trying to review the 'square bounding box' RfC -- which is Not This Bug.
(In reply to Krinkle from comment #17)
> I can't be bothered to read through and interpret the logic of height bound
> and width bound and square cropped box ponies.
> 
> But I'm confused by two things:
> 
> 1) I can understand why certain keywords should not result in a cropped
> image and thus for 'frame' to now only respect height of width. But ignoring
> both seems like a pointless change that is asking to break and upset
> existing content.
> 
> Existing usage like [[File:Example.jpg|frame]] would be unaffected, but
> existing content like [[File:Test wiki logo notext.png|frame|200x200px]]
> will not result in a gigantic 3000px image being framed on the page[1]

Note that only 200x200px was scaled so far, and is rare in combination with frame. 200px was *not* scaled with frame, and still isn't.


> 2) Wait, we made this change because some old Help documentation page[2] on
> mediawiki.org says[3] so? That's not by any means a specification. Also,
> that same exact documentation page has an example of
> [[File:Example.jpg|frame|50px]] which is now broken[4] by being way too
> large.

There should be no change here at all. Framed images with only a width bbox specified were not scaled so far.

Gabriel
I can't be bothered to read through and interpret the logic of height bound and width bound and square cropped box ponies.

But I'm confused by two things:

1) I can understand why certain keywords should not result in a cropped image and thus for 'frame' to now only respect height of width. But ignoring both seems like a pointless change that is asking to break and upset existing content.

Existing usage like [[File:Example.jpg|frame]] would be unaffected, but existing content like [[File:Test wiki logo notext.png|frame|200x200px]] will not result in a gigantic 3000px image being framed on the page[1]


2) Wait, we made this change because some old Help documentation page[2] on mediawiki.org says[3] so? That's not by any means a specification. Also, that same exact documentation page has an example of [[File:Example.jpg|frame|50px]] which is now broken[4] by being way too large.

[1] https://www.mediawiki.org/w/index.php?title=VisualEditor:Test&oldid=1011846
[2] https://www.mediawiki.org/w/index.php?title=Help:Images&oldid=945436
[3] "An image with frame always ignores the size specification, the original image will be reduced if it exceeds the maximum size defined in user preferences."
[4] https://www.mediawiki.org/w/index.php?title=Help:Images&oldid=945436#Size_and_frame
We use the parsoid HTML for the page, so we do in fact handle localized option names.  However, the caveat in comment 6 applies: "One limitation is that it uses the wp allimages API query, so it does not include pages which include images *only from commons*."  That seems to have been the case on the page you link to.
You have missed the localized version at least for dewiki ("gerahmt"), see [1]
There are also english aliase ("enframed" and "frame")



[1] https://de.wikipedia.org/w/index.php?title=Airbus_A350&oldid=129797202#Zweiter_Entwurf
Change 125885 merged by jenkins-bot:
Match fixed PHP behavior for framed images with a height specification.

https://gerrit.wikimedia.org/r/125885
Change 125885 had a related patch set uploaded by Cscott:
Match fixed PHP behavior for framed images with a height specification.

https://gerrit.wikimedia.org/r/125885
Change 125876 merged by jenkins-bot:
Update release notes to describe user-visible change to framed images.

https://gerrit.wikimedia.org/r/125876
Change 125876 had a related patch set uploaded by Cscott:
Update release notes to describe user-visible change to framed images.

https://gerrit.wikimedia.org/r/125876
Change 116995 merged by jenkins-bot:
Ignore height as well as width for framed images.

https://gerrit.wikimedia.org/r/116995
(In reply to comment #8)
cscott had already fixed the pages "Gliederung des Feldheeres (Bundeswehr, Heeresstruktur 4)", "Hauptkirche Sankt Michaelis (Hamburg)", and "Ceylor" and I've fixed the rest now on de.wp.
Full list for dewiki:
Ceylor Datei:Lochtest.png x206px
Ceylor Datei:Volumentest.png x206px
Fernsehwerbung Datei:Werbeanteile.png x200px
Fahrtanzeiger Datei:FSM_WT.png 500x300px
Friedrich Glauner Datei:Grafik_Wertetrichter_unterlegt.png 480x367px
Gliederung des Feldheeres (Bundeswehr, Heeresstruktur 4) Datei:II._Korps.svg x150px
Gliederung des Feldheeres (Bundeswehr, Heeresstruktur 4) Datei:III._Korps.svg x150px
Gliederung des Feldheeres (Bundeswehr, Heeresstruktur 4) Datei:I._Korps.svg x150px
Hauptkirche Sankt Michaelis (Hamburg) Datei:Oratorium_zur_Einweyhung_der_Michaeliskirche_1762.JPG 180x180px
Opernhaus vorm Salztor Datei:Salztor_NMB_1800.JPG 200x200px
Opernhaus vorm Salztor Datei:Karte_NB_Oper.jpg 300x300px
Raketenartilleriebataillon Datei:APP-6_MLRS.svg x80px
Reedschalter Datei:Form_A_-_Schließer_(Normally_Open).jpg x50px
Reedschalter Datei:Form_C_-Wechsler_bzw._Umschalter.jpg x50px
Rheintal-Express Datei:Rheintal-Express_RABe_511.jpg 260x260px
SV Salamander Kornwestheim Datei:Logo_TV_Kornwestheim_Kodiaks.gif x130px
STUDIOPARK KinderMedienZentrum Datei:STUDIOPARK_KinderMedienZentrum.png x100px
ToiToiToi Datei:Toitoitoi-symbole.svg x70px
Spotlight (Software) Datei:Spotlight-Suche_im_Finder.png x222px
Zwergsignal Datei:Zs-beispiel1.png 500x300px
Sorry, my stats were slightly wrong above:
frwiki: 
  60 image links using the "framed" option
   1 of which uses a height bound
dewiki:
 538 image links using the "framed" option
  20 of which use a height bound

So on dewiki/frwiki I've only been about to find 21 image links whose size would be changed by this bug fix.  I'm still collecting data on enwiki, I'll update this bug with the numbers when I have them.
The patch attached to https://gerrit.wikimedia.org/r/116995 now fixes the bug in the "right way" -- that is, it fixes File::getUnscaledThumb.

This will change the size of all images which combine a height bound and a framed image.

In order to determine whether fixing this bug will affect this display of too many images, I wrote a script to grunge through all images and pages containing images on a wiki.  See https://github.com/cscott/wp-image-info

One limitation is that it uses the wp allimages API query, so it does not include pages which include images *only from commons*.

I'm still collecting data for enwiki, but for frwiki:
   43,014 total non-commons images
    8,839 of them are in portrait orientation
1,242,985 image links on pages, of which only
       60 use the 'framed' option with a height bound

For dewiki:
  170,701 total non-commons images
   55,208 of these are in portrait orientation
1,786,779 image links on pages, of which only
      538 use the 'framed' option with a height bound

I fixed some of these:
https://de.wikipedia.org/w/index.php?title=Hauptkirche_Sankt_Michaelis_%28Hamburg%29&diff=129396939&oldid=129292349
https://de.wikipedia.org/w/index.php?title=Ceylor&diff=129396510&oldid=129332266
https://de.wikipedia.org/w/index.php?title=Ceylor&diff=129396510&oldid=129332266
To be specific, the reason why framed images respect height (but not width) is because the linker uses:
  $thumb = $file->getUnscaledThumb( $hp );
but includes/filerepo/file/File.php::getUnscaledThumb forces the requested width to be the same as the images natural width *but not the height*.  So if there is a height specification, getUnscaledThumb actually returns a scaled thumb.  Which is... a bug.

https://gerrit.wikimedia.org/r/116995 fixes this, but probably in the wrong way (unsets height for framed images).  File::getUnscaledThumb should probably be fixed so that it ignores the specified height if present.
Parsoid commit https://gerrit.wikimedia.org/r/#/c/116983/ makes Parsoid match the old (broken) behavior. We'll need to partly undo it once this bug is fixed.
Change 116995 had a related patch set uploaded by Cscott:
Ignore height as well as width for framed images.

https://gerrit.wikimedia.org/r/116995
As you say, James, these are mostly questions for an RFC, and not really relevant here, though maybe blockers. A separate bug is called for.

For what it's worth I would err in the direction of following the spec, but without a complaining user it may just be that the spec has fallen out of favour with reality. I would suggest asking on VPT and a few other sites that use lots of images in their work - Wikibooks and Commons come to mind - and maybe getting some CL time to help you sort out the replies, and post to more languages than just English.

HTH...
screenshot

Right now , we are not showing the * mark beside the required parameter in the Add Parameter section.I think we should show it there too, because if a user accidentally deletes a required parameter from the left panel of transclusion dialog then he will not have any indication on the required parameter anymore.

See the screenshot attached

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

**Attached**: {F12919}
(In reply to Rummana Yasmeen from comment #0)
> because if a user accidentally deletes a required parameter from the left
> panel of transclusion dialog

We removed the ability to do this (bug 60358).
Not exactly Bug 51774, but:
while descriptions of what a parameter is supposed to mean/do are provided in the list of available parameters inside the template inspector, this is not (no longer?) true for required and already selected parameters. The only way to read their description is to remove them from the left panel and get them back in the list, where they can be selected again, but clearly this is not optimal. Not sure a tooltip would be the way, so I'm filing this separately.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51774
Verified the fix in production:https://en.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/sandbox&veaction=edit
Verified the fix in test2
Verified the fix in Betalabs
This has been done by gerrit 115548 which will be coming soon. Completely agreed that it was a pain.
Navigate to https://commons.wikimedia.org/wiki/File:Apthorp_south_jeh.JPG
Now navigate to the same page via a ForeignAPI https://en.wikipedia.org/wiki/File:Apthorp_south_jeh.JPG

Notice that in the latter a broken VisualEditor link appears.
Expected: No VisualEditor link

Similarly if you go to the mobile site you will see the same problem - an edit link appears in square brackets rather than an edit icon (see bug 61807). The mobile skin uses doEditSectionLink which seems to be incompatible with FileRepo.

 I've spent the morning talking with Brion to understand more about how the magic commons file page works and how the page is rendered.

Basically the problem is in FileRepo.php
getDescriptionRenderUrl creates an API request to something akin to https://commons.wikimedia.org/w/index.php?title=Image:Apthorp_south_jeh.JPG&action=render&uselang=en
If we can route this through the current skin this problem goes away.
e.g.
https://commons.wikimedia.org/w/index.php?title=Image:Apthorp_south_jeh.JPG&action=render&uselang=en&useformat=mobile
or
https://commons.wikimedia.org/w/index.php?title=Image:Apthorp_south_jeh.JPG&action=render&uselang=en&useskin=vector

Brion is taking a look to see if he can add a hook.

--------------------------
**Version**: 1.23.0
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54259
Making FileRepo stuff depend on current skin would be horrible, also there's a problem with permissions/being logged in on foreign wiki which makes displaying edit links unreliable. However, I redid Bartosz's fix for bug 19415 in https://gerrit.wikimedia.org/r/#/c/118135/
Actually in the case of the file page we would like to render the edit links and make it possible to edit the content (albeit on a foreign wiki)

So really it would be great if this could just pass the current skin name along with the request..
Hmm. You seem to be requesting the same thing as bug 19415 here – I already tried to fix it once, but there were complications. There's a patch there that needs to be reworked.

(On a side note, my personal opinion about doEditSectionLink is that it should die in a fire and you should style the section edit links with CSS, as I made it possible to easily hide the brackets a few months ago.)
Thanks for clarifying the VE issue is a different problem.

Compare results of
https://commons.wikimedia.org/w/index.php?title=Image:Apthorp_south_jeh.JPG&action=render&uselang=en&useskin=vector
https://commons.wikimedia.org/w/index.php?title=Image:Apthorp_south_jeh.JPG&action=render&uselang=en&useformat=mobile
(triggers useskin=minerva but minerva is unregistered so this is needed)

The MinervaSkin overrides doEditSectionLink. There may be other skins that also override it and will thus be inconsistent.
The VE bug for this is bug 54259.
That sounds like a VE/mobile bug, the links generated by core work just fine.
Apologies for the brain dump - I hope this is relatively clear.
Applying the patch from Ie6b47f5d192953366911 in VisualEditor did not result in a module change update.

I kept refreshing and purging but nothing happened.

Turns out the way we fetch files in #getModifiedTime is broken for 'skinStyles'.

For some reason, this method duplicates the logic to interpret the 'skinStyles' array structure from #getStyleFiles (instead of using that method), and did so incorrectly causing it to always end up with an empty array.

The bug is quite subtle in that the module is capable of including these files (they're not missing from the css build), it's just that the module cache isn't invalidated if a commit only changed files listed in that part of a module.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 116143 abandoned by Krinkle:
[WIP] resourceloader: Regression test for bug 62068

https://gerrit.wikimedia.org/r/116143
Change 112837 merged by jenkins-bot:
resourceloader: Fix broken skinStyles loop in #getModifiedTime

https://gerrit.wikimedia.org/r/112837
Change 116143 had a related patch set uploaded by Krinkle:
[WIP] resourceloader: Regression test for bug 62068

https://gerrit.wikimedia.org/r/116143
Change 112837 had a related patch set uploaded by Krinkle:
resourceloader: Fix broken skinStyles loop in #getModifiedTime

https://gerrit.wikimedia.org/r/112837
Start case:
1. Create a document that starts with {{echo|<div>foo</div>}} followed by some more content
2. Put the cursor on the paragraph below the template
3. Press left arrow until you're selecting the template
4. Press left arrow; the cursor is now in the block slug
5. Press left arrow; the cursor is now on the template
6. Go to step 4

End case:

1. Create a document that ends with <references /> preceded by some content
2. Put the cursor in the paragraph above the reflist
3. Press right arrow until you're at the end of this paragraph
4. Press right arrow; the cursor is now on the reflist
5. Press right arrow; the cursor is now in the block slug
6. Press right arrow; the cursor is now before the reflist 
7. Go to step 4

Note how the end case differs from the start case in that the loop is 3 keypresses long rather than 2.

--------------------------
**Version**: unspecified
**Severity**: normal
Hello,

Just to ask if it's possible to unable the Visual Editor for IP user on fr.wikiversity like fr.wikipedia.

Thanks a lot and have a nice day.

Lionel

--------------------------
**Version**: unspecified
**Severity**: enhancement
Thanks every one and have a nice day !
This was done three weeks ago.
Change 117238 merged by jenkins-bot:
Enable VisualEditor by default on French Wikiversity

https://gerrit.wikimedia.org/r/117238
Ok, I didn't understand every things but it looks like I have to wait. Thank you Andre.
Lionel: https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle - this bug report is in PATCH_TO_REVIEW status, see comment 3.
Hello every one, Some body can translate in human language what's happen about the resolution of this "bug" because I didn't understand nothing about what's happen. What I just can see is the Visual editor still not work on fr.wikiversity for IP connection. Have a nice day.
Change 117238 had a related patch set uploaded by Jforrester:
Enable VisualEditor by default on French Wikiveristy

https://gerrit.wikimedia.org/r/117238
Yep !

You can already see the result of our vote about visual editor for IP on fr.wikipedia : https://fr.wikiversity.org/wiki/Projet:Wikiversit%C3%A9/Editeur_Visuel_pour_utilisateur_IP

Have a nice day,

Lionel
Yes, this is possible, but you should confirm with the rest of the community that they are OK with doing it.
In Thai language, it is possible that many characters (at most 3 or 4) will be on top each other. For example, "ที่" consists of three characters: "ท", "ี", and "่". In standard textbox/textarea, including normal wikieditor, when you press left, the cursor will go left by 1 block = 3 characters in case of "ที่". However, for VE's editor, it will go left by only 1 character, making editors feel that he unsuccessfully pressed the key. More importantly, with the way VE's editor is, it opens possibility that editors, thinking that the cursor is after "่", will accidentally insert text between "ี" and "่".

--------------------------
**Version**: unspecified
**Severity**: normal
Thank you very much for this bug report; it's very clear.
Note that VE produces the correct behavior for deleting text. For example, "ที่" requires 3 backspaces in order to delete it. It has already been correct. Just only iterating through letters that is wrong.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Page Settings page
3.Now type something 

Observed Result:

It inserts the text in the CE

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=Imageghau&veaction=edit

See the screenshot attached.

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

**Attached**: {F13238}
Verified the fix in production:https://en.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/sandbox&veaction=edit
Verified the fix in test2
Verified the fix in betalabs
Change 116114 merged by jenkins-bot:
Blur the surface when a dialog is opened

https://gerrit.wikimedia.org/r/116114
Change 116114 had a related patch set uploaded by Esanders:
Blur the surface when a dialog is opened

https://gerrit.wikimedia.org/r/116114
This issue is not just for Page Settings rather for all these dialogs :Advanced Settings,Categories,Languages and Keyboard shortcuts page
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Go to Media Settings>Advanced Settings for that image
4.Set the position to left and image type to border
5.Save the page
6.Reopen the page 
7.Select the image and open the media settings for it

Observed Result:

TypeError: this.typeInput.getSelectedItem(...) is null appears in the console and also I could not cross out the media settings page for that image and got stuck in VE.

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

See the screenshot attached

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

**Attached**: {F13211}
Change 120690 merged by Catrope:
Fix 'original dimensions' async call in MediaEdit dialog

https://gerrit.wikimedia.org/r/120690
Change 120691 merged by Catrope:
Fix 'original dimensions' async call in MediaEdit dialog

https://gerrit.wikimedia.org/r/120691
Looks like its fixed in Betalabs.I tried the bonsai image in this page after the fix has been merge , did not get that error whereas previously I was getting it there:
http://en.wikipedia.beta.wmflabs.org/wiki/24thMarchrome
Change 120057 merged by jenkins-bot:
Fix 'original dimensions' async call in MediaEdit dialog

https://gerrit.wikimedia.org/r/120057
Change 120691 had a related patch set uploaded by Catrope:
Fix 'original dimensions' async call in MediaEdit dialog

https://gerrit.wikimedia.org/r/120691
Change 120690 had a related patch set uploaded by Catrope:
Fix 'original dimensions' async call in MediaEdit dialog

https://gerrit.wikimedia.org/r/120690
Change 120057 had a related patch set uploaded by Mooeypoo:
Fix 'original dimensions' async call in MediaEdit dialog

https://gerrit.wikimedia.org/r/120057
*** Bug 62926 has been marked as a duplicate of this bug. ***
https://bugzilla.wikimedia.org/show_bug.cgi?id=62926 might be a duplicate of this. Although in a more general setting.

Note though that this also occurs for a thumbnail images* (which is the default setting for images inserted by VE).

*This occurs on sv.wp [1] whilst it does not seem to occur on en.wp [2]

[1] https://sv.wikipedia.org/w/index.php?title=User:Andr%C3%A9_Costa_%28WMSE%29/test2&veaction=edit
[2] https://en.wikipedia.org/w/index.php?title=User:Andr%C3%A9_Costa_%28WMSE%29/test2&veaction=edit

I would also argue for bringing the priority of this up since not being able to close the dialogue window means that any unsaved data in the article is lost. We have already had this occur during a workshop.
Created attachment 14856
The most recent error appeared on 18th March

**Attached**: {F13215}
Correction: everytime you make it frameless and fullsize, it results into NaNxNaN
Also, observe that for every copy of that image if you make it frameless , the resulting size in wikitext becomes NaNxNaN
I just reproduced it on betalabs again : http://en.wikipedia.beta.wmflabs.org/wiki/18thMarChrome?veaction=edit

Try the second image

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

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

https://gerrit.wikimedia.org/r/115939
This is the bug ed noticed this morning. 

This should fix the error: https://gerrit.wikimedia.org/r/#/c/115939/
Small modification: It has nothing to do with the image position, just select the image type as border with whatever image position it will throw that error.
Created attachment 14710
Missing caption section

**Attached**: {F13213}
Also , observe in the general settings of the image with such position and format there is not caption section.
See the screenshot attached
Screenshot

Steps to reproduce:

1.Create a page with VE
2.Add a bullet list
3.Add an image as a bulleted item of that list (
4.Save the page
5.Reopen the editor

Observed Result:
As soon as I open the page I get the error:
 "Uncaught TypeError: Cannot call method 'getOffset' of null"

And then clicking on Bullet list icon again does not un-bullet the list
Also, every time I switch to this page from other window/page it shows this error again and again. 



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

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

**Attached**: {F13207}
Verified the fix in production:https://en.wikipedia.org/w/index.php?title=User:RYasmeen_%28WMF%29/sandbox&veaction=edit
verified the fix in test2
Verified the fix in betalabs
Change 116172 merged by jenkins-bot:
Don't allow getNearestCorrectOffset to return -1

https://gerrit.wikimedia.org/r/116172
Change 116172 had a related patch set uploaded by Esanders:
Don't allow getNearestCorrectOffset to return -1

https://gerrit.wikimedia.org/r/116172
A user at en.wp reported today that you can add interlanguage links while you're in VE. The last step when doing so means the whole page gets reloaded, so whatever was done in VE until that moment gets lost. I am not aware of ways to prevent this, and there is no indication in VE that this will happen when you start that procedure.

--------------------------
**Version**: unspecified
**Severity**: normal
**Whiteboard**: u=dev c=backend p=0
**See Also**:
{T54105}
(Filed initially as WD, thought you hadn't mentioned this detail, re-filed again as VE. Close enough.)
Wikidata bug, not VE bug.
Some types like mw:ExpandedAttrs are universal, meaning they can apply to any element and their presence shouldn't be taken into account when figuring out which node handler to invoke. The node handlers themselves probably do need to make decisions based on their presence, but that's fine, they can do that already.

For now the approach I'm considering is to add the concept of a universal RDFa type, which will be ignored by ve.dm.ModelRegistry#matchElement for all purposes (including the "if not all mw: types are matched it's not a match" logic and all of that). mw:ExpandedAttrs and mw:Error (the latter would be introduced by bug 50788) would be universal types. mw:Placeholder wouldn't be one, because it needs to trigger alienation.

--------------------------
**Version**: unspecified
**Severity**: major
Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Go to Media Settings of that image
4.Insert another image inside it in the General Settings section
5.Go to Media Settings for that image and set the Image type as Frameless and keep the position to right

Observed Result:
The image resize handlers appear at all four corners instead of appearing only at bottom left corner

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
yes, now it is fixed.
This appears to now be fixed.
*** Bug 62283 has been marked as a duplicate of this bug. ***
Created attachment 14695
screenshot

**Attached**: {F13084}
Use Existing reference dialog  box

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Reference >Use an existing reference
3.Type a search term in the search box
4.Select a reference from the search result.
5.Now again attempt to add another existing reference 

Observed Result:
When the page of existing references opens up it still keeps the search term from previous attempt and shows the search results , it should rather clear the previous search term and let user to start over.
This issue also occurs for new media adding dialog

See the screenshots attached.

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

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

**Attached**: {F13051}
verified the fix in betalabs:http://en.wikipedia.beta.wmflabs.org/w/index.php?title=27thmarChrome&veaction=edit
Change 120566 merged by jenkins-bot:
Blank the reference and media search queries when closing dialogs

https://gerrit.wikimedia.org/r/120566
Change 120566 had a related patch set uploaded by Jforrester:
Blank the reference and media search queries when closing dialogs

https://gerrit.wikimedia.org/r/120566
Created attachment 14690
New Media Add dialog

**Attached**: {F13052}
Specifically on this page, https://it.wikipedia.org/w/index.php?title=Categoria:Aggiornare_-_economia&veaction=edit .
I tried adding all those categories to my sandbox but they work fine there (https://it.wikipedia.org/w/index.php?title=Utente:Elitre_(WMF)/Sandbox_VE&oldid=64431369&veaction=edit ), same if I add the rest of the content of that page.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=72303
(In reply to Elitre from comment #3)
> So... is there a bug about how VE needs to be doing that yet?

I thought so, but no; re-opening as said bug.
So... is there a bug about how VE needs to be doing that yet?
The only two categories on this page directly are listed by VE. Obviously, we can't include transcluded categories.
Very odd.
Steps to Reproduce:
1. Open a page (like Today's Featured Article) that will have notices.
2. Hover over the "Notices" triangle.
3. Read the tooltip.



Reproducible: Didn't try

--------------------------
**Version**: unspecified
**Severity**: trivial
Change 115826 merged by jenkins-bot:
Don't use a changeable tooltip for edit notices

https://gerrit.wikimedia.org/r/115826
Change 115826 had a related patch set uploaded by Jforrester:
Don't use a changeable tooltip for edit notices

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

- Create a numbered list as follows:
```
1.item 1
2.
3.item 3
```
- Now add indentation to the third item , so it becomes:
```
1.item 1
2.
      1.item 3
```
- Now place the cursor just before the item 3 and press delete

Instead of having the item 3 unindented the resulting list comes up as: 
```
1.item 1
2. 1. item 3
```
See the screenshot: {F12837}

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

**See Also**: {T65051}
The proper order is #REDIRECT[[Whatever]], then categories and other stuff.  If you place the redirect anywhere other than the very top of the page, it won't work.

--------------------------
**Version**: unspecified
**Severity**: trivial
Will mark this as fixed in favour of Parsoid bug 53508 then.
Change 115309 merged by jenkins-bot:
Always try to put redirects at index 0, offset 0

https://gerrit.wikimedia.org/r/115309
(In reply to Gabriel Wicke from comment #7)
> Moving back to VE; Position of inline metadata is the client's
> responsibility. Our long-term solution is to move that metadata out of the
> content altogether.

This is semantically non-positional meta-data that breaks if not in a particular syntactical position…
Moving back to VE; Position of inline metadata is the client's responsibility. Our long-term solution is to move that metadata out of the content altogether.
Change 115287 merged by jenkins-bot:
Always try to put redirects at index 0, offset 0

https://gerrit.wikimedia.org/r/115287
Change 115309 had a related patch set uploaded by Catrope:
Always try to put redirects at index 0, offset 0

https://gerrit.wikimedia.org/r/115309
(In reply to WhatamIdoing from comment #2)
> If "rendering in place" means "where the cursor is", then that's not
> happening.  It's placing the redirect at the bottom of the page even if your
> cursor is at the top or in the middle.

No, it's rendering "in place" in the HTML document; VE just puts meta-items at the end of the HTML string (because internal logic of what MW's parser does and doesn't prefer is a decision for Parsoid), so Parsoid renders this at the end of the wikitext, which helpfully doesn't work.

(In reply to Gerrit Notification Bot from comment #3)
> Change 115287 had a related patch set uploaded by Jforrester:
> Always try to put redirects at index 0, offset 0
> 
> https://gerrit.wikimedia.org/r/115287

This is a hack to make VE try to insert it right at the top, which may not work in all cases but at least should patch over the issue.
Change 115287 had a related patch set uploaded by Jforrester:
Always try to put redirects at index 0, offset 0

https://gerrit.wikimedia.org/r/115287
If "rendering in place" means "where the cursor is", then that's not happening.  It's placing the redirect at the bottom of the page even if your cursor is at the top or in the middle.
Logically, Parsoid should decide where in the page such things go (right now it just renders in place); VisualEditor could hack around this by putting it at the top of the HTML, but that's not a scalable fix (and will likely break other things).

Parsoid, what do you think?
When you set a redirect in VisualEditor, it doesn't display anything, so it looks like it didn't work.
Change 273391 merged by jenkins-bot:
Show redirect target inside target

[[https://gerrit.wikimedia.org/r/273391]]
Change 273397 merged by jenkins-bot:
Make mediawiki.action.view.redirectPage available on mobile

[[https://gerrit.wikimedia.org/r/273397]]
Change 273397 had a related patch set uploaded (by Alex Monk):
Make mediawiki.action.view.redirectPage available on mobile

[[https://gerrit.wikimedia.org/r/273397]]
Change 271701 abandoned by Alex Monk:
Move redirects out of the meta list into actual nodes

Reason:
Per Ed, in favour of a different commit

[[https://gerrit.wikimedia.org/r/271701]]
Change 273391 had a related patch set uploaded (by Alex Monk):
Show redirect target inside target

[[https://gerrit.wikimedia.org/r/273391]]
As discussed on IRC there are two approaches: Make the redirect render as a node (the patch just submitted) or keep it in metadata and render a new control above the document.

Having it as a node gives us selection and delete for free, but there are no systems in place to make that node un-moveable, or un-copyable. Given that an unmovebale node can only ever be at the start or end of a document (by definition) I'm not sure we need to support that. 

If all we need is a bit of rendering in the surface we can add a styled button above the document showing the redirect, and which launches the dialog.
Change 271701 had a related patch set uploaded (by Alex Monk):
Move redirects out of the meta list into actual nodes

[[https://gerrit.wikimedia.org/r/271701]]
Note that in some cases redirects actually have some content, so are not necessarily blank.
Still valid.
>>! In T63861#648996, @Krenair wrote:
> When checking that I was right about the valid positioning of redirects, I found that Parsoid implements redirects wrong (or rather, differently to MediaWiki core's parser): it seems quite happy to accept a redirect that is anywhere in the document.

Reported as T88081
Created attachment 15753
In this case, I re-pointed a redirect, so it was displayed, and now it *looks like* changing it caused the redirect to be removed rather than changed.

**Attached**: {F12829}
I spoke to Roan about what I would need to know to do this today. After some explanation we realised that this relies on meta items (e.g. redirects) having the possibility of being visible (at the moment they are just stripped from the model data so we don't know where they are). That is somewhere on his work list but he is not particularly close to starting it.

Also, I thought for a moment that since a valid redirect must be in a certain position (at the top of the document - if it's under something else then it's actually just a list element starting with 'redirect' and with a link to the target page), we could perhaps rely on that to make it visible. But I suspect that would be a pretty ugly solution.

When checking that I was right about the valid positioning of redirects, I found that Parsoid implements redirects wrong (or rather, differently to MediaWiki core's parser): it seems quite happy to accept a redirect that is anywhere in the document.
This was mis-labelled; sorry for the confusion.
We should probably show the same as the MW-rendered redirect:

https://bits.wikimedia.org/static-1.23wmf14/skins/common/images/redirectltr.png

… or ideally a better system that doesn't use an image, and fix MW whilst we're at it.
I find the whole thing to be rather confusing. It's much too technical. Also it partially mixes the concept of ToC with that of a structure editor. It has some widgets on the ToC (add template, add content, change order) and others inside the editor (Add param, del param, del template). This is terribly inconsistent. And makes you having to scan the screen too much.

Also by default it tries to introduce you to the concept of chained templates ( starttemplate, content, endtemplate ). Which is rather complex and often not even needed.

This needs serious work to make the usability much more consistent and predictable. I would take the following into account.


1: Make a decision. Is it a toc, or a structure editor ? If the latter, then put all structure controls in the structure editor. Otherwise avoid putting them in there.
2: By default, don't show the buttons for chained/wrapping templates. Instead, only add them if Parsoid assumes there is content wrapping happening. For new templates insertion, make an addition to templatedata "openedBy, closedBy", and only add the buttons if the template data says they are needed.
3: Keyboard control. I try tab key to move focus to the "Add template" button next to the field. Seems this is captured by the UI, so I cannot move focus that way. It seems I can only click the button. BAD... Also seems that the add button and the delete buttons do not have a :focus state. Or rather, it seems that buttons have focus state, but the focusable element is the <a> inside it, so it doesn't really work.
4: The layout of the params view.. I don't know how to do it better right now, but this needs work. too many lines/blocks, it's too cluttered. Do you need a double line separator if you have a heading ?

--------------------------
**Version**: unspecified
**Severity**: enhancement
What about a drop-down menu with a list of most used templates (on the project or chosen by the single user)? I think it was asked somewhere else, but it's being brought up again on en.wp so I hope this is the right place to mention it. I know something like this will be added to the referencing system, but it'd be great to have it for more general purposes as well.
That would be https://bugzilla.wikimedia.org/show_bug.cgi?id=49772 I think? (although not specific to the missing TD case).
Add way to access/view /doc, if TemplateData is not visible.
eg. https://ca.wikipedia.org/wiki/Tema:T3edcbkgt2ns31ff 

(Old example: http://ee-flow.wmflabs.org/w/index.php?title=User_talk:Quiddity&topic_postId=rpnkneesuic1rsx8&workflow=rnhr0vbpmcq1wj5m#flow-post-rpnkneesuic1rsx8 )

--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: http://ee-flow.wmflabs.org/w/index.php?title=User_talk:Quiddity&topic_postId=rpnkneesuic1rsx8&workflow=rnhr0vbpmcq1wj5m#flow-post-rpnkneesuic1rsx8
> The "thumb" works ok

Not really. A thumbnail is created, but clicking it doesn't play the video, it leads to the File page.

Reported at [[ https://ca.wikipedia.org/wiki/Fitxer:This_is_the_Wikimedia_Foundation.webm | w:ca.Tema:T3edcbkgt2ns31ff ]].
Copying from merged:

>>! In T72532#769902, @Amire80 wrote:
> Link: https://he.wikipedia.org/wiki/%D7%A0%D7%95%D7%A9%D7%90:S1wm63huv90migi0
> 
> Thanks for the reporting.
fresh examples of webm video failing to render at fullsize, and ogg audio failing to display its player: https://www.mediawiki.org/wiki/Topic:S52i2un1zblzd8s8#flow-post-s5fley5jhc8a8pub (Does this bug/issue also cover audio files? I'm not sure whether to rename, or fork.)
This is partly the same as bug 61786 (the image HTML generated by Parsoid is different from PHP parser output), but there are additional problems for video links.

For both [[File:Sequence-Test.ogv]] and [[ File:Sequence-Test.ogv|thumb]] in a Flow post, the links to the video are an invalid <a href="./File:Sequence-Test.ogv">. The HTML doesn't include a <video> tag, just an <img> tag. The full-size video uses the original .ogv file as the src of the nested image tag, which obviously doesn't work, while the thumb video correctly uses the Sequence-Test.ogv.jpg thumbnail.

Furthermore, the resulting HTML doesn't seem to trigger the MwEmbedSupport/TimedMediaHandler RL modules that add player controls and such to the video. Maybe those look for <div class="mediaContainer"> or the <video> tag.

O VisualEditor team, do you have CSS and JS that make Parsoid video HTML work? :)
If you add a formula (or other inline item) to a normal paragraph, everything works in VE consistently with MW (yay).

If you add a formula (or other inline item) to a pre-formatted paragraph, everything still works works (yay).

If you add a gallery (or other block item) to a normal paragraph, everything works in VE consistently with MW (yay).

If you add a gallery (or other block item) to a pre-formatted paragraph, VE tries to let you do that, and MW decides retroactively that the paragraph wasn't actually pre-formatted (boo), unless it's a <pre>-formatted rather than indent-pre-formatted block, in which case galleries don't work.

Not tested with Headings, but there's probably similar wonkiness there too.

*sighs*

--------------------------
**Version**: unspecified
**Severity**: normal
Looks like this is now fixed.
Sounds like a Parsoid issue.
We are currently using a hack[1] to make VisualEditor to be the default edit mode on Portuguese Wikibooks.

Could someone make it the default in the right way?

[1] https://pt.wikibooks.org/wiki/MediaWiki:Gadget-VisualEditorByDefault.js

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
**URL**: https://pt.wikibooks.org/wiki/T%C3%B3pico:Wikilivros_Discuss%C3%A3o:Portal_comunit%C3%A1rio/Testes_com_o_Editor_Visual_no_Wikilivros/resposta_%284%29
Thanks!
(In reply to Gerrit Notification Bot from comment #6)
> Change 115213 merged by jenkins-bot:
> Make VisualEditor opt-out on Portuguese Wikibooks
> 
> https://gerrit.wikimedia.org/r/115213
Deployed now.
Change 115213 merged by jenkins-bot:
Make VisualEditor opt-out on Portuguese Wikibooks

https://gerrit.wikimedia.org/r/115213
Scheduled for 16:00 PST today.
Change 115213 had a related patch set uploaded by Jforrester:
Make VisualEditor opt-out on Portuguese Wikibooks

https://gerrit.wikimedia.org/r/115213
(In reply to Helder from comment #2)
> The link is in the URL field

Sorry, I missed that. If there have been no objections from the community I guess it is OK to proceed then.
The link is in the URL field, but there is little activity there currently, so I doubt there will be more comments...
I assume, because the JS is in place by default, that community consensus has already been reached? Could you provide a link for completeness' sake?
Please uninstall the Flow extension from Meta-Wiki. Relevant discussion: <https://meta.wikimedia.org/w/index.php?title=Meta:Babel&curid=69328&diff=16251209&oldid=16240965>.

The extension was installed in <https://gerrit.wikimedia.org/r/114088>.

Explicit consensus for complete removal (and lack of consensus for any partial survival of the extension): https://meta.wikimedia.org/w/index.php?title=Meta:Babel&oldid=16337330#Proposal_to_remove_Flow_on_Meta-Wiki
>>! In T63729#3948471, @MarcoAurelio wrote:
> 1 can be fixed with a rWMME entry

Before we identify an alternative technical solution (e.g. code duplication to put log formatting in WikimediaMessages), we should first identify a technical problem with the simplest solution (deleting SD boards, preventing new ones from being created, and leaving the extension installed).

>>! In T63729#3950882, @Alsee wrote:
> Considering that the extension is uninstalled, I'd say those log issues are pretty insignificant.
> 
> However I think it suggests that new extension development should have a checklist item to consider and test uninstallation. We wouldn't want some other extension causing hard-to-reverse problems in the future.

This applies to any extension with log types, not just StructuredDiscussions.  It's expected behavior.  There is no solution other than code duplication (which is okay if that's the best solution, but no one has explained why it is in this case).
Actually please follow the discussion at T186463. This task has been long closed. Thanks.
Considering that the extension is uninstalled, I'd say those log issues are pretty insignificant.

However I think it suggests that new extension development should have a checklist item to consider and test uninstallation. We wouldn't want some other extension causing hard-to-reverse problems in the future.
1 can be fixed with a rWMME entry as for 2 I'd not care much, as the Topics are either converted to Wikitext using the script, or deleted, or both. As for Meta-Wiki, nothing broke after uninstallation.
>>! In T63729#3069153, @Catrope wrote:
>>>! In T63729#3068503, @demon wrote:
>>>>! In T63729#3068479, @Dereckson wrote:
>>> @demon @MZMcBride The collaboration team have some reserves about the logs integrity: it will be difficult to see the previous contributions.
>>> 
>> 
>> Integrity? What?
>> 
> 
> The concern here was that the rendering of e.g. https://meta.wikimedia.org/wiki/Special:Contributions/Flow_talk_page_manager would break, because the Topic namespace would go away.

It's also the actual logs:

1. Valid log entries don't render, so you just get "flow-delete-post (Test)", instead of something like "deleted a post on "Test" on Structured Discussions/Sandbox (delete test post)" (these are different examples, but the same action type; correct version also has proper links): https://en.wikipedia.org/w/index.php?title=Special%3ALog&type=delete&user=Fram&page=&year=2016&month=9&tagfilter=&subtype=
2. The namespace stops existing, which still causes breakage even with https://wikitech.wikimedia.org/wiki/Flow .  See https://en.wikipedia.org/w/index.php?title=Special%3ALog&type=&user=Roan+Kattouw+%28WMF%29&page=&year=2016&month=-1&tagfilter=&hide_thanks_log=1&hide_patrol_log=1&hide_tag_log=1&hide_review_log=1 (namespace is missing even for the workaround deletes).
I would like to thank all participants in this and related tasks here on Phabricator for their communication and handling of what was and is a delicate and sometimes tense matter on the wikis. I truly appreciate it from everyone.
>>! In T63729#3069224, @Catrope wrote:
>>>! In T63729#3069218, @demon wrote:
>>>> , but otherwise that plan sounds good. Let's get this on Wikitech.
>>> It's already there, for the deployment window that's right now. Matt is doing the cawiki change, I'll coordinate with him.
>> 
>> I meant more a [[Uninstalling Flow]]
> 
> Oh, the procedure for it, gotcha. Will do that right after I do it on meta so it's fresh in my mind.

Done now: https://wikitech.wikimedia.org/wiki/Flow
This is now done
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVqRM-z1lCyyDMEPvQd9} [2017-03-02T22:46:23Z] <catrope@tin> Synchronized dblists/: T63729: disable Flow on metawiki (duration: 00m 58s)
Change 333860 merged by Catrope:
[operations/mediawiki-config] Remove Flow from Meta-Wiki

[[https://gerrit.wikimedia.org/r/333860]]
>>! In T63729#3069218, @demon wrote:
>>> , but otherwise that plan sounds good. Let's get this on Wikitech.
>> It's already there, for the deployment window that's right now. Matt is doing the cawiki change, I'll coordinate with him.
> 
> I meant more a [[Uninstalling Flow]]

Oh, the procedure for it, gotcha. Will do that right after I do it on meta so it's fresh in my mind.
>>! In T63729#3069212, @Catrope wrote:
>>>! In T63729#3069205, @demon wrote:
>> I'm not sure we need `deleteBatch.php` in this case since it's already down to just one page
> 
> We do need it, there is more than one topic page: https://meta.wikimedia.org/wiki/Special:AllPages/Topic:
> 

Ah ok, I understand what you mean.

>> , but otherwise that plan sounds good. Let's get this on Wikitech.
> It's already there, for the deployment window that's right now. Matt is doing the cawiki change, I'll coordinate with him.

I meant more a [[Uninstalling Flow]]
>>! In T63729#3069205, @demon wrote:
> I'm not sure we need `deleteBatch.php` in this case since it's already down to just one page

We do need it, there is more than one topic page: https://meta.wikimedia.org/wiki/Special:AllPages/Topic:

> , but otherwise that plan sounds good. Let's get this on Wikitech.
It's already there, for the deployment window that's right now. Matt is doing the cawiki change, I'll coordinate with him.
I'm not sure we need `deleteBatch.php` in this case since it's already down to just one page, but otherwise that plan sounds good. Let's get this on Wikitech.
>>! In T63729#3068503, @demon wrote:
>>>! In T63729#3068479, @Dereckson wrote:
>> @demon @MZMcBride The collaboration team have some reserves about the logs integrity: it will be difficult to see the previous contributions.
>> 
> 
> Integrity? What?
> 

The concern here was that the rendering of e.g. https://meta.wikimedia.org/wiki/Special:Contributions/Flow_talk_page_manager would break, because the Topic namespace would go away. Flow also doesn't let you delete pages in the Topic namespace, and without Flow the namespace doesn't exist. So the way I worked around this on enwiki was:
- Uninstall Flow
- Temporarily add `$wgExtraNamespaces[2600] = 'Topic';` to the config
- Use `deleteBatch.php` to delete all pages in the Topic namespace
- Remove the `$wgExtraNamespaces` config
That's a bit ugly, but we should just do the same thing on metawiki, since there's only a test board there and the only real board was transwikied. If we ever wanted to reinstall Flow there, we could undelete the relevant pages: they wouldn't be gone forever, they just wouldn't be viewable or undeletable without reinstalling Flow (because of content model issues).

I've scheduled this (the uninstall + namespace + deleteBatch dance) for the deployment window we already had (for T159047) at 22:00 UTC (i.e. 7 minutes from now).
There were two flow boards: the ORES talk page has been moved to mw.org and the contributions can be seen there (also in Special:Contributions). As for the development test page, I daresay I won't miss that. The comments on there were: 1 thread of complaint and 1 thread of test. Given the clear, explicit consensus to remove the extension in the RfC, this isn't an excuse not to honour it.
>>! In T63729#3068479, @Dereckson wrote:
> @demon @MZMcBride The collaboration team have some reserves about the logs integrity: it will be difficult to see the previous contributions.
> 

Integrity? What?

> To remove the extension is possible, but will be at the detriment of the capability to explore past contributions.

Why did we not have this discussion with enwiki?
@demon @MZMcBride The collaboration team have some reserves about the logs integrity: it will be difficult to see the previous contributions.

As much, as an alternative discussion, it's offered to keep the extension, so it's still possible to explore  the full contributions, but don't have any Flow page active.

To remove the extension is possible, but will be at the detriment of the capability to explore past contributions.
@demon @MZMcBride The Flow team have some reserves about the logs integrity: it will be difficult to see the previous contributions.

As much, as an alternative discussion, it's offered to keep the extension, so it's still possible to explore  the full contributions, but don't have any Flow page active.
>>! In T63729#3066801, @MZMcBride wrote:
> @Dereckson: I missed the discussion in `#wikimedia-operations`. I'm trying to better understand the status of this task. Are you unwilling to deploy <https://gerrit.wikimedia.org/r/333860>?

I'm more than willing.
@Dereckson: I missed the discussion in `#wikimedia-operations`. I'm trying to better understand the status of this task. Are you unwilling to deploy <https://gerrit.wikimedia.org/r/333860>?
As @MZMcBride said, I don't think there are technical reasons for not doing this. The English Wikipedia had way more Flow boards enabled and got removed there per request of its community. Now there's this request, with large community consensus and no active Flow boards. It should be even easier to perform, even if afterwards we need some manual work to do. The community has asked clearly that they want the feature removed (@Alsee even opened a section in that discussion for if it was any doubt), not socially disabled, which is an euphemism for not doing what it was explicitly requested. I don't think they are serious problems for this not to be done, but some personal choices of not wanting Flow gone from Meta; and that is not appropriate when executing valid community consensus. The community at large had their opportunity to voice their personal opinion, and the result was that we want the feature removed. We ain't requesting anything impossible to do, or prohibited or absurd (ie: remove CheckUser or CentralAuth). Thank you.
I strongly agree with MarcoAurelio. Installing Flow on Meta-Wiki never had consensus and there's now a strong consensus to remove the extension completely. The discussion even specifically addressed whether this meant removing Flow from all pages or completely uninstalling the extension.

If there are technical reasons that Flow cannot be uninstalled from Meta-Wiki currently, I would like to know what those reasons are specifically in Phabricator Maniphest tasks so that these issues can be addressed.
Change 333860 restored by MarcoAurelio:
Remove Flow from Meta-Wiki

Reason:
This is not appropriate, Dereckson. The discussion at -operations is that the contribs of Flow talk page manager can stay where they are w/o any problems so far. Restoring. Please implement the community consensus. If this was done for enwiki, this can happen for Meta-Wiki as well. Nothing broke there and nothing will break here either.

[[https://gerrit.wikimedia.org/r/333860]]
Change 333860 abandoned by Dereckson:
Remove Flow from Meta-Wiki

Reason:
Per discussion on #wikimedia-operations, we'll disable it socially, but will leave the Flow extension installed.

That will avoid to get an inconsistent state in the logs, contributions.

The meta RFC is still satisfied as there isn't any active Flow page on meta. (and socially won't), as steps have been taken to move the last one to another wiki.

[[https://gerrit.wikimedia.org/r/333860]]
I ran the preparatory scripts.

Thanks to @Matiia for doing the 4 steps above.
Re {T154816} and {T156113}, the script parts are done.  Could an admin please do the following:
1. Delete https://meta.wikimedia.org/wiki/Research_talk:ORES_paper
2. Soft redirect from https://meta.wikimedia.org/wiki/Research_talk:ORES_paper to https://www.mediawiki.org/wiki/Talk:ORES/Paper .
2. Delete https://meta.wikimedia.org/wiki/Talk:Flow/Developer_test_page
3. Move https://meta.wikimedia.org/wiki/Talk:Flow/Developer_test_page/Wikitext to https://meta.wikimedia.org/wiki/Talk:Flow/Developer_test_page .

? Thanks.
Re {T154816} and {T156113}, the script parts are done.  Could an admin please do the following:
1. Delete https://meta.wikimedia.org/wiki/Research_talk:ORES_paper
2. Delete https://meta.wikimedia.org/wiki/Talk:Flow/Developer_test_page
3. Move https://meta.wikimedia.org/wiki/Talk:Flow/Developer_test_page/Wikitext to https://meta.wikimedia.org/wiki/Talk:Flow/Developer_test_page .

? Thanks.
Added to the latest window available for Europeans: https://wikitech.wikimedia.org/w/index.php?title=Deployments&action=historysubmit&type=revision&diff=1555498&oldid=1555483
>>! In T63729#3038137, @jeblad wrote:
> <rant>Sometimes I would really want a more firm standpoint from WMF against people moving backwards… </rant>

<rant>Agreed. And the necessary prerequisite is to correctly identify "forward" in the first place. During the Flow prototype stage numerous community members told Flow's lead designer that the project was going in the wrong direction. He was told that it could never be successfully deployed as a replacement for Talk pages. The designer aggressively ignored critical project requirements. Uninstalling a non-viable project is a step forwards.</rant>
T154816 is not a hard blocker, just a nice to have (why not make a couple persons happy if it costs us nothing). Doing T156113 before the disabling is instead definitely recommended, though not absolutely necessary per T156113#2964757.

Since there is no way in Phabricator to distinguish "real blockers" from "things you'd also do at the same time in an ideal world", I'm removing the soft subtask again.
I asked for a status update regarding {T154816} at T154816#3038183. This task turns three years old in a couple of days. ;-)  But more seriously, I'd like to see this task resolved in the next week or two. March 1 seems like a reasonable deadline.

One way or another, I'm going to call March 1, 2017 a hard deadline. We will not be saving posts to a Flow-backed version of <https://meta.wikimedia.org/wiki/Research_talk:ORES_paper> after this date.
Standing against the communities which gave success to the WMF movement ain't going to work. Saying that Flow is moving forward is also a disputable statement, specially when so much people has objected to its use on that project, some of those because they ain't able to use that software at all. World is not fair, but excluding community members from discussion pages is not what I'd call moving forward.
<rant>Sometimes I would really want a more firm standpoint from WMF against people moving backwards… </rant>
>>! In T63729#3016898, @MarcoAurelio wrote:
> Flow board still needs to be ported to mw.org and a maintenance script run
> afterwards to convert remaining Flow boards before being removed I think.

That would be nice, but not necessary: we're not dropping the database tables any time soon. Also, if there is really an urgency to keep the content the script for conversion to wikitext is available.
Flow board still needs to be ported to mw.org and a maintenance script run
afterwards to convert remaining Flow boards before being removed I think.
It seems about time to schedule the configuration change and send notices. Can a week or two of windows be added to https://wikitech.wikimedia.org/wiki/Deployments ?
>>! In T63729#2963875, @MZMcBride wrote:
> I think it's reasonable to wait for {T154816} to be resolved, if possible, but we should set a firm deadline. Is four weeks enough time?

4 weeks seems unnecessarily long, but should be tolerable.
Proposed workflow:

# {T154816}, then
# {T156113}, then
# SWAT https://gerrit.wikimedia.org/r/#/c/333860/
Change 333860 had a related patch set uploaded (by MarcoAurelio):
Remove Flow from Meta-Wiki

[[https://gerrit.wikimedia.org/r/333860]]
I think it's reasonable to wait for {T154816} to be resolved, if possible, but we should set a firm deadline. Is four weeks enough time?
[[ https://meta.wikimedia.org/w/index.php?title=Meta:Babel&curid=69328&diff=16251209&oldid=16240965 | The RFC on Meta has closed]] with a clear consensus to remove Flow. Note that this was not an RFC to reduce active Flow pages to zero, this was an RFC for the extension be uninstalled as was done on Enwiki. (T148611)
Note: There is an ongoing proposal to remove Flow from Meta: https://meta.wikimedia.org/wiki/Meta:Babel#Proposal_to_remove_Flow_on_Meta-Wiki
>>! In T63729#2755301, @Alsee wrote:
> Flow is to be uninstalled on EnWiki T148611, can we just roll the two tasks into one?


No separate tasks, should always be kept seperate
Flow is to be uninstalled on EnWiki T148611, can we just roll the two tasks into one?

The [[ https://meta.wikimedia.org/wiki/Meta:Requests_for_comment/Enable_Flow_as_beta_feature | RFC for Flow on Meta ]] was unanimous against Flow, except for the author. I wish I heard about the RFC, I would have eagerly piled-on against Flow. The lead software designer for Flow was told during the prototyping stage, by many many editors, that the design was wrong and that it was never going to be used. He just blew-off all community input on it. (EnWiki Flow talk archives, and almost certainly anywhere else Flow was discussed at the time.)
Flow is to be uninstalled on EnWiki T148611, can we just roll the two tasks into one?

The [[ https://meta.wikimedia.org/wiki/Meta:Requests_for_comment/Enable_Flow_as_beta_feature | RFC for Flow on Meta ]] was unanimous against Flow, except for the author. I wish I heard about the RFC, I would have eagerly piled-on against Flow. The lead software designer for Flow was told during the prototyping stage, by many many editors, that the design was wrong and that it was never going to be used. He just blew-off all community input on it. (EnWIki Flow talk archives, and almost certainly anywhere else Flow was discussed at the time.)
Triaged.
The RfC is closed now and the closure result has not been contested for some time. Flow has no use on Meta other than the test page linked above so there should be no major fuss in removing this.
Also, [[ https://meta.wikimedia.org/wiki/Meta:Requests_for_comment/Enable_Flow_as_beta_feature | this RfC ]] on enabling Flow on Meta as beta feature, although few people participated, is leaning towards not allowing this.
> (there was a discussion at https://gerrit.wikimedia.org/r/#/c/115412/ too)

NSFW link! My eyes bleed... luckily the past is behind us.
(there was a discussion at https://gerrit.wikimedia.org/r/#/c/115412/ too)
>>! In T63729#2295518, @Nemo_bis wrote:
> This request should probably be reopened and completed.

Sure. I've re-opened this task to allow for further consideration.
Two years later, from https://meta.wikimedia.org/wiki/Special:AllPages?from=&to=&namespace=2600 it appears there is no meaningful content anywhere, only https://meta.wikimedia.org/wiki/Talk:Flow/Developer_test_page with some garbage and complaints.

This request should probably be reopened and completed.
Change 115412 abandoned by Odder:
Remove Flow from Meta-Wiki

Reason:
This is very unlikely to ever be merged.

https://gerrit.wikimedia.org/r/115412
I interpret comments 13 to 17 as WONTFIX for this request.

Are there any further arguments that have not been brought up yet plus need answers?
**wmf.amgine3691** wrote:

(In reply to Erik Moeller from comment #17)
> Yeah, sure - I agree there's no point pissing off people unnecessarily while
> we're looking at different test scenarios. There's also no point creating
> more drama than required about a single page test deploy. :) Preemptively
> deleting comments on a page flagged as "developer test page" and then
> raising alarm bells about the coming incursion seems a wee bit premature.
> Let's all have a sensible chat about what makes sense on Meta, but let's
> also give each other the benefit of the doubt as we go please.

AGF is stretched a bit, since there were clear examples cited, communications channels were not used, etc. That is, AGF is not required from only one party.
Where does the single page test end, and using it as a backdoor to enabling it wider or sitewide without community consensus
Yeah, sure - I agree there's no point pissing off people unnecessarily while we're looking at different test scenarios. There's also no point creating more drama than required about a single page test deploy. :) Preemptively deleting comments on a page flagged as "developer test page" and then raising alarm bells about the coming incursion seems a wee bit premature. Let's all have a sensible chat about what makes sense on Meta, but let's also give each other the benefit of the doubt as we go please.
(In reply to Erik Moeller from comment #15)
> What practical concerns are there with the current test page deploy?

I think you and I may fundamentally disagree about whether pissing off a local editing community and engendering further ill will toward these type of projects (ArticleFeedbackv5, LiquidThreads, Flow, UniversalLanguageSelector, VisualEditor, etc.) is a practical concern. The erosion of trust and collaboration between the Wikimedia Foundation and the active editing communities is a very serious and practical concern, in my opinion.

As far as I know, deploying Flow will not cause anything to explode. This is _not_ the same as saying deploying Flow will not cause any harm. I think attempting to force this alpha discussion software on Meta-Wiki (and wherever else next) will actively harm already battered relations.

I'll try to put it another way: if the software has virtue and merit as a product, it should be no issue for the Flow team to establish local community consensus to test it out. However there are over 800 Wikimedia wikis; if, after discussion and consultation, the Meta-Wiki community decides it doesn't want to install Flow right now, test it elsewhere. What's the issue?
I think everyone agrees that the communication about the single-page test wasn't sufficient. But I don't think the LQT comparison is valid. LQT comes with a rather scary per-page flag allowing any page to be LQT-enabled, and the discussions you're pointing to refer to enabling LQT across Meta.

Flow has no such flag right now - pages are manually and carefully selected for testing purposes, and effects truly are pretty limited. This deploy enabled a page called "Developer test page". So this analogy seems _very_ stretched, and the arguments seem theoretical at this point. What practical concerns are there with the current test page deploy?
We can't get consensus on a per-wiki basis before enabling any software change. That has never been our practice and never will be. Clear communication is another matter and it looks like we could have done better in this respect.

What are the actual material issues with this deploy?
(In reply to Maryana Pinchuk from comment #9)

> We are not going to disable Flow from Meta unless there is an actual issue
> with the software. Please do not reopen this bug again unless you can point
> to an actual issue with the software; doing otherwise is disruptive and
> pointless.

You have conveniently avoided answering any of the questions asked by MZMcBride. The truth is, you did not ask the Meta community for their opinion on whether Flow should be enabled or not, and you refuse to acknowledge it.

This is VisualEditor all over again: you have learnt nothing from that experience, and that's just sad.
Change 115412 had a related patch set uploaded by Odder:
Remove Flow from Meta

https://gerrit.wikimedia.org/r/115412
Just as is enabling an extension on a production wiki without asking its community for opinion first.
We are not going to disable Flow from Meta unless there is an actual issue with the software. Please do not reopen this bug again unless you can point to an actual issue with the software; doing otherwise is disruptive and pointless.
(In reply to Maryana Pinchuk from comment #4)
> This is all following along our course of enabling Flow on an opt-in, user
> requested basis on a limited set of pages for testing purposes over the next
> 3-6 months.

I don't believe the Meta-Wiki community wants the Flow extension enabled right now. Have you tried asking the community about its thoughts on the matter?

Unlike most of the Flow team, most active users at Meta-Wiki have been around for a long time. Meta-Wiki eschewed LiquidThreads (I believe I even once proposed enabling it there and it was quickly shot down). Perhaps with Flow, the Meta-Wiki community will be more receptive, but I think it would make sense to ask. Have you asked?
(In reply to spage from comment #6)
> Enabling Flow on a wiki test page before enabling it on a requested Talk
> page on that wiki is clearly the right thing to do. We found a problem with
> Parsoid configuration on meta by doing so.  We do indeed have playgrounds
> already so I didn't see much point in publicizing yet another test page, but
> since people find them anyway we should do so in the future.
> 
> I think people's bigger objection is Flow coming to a wiki because some
> small group requests it on "their" Talk page. That's implicit in the
> roll-out strategy Maryana mentioned, which is on the main Flow page:
>    Wider release to more WikiProject and community discussion spaces on
> English Wikipedia and other projects, on an opt-in trial basis
> 
> I don't think this bug is the best place to discuss the rollout strategy,
> I've created https://www.mediawiki.org/wiki/Flow/Rollout and it has a talk
> page, the latter is not yet Flow-enabled :)

I think you're totally missing the point about the objections raised in this bug.
Enabling Flow on a wiki test page before enabling it on a requested Talk page on that wiki is clearly the right thing to do. We found a problem with Parsoid configuration on meta by doing so.  We do indeed have playgrounds already so I didn't see much point in publicizing yet another test page, but since people find them anyway we should do so in the future.

I think people's bigger objection is Flow coming to a wiki because some small group requests it on "their" Talk page. That's implicit in the roll-out strategy Maryana mentioned, which is on the main Flow page:
   Wider release to more WikiProject and community discussion spaces on English Wikipedia and other projects, on an opt-in trial basis

I don't think this bug is the best place to discuss the rollout strategy, I've created https://www.mediawiki.org/wiki/Flow/Rollout and it has a talk page, the latter is not yet Flow-enabled :)
No. Meta is not your playground. Go test Flow on the Beta cluster if you need to.
Andre: From https://wikitech.wikimedia.org/wiki/Deployments: Tuesday February 18th, "enable Flow on meta test page and a few more mediawiki.org talk pages" :)

I got a request from the WMF Programs Evaluations team to enable Flow on the talk page of https://meta.wikimedia.org/wiki/Programs:Evaluation_portal/Learning_modules. The extension's been tested in production for 2 months now (on mw.org, as well as English Wikipedia for about 2 weeks now), but we wanted to be sure to enable it on a test page on Meta before releasing it on a real discussion page. 

This is all following along our course of enabling Flow on an opt-in, user requested basis on a limited set of pages for testing purposes over the next 3-6 months.
(In reply to Bawolff (Brian Wolff) from comment #2)
>(Surely flow should add a page property
> or something to flow pages so that they can be found sanely?)

Filed as bug 61747
(In reply to Andre Klapper from comment #1)
> I did not see this mentioned anywhere on
> https://wikitech.wikimedia.org/wiki/Deployments (link welcome if I missed
> it). 
> The patch is missing any link to a bug report or on-wiki discussion, as
> MZMcBride correctly pointed out. And I have no idea what the "one page of
> meta" is, as the commit message is so vague.
> 

It's https://meta.wikimedia.org/wiki/Talk:Flow/Developer_test_page . You can find flow pages by doing searches like https://meta.wikimedia.org/w/index.php?title=Special:Search&search=%22This%20talk%20page%20has%20been%20taken%20over%20by%20a%22&fulltext=Search&profile=all&redirs=1 (Surely flow should add a page property or something to flow pages so that they can be found sanely?)
I did not see this mentioned anywhere on https://wikitech.wikimedia.org/wiki/Deployments (link welcome if I missed it). 
The patch is missing any link to a bug report or on-wiki discussion, as MZMcBride correctly pointed out. And I have no idea what the "one page of meta" is, as the commit message is so vague.

I really hope I missed something, otherwise this would look like pretty bad communication.
Screenshot

Steps to reproduce:

Open the VE and observe the toolbar

See the screenshot attached.

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

**Attached**: {F13046}
Verified the fix in betalabs
This has been resolved because the offending commit was reverted

I7e8ab90f7a9f77f5cf6d7baeab586d4e0332042e
Change 114637 abandoned by Trevor Parscal:
Fix a missing { and remove some debugging CSS left in Ied29358

Reason:
Ied29358 was reverted

https://gerrit.wikimedia.org/r/114637
Change 114637 had a related patch set uploaded by Krinkle:
Fix a missing { and remove some debugging CSS left in 4a067460

https://gerrit.wikimedia.org/r/114637
Created attachment 14638
Screenshot

**Attached**: {F13047}
The file modules/syntaxhighlight/rules/mysql.json has at least one double quoted string containing unescaped double quotes. I.e something like:

{
 "match" : """
}

That cause PHP json_decode() to choke with a syntax error.  I wrote a json linter to lint json files in Jenkins.  You can try it using integration/jenkins.git and running bin/json-lint.php

 ./modules/syntaxhighlight/rules/mysql.json: Syntax error

--------------------------
**Version**: unspecified
**Severity**: normal
hashar@gallium:~/extensions$ /srv/deployment/integration/slave-scripts/bin/json-lint.php VisualEditor/; echo $?
0
hashar@gallium:~/extensions$
The PHP json_decode() no more reports any error. Thank you!
Change 114518 merged by jenkins-bot:
Fix broken JSON in modules/syntaxhighlight/rules/mysql.json

https://gerrit.wikimedia.org/r/114518
(In reply to Antoine "hashar" Musso from comment #0)
> The file modules/syntaxhighlight/rules/mysql.json has at least one double
> quoted string containing unescaped double quotes. I.e something like:
> 
> {
>  "match" : """
> }
> 
> That cause PHP json_decode() to choke with a syntax error.  I wrote a json
> linter to lint json files in Jenkins.  You can try it using
> integration/jenkins.git and running bin/json-lint.php
> 
>  ./modules/syntaxhighlight/rules/mysql.json: Syntax error

It's in a file that's not currently used (the code needs some work), but I've fixed it.
Change 114518 had a related patch set uploaded by Jforrester:
Fix broken JSON in modules/syntaxhighlight/rules/mysql.json

https://gerrit.wikimedia.org/r/114518
Right now the reference group input (in both MWReferenceDialog and MWReferenceListDialog) is a plain text input box (with a placeholder).

Instead, it should be a drop-down that suggests existing groups, as well as giving the ability to write in a new value, aka a ComboBox.

The default value should still have a placeholder, I think.

[Blocked on OOjs UI having a ComboBox widget.]

--------------------------
**Version**: unspecified
**Severity**: enhancement
Verified the fix in Production
Verified it in Betalabs and test 2
Change 156160 merged by jenkins-bot:
Use combo box widget to suggest existing values for reference group

https://gerrit.wikimedia.org/r/156160
Change 156160 had a related patch set uploaded by Alex Monk:
Use combo box widget to suggest existing values for reference group

https://gerrit.wikimedia.org/r/156160
Right now it's in MWInternalLinkAnnotation and MWRedirectMetaItem just calls into that (see https://gerrit.wikimedia.org/r/#/c/114381/). There's also some ./ stripping regexes strewn across the rest of the codebase. This should all be factored out and centralized.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Inside the category editor, there used to be a drop-down indicator on categories.  It's not there now.  Not at MediaWiki, not at Wikipedias, not in Safari 6, not in Firefox 26 (on Mac OS 10.8.5).

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in test2
Yes, this got broken some time ago due to an oversight – and we just fixed it on Friday (gerrit 113477). The fix will be going out to MediaWiki.org tomorrow. Sorry!
It's incredibly confusing spaghetti code that's not documented well. Kill it with fire and start from scratch.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This function doesn't actually exist. I'm assuming this refers to getOffset/getOffsetFromElementNode/getOffsetFromTextNode which have been rewritten in https://gerrit.wikimedia.org/r/#/c/121563/
Screenshot

Steps to reproduce:


1.Open a page with VE
2.Insert an image
3.Go to Media Settings of that image and add another image inside it
4.Now Go to the media settings of the image that you just added
5.Type something in the caption of the second image
6.Apply changes
7.Save the page

Observed Result:
The wiki text for the image shows up in the read mode

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/19thfebFF

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

**Attached**: {F13390}
I can't make three-deep nested images work in wikitext.

Three deep (image1's caption contains image2, and image2's caption contains image3) causes this problem if done in VisualEditor:  
http://en.wikipedia.beta.wmflabs.org/w/index.php?&oldid=82440  It displays correctly in VisualEditor, but makes a mess when you save.

Two deep in wikitext displays correctly:  https://en.wikipedia.org/w/index.php?&oldid=598318957#List

Three deep in wikitext shows me only the first image.  The other two in my (unsaved) attempts simply disappeared from view (although present in the wikitext code).

It's possible that I simply haven't found the perfect sequence of nesting the images, but if wikitext can't handle more than two in a nested sequence, the VisualEditor shouldn't offer it.
Parsoid's bug 49844 with link attributes has been fixed.

In https://bugzilla.wikimedia.org/show_bug.cgi?id=49844#c5 James Forrester wrote:

This is worked around (albeit with potentially a bit of a hack) in VisualEditor, so not so important now from VisualEditor's POV.

Now that the parsoid fix has been deployed (for a while now), I'm opening a new bug to revert Visual Editor's hack.

--------------------------
**Version**: unspecified
**Severity**: normal
As discussed, this wasn't a hack, this was the right thing to do, so INVALIDing this bug.
Change 119088 merged by jenkins-bot:
Remove commented-out, now-confirmed-as-wrong wrong image insertion code

https://gerrit.wikimedia.org/r/119088
Change 119087 merged by jenkins-bot:
Clarified the default link for image insertion.

https://gerrit.wikimedia.org/r/119087
Change 119088 had a related patch set uploaded by Jforrester:
Remove commented-out, now-confirmed-as-wrong wrong image insertion code

https://gerrit.wikimedia.org/r/119088
Change 119087 had a related patch set uploaded by Cscott:
Clarified the default link for image insertion.

https://gerrit.wikimedia.org/r/119087
I believe the reversion is correct.  Clarified the spec: https://www.mediawiki.org/w/index.php?title=Parsoid%2FMediaWiki_DOM_spec&diff=931265&oldid=931084
VE's current behavior matches the spec.
This isn't fixed.

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:Whatamidoing_(WMF)/Sandbox&diff=81525&oldid=81245

*sighs*
Change 114352 merged by jenkins-bot:
Revert "Set href attribute of newly inserted image to image title"

https://gerrit.wikimedia.org/r/114352
Change 114352 had a related patch set uploaded by Jforrester:
Revert "Set href attribute of newly inserted image to image title"

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

Steps to reproduce:


1.Open a page with VE
2.Insert an image .
3.Go to Media Settings>Advances Settings
4.Set the image alignment to left/None
5.Save the page
6.Reopen the page
7.Select the image
8.Start typing something


Observed Result:
ncaught Error: Offset could not be translated to a DOM element and offset: 143 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=18thfebchrome&veaction=edit

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

**Attached**: {F13297}
Found the steps to reproduce the case with deleting the reflist:

1.Add an image
2.Go to Media Settings>Advanced Settings
3.Set the position to left
4.Add a reference inside the image
5.Save the page
6.Open the page again
7.Delete the reflist

The error Uncaught Error: Offset could not be translated to a DOM element and offset: 143 appears in the console
This is also happening while deleting the reflist of the same page
It seems Flow has not defined any HTML accesskeys for previewing/submitting posts and topics.

The default accesskey "p" should be added to the "Preview" button.
The default accesskey "s" should be added to the "Reply"/"Add Topic"/"Submit changes" buttons when replying to a topic/adding a topic or editing a post respectively.

Docs (I'm not sure which of these are most uptodate):
* https://www.mediawiki.org/wiki/Manual:Interface/Access_keys
* https://meta.wikimedia.org/wiki/Help:Keyboard_shortcuts
* https://en.wikipedia.org/wiki/Wikipedia:Keyboard_shortcuts
* https://www.mediawiki.org/wiki/VisualEditor/Portal/Keyboard_shortcuts

See also {T158779}
I use alt(+shift)+s to save in articles, which is specified when hovering over the save-button (in wikicode-mode). That should be standard for Flow as well.
Well, it's "non-standard in the Wikimedia world" because we didn't decide to use it as a standard. There is no Wiki God (sorry, Jimbo!) declaring "the standard". There is only us.

And Echo is being introduced for the same reason Visual Editor is: Because "our ways" don't cut it for the mere rest of the world. There, WYSIWYG editing is standard. So is Crtl/Cmd-Enter to save.
First of all the long established accesskeys (with "S" for saving and "P" for preview respectively) should be added to Flow.

If we add yet another - currently non-standard (in the Wikimedia world) - possibility for submitting (like Ctrl+Enter) is not within the scope of the bug as far as I'm concerned.
Frankly, I think the ULS should get a different shortcut then. Simple question:
* How many people will use the ULS often enough to remember and use a shortcut, per day?
* How many people will save a comment on a Flow talk page, using the pseudo-standard shortcut (used by gmail, phabricator, etc.), per day?

Principle of least surprise, people...
We could use the standard accesskey mechanism, and the same keys for save (corresponding to Flow submit) and preview (corresponding to Flow "switch to VE") as standard edit pages (mouse over the save and preview buttons).
Is there a different shortcut we could use?
Ctrl+Enter is currently taken over by UniversalLanguageSelector. T106700
A request for Ctrl-Enter (Cmd-Enter) to "Save" an edit, via twitter: https://twitter.com/MagnusManske/status/631122281931112448  (and the previous onwiki discussion I linked above, also suggested this standard key combination)
Thanks Eduard. :)

Tracked at https://trello.com/c/Y8vvggBw/99-keyboard-shortcuts-accesskeys

with previous discussion and notes at https://www.mediawiki.org/w/index.php?title=Talk:Flow&topic_postId=roaqtzq187eo7d74&workflow=roaqtzq187eo7d74
For projects built with npm (e.g. VE, OOjs UI) this could be relatively easy, but for MW core I imagine it's a bit harder to parse .php files.

(For VE we'd want this blocking merge, but that's a distinct conversation.)

--------------------------
**Version**: unspecified
**Severity**: enhancement
Other repositories (i.e. MediaWiki extensions) will be checked using a dedicated Jenkins job. That is the purpose of bug 64045.
Change 125050 merged by jenkins-bot:
Use new banana checker as a linter to avoid lacking qqq messages

https://gerrit.wikimedia.org/r/125050
(In reply to Gerrit Notification Bot from comment #5)
> Change 5550 abandoned by Jforrester:
> tests to compare En, Qqq and messages.inc
> 
> Reason:
> Replaced by https://www.npmjs.org/package/grunt-banana-checker now.
> 
> https://gerrit.wikimedia.org/r/5550

Sounds good to me :-]
Change 5550 abandoned by Jforrester:
tests to compare En, Qqq and messages.inc

Reason:
Replaced by https://www.npmjs.org/package/grunt-banana-checker now.

https://gerrit.wikimedia.org/r/5550
Done in https://www.npmjs.org/package/grunt-banana-checker – gerrit 125050 adds this to MediaWiki core; gerrit 124069, gerrit 124023 and gerrit 124021 added it to OOjs UI, VisualEditor, and VisualEditor-MediaWiki.
Change 125050 had a related patch set uploaded by Jforrester:
Use new banana checker as a linter to avoid lacking qqq messages

https://gerrit.wikimedia.org/r/125050
Change 5550 had a related patch set uploaded by Hashar:
tests to compare En, Qqq and messages.inc

https://gerrit.wikimedia.org/r/5550
For mediawiki/core I once wrote a test suite that compares messages in messages.inc, en and qqq https://gerrit.wikimedia.org/r/#/c/5550/

They are not passing though and I don't really have the mood to complete this patch though :-(
Last working job:
  https://integration.wikimedia.org/ci/job/mwext-VisualEditor-npm/942/console

  - Feb 16, 2014
  - Building remotely on integration-slave01

  - node v0.10.22
  - npm v1.1.38

First failing job:
  https://integration.wikimedia.org/ci/job/mwext-VisualEditor-npm/943/console

  - Feb 18, 2014
  - Building remotely on integration-slave02

  - node v0.8.2
  - npm v1.1.39

16:23:41 npm ERR! Error: SSL Error: CERT_UNTRUSTED
16:23:41 npm ERR!     at ClientRequest.<anonymous> 
16:23:41 npm ERR!     at Socket.ondata (stream.js:38:26)
16:23:41 npm ERR!  [Error: SSL Error: CERT_UNTRUSTED]

Server log:
  https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=99596&oldid=99549


  - February 17
    - 16:15 hashar: Jenkins deleting slave integration-slave01
    - 16:14 hashar: Jenkins added two labs slaves with 4 CPU: integration-slave02 and integration-slave03
    - 08:46 hashar: Upgrading Jenkins, half an hour downtime



So npm was upgraded one minor version, and nodejs was downgraded *2 major versions*, and (possibly unrelated) it seems to be unable to verify the certificate properly.

According to existing bug reports, this is related to it being a self-signed certificate, however this shouldn't be a problem since a validation mechanism for their official certificate ships with the npm package. Upstream recommends upgrading to the most recent minor version, but that doesn't seem to be the problem considering the bug started happening for us overnight (no certificate change upstream) when we went from v1.1.38 to v1.1.39 (not down).

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
https://github.com/npm/npm/issues/4838
Existing instances have been patches so marking this as fixed.

The fact that we need to puppetize the patches is a separate bug.

See:
* bug 68256
* bug 66056

And the patches are documented at:
https://wikitech.wikimedia.org/wiki/Nova_Resource:Integration/Setup
The new
Thank you Timo for fixing up the installation on integration-slave1003.  I guess we can close that bug since you proposed to use node 10.x on bug 66056 which would definitely fix the issue.
(In reply to Antoine "hashar" Musso from bug 66048 comment #1)
> Node marked offline on
> https://integration.wikimedia.org/ci/computer/integration-slave1003/

Brought back online.
*** Bug 66048 has been marked as a duplicate of this bug. ***
https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&oldid=115053

> 20:08 hashar: Jenkins unpolled integration-slave1003 npm is outdated there and does not trust npmregistry.org ( bug 61508 )
> 22:37 Krinkle: Hack-patching integration-slave1003.eqiad.wmflabs per https://bugzilla.wikimedia.org/show_bug.cgi?id=61508#c2


krinkle at integration-slave1003.eqiad.wmflabs in ~
$ node --version
v0.8.2

$ npm --version
1.1.39

$ sudo -s
# export HOME=/root
# npm conf set strict-ssl false
# l /usr/bin/npm

  /usr/bin/npm -> /etc/alternatives/npm*

# rm /usr/bin/npm
# /etc/alternatives/npm install -g npm

  ...
  npm@1.4.13 /usr/lib/node_modules/npm

# cd /tmp && mkdir foo123 && cd foo123
# npm install jshint

  .. success ..
  jshint@2.5.1 node_modules/jshint

# l `which npm`

  /usr/bin/npm -> ../lib/node_modules/npm/bin/npm-cli.js*

# npm conf set strict-ssl true

# cd ~ && rm -rf /tmp/foo123/
# npm install -g grunt-cli

  .. success ..
  /usr/bin/grunt -> /usr/lib/node_modules/grunt-cli/bin/grunt
  grunt-cli@0.1.13 /usr/lib/node_modules/grunt-cli

# npm --version
1.4.13
# grunt --version
grunt-cli v0.1.13
Has this recurred?
I was a bit upset this morning. I have applied Timo fix from Comment #2 on all four instances:

 integration-slave02.pmtpa.wmflabs
 integration-slave03.pmtpa.wmflabs
 integration-slave1001.eqiad.wmflabs
 integration-slave1002.eqiad.wmflabs

Seems to work now.
(In reply to Nemo from comment #7)
> I don't know if it's the same for you, but docs were wrong for me.
> <https://www.mediawiki.org/w/index.
> php?title=Parsoid%2FSetup&diff=930615&oldid=930612>

The doc instructs to use a ppa which provides 0.10.x.  We do not use ppa.
Mailed ops list.  The Parsoid and VisualEditor npm jobs are now failing and preventing changes to be merged until the SSL cert issue is properly fixed.
(In reply to Antoine "hashar" Musso from comment #6)
> Will mail ops list to figure out how to get nodejs 0.10.x marked for install
> on those hosts.

I don't know if it's the same for you, but docs were wrong for me.
<https://www.mediawiki.org/w/index.php?title=Parsoid%2FSetup&diff=930615&oldid=930612>
For some reason I managed to get the pmtpa slave nodes back to nodejs 0.8.x which break the VisualEditor npm jobs.

I also created two new slaves in eqiad (integration-slave1001 and integration-slave1002) and they come up with nodejs 0.8.x as well.

Will mail ops list to figure out how to get nodejs 0.10.x marked for install on those hosts.
(In reply to Antoine "hashar" Musso from comment #3)
> integration-slave01 received nodejs 0.10.x when it got added to
> apt.wikimedia.org. It has been later removed but the instance never got
> cleaned up.
> 
> npm, I have no idea, probably similar.
> 
> 
> I dont want the slaves to be tweaked manually, everything must be in puppet.
> So there is a few bugs that we should fill all related to updating packages
> in apt.wikimedia.org:
> 
> * nodejs 0.10.x (that is apparently a work in progress)
> * npm 1.3.10 should be backported from Ubuntu Trusty
> * grunt-cli needs to be packaged
> 
> Then we can update the list of packages in operations/puppet.git file
> ./modules/contint/manifests/packages/labs.pp . It list npm but no grunt-cli
> since there is no package there.
> 
> Does it sound right?

Yes, except for grunt-cli needing to be packaged. We explicitly don't want to do that, like the over 300 other arbitrary npm modules we fetch daily on the integration slaves based on things listed in package.json in local repositories, this yet just another package like that. We can and should (for consistency and for it being the right version) install this via npm.

I'm sure there is a puppet syntax for ensuring a certain shell command has been executed (e.g. based on a certain file existing). Similar to how we use git::clone in some places and the puppet file{} syntax. They're not provisioned packages, just inline specified within our manifest created by something other than a package (a rb template file, a git clone, or, in this case, an npm install)
Lowering priority and assigning back to Timo.  He applied a workaround.  Still have to fill bugs as mentioned in comment #3
integration-slave01 received nodejs 0.10.x when it got added to apt.wikimedia.org. It has been later removed but the instance never got cleaned up.

npm, I have no idea, probably similar.


I dont want the slaves to be tweaked manually, everything must be in puppet. So there is a few bugs that we should fill all related to updating packages in apt.wikimedia.org:

* nodejs 0.10.x (that is apparently a work in progress)
* npm 1.3.10 should be backported from Ubuntu Trusty
* grunt-cli needs to be packaged

Then we can update the list of packages in operations/puppet.git file ./modules/contint/manifests/packages/labs.pp . It list npm but no grunt-cli since there is no package there.

Does it sound right?
krinkle at integration-slave03:

# Enter root and fix HOME so that npm doesn't put cache in /home
# which is read-only in labs (why?)
$ sudo -s
$ export HOME=/root

# Temporarily disable ssl check
$ npm conf set strict-ssl false

# Remove symlink to apt-get installed version
# because npm is not allowed to to delete this shadow 
$ l /usr/bin/npm
  /usr/bin/npm -> /etc/alternatives/npm*
$ rm /usr/bin/npm

# Upgrade npm
$ /etc/alternatives/npm install -g npm

 npm@1.1.39
 ...
 npm@1.4.3

# Re-enable ssl check
$ npm conf set strict-ssl true

# Verify that stuff works by doing an
# install of an example package (jshint)
# in a tmp dir
$ cd /tmp && mkdir foo123 && cd foo123
$ npm install jshint
 ...
 success
$ cd ~
$ rm -rf /tmp/foo123

# Install Grunt
$ npm install -g grunt-cli

 ...
 success
So the certificates partially ship with nodejs, not the npm package.

Upstream nodejs takes care to backport these cert changes to v0.8, however the slaves not only downgraded from v0.10 to v0.8 but also to an way older minor release of the v0.8 branch.

There have been 24 (!) minor releases since v0.8.2, latest is v0.8.22.

In case this particular cert change can be mitigated by only upgrading npm, I've done a manual upgrade of npm on the individual instances using npm itself:

 $ sudo -s
 $ npm conf set strict-ssl false
 $ npm install -g npm
 npm 1.1.39
 ...
 npm 1.4.3
 $ npm conf set strict-ssl true
 $ cd /tmp && mkdir foo123 && cd foo123
 $ npm install jshint
 success

The jobs still fail after this because the new labs slaves are also missing grunt.

 $ sudo -s
 $ npm install -g grunt-cli
 success


Note that I couldn't interact with npm the normal way because for some reason /home is read-only on the integration instances (even in root, npm still uses your original home as location to do some temporary work and caching).

Had to set `export HOME=/root` to bypass that.
The VE template dialog can - with the help of #templatedata - show input fields for a template's parameters. Usually these are simple text fields that offer no editing tools.

As a user it would be nice to have a simple way to add references or re-use reference from the main article to input fields in dialog.

A way to move forward here could be:
- For a specific template parameter type (e.g. `content`) add...
- ...either a button that opens the Citation dialog and adds wikitext, similar to how it's done in the WTE2017
- ...or add a "inline" VisualEditor similar to what's done for the image dialog's caption field
{T52896} seems closely related.
If you add an empty, unnamed reference in wikitext ("<ref />"), then you get an empty, invalid reference.

If you add an empty, unnamed reference in VisualEditor (Insert>Reference, then "Add reference" without typing anything), then you get an empty, invalid reference.

VisualEditor should do better than wikitext:  it should detect empty, unnamed ref tags and refuse to insert them.

--------------------------
**Version**: unspecified
**Severity**: normal
We fixed this a while ago. Sorry for the slow triage!
**Author:** `duongxvu`

**Description:**
I was wondering whether it is possible for VisualEditor to work with other skins besides the officially supported ones (which I believe to be Vector, Monobook, and Apex). I’ve been tasked with creating a custom skin to meet my organization’s existing design standards, but it does not seem so easy to add support for VisualEditor in this regard. And documentation addressing similar issues to mine seem to be rare at the moment.

For now, I've heavily modified Vector as a workaround, but would prefer a more long-term solution if one exists. I assume that the Vector skin will continue to receive regular updates in the future, and I’d like to avoid having to modify it every time that happens.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://www.mediawiki.org/wiki/VisualEditor/Skin_requirements
I'm going to deem this fixed based on the details in https://www.mediawiki.org/wiki/VisualEditor/Skin_requirements now available.
I have a skin ([[Skin::Cameleon]]) that's based on Dantmman's excellent tutorial ([[Manual:Skinning/Tutorial]]). All I really did (aside from installing Visual Editor) was to add my skin's name to the $wgVisualEditorSupportedSkins global array variable.

We already found a number of CSS issues, that need fixing, but aside from that it seems to work.
I started writing some notes about what VE expects of skins in https://docs.google.com/a/wikimedia.org/document/d/1awG4IKujTFd72RJzr_4DVInKDO1BqRxRHbTnCHvYLr4/edit (Obviously, when I started a Google doc I expected to end up writing more. :/). Looking for feedback.

Currently it starts with the IDs it expects to be present and then a note relating to Gerrit change 130085 and Gerrit change 130656.

Never having made a skin myself I'm not 100% confident about what we need to make clear here or what's wanted by the bug reporter.
Yes, we currently don't document well what requirements we have on skins (because we're adding requirements as we go). We should improve documentation so that it's easier for skin maintainers to know what they need to do.
Please go to the youtube link for fully demo http://www.youtube.com/watch?v=DZ90EDLqHUI

--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Mac OS X 10.6
**Platform**: Macintosh
**Coiby.Xu** wrote:

Same problem on Ubuntu 13.04, Firefox 26 and Chrome 33. I've tested both on wikipedia and local server.

For the details, see https://www.mediawiki.org/wiki/Talk:VisualEditor#first_line_comes_out_extra_words_when_typing_chinese.
Steps to reproduce:

1.Open a page with VE
2.Add a reference with a group name "first group"
3.Now Add a references list but under Use this group, type "first group one"
4.Apply changes.("there are no references with this group" will appear which is correct)
5.Now reopen the References list dialog again.
6.Just delete the "one" from "first group one" to make it "first group"
7.Apply changes

Observed Result:
Even this time it says "there are no references with this group" which is wrong.


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

--------------------------
**Version**: unspecified
**Severity**: normal
The shadow

Steps to reproduce:


1.Open a page with VE
2.Insert an image
3.Go to Media Settings for that image
4.Go to Insert>Transclusion
5.Search for the Cite Web template
6.Add a value for URL and Source Title
7.Apply Changes
8.Now again re-open the cite web dialog for the template you just added
9.When all the parameter list appears in the dialog box , scroll down a bit.

Observed Result:

Observe that,there is a black shadow appearing on the border above the Apply Changes button, it seems to me coming from the "URL Access Date" field as it was initially aligned with that border.


See the screenshot attached to better understand the problem

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**: {F12975}
Verified the fix.
This appears to now be fixed, AFAICT, due to the changes to this layout. Closing.
Created attachment 14594
The position of URL access date field when the dialog is opened

**Attached**: {F12976}
On inserting an image, or editing an image, it should be possible to visit the file description page. Currently it's not even possible to get the filename of an image when in VE.

Why this is needed: In order to access the captions on the image page or verify the license or similar. E.g. on inserting an image of Obama shaking hands with some other important person into the Obama article you might want to find out who this other person is

Suggested solution: Add a link to the filepage in media settings.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This was implemented during the last major work on the media dialog.  Choose an image from the search results, and click on the "More information" link (at the end of list of information about the image).
Screenshot attached

Steps to reproduce:

1.Open a page with VE
2.Make some changes
3.Switch to edit source mode
4.Save the page from Edit source mode

Observed Result:
Uncaught SyntaxError: Invalid flags supplied to RegExp constructor 'index' appears in the console

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

See the screenshot attached

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

**Attached**: {F12828}
Bug caused by the Citation expander gadget.
Steps to replicate:

1. Edit an article in VisualEditor (or start a new one)
2. Go to http://git-scm.com/download/linux
3. Copy the list, from "Debian/Ubuntu" to the end of the content in the white space.
4. Paste into the article in VE.

Observed: 

"Uncaught TypeError: Cannot call method 'getComparableObjectForSerialization' of undefined"

After that, interaction with the CE - mostly with link inspector and surface widgets produces errors or is unresponsive (Without console error)

I got this when I tried to add a link: "Uncaught TypeError: Cannot call method 'getSurface' of null"
"



Chrome 32.0.1700.107 under Ubuntu 12.04.

--------------------------
**Version**: unspecified
**Severity**: minor
Committed while bugzilla was down:
https://gerrit.wikimedia.org/r/#/c/113538/
This is a bug in remapStoreIndexes, so this only happens when the target document already has some annotations, and the content being pasted has annotated elements (in Moriel's case, a <br> inside a <code>)
WFM in standalone and MediaWiki. Can anyone else reproduce?
**Author:** `swalling`

**Description:**
Francais

Edit beta is specific to English Wikipedia but we hard coded it in the tour text for GettingStarted, so it is showing up incorrectly in translated versions such as French etc.

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

**Attached**: {F12815}
Change 114698 merged by Phuedx:
Use VisualEditor configuration for appendices (e.g. beta).

https://gerrit.wikimedia.org/r/114698
Change 114698 had a related patch set uploaded by Mattflaschen:
Use VisualEditor configuration for appendices (e.g. beta).

https://gerrit.wikimedia.org/r/114698
This is in a firsteditve message in the GuidedTour extension.
See the attachment for the issue.  Note how the guider says "Modifier bêta", but the actual tab just says "Modifier".  We want to fix the guider to check the configuration and always match the tab.
(In reply to Nemo from comment #2)
> (In reply to Matthew Flaschen from comment #1)
> > It's easy to detect if this is enabled (mw.config.get(
> > 'wgVisualEditorConfig' ).tabMessages).  However, I need to decide whether to
> > make separate messages or substitute it in.
> 
> Can you pass two messages to it directly?

Sorry, I'm a little unclear what you mean.  What would the two messages be, and what would I pass them to?

> If the message(s) are just '{{int:vector-view-edit}}
> {{int:visualeditor-beta-appendix}}' it's not less lego to have two. You can
> pass to the tab a message '{{int:vector-view-edit}}$1" where $1 is nothing
> or "&#160;{{int:visualeditor-beta-appendix}}".

I'm not controlling the text of the tab (sorry, the bug title was misleading).  I'm controlling the text of the guider (a kind of modal popup), which refers to the text of the tab.

However, I think your suggestion of using a parameter just for the second part could still apply.
(In reply to Matthew Flaschen from comment #1)
> It's easy to detect if this is enabled (mw.config.get(
> 'wgVisualEditorConfig' ).tabMessages).  However, I need to decide whether to
> make separate messages or substitute it in.

Can you pass two messages to it directly?

> 
> Is this an acceptable use of a parameter (passing either
> '{{int:vector-view-edit}} {{int:visualeditor-beta-appendix}}"' or
> '{{int:vector-view-edit}}' depending on configuration?
> 
> Or should I make separate messages?

If the message(s) are just '{{int:vector-view-edit}} {{int:visualeditor-beta-appendix}}' it's not less lego to have two. You can pass to the tab a message '{{int:vector-view-edit}}$1" where $1 is nothing or "&#160;{{int:visualeditor-beta-appendix}}".
It's easy to detect if this is enabled (mw.config.get( 'wgVisualEditorConfig' ).tabMessages).  However, I need to decide whether to make separate messages or substitute it in.

Is this an acceptable use of a parameter (passing either '{{int:vector-view-edit}} {{int:visualeditor-beta-appendix}}"' or '{{int:vector-view-edit}}' depending on configuration?

Or should I make separate messages?
After a discussion with no objections amongst the OTRS administrators on our mailing list, we would like to have the Translate extension enabled on OTRS wiki to facilitate translating messaging. Thanks!

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
Just to make it clear, {{autotranslate}} ({{int:Lang}}), LangSelect (+ {{mld}}), LanguageSelection, LangSwitch have nothing to do with the Translate extension.
(In reply to Steinsplitter from comment #11)
> {{autotranslate}} dos not work. The template seems okay. (problems with
> {{int:*}} ?).
> 
> Can someone pleas take a look?

They actually do work, I just overlooked something and told Steinsplitter that they don't seem to work...
{{autotranslate}} dos not work. The template seems okay. (problems with {{int:*}} ?).

Can someone pleas take a look?
Bungled jargon. Tomasz for the patch/commit,  Reedy deploy. Thanks.
Thanks for the patch, Tomasz, thanks for the commit, Reedy, thanks for the comments, all. This should a very small but useful tool in agent onboarding. :)
Merged & deployed by Reedy; the extension is now available on the wiki (and working).
Change 113160 merged by jenkins-bot:
Enable Translate extension on OTRS wiki

https://gerrit.wikimedia.org/r/113160
Change 113160 had a related patch set uploaded by Odder:
Enable Translate extension on OTRS wiki

https://gerrit.wikimedia.org/r/113160
(In reply to Keegan Peterzell from comment #0)
> After a discussion with no objections amongst the OTRS administrators on our

Who? The OTRS admins, the admins on OTRS wiki, the end users on OTRS wiki?

From what i've heard the end users (aka the otrs agents that use the wiki) haven't even been really asked for consensus…
You would have to do without a translation memory if the content is private.
Eh, I'd rather see OTRS pick up VisualEditor (which is incompatible with the Translate extension...) than the Translate extension. It's a bit of a rough user experience. However the Translate extension _is_ supported on the cluster and if the OTRS admins want it (after consulting with the relevant stakeholders), it's fine to enable there.

This happens to be MediaWiki configuration related to OTRS rather than OTRS configuration related to Wikimedia, so this goes into "Site requests" with the "shell" keyword.
Yes, it would be useful for providing documentation pages (like Help: space) in other languages for agents.
(In reply to Keegan Peterzell from comment #0)
> wiki to facilitate translating messaging. Thanks!

For such a small wiki, Do you really want it? It does complicate the subpage management workflow for some simple functions.
Maggie Dennis on bug 50645:
> I'm not sure if this is the same issue, but as reported on English Wikipedia
> and tested by myself, using the image resizer to "Make full size" resulted in
> either a notice that no change had been made or a silent failure to save.
> 
> This was tested on FF26, W7 and Chrome 32.0.1700.107 m, W7. 
> 
> The reporting editor concludes that "These new settings, for what they are
> worth, only work if the image already has a size indication (200px,
> 250px*250px, whatever), not when it only has a 'thumb' indication. Sadly, the
> latter is the default and by far most common situation."
> 
> He also questions the purpose of "Make full size", but I'll report that
> separately. 
> 
> See:
> https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/
> Feedback&oldid=595141503#Advanced_image_settings.
> 3F_More_VisualEditor_rubbish.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 112942 had a related patch set uploaded by Jforrester:
Update image size properly when size is default

https://gerrit.wikimedia.org/r/112942
In an effort to allow the legal and lca team to work directly on a wiki more often (including for legally sensitive work) and to move away from google docs and the like as much as possible we would like to set up a private wiki for the team.

In general Ombudsmanwiki would be a good wiki to copy settings from but for the ones I can think of off the top of my head:

Wiki domain should be legalwiki.wikimedia.org.
Language should be English.
Logo can be $stdlogo.
Favicon can be wmf.ico
Canonical server should be https (forced should be on).
Account creation should be bureaucrat only (not sysop).
Transwiki destinations of office, collab and meta would be helpful. (Not sure if private wikis can be tw destinations though... if not that's fine.
wmgUseDisableAccount should be true

I can be the original sysop/crat.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
All done here methinks! Enjoy your new wiki.
Change 117377 merged by jenkins-bot:
Add logo for legalteamwiki

https://gerrit.wikimedia.org/r/117377
Change 117377 had a related patch set uploaded by Jalexander:
Add logo for legalteamwiki

https://gerrit.wikimedia.org/r/117377
(In reply to Sam Reed (reedy) from comment #21)
> (In reply to Sam Reed (reedy) from comment #20)
> > Does $stdlogo work on other privte wikis?
> > https://upload.wikimedia.org/wikipedia/legalteam/b/bc/Wiki.png 404s
> 
> Because it won't have been uploaded yet... Duh.

Yup, but you are indeed correct, it doesn't work for private wikis because it puts it into a different (private) file url scheme which you have to be logged in to use. I'm uploading a config patch with the logo.
(In reply to Sam Reed (reedy) from comment #20)
> Does $stdlogo work on other privte wikis?
> https://upload.wikimedia.org/wikipedia/legalteam/b/bc/Wiki.png 404s

Because it won't have been uploaded yet... Duh.
This is mostly done now...

Does $stdlogo work on other privte wikis? https://upload.wikimedia.org/wikipedia/legalteam/b/bc/Wiki.png 404s
Change 112717 merged by jenkins-bot:
Enable VisualEditor for legalteamwiki by default

https://gerrit.wikimedia.org/r/112717
Change 112850 merged by jenkins-bot:
Initial setup for legalteamwiki

https://gerrit.wikimedia.org/r/112850
Change 116219 merged by Mark Bergsma:
Apache config for legalteamwiki

https://gerrit.wikimedia.org/r/116219
Change 116220 merged by Mark Bergsma:
DNS setup for legalteamwiki

https://gerrit.wikimedia.org/r/116220
Change 116220 had a related patch set uploaded by Jalexander:
DNS setup for legalteamwiki

https://gerrit.wikimedia.org/r/116220
Change 116219 had a related patch set uploaded by Jalexander:
Apache config for legalteamwiki

https://gerrit.wikimedia.org/r/116219
Change 112716 merged by jenkins-bot:
Add support for new private legalteamwiki

https://gerrit.wikimedia.org/r/112716
Change 112850 had a related patch set uploaded by TTO:
Initial setup for legalteamwiki

https://gerrit.wikimedia.org/r/112850
(In reply to comment #10)
> I note that ombudsmenwiki assigns no rights to the autoconfirmed and
> confirmed
> groups (except OAuth and transcode rights). Is this required for
> legalteamwiki?

hmm, no, I just saw that... not entirely sure why that was done but it would be best to still allow the normal options on legalteamwiki. I don't anticipate semi protection being a thing on the wiki obviously but no reason to turn something off (especially upload) without reason.
I note that ombudsmenwiki assigns no rights to the autoconfirmed and confirmed groups (except OAuth and transcode rights). Is this required for legalteamwiki?
> How about legalteam.wikimedia.org? Using the name legalwiki.wikimedia.org
> could
> be confusing, as wiki internal names are by convention formed by taking the
> subdomain and adding "wiki".

> I also disagree with 'legalwiki.wikimedia.org', especially if you see the
> potential of using legal.wikimedia.org in the future (which would probably
> be a
> wiki too, the difference between the two then actually being access controls
> -
> and obviously content).

I'm fine with legalteam if we prefer, I don't really care I just want it to make sense and get done :).
I also disagree with 'legalwiki.wikimedia.org', especially if you see the potential of using legal.wikimedia.org in the future (which would probably be a wiki too, the difference between the two then actually being access controls - and obviously content).
(In reply to comment #5)
> (In reply to comment #1)
> > Why not legal.wikimedia.org?
> 
> To keep legal.wikimedia free incase it's wanted for something broader and
> more
> open then a confidential wiki.

How about legalteam.wikimedia.org? Using the name legalwiki.wikimedia.org could be confusing, as wiki internal names are by convention formed by taking the subdomain and adding "wiki".
(In reply to comment #0)
> Transwiki destinations of office, collab and meta would be helpful. (Not sure
> if private wikis can be tw destinations though... if not that's fine.

I don't know that either but would guess that not. Even if, you'd have the problem that any sysop on the target wiki could then make guesses which pages exist on the private wiki and try to import them.
(In reply to comment #1)
> (In reply to comment #0)
> 
> > Wiki domain should be legalwiki.wikimedia.org.
> 
> Why not legal.wikimedia.org?

To keep legal.wikimedia free incase it's wanted for something broader and more open then a confidential wiki.
Above patches will allow VisualEditor support; it needs to be created first, however (obviously).
Change 112717 had a related patch set uploaded by Jforrester:
Enable VisualEditor for legalwiki by default

https://gerrit.wikimedia.org/r/112717
Change 112716 had a related patch set uploaded by Jforrester:
Add support for new private legalwiki

https://gerrit.wikimedia.org/r/112716
(In reply to comment #0)

> Wiki domain should be legalwiki.wikimedia.org.

Why not legal.wikimedia.org?
Per e-mail request

Consensus: https://fr.wikiversity.org/wiki/Projet:Wikiversit%C3%A9/Editeur_Visuel

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
This is now done.
Change 112582 had a related patch set uploaded by Jforrester:
Enable VisualEditor in opt-in mode for French Wiktionary

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

Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Go to Media Settings>Advanced Settings for the image
4.Select the value "None" under the postion 

Observed Result:
Selecting "None" as position in Media Settings>Advanced Settings shifts the image to the right of the page

See the screenshot attached.
Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5 
Page:http://en.wikipedia.beta.wmflabs.org/wiki/10thFeb

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

**Attached**: {F13027}
Think this is OK now?
When I try this in betalabs, the image shifts to the left of the page when I select "None", as expected.

There is, however, another bug where the image doesn't have an *initial* position visible in the editor. That is fixed in the upcoming commit that I mentioned above.
I can't manage to replicate this bug in master. "None" shifts the image to the left in an English wiki, and right in an RTL wiki (Hebrew on my local machine)

That said, this fix changes the behavior of the position widget. I tested it under that commit as well and couldn't replicate in both Chrome and Firefox.

https://gerrit.wikimedia.org/r/#/c/112041/
After that , Selecting Right moves the image to the left
'Cos we do most of the others.

--------------------------
**Version**: unspecified
**Severity**: minor
Change 133037 merged by jenkins-bot:
Allow VisualEditor users to set if a page whether a Disambiguation

https://gerrit.wikimedia.org/r/133037
Change 130328 merged by jenkins-bot:
Allow extensions to add extra meta item checkboxes to the page settings dialog

https://gerrit.wikimedia.org/r/130328
Change 133037 had a related patch set uploaded by Alex Monk:
Allow VE users to set whether a page is for Disambiguation or not

https://gerrit.wikimedia.org/r/133037
Change 130328 had a related patch set uploaded by Alex Monk:
Allow users to set whether a page is for Disambiguation or not

https://gerrit.wikimedia.org/r/130328
I guess we could query action=paraminfo&querymodules=querypage and look for "DisambiguationPages" in data.paraminfo.querymodules[0].parameters[0].type

Would prefer not to though. Might have to pass whether or not Disambiguation is there via paction=parse (ugh)
Looks like we need to try to detect the Disambiguation extension somehow...
Appears towards the end of the page

Steps to reproduce:


1.Open a page with VE
2.Select a text in such way that it selects the whole line
3.Now open the link inspector

Observed Result:

Sometimes the link inspector appears in a broken way and sometimes it appears little below the text towards the end of the page

See the screenshot attached.

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

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

**Attached**: {F12833}
On discussion, we'll leave this as is.
Created attachment 15640
12thjune

The broken UI issue seems like got fixed, but if a gallery follows a line and I select the whole line and try to open the link inspector , it still opens at the end of the page after the gallery.
See the recent screesnhot attached:12thjune

**Attached**: {F12836}
I think that we fixed this recently, though I can't pin it down.
Created attachment 14528
Broken UI

**Attached**: {F12835}
Screenshot

steps to reproduce:

1.Open a page with VE
2.Go to Insert>Gallery 
3.Insert a gallery

Observed Result:
The newly inserted gallery is not highlighted but the gallery inspector icon is appearing at the corner of the page which is not consistent with the behavior observed with other link inspectors like Math/Hiero

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

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

**Attached**: {F12822}
mwGallery is not in the insert menu anymore, but testing locally they do appear to highlight correctly if they are re-enabled.
Actually, every time when I try to select the newly inserted gallery , it seems its not selecting it as it does not get highlighted like the usual selection behavior, however the gallery inserter icon appears at the far right end.
Steps to reproduce:

1.Open a page with VE which contains an image

2.Open the media settings for the image

3.Go to the advanced settings page

4.Now switch the browser tab or window and then again switch back


Observed Result:

The tab in Media Settings got switched to General Settings from Advanced Settings.

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
yeah! Not reproducible anymore at my end as well.
Rummana?
I can't reproduce this in Chrome on my local wiki. Rummana, can you still reproduce this issue?
As noted in bug 61226, I can't reproduce this in Firefox.  

I can reproduce it at the English Wikipedia, not only at Beta Labs.
*** Bug 61226 has been marked as a duplicate of this bug. ***
Steps to reproduce:

1.Open the page in VE
2.Insert an image
3.Go to Media Settings>Advanced Settings
4.Now delete the first digit of the size.For example:if you have size :600*450
Just attempt to make it 500*450

Observed Result:
The Width and the Height both values turned into 0.User have to again type the input of Height value which he might not wanted to change.


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

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

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

https://gerrit.wikimedia.org/r/115939
I'm working on trying to get default size to work. There are several technical problems I am trying to sort through now, but once those are solved, we'll be able to have more options with default size, like a 'default' button and reverting to default on 0 value.
What about making any "0" immediately become the wiki's default size?  

Right now, there's no way to remove a size and return to unspecified default (see bug 50379).
The problem is that the size widget constantly adjusts both values numerically, so value "00" in the width is read as the number '0', which actively changes the value in the height input (to 0). 

Now, since a change occurred in height, that triggers an automatic change to width, which brings it down to the number 0.

We can fix this by not triggering the adjustment on keypress but rather when you leave the input (so, onChange event) but that has several other issues it may raise. For instance, what happens if I changed a width without moving away from the input (technically no 'change' input event) and then clicked the "Apply" button? The corresponding dimension didn't get updated, and while the 'change' event will trigger when I click the button (because the input loses focus) it will be too late to notify the user of a changed dimension.

I am not sure how this can be fixed without removing the functionality of updating both dimensions simultaneously. We should discuss this further.
If the size is "400" and you delete the first character (4), it becomes "00", which instantly becomes "0". Undoing this restores the 4… so it becomes "40" (and there's nothing left on the browser undo stack).

Maybe if you change the value such that it doesn't make sense, rather than cleaning up "00" or "0" and then complaining, we should just blank the field?
Cannot replicate in master.

Changing the size in either width or height (by deleting or changing the first digit or typing from scratch) changes the corresponding input.

Example:

- Inserted an image with initial size 182x150
- Media settings -> Advanced settings, deleted '1' to result in width: 82
- Result: Height adjusted to 68 (Expected)
- Marked the first digit in Width (8) and changed to 9
- Result: Height adjusted to 76

This works for me in both Chrome and Firefox.

Am I missing any details to replicate?
Created attachment 14524
Screenshot

**Attached**: {F12816}
Intention:
Add a link to a template using {{tl}} on English Wikipedia.

Steps to Reproduce:
1.  Add Template:Tl.
2.  Add any template name, and press return afterwards (so that the parameter field is name+return)
3.  Apply changes.

Expected Results: No newline is inserted.

Actual Results:  
The template is broken because the parameter can't support the inclusion of a return.
`modules/ve-mw/ui/pages/ve.ui.MWParameterPage.js` actually has `// TODO: Use spec.type` :) (should be `getParameterType()`, rather).
This is now being done for named parameters per T52439, which do not preserve whitespace. However, it must not be done for positional parameters (like in {{tl}}) per T53484, because these do actually preserve whitespace.

Like Krenair says, VE shouldn't use multiline text inputs for single-line parameters, like this one (I just fixed the templatedata on en.wp). Let's rephrase the bug.
I wonder if this parameter should be marked with TemplateData type "line" and VE should enforce this in the input.
If it's not desirable to always strip returns (or spaces) from the end of parameters, then perhaps we should be able to specify in TemplateData how they should be handled.
Intention:
Add more information to an infobox.

Steps to Reproduce:
1. Open the infobox.

2. Add a parameter with a link to a disambiguated page name.

3. Use the pipe trick to label the link: [[Wooden spoon (award)|]]

4.  Apply changes.

Actual Results:  
In VisualEditor, the template displays raw wikitext for that item:   [[Wooden spoon (award)|]] 

Expected Results:  
That VisualEditor would display the same blue link with the same link label as the page will when it is saved ("Wooden spoon")

Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=User:Whatamidoing_(WMF)/sandbox&diff=594279537&oldid=593922721
Change 112829 merged by jenkins-bot:
Pass 'pst' as true in parse request for fragments

https://gerrit.wikimedia.org/r/112829
Change 112829 had a related patch set uploaded by Jforrester:
Pass 'pst' as true in parse request for fragments

https://gerrit.wikimedia.org/r/112829
This looks like we're passing the wrong flag to action=parse; will try to fix this myself.
CTRL/CMD+B for bolding highlighted text
CTRL/CMD+I for italicising highlighted text
CTRL/CMD+U for underline highlighted text

CTRL+1,2,3 for H1,H2, H3, etc

CTRL/CMD+K for linking highlighted text

--------------------------
**Version**: master
**Severity**: enhancement
I'm not sure which of these is most uptodate, but... here are some known knowns.

    https://www.mediawiki.org/wiki/Manual:Interface/Access_keys

    https://meta.wikimedia.org/wiki/Help:Keyboard_shortcuts

    https://en.wikipedia.org/wiki/Wikipedia:Keyboard_shortcuts

    https://www.mediawiki.org/wiki/VisualEditor/Portal/Keyboard_shortcuts
Moving to WikiEditor; we're probably going to kill the difference between the two, but for now…
Screenshot

Steps to reproduce:

1.Open the page with VE
2.Add a text with reference
3.Add an image
4.Go to Media Settings for the image
5.Go to Insert>Reference

Observed Result:
Observe that, the "Use an existing reference " button remains disabled even if there is a reference added in the page


See the screenshot attached

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

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

**Attached**: {F13113}
>>! In T62919#3709391, @Deskana wrote:
> This specific problem doesn't happen any more, although there is some really weird UI stuff going on...
> 
> {F10426560}

Actually this issue is still happening. It was about "Use an existing reference" button  inside Media Settings>Cite> Basic reference dialog remaining disabled. 

Updated screenshots:

{F10521929}
>>! In T62919#3709391, @Deskana wrote:
> This specific problem doesn't happen any more, although there is some really weird UI stuff going on...

For posterity, the weird UI stuff is filed as {T178986}.
This specific problem doesn't happen any more, although there is some really weird UI stuff going on...

{F10426560}
This is blocked by bug 47344, the infamous sub-documents bug.
(In reply to Ed Sanders from comment #1)
> Looks like we aren't copying over the internalList object from the parent dm
> document.

Does that explain bug 58322 or bug 71214?
Looks like we aren't copying over the internalList object from the parent dm document.
Please enable VisualEditor also in the "Projekt" namespace on the wmse chapters wiki.

Please note that this is not the same as the NS_PROJECT/Wikimedia
namespace.

Poll/request at: https://se.wikimedia.org/wiki/Tr%C3%A5d:Wikimedia:Bybrunnen/VisualEditor_p%C3%A5_Projekt:-sidorna

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
Merged & deployed by Reedy (thank you!).
Change 113141 merged by jenkins-bot:
Enable VisualEditor for Projekt: NS on sewikimedia

https://gerrit.wikimedia.org/r/113141
Change 113141 had a related patch set uploaded by Odder:
Enable VisualEditor for Projekt: NS on sewikimedia

https://gerrit.wikimedia.org/r/113141
Discussion: {T196314}

Deliverables:
* API module to allow apps to set global value for a preference.

See also:
* {T197259}
* {T197260}
**Author:** `jhall`

**Description:**
While developing a browser test for bug 60797, I've noticed that some production wikis where VisualEditor is expected to be available do not load VE as expected.  In each case, the error message captured at the browser level is (with some variation in the specific line numbers referenced):


[Error] Error: JavaScript parse error: Parse error: Missing operand in file 'MediaWiki:Common.js' on line 125
	global code (load.php, line 1)



Repro steps:

1) Visit a production wiki where VE is expected to be available, and request a random article with a VE edit param: http://cv.wikipedia.org/wiki/Special:Random?veaction=edit

2) In browser error console, note JavaScript error mentioned above, and note also that the VE editing surface simply never loads (although it appears to keep trying!)


I'll add list(s) of production wikis where this problem occurs as I uncover them in comments on this bug ticket.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60797
Change 127373 merged by jenkins-bot:
[Browser tests] Updated list of production wikis to check

https://gerrit.wikimedia.org/r/127373
Change 127373 had a related patch set uploaded by Jforrester:
[Browser tests] Updated list of production wikis to check

https://gerrit.wikimedia.org/r/127373
Updated current list of failures:

http://bpy.wikipedia.org
http://cv.wikipedia.org
http://mzn.wikipedia.org
http://new.wikipedia.org

I have fixed:

> http://af.wikipedia.org
> http://am.wikipedia.org
> http://kaa.wikipedia.org
> http://ln.wikipedia.org
> http://szl.wikipedia.org
**jhall** wrote:

Found one more, so here's a consolidated list of "broken" wikis identified so far:

http://af.wikipedia.org
http://am.wikipedia.org
http://bpy.wikipedia.org
http://cv.wikipedia.org
http://kaa.wikipedia.org
http://ln.wikipedia.org
http://mzn.wikipedia.org
http://new.wikipedia.org
http://szl.wikipedia.org
**jhall** wrote:

Some more wikis with the same problem:

http://kaa.wikipedia.org
http://ln.wikipedia.org
http://mzn.wikipedia.org
http://new.wikipedia.org
http://szl.wikipedia.org
**jhall** wrote:

Wikis where this problem has been seen:

http://af.wikipedia.org
http://bpy.wikipedia.org
http://cv.wikipedia.org
Intention:
Add a special character from the built-in Mac OS character inserter.

Steps to Reproduce:
1. Using Safari, open a page in VisualEditor.

2. In Safari's menu bar, choose Edit > Special Characters...

3. Double-click on special characters to add them.

Actual Results:  
The special characters display on the screen, but are not present when you try to save the text.  Characters that were typed from the keyboard are saved.  No characters (even if they are 'normal' ones) are saved if they were added with the character inserter.


Reproducible: Always

It works in Firefox 26.  It does not work in Safari 6.  I haven't tested Chrome.

--------------------------
**Version**: unspecified
**Severity**: normal
This is now working, presumably through the same fix that fixed {T61748}.
Confirmed in Safari 8.0 in VE master as of now; almost certainly the same issue as {T61748} and {T63884}.
Created attachment 14484
The red oval on the far left shows the three characters (one normal 'r' and two fancier ones) added with the OS's special character inserter.  These should appear in the Review Changes diff, but don't

**Attached**: {F12931}
Screenshot of the error

Steps to reproduce:

1.Open a page with VE
2.Add an image in the page
3.Open the Media Settings for that image
4.Insert another image inside it.
5.Apply Changes
6.Save the page
7.Reopen the page again
8.Open the media settings again for the image on the page


Observed Result:
VE stops reposnding.Cannot cross out the dialog box."Apply Changes" does not close the dialog box.
An error appears in the console
Error: Offset could not be translated to a DOM element and offset: 22
	

(297 out of range 182)

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

See the screenshot attached,

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

**Attached**: {F12818}
Verified the fix in production:https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/sandbox?veaction=edit
Change 111695 merged by jenkins-bot:
Make globalOverlay really global

https://gerrit.wikimedia.org/r/111695
Verified the fix in Betalabs
Change 111695 had a related patch set uploaded by Catrope:
Make globalOverlay really global

https://gerrit.wikimedia.org/r/111695
Change 111694 abandoned by Catrope:
Make globalOverlay really global

Reason:
Wrong branch

https://gerrit.wikimedia.org/r/111694
Change 111694 had a related patch set uploaded by Catrope:
Make globalOverlay really global

https://gerrit.wikimedia.org/r/111694
Change 111690 merged by jenkins-bot:
Make globalOverlay really global

https://gerrit.wikimedia.org/r/111690
Change 111690 had a related patch set uploaded by Catrope:
Make globalOverlay really global

https://gerrit.wikimedia.org/r/111690
This error also appears when you delete the reflist that contains a reference which has image inside:

Error: Offset could not be translated to a DOM element and offset: 31
	

(297 out of range 182)
Screenshot

Steps to reproduce:


1.Open a page with VE
2.Insert an image and a reference
3.Open the Media Settings for the image and include another image
4.Click on the Media Settings icon on the second image that you just inserted
OR
5.Open the reference dialog box
6.Add an image inside
7.Click on the Media Settings icon on the image you just inserted

Observed Result:
In both cases after step 4 and step 7, Media Settings dialog box does not open up
In the console following error appears:
NS_ERROR_NOT_AVAILABLE:
	

...w Date()).getTime();}});jQuery.ready.promise=function(obj){if(!readyList){readyL...

load.p...034436Z (line 11)

See the screenshot attached

**This is happening in FireFox only** 


Test Environment: https://test2.wikipedia.org/
Browser:  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**: {F13424}
Verified the fix in production:https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/sandbox?veaction=edit
Change 111695 merged by jenkins-bot:
Make globalOverlay really global

https://gerrit.wikimedia.org/r/111695
Verified the fix in Betalabs
Change 111695 had a related patch set uploaded by Catrope:
Make globalOverlay really global

https://gerrit.wikimedia.org/r/111695
Change 111694 abandoned by Catrope:
Make globalOverlay really global

Reason:
Wrong branch

https://gerrit.wikimedia.org/r/111694
Change 111694 had a related patch set uploaded by Catrope:
Make globalOverlay really global

https://gerrit.wikimedia.org/r/111694
Change 111690 merged by jenkins-bot:
Make globalOverlay really global

https://gerrit.wikimedia.org/r/111690
Change 111690 had a related patch set uploaded by Catrope:
Make globalOverlay really global

https://gerrit.wikimedia.org/r/111690
screenshot of empty gallery in edit mode

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Gallery
3.Just close the inspector

Observed Result:
An empty gallery inspector is getting added in the page


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=31st_january&veaction=edit

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

**Attached**: {F13379}
Verified the fix on test2
Verified the fix in Betalabs
*** Bug 60914 has been marked as a duplicate of this bug. ***
Fixed in gerrit 111178.
Created attachment 14456
Screenshot in edit source mode

**Attached**: {F13380}
Firefox also supports CSS3 animations and transitions, see how it can be done: http://tympanus.net/Development/ModalWindowEffects/

--------------------------
**Version**: unspecified
**Severity**: minor
Now everything has the same appearance like in Chrome, so well done!
(In reply to Andre Klapper from comment #4)
> Hello! Nobody yet, obviously. 
> If this functionality is important to you, providing patches speeds up
> getting this implemented. See https://www.mediawiki.org/wiki/Developer_access

Thanks Andre!
Hello! Nobody yet, obviously. 
If this functionality is important to you, providing patches speeds up getting this implemented. See https://www.mediawiki.org/wiki/Developer_access
Hello? Nobody?
Dialog animations have been already implemented(!) and work in Chrome, only!
Could someone create some CSS love for Firefox as well?
(In reply to comment #1)
> Why should VE "support" this? I am missing a usecase / user story here so
> far.

This animation is supported in Google Chrome/Chromium, just open this dialog in this browser and see. Same effect can be done in Firefox as well. VE has this animation already implemented!
Why should VE "support" this? I am missing a usecase / user story here so far.
For wikis with FlaggedRevs extension: After saving a page the notice on top of page "1 change in this version is pending review ..." is not shown.

I guess due to not reloading the whole page.

This is a bad experience for every editor w/o reviewer right. No chance to spot that the new revision has to be sighted first.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 172746 merged by jenkins-bot:
When saving, return the full contentSub to the client

https://gerrit.wikimedia.org/r/172746
(It's slightly less horrible now. But only slightly.)
Change 172746 had a related patch set uploaded by Alex Monk:
When saving, return the full contentSub to the client

https://gerrit.wikimedia.org/r/172746
I came up with some terrible code that successfully achieves this yesterday.
I took a look into this today... Seems that the review notice is not being made available even as part of the page subtitle to VE.
Screenshot attached

Steps to reproduce:

1.Open a page with VE
2.Add any image 
3.Go to Media Settings>Advanced Settings
4.Say for example the original dimension of the image is  150x150
5.Change the values in such way that it exceeds the original size for example: 300x300

Observed Result:
Apply Changes button remains active even though "Size values are invalid " appears in the dialog box.

See the screenshot attached.

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 
OS: MAC OS X 10. 8. 5 
Sample Page:http://en.wikipedia.beta.wmflabs.org/wiki/29th_January?veaction=edit

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

**Attached**: {F12971}
I think this can be best "fixed" by altering the design and copy so that it's clear that invalid changes won't be put into effect.
The problem in my opinion with #2 is that if a user spent time working on new settings (caption / alternate text / position etc) we force them to deal with size before applying the rest. In general I think that might be less convenient in the long run.

I think the better approach (giving the user more leeway) is to alert the user that the parameter is wrong and won't be applied, save everything else, and allow the user to go back in and deal with the size widget specifically if they want to (or decide they don't want to deal with numerical values and resize with the mouse)

I think that while it's less like "others" are doing, this might give the user more leeway when fixing and working on stuff. Instead of forcing the user to deal with a problem they might just want to undo, we let the user save everything else and choose if they want to go back to retrying the size specifically.
> I am leaning towards #1, but we should discuss and see if we want to apply
> #2.
Wont #2 be more obvious ?
This is actually intended behavior, but one that's not clearly explained; if the size parameters are invalid, the media edit dialog will apply all other changes except for size (so to allow other changes like image type, alternate text, etc)

There are two ways to solve this bug imho:

1. Adjust the message to "Size values are invalid and will not be applied."

2. Make the 'apply' button inactive if size is invalid, forcing the user to find valid parameters or cancel -- but this will also mean that if other changes were made in the dialog, and the user doesn't know or want to change the size after seeing it is invalid (or wants to revert to the previous dimensions) we force them to cancel *all* changes and redo them again.

I am leaning towards #1, but we should discuss and see if we want to apply #2.
Ex. #1, https://fr.wikipedia.org/w/index.php?title=%C3%89conomie_de_la_France&diff=100357906&oldid=100354236 , the </small> tag vanishes (the user said he fixed the spaces and removed a link);
ex. #2, https://fr.wikipedia.org/w/index.php?title=Utilisateur:NemesisIII/Brouillon&diff=100052444&oldid=99902909 , the </code> tag misses the less-than sign (the user had just added a link);
ex. #3, https://fr.wikipedia.org/w/index.php?title=Utilisateur:NemesisIII/Brouillon&diff=99902829&oldid=99228289 the same thing happens (the user just deleted a template).
Some curly brackets went missing as well.
I think this has been long-since fixed.
**Author:** `jhall`

**Description:**
Follow-up to a pairing session between Jeff and Željko on 1/29/2013.  In order to make headless browser testing available in as many WMF repositories as possible, we should add headless support[1] to the env.rb and hooks.rb setup in the mediawiki-selenium Rubygem[2].


[1] http://watirwebdriver.com/headless/
[2] https://git.wikimedia.org/tree/mediawiki%2Fselenium/ef67a1f40db97a7e0b456fcc3fbf20c6a8ec4e81/lib%2Fmediawiki%2Fselenium

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
But then he introduced the same thing in https://gerrit.wikimedia.org/r/#/c/110606 :)
Zeljko are you sure it is fixed ? Jeff reverted https://gerrit.wikimedia.org/r/110390
Change 110390 merged by jenkins-bot:
Make it possible to run VisualEditor tests in headless mode

https://gerrit.wikimedia.org/r/110390
Change 110390 had a related patch set uploaded by Zfilipin:
Make it possible to run VisualEditor tests in headless mode

https://gerrit.wikimedia.org/r/110390
Change 110205 merged by jenkins-bot:
Run browsers headlessly if HEADLESS environment variable is set to true

https://gerrit.wikimedia.org/r/110205
at one point CirrusSearch had this hook.  It's in the README, but I don't see the hook itself any more.
I still have to test this with repositories that have at_exit hook. Looks like only VisualEditor has the hook, and it should probably be moved to the gem.
Change 110335 abandoned by Zfilipin:
WIP run browsers headlessly if HEADLESS environment variable is set to true

https://gerrit.wikimedia.org/r/110335
Change 110335 had a related patch set uploaded by Zfilipin:
WIP run browsers headlessly if HEADLESS environment variable is set to true

https://gerrit.wikimedia.org/r/110335
We had some browser tests running on integration-selenium-driver.pmtpa.wmflabs which is an Ubuntu Precise instance. xvfb package is 2:1.11.4-0ubuntu10.14 

There is apparently no package for ruby gems headless but it is going to be a dependency of mediawiki-selenium apparently ( https://gerrit.wikimedia.org/r/#/c/110205/3/mediawiki-selenium.gemspec,unified )
Change 110205 had a related patch set uploaded by Zfilipin:
WIP run browsers headlessly if HEADLESS environment variable is set to true

https://gerrit.wikimedia.org/r/110205
**jhall** wrote:

Should note that in order to run headless browser tests, the test environment(s) needs to have two additional components installed:

a) Headless Rubygem[1]
b) Xvfb binary for your OS[2]

[1] http://rubygems.org/gems/headless
[2] http://en.wikipedia.org/wiki/Xvfb
Steps to reproduce:

1.Open a page with VE
2.Select a reference note or a text and open the gallery inspector or a Link inspector
3.Close the inspector and go to the next line
4.Again go to Insert>Gallery or Open the link inspector

Observed Result:
The inspector opens up with an animation from left to right

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=66552
Fixed in gerrit 139550.
This also happens when working with a list of links.

1. Have a page with a list containing a list item with a link.
2. Put cursor at end of list item (thus triggering the context menu).
3. Press return (creating a new list item)
4. Insert link.

The link inspector animates in an odd way from the left of the screen.

Can also be seen at the beginning of this (otherwise unrelated) recording for another bug. http://cl.ly/3s460Q442L3S
This is still happening
This looks like it's now fixed.
Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: Chrome Version 26.0.1410.65 & FF
OS: MAC OS X 10. 8. 5
Screenshot of the bug

The diff in the save dialog isn't being styled correctly, which causes highlighted text to overlap with text above it. Timo tells me that this is due to a missing line-height style.

This is exacerbated by bug 60494. which causes the save dialog to be narrower than it should be, which means lines wrap more often and highlighted text more frequently has text directly above it.

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

**Attached**: {F13394}
*** Bug 57300 has been marked as a duplicate of this bug. ***
This has been fixed, AFAICT.
So I think we just need to apply line-height: 1.6px to the body of the frame like MW core does for #bodyContent, .mw-body-content (but I don't think we should use those here as they apply some other changes which don't look right e.g. font-size: 0.875em)
When adding a special character via the new tool,
this will not retain styles applied to what was being typed; that is,
it will not appear for example in bold or italics.

--------------------------
**Version**: unspecified
**Severity**: minor
Change 157703 merged by jenkins-bot:
Annotate inserted special characters

https://gerrit.wikimedia.org/r/157703
Change 157703 had a related patch set uploaded by Jforrester:
Annotate inserted special characters

https://gerrit.wikimedia.org/r/157703
*** Bug 70265 has been marked as a duplicate of this bug. ***
*** Bug 65497 has been marked as a duplicate of this bug. ***
Screenshot attached

Steps to reproduce:


1.Open a page with VE 
2.Go to Insert>Transclusion
3.Search for the template Cite Web
4.Observe that the required parameters are now marked with * symbol
5.Delete the required parameters

Observed Result:

The required parameters gets deleted

See the screenshot attached.

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

**Attached**: {F13028}
Verified the fix in production
This kind of relationship between parameters was requested on bug 50407.
(In reply to Helder from comment #8)
> (In reply to James Forrester from comment #6)
> > (In reply to Ricordisamoa from comment #5)
> > > or a set of fields may be mutually exclusive (and yet one of them would
> > > be required).
> > 
> > That doesn't make sense. "Required" means "the template will die horribly if
> > you don't include this". It is *not* a "we'd like you to fill this in" –
> > that's what "suggested" is for. Most templates will have no 'required'
> > fields.
> 
> It seems perfectly valid for a template to require that "either A or B be
> provided" and the user should be able to delete one of them if it is not
> needed.

This feels like a pretty edge case (and suggests that we should consider whether the template should be re-written to be less anti-human); maybe file a TemplateData bug to ask for a way to express this relationship?
(In reply to Ricordisamoa from comment #5)
> ...a set of fields
> may be mutually exclusive (and yet one of them would be required).

(In reply to James Forrester from comment #6)
> > or a set of fields may be mutually exclusive (and yet one of them would
> > be required).
> 
> That doesn't make sense. "Required" means "the template will die horribly if
> you don't include this". It is *not* a "we'd like you to fill this in" –
> that's what "suggested" is for. Most templates will have no 'required'
> fields.

It seems perfectly valid for a template to require that "either A or B be provided" and the user should be able to delete one of them if it is not needed.
(In reply to James Forrester from comment #6)
> The wikitext editor lets you do lots of things that are stupid.

I do 'stupid' things all the time.
Now I understand that VE will always be a toy for newbies, and never a valid replacement for the wikitext editor.
(In reply to Ricordisamoa from comment #5)
> VisualEditor should only make edits easier,

I agree.

> not restrict the users' capabilities.

I think this is a false dichotomy.

> As long as the wikitext editor allows removing required fields from
> templates (and it should, indeed), VE should too.

The wikitext editor lets you do lots of things that are stupid. VisualEditor's job is to make it easy to make good content, not easy to make broken pages. :-)

> Sometimes the TemplateData information may be incorrect, 

Then the TemplateData should be fixed.

> or a set of fields may be mutually exclusive (and yet one of them would
> be required).

That doesn't make sense. "Required" means "the template will die horribly if you don't include this". It is *not* a "we'd like you to fill this in" – that's what "suggested" is for. Most templates will have no 'required' fields.

> Sometimes a user may want to remove a wrong value, and a template may
> show a warning for missing arguments (always better than wrong data).

If the template outputs an error, that's probably a required parameter.

> Instead, a warning should be shown when a required parameter is going to be
> removed.

I disagree, for the reasons above.
VisualEditor should only make edits easier, not restrict the users' capabilities.
As long as the wikitext editor allows removing required fields from templates (and it should, indeed), VE should too.
Sometimes the TemplateData information may be incorrect, or a set of fields may be mutually exclusive (and yet one of them would be required). Sometimes a user may want to remove a wrong value, and a template may show a warning for missing arguments (always better than wrong data).
Instead, a warning should be shown when a required parameter is going to be removed.
Verified the fix in test2
Verified the fix in Betalabs
Change 154133 merged by jenkins-bot:
Remove delete button from required parameters in template dialog

https://gerrit.wikimedia.org/r/154133
Change 154133 had a related patch set uploaded by Alex Monk:
Don't add delete button to required parameters in template dialog

https://gerrit.wikimedia.org/r/154133
**Author:** `jhall`

**Description:**
The time has come to create additional VisualEditor browser tests for accessing VE via the Mobile interface.

James F had great feedback on which repo (MobilefrontEnd vs. VisualEditor) these tests belong in:

"​One way of looking at it is on the blocking model. If (when!) these tests were to block merge, which repo's changes should they be triggered by? In this case, I think there's a case for some basic browser tests for VE-on-Mobile to be in VisualEditor (specifically, in the MediaWiki VisualEditor repo) with the major tests be in MobileFrontend."

An example URL for accessing VE via Mobile UI is: [1]


[1] http://en.m.wikipedia.beta.wmflabs.org/wiki/0.04730373828804457?mobileaction=alpha#editor/0

--------------------------
**Version**: unspecified
**Severity**: enhancement
In the Triage meeting we felt that this wasn't a clear enough ask for Q4.
So.. MobileFrontend has some basic ones [1]. I wonder if we should have a dedicated extension for MobileFrontendVETests that depends on MobileFrontend and VisualEditor? It seems silly having two (might even be worth breaking out MobileFrontendVE into its own extension?)

[1] e.g. https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/440/testReport/(root)/VisualEditor%20Mobile/I_can_edit_a_page_using_VisualEditor/
>>! In T62290#967236, @Cmcmahon wrote:
> I'll take this on. Having refactored both MF and VE at the end of 2014, both repos are in good shape to support new feature coverage.

Awesome. :-)
I'll take this on. Having refactored both MF and VE at the end of 2014, both repos are in good shape to support new feature coverage.
Change 108987 abandoned by Jforrester:
[Browser test] WIP New test(s) for editing with VisualEditor via mobile user interface.

Reason:
Not currently being worked on AFAICT.

https://gerrit.wikimedia.org/r/108987
**jhall** wrote:

Setting status back to ASSIGNED since Gerrit is a little over-eager to mark even WIP patch sets as being ready for review!
Change 108987 had a related patch set uploaded by Jhall:
[Browser test] WIP New test(s) for editing with VisualEditor via mobile user interface.

https://gerrit.wikimedia.org/r/108987
Daniel on Mediawiki.org says they use strikethrough a lot and would like a shortcut for it.
Verified the fix in production
Verified the fix in Betalabs and test2
Re-fixed.
We need to change the shortcut key for code annotation on mac from "cmd+shift+3".Because,its a shortcut to take screenshot so it does not work there.
Change 160174 merged by jenkins-bot:
Add keyboard shortcuts for strikethrough and code annotations

https://gerrit.wikimedia.org/r/160174
Change 160174 had a related patch set uploaded by Jforrester:
Add keyboard shortcuts for strikethrough and code annotations

https://gerrit.wikimedia.org/r/160174
I added your comment to Mediawiki.org. 
I think I noticed that the numbers 8 and 9 are still available?
Or at least this is what I read in the new keyboard shortcuts list.
(Which, BTW, is not available for me by its shortcut, since / is located on the numeric pad or above number 7, thus won't work).
Sure. But what short-cut? Remember that it needs to:

* not clash with
** any existing VE shortcut,
** any expected VE shortcut for future uses (e.g. edit image/template/table), or
** any OS or browser shortcut (e.g. Ctrl+C for copy, Cmd+Q for quit);
* be available on most users' keyboards;
* be type-able; and
* ideally be the "standard" shortcut.

This doesn't leave many options. :-(
*he uses
[Split from bug 47759 to cover block level items.]

Bug 47759 covers a language inspector to handle <span lang='xx' dir='yyy'>s, but for <div lang='xx' dir='yyy'> blocks and similar (like annotations on <ul>s or <li>s) we'll need a totally different editing concept.

--------------------------
**Version**: unspecified
**Severity**: enhancement
*** Bug 69892 has been marked as a duplicate of this bug. ***
Opt-in state, per community member requesting.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://pt.wikibooks.org/wiki/Tópico:Wikilivros_Discussão:Portal_comunitário/Testes_com_o_Editor_Visual_no_Wikilivros
Thank you James, it's working great now =)
(In reply to comment #20)
> Hi,
> 
> Well, something got through because, though it's still not working, it no
> longer pops up that error message, just quietly hangs while "loading" the VE.
> 
> Is this a different issue? Or just consequence of stuff that went wrong on
> monday? I mean, will it get fixed with the next deployment?

Sorry for the slow response - the issue has now (finally) been fixed. See https://pt.wikiversity.org/w/index.php?namespace=&tagfilter=visualeditor&title=Especial%3AMudan%C3%A7as+recentes for a list of all edits with VisualEditor on Portuguese Wikiversity (just my test one so far).
Hi,

Well, something got through because, though it's still not working, it no longer pops up that error message, just quietly hangs while "loading" the VE.

Is this a different issue? Or just consequence of stuff that went wrong on monday? I mean, will it get fixed with the next deployment?
I'm afraid that the deployment went slightly wrong and this fix did not get merged. Sorry. :-(
Hi, thanks, that's useful information. The workshop is not about wikis (it's a permaculture course promoted by the city, that will use wikiversity for classes), and in fact starts at 21:30, so we can plan to start introducing wiki editing after 22:00 and get a better chance of meeting the fix =) Cheers!
This is scheduled to happen in the hour-long block from 21:00 to 22:00 UTC today (see https://wikitech.wikimedia.org/wiki/Deployments#Week_of_February_3rd row three); it's quite a tricky operation this time around due to other changes, so unfortunately you shouldn't expect it to be available until later in that hour, sorry.
Thank you James,

Any indication this might be shipped by 21:00 UTC today?

[]s
OK, the configuration change has been merged; this should now ship on Monday (Pacific time); sorry for the confusion and disruption. I'll get a more exact time when I know.
Change 110660 merged by jenkins-bot:
Add Wikiversity to site list in ParsoidConfig

https://gerrit.wikimedia.org/r/110660
Change 110660 had a related patch set uploaded by Jforrester:
Add Wikiversity to site list in ParsoidConfig

https://gerrit.wikimedia.org/r/110660
(In reply to comment #11)
> Ni!
> 
> Any idea of whether/when will this get fixed for Wikiversity?
> 
> I am giving a workshop Monday evening and I was really really expecting to be
> able to show people the Visual Editor working on Wikiversity.
> 
> Cheers
> .~´


Sorry, this is because https://gerrit.wikimedia.org/r/#/c/108158/ wasn't merged and deployed, so Parsoid has no idea what Wikiversity is. :-(

Working on getting it fixed now.
Ni!

Any idea of whether/when will this get fixed for Wikiversity?

I am giving a workshop Monday evening and I was really really expecting to be able to show people the Visual Editor working on Wikiversity.

Cheers
.~´
I confirm it is working on Portuguese Wikibooks[1] but not on Portuguese Wikiversity[2].

[1] https://pt.wikibooks.org/wiki/Special:RecentChanges?tagfilter=visualeditor
currently has 3 edits.
[2] https://pt.wikiversity.org/wiki/Álgebra_linear?veaction=edit&uselang=en
shows the message "Error loading data from server: parsoidserver-http-bad-status: 404. Would you like to retry?"
Ni!

It ain't working on pt.wikiversity.

After activating VisualEditor, clicking "Edit" pops up a floaty with this error:

"Erro ao carregar dados do servidor:  parsoidserver-http-bad-status: 404. Gostaria de tentar novamente?"

I guess that freely translates to

"Error loading data from server: parsoidserver-http-bad-status: 404. Would you like to try again?"

Does seem to be working on pt.wikibooks though.
Change 108156 merged by Reedy:
Enable VisualEditor on ptwikibooks, ptwikiversity for testing

https://gerrit.wikimedia.org/r/108156
(In reply to comment #6)
> Community consensus for this is where?

It's enabling a widely-deployed code path as an opt-in beta feature for testing…
Community consensus for this is where?
Change 108158 had a related patch set uploaded by Jforrester:
Add ptwikiversity to interwiki map

https://gerrit.wikimedia.org/r/108158
Yes, this is OK. Thank you!
^^^

Done by that config change; we should be able to get that pushed out w/c 27 January (next week we're in lock-down because people are busy at a conference).

Will this be OK? If there's a major issue, we may need to switch it back off, though this hasn't been a problem so far.
Change 108156 had a related patch set uploaded by Jforrester:
Enable VisualEditor on ptwikibooks, ptwikiversity for testing

https://gerrit.wikimedia.org/r/108156
Ni!

Community member here.

.~´
screenshot

Steps to reproduce:

1.Open VE for a page
2.Now resize the window down
2.Go to Settings>Keyboard shortcuts

Observed Result:
There is no scroll bar in this window therefore cannot see the last line of it as it is getting cut off.

See the screenshot

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

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

**Attached**: {F13257}
Verified the fix in production: https://en.wikipedia.org/wiki/User:RYasmeen_(WMF)/sandbox?veaction=edit
Verified the fix in test2 environment
Verified the fix in Betalabs
Should now be fixed.
Change 116479 merged by jenkins-bot:
Increase keyboard shortcut height hack to work in FF

https://gerrit.wikimedia.org/r/116479
Change 116479 had a related patch set uploaded by Esanders:
Increase keyboard shortcut height hack to work in FF

https://gerrit.wikimedia.org/r/116479
Both the scroll bars:Horizontal and vertical remains active in the same time which seems like moving the whole page instead of scrolling in a specific direction
Change 109483 merged by jenkins-bot:
Fix layout of keyboard shortcuts page

https://gerrit.wikimedia.org/r/109483
Change 109483 had a related patch set uploaded by Esanders:
Fix layout of keyboard shortcuts page

https://gerrit.wikimedia.org/r/109483
Created attachment 14334
screenshot

**Attached**: {F13260}
Once we're happy with it. Currently feature-flagged off.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 157478 merged by jenkins-bot:
Enable TemplateData GUI for all wikis; move config to CommonSettings.php

https://gerrit.wikimedia.org/r/157478
Scheduled for 6 November.
Change 157478 had a related patch set uploaded by Jforrester:
Enable TemplateData GUI for all wikis; move config to CommonSettings.php

https://gerrit.wikimedia.org/r/157478
(In reply to James Forrester from comment #4)
> (In reply to Lokal_Profil from comment #3)
> > What is the current status on deployment to other wikis?
> 
> The GUI is deployed on MediaWiki.org but has had little use; we're working
> on improvements to it, and we'd be interested in feedback. It might be a
> little premature to deploy it to other wikis, but if you've tried it and
> think your community would like it, please do ask.

Mainly asking since VisualEditor is now default on many wikis yet the knowledge on how to prepare the templates is sparse and the understanding of how the json works is even more so.

Would an embedded solution (as on Commons) work better/feel more natural? I.e. a "normal" template for documenting the template which also produces TemplateData behind the scenes.
(In reply to Lokal_Profil from comment #3)
> What is the current status on deployment to other wikis?

The GUI is deployed on MediaWiki.org but has had little use; we're working on improvements to it, and we'd be interested in feedback. It might be a little premature to deploy it to other wikis, but if you've tried it and think your community would like it, please do ask.
What is the current status on deployment to other wikis?
*** Bug 63815 has been marked as a duplicate of this bug. ***
From bug 51734 comment 14:
| Hi, we would like to try the TempalteDataEditor on NL wiki, see
| https://nl.wikipedia.org/wiki/Wikipedia:De_kroeg#Aanzetten_TemplateData-editor_op_nl-wiki

First I think we should deploy it to MediaWiki.org to let people try it out.
The OOjs UI library has a useful demos directory, which shows off each of the widgets available. Similarly, VisualEditor also has a demos directory, and I imagine other projects do (or would if it became an established pattern.

It would be really great if we could somehow expose these alongside their projects' documentation, so we can point people to a living thing rather than telling them to checkout the repo and play. Something like…

https://doc.wikimedia.org/visualeditor/master/
https://doc.wikimedia.org/visualeditor/master/demo/

https://doc.wikimedia.org/visualeditor/v0.1.0/
https://doc.wikimedia.org/visualeditor/v0.1.0/demo/

https://doc.wikimedia.org/oojs-ui/master/
https://doc.wikimedia.org/oojs-ui/master/demos/

https://doc.wikimedia.org/oojs-ui/v1.0.6/
https://doc.wikimedia.org/oojs-ui/v1.0.6/demos/
>>! In T62143#1165994, @Krinkle wrote:
> The main this this is blocked on now is:
> * Setting up a redirect.

Redirect for what?

> * Upstream OOjs UI and VisualEditor need to have their demo-directory be standalone (like docs). So must not reference `../` but instead build and copy relevant files.

For OOUI, {e538462cbd8f7dcf2423a8ee49b8ebd329f10c84} introduces a `npm demos` command to build the standalone demos directory.
Timo worked on generic templates to publish /cover/ directories. It can be reused now to publish the /demos/ directories.
>>! In T62143#1162486, @hashar wrote:
> We should be able to craft a job that triggers doc-publish-sync job with source /demos/ and dest /visualeditor/<version>/demos/ .  The job would be triggered on postmerge.

The main blocker for this used to be the ability to run a build script. That is resolved now that we migrated jsduck to labs. The OOjs UI publication job for documentation already makes use of `npm-install` ([example](https://github.com/wikimedia/integration-config/blob/96fa3fd720d13c2f52454ab283382fd0cd38802a/jjb/misc.yaml#L28-L36)).

The main this this is blocked on now is:
* Setting up a redirect.
* Upstream OOjs UI and VisualEditor need to have their demo-directory be standalone (like docs). So must not reference `../` but instead build and copy relevant files.

After that, it's just a simple change to update publication job to call push-doc a second time (once for `docs/` to `visualeditor/:version` and a second time for `demos/` to `visualeditor/:version/demo`

> That is similar to {T87490}.

That one is primarily blocked on {T93558}. Trivial otherwise.
>>! In T62143#1162486, @hashar wrote:
> We should be able to craft a job that triggers doc-publish-sync job with source /demos/ and dest /visualeditor/<version>/demos/ .  The job would be triggered on postmerge.

The main blocker for this used to be the ability to run a build script. That is resolved now that we migrated jsduck to labs. The OOjs UI publication job for documentation already makes use of `npm-install` ([example](https://github.com/wikimedia/integration-config/blob/96fa3fd720d13c2f52454ab283382fd0cd38802a/jjb/misc.yaml#L28-L36)).

The main this this is blocked on now is:
* Setting up a redirect.
* Upstream OOjs UI and VisualEditor need to have their demo-directory be standalone (like docs). So must not reference `../` but instead build and copy relevant files.
 
 After that, it's just a simple change to update publication job to call push-doc a second time (once for `docs/` to `visualeditor/:version` and a second time for `demos/` to `visualeditor/:version/demo`

> That is similar to {T87490}.

That one is primarily blocked on {T93558}. Trivial otherwise.
>>! In T62143#1162486, @hashar wrote:
> We should be able to craft a job that triggers doc-publish-sync job with source /demos/ and dest /visualeditor/<version>/demos/ .  The job would be triggered on postmerge.

The main blocker for this used to be the ability to run a build script. That is resolved now that we migrated jsduck to labs. The OOjs UI publication job for documentation already makes use of `npm-install` ([example](https://github.com/wikimedia/integration-config/blob/96fa3fd720d13c2f52454ab283382fd0cd38802a/jjb/misc.yaml#L28-L36)).

The main this this is blocked on now is:
* Setting up a redirect.
* Upstream OOjs UI and VisualEditor need to have their demo-directory be standalone (like docs). So must not reference `../` but instead build and copy relevant files.
 
 After that, it's just a simple change to update publication job to call push-doc a second time (once for `docs/` to `visualeditor/:version` and a second time for `/demos` to `visualeditor/:version/demo`

> That is similar to {T87490}.

That one is primarily blocked on {T93558}. Trivial otherwise.
From https://www.mediawiki.org/wiki/Continuous_integration/meetings/2015-03-30/minutes

We should be able to craft a job that triggers doc-publish-sync job with source /demos/ and dest /visualeditor/<version>/demos/ .  The job would be triggered on postmerge.

I have not much time available to handle this though. So it is going to sit in the backlog for now :/

That is similar to {T87490}.
From https://www.mediawiki.org/wiki/Continuous_integration/meetings/2015-03-30/minutes

We should be able to craft a job that triggers doc-publish-sync job with source /demos/ and dest /visualeditor/<version>/demos/ .  The job would be triggered on postmerge.

I have not much time available to handle this though. So it is going to sit in the backlog for now :/
>>! In T62143#962939, @hashar wrote:
> Can you ship the demo directly in the doc ? Ie: https://doc.wikimedia.org/visualeditor/v0.1.0/doc/demos/ ? The demos could be linked from the documentation main page.

No, they don't nest well and are independent web entry points. Keep them as `doc/` and `demos/`. The `doc/` dir is auto-generated and managed by jsduck. The `demo/` on the other hand is in git and should work after a plain git clone and running install/build.
>>! In T62143#962939, @hashar wrote:
> Can you ship the demo directly in the doc ? Ie: https://doc.wikimedia.org/visualeditor/v0.1.0/doc/demos/ ? The demos could be linked from the documentation main page.

No, they don't nest well and are independent web entry points. Keep them as `doc/` and `demos/`. The `doc/` dir is auto-generated completely. The `demo/` on the other hand is in git and should work after a plain git clone and running install/build.
Can you ship the demo directly in the doc ? Ie: https://doc.wikimedia.org/visualeditor/v0.1.0/doc/demos/ ? The demos could be linked from the documentation main page.
Can you ship the demo directly in the doc ? Ie: https://doc.wikimedia.org/visualeditor/v0.1.0/doc/demos/ ? They could be linked from the main page.
Once we have dev.wikimedia.org up and running, we should migrate documentation to there, which will help remove the awkward terminology overlap/ambiguity between "documentation" and "demo". We'd e.g. have:

* dev.wikimedia.org/visualeditor/documentation/
* dev.wikimedia.org/visualeditor/demo/

But for the time being on doc.wikimedia.org, we can just do the same and don't mind the fact that there is already "doc" in the url somewhere.

So there's nothing blocking us from having additional directories up on doc.wikimedia.org. The blocking aspects of this are specific to each project.

>>! In T62143#666023, @Spage wrote:
> This is similar to bug 58620.  Since the OOjs UI demos require nodejs/npm setup similar to building the KSS documentation, fixing this will require similar steps as hashar outlined in comment 1 there.

The blocker for OOjs UI is being able to run Grunt and arbitrary npm dependencies on the server. Which is blocked on migrating that job from gallium to labs slaves.

For VisualEditor, the main blocker was directory management (it doesn't require a build step).
Once we have dev.wikimedia.org up and running, we should migrate documentation to there, which will help remove the awkward terminology overlap/ambiguity between "documentation" and "demo". We'd e.g. have:

* dev.wikimedia.org/visualeditor/documentation/
* dev.wikimedia.org/visualeditor/demo/

But for the time being on doc.wikimedia.org, we can just do the same and don't mind the fact that there is already "doc" in the url somewhere.
This is similar to bug 58620.  Since the OOjs UI demos require nodejs/npm setup similar to building the KSS documentation, fixing this will require similar steps as hashar outlined in comment 1 there.
(In reply to comment #1)
> Do the demo require a server side backend or are they 100% executing in the
> browser?  If we need to serve content, that would need to be done on another
> server.  Else, it is "just" about enhancing the doc jobs to publish the demo
> to
> the document root.

Fully stand-alone client-side JS only, providing static files. Theoretically they could just be linked off beta's bits – e.g. http://bits.beta.wmflabs.org/static-master/extensions/VisualEditor/lib/ve/demos/ve/eventLogger.html – but this is ugly (and doesn't work for OOjs UI because it's only deployed in compiled form without demos).
Do the demo require a server side backend or are they 100% executing in the browser?  If we need to serve content, that would need to be done on another server.  Else, it is "just" about enhancing the doc jobs to publish the demo to the document root.
1. Create a new math node (Insert -> Formula)
2. Type L' = \{\<x, \underbrace{1111\dots1111}_{s(|x|)}0\> | x \in L\} into the input box
3. Observe &lt; and &gt; in the preview :(

--------------------------
**Version**: unspecified
**Severity**: minor
*** This bug has been marked as a duplicate of bug 57429 ***
Intention:
Delete a template.

Steps to Reproduce:
1. Open an article containing a template.
2. Select the template.
3. Try to press the delete key on the now-non-existent keyboard.

Actual Results:  
The keyboard closes, so you can't delete them.


Reproducible: Didn't try

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=67390
Change 230592 merged by jenkins-bot:
MobileContext: Provide a delete button for nodes' context

[[https://gerrit.wikimedia.org/r/230592]]
Mobile styling:
{F1273774}
Change 163662 abandoned by Esanders:
[WIP] Add a "Remove" context button to all Focusable nodes

Reason:
Context items have moved on a fair bit. See I41109537d for latest attempt.

[[https://gerrit.wikimedia.org/r/163662]]
Change 230592 had a related patch set uploaded (by Esanders):
[WIP] Delete button for node context items

[[https://gerrit.wikimedia.org/r/230592]]
I have a patch which adds a delete action. The only question is should we hide it on desktop, because it looks okay and could be useful:

{F1182099}
Change 163662 had a related patch set uploaded (by Jforrester):
[WIP] Add a "Remove" context button to all Focusable nodes

[[https://gerrit.wikimedia.org/r/163662]]
(In reply to Ed Sanders from comment #11)
> Of course this behaves completely differently in iOS 8 (the keyboard stays
> up). *sigh*

Re-prioritising.
Of course this behaves completely differently in iOS 8 (the keyboard stays up). *sigh*
Change 163662 had a related patch set uploaded by Jforrester:
Add a "Remove" context button to all Focussable nodes

https://gerrit.wikimedia.org/r/163662
This seems to be because we programmatically move focus from the surface to the pasteTarget, and iOS Safari is very picky about when it allows a programmatic focus move to open the keyboard. Something like, it only works if you do it in direct response to a mouse/touch event. I tried a few solutions I found on the internet but I haven't gotten any of them to work yet.
*** Bug 67257 has been marked as a duplicate of this bug. ***
(In reply to Brion Vibber from comment #6)
> I've noticed a few bugs coming through related to certain operations hiding
> the keyboard and then that killing focus and causing selections and menus to
> disappear. Is there a general problem where losing keyboard focus causes VE
> to lose state?

Quite possibly; escalating.
I've noticed a few bugs coming through related to certain operations hiding the keyboard and then that killing focus and causing selections and menus to disappear. Is there a general problem where losing keyboard focus causes VE to lose state?
Yes, for all block items such as image, reference note, template ,math function: selecting it hides the keyboard.
Can this be rechecked?
Aaaah, OK. Updating summary to reflect that.
No, I mean the keyboard.  It's an iPad without an attached physical keyboard.  The keyboard is displayed on the screen, like the one shown in the picture at https://commons.wikimedia.org/wiki/File:Apple_iPad_Event03.jpg

(Presumably the same problem happens on any mobile device.)
Did you mean the cursor instead of the keyboard? Surely VisualEditor didn't make your physical keyboard dissolve into a pool of molten plastic?
Especially now that we have mixins adding properties with very generic names like this.min and this.max (ResizeableNode), we should look at namespacing them. Maybe an object to contain them all, like this.resizeableNode = { min: 1, max: 1000 }; ?

--------------------------
**Version**: unspecified
**Severity**: enhancement
The Zuul Debian package embeds some python modules including `GitPython` which is now `>=0.3.3`.
That is apparently solved in v3.2.  Now pending upgrade of Zuul.
Possible upstream bug: https://github.com/gitpython-developers/GitPython/issues/94

Got to find a way to reliably reproduce the issue :(
1. Create a document with just a block image [[File:Foo.jpg|thumb]] on one line
2. Edit the document and try to place the cursor in the second slug (after the image)
3. An exception is thrown (getNearestContentOffset(selection.end) returns -1 and this is fed into getAnnotationsFromOffset)

--------------------------
**Version**: unspecified
**Severity**: normal
verified the fix in test2
Change 107134 merged by jenkins-bot:
Check for valid offset when calculating insertion annotations

https://gerrit.wikimedia.org/r/107134
Change 107134 had a related patch set uploaded by Esanders:
Check for valid offset when calculating insertion annotations

https://gerrit.wikimedia.org/r/107134
In the read mode

Steps to reproduce:

1.Open a page with VE
2.Add a reference to a text by going to Insert>Reference
3.When the reference dialog box opens up insert a numbered list and then type the reference for example as: 1.reference
4.Click on "Insert Reference"
5.Save the page

Observed Result:
In the read mode,the serials of the numbered list are appearing in wikitext with #.

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

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

**Attached**: {F12322}
The PHP parser requires a \n before every *, including the first one. So it should be:

Hey!<ref>
* foo
* ...

Unless you want to start messing with the PHP parser...
(In reply to Ed Sanders from comment #5)
> Todo: create a ticket for the Parsoid side if this bug (not inserting line
> breaks before */#)

Ed, what's the specific problem Parsoid's doing wrong?

<p>Hey!<span class="reference" data-mw="{&quot;name&quot;:&quot;ref&quot;,&quot;body&quot;:{&quot;html&quot;:&quot;&lt;ul &gt;&lt;li &gt; foo&lt;/li&gt;&lt;li &gt; bar&lt;/li&gt;&lt;li &gt; baz&lt;/li&gt;&lt;/ul&gt;&quot;},&quot;attrs&quot;:{}}" id="cite_ref-1-0" rel="dc:references" typeof="mw:Extension/ref"><a href="#cite_note-1">[1]</a></span></p>

… goes neatly to …

Hey!<ref>* foo
* bar
* baz</ref>

With \n as needed.
Todo: create a ticket for the Parsoid side if this bug (not inserting line breaks before */#)
https://gerrit.wikimedia.org/r/#/c/111507/
One really shouldn't put lists inside a reference. References are supposed to be a single paragraph. I'll remove the tools for doing so which should reduce the impact of this.
This issue is also occurring for bullet list thats is added inside Reference dialog bix, they appear as * in the Read mode
Created attachment 14250
In Edit mode

**Attached**: {F12323}
screenshot

Steps to reproduce:

1.Open a page with VE
2.Select Insert>Special Character
3.Close the special character window.
4.Go to Insert option in the toolbar

Observed Result:
The Special Character option is still appearing selected even after closing the window

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

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

**Attached**: {F12316}
This issue got fixed with https://gerrit.wikimedia.org/r/#/c/107193/
Bug 49846 was this happening last time around. Possibly the same cause.

--------------------------
**Version**: unspecified
**Severity**: normal
Merging into 49846 then.

*** This bug has been marked as a duplicate of bug 49846 ***
Ok, so it's definitely bug 49846 coming back again.

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)

Which is wrong Wrong WRONG! There's a bug here, will need to report upstream.

In the meantime: we can't have submodule subscriptions where there's a repo with the same base name. Gerrit gets confused.

VisualEditor.git will have to be renamed or something if we expect mw/ext/VisualEditor to update properly.
Trying to update manually on deployment-bastion.pmtpa.wmflabs in /home/wikipedia/common/php-master/extensions

Looking at VisualEditor:


$ git submodule VisualEditor
 3e925e634398ab80711819ee4c10a29b89854588 VisualEditor (remotes/origin/wmf/1.23wmf9-1-g3e925e6)

Although the HEAD of mediawiki/extensions.git checkout is up to date :(
Especially if the icon for a menu button is a mere symbol, add a tooltip to that button (i.e., the three-bars icon).

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 108855 had a related patch set uploaded by Jforrester:
Add tooltips to the drop-down menus explaining what they do

https://gerrit.wikimedia.org/r/108855
Per Gabriel's report via email, when VE POSTs HTML, it uses multipart/x-www-urlencoded to encode the POST body, which results in a lot of URL-encoding of special characters (especially <>") in the HTML. We should instead use multipart/form-data , which is more efficient for such large POST bodies with many special characters.

TODO: Figure out how to tell the browser to use this encoding when sending an AJAX request.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 105486 merged by jenkins-bot:
Add multipart/form-data emulation to ve.init.mw.Target#apiRequest

https://gerrit.wikimedia.org/r/105486
Change 105486 had a related patch set uploaded by Catrope:
Add multipart/form-data emulation to ve.init.mw.Target#ajax

https://gerrit.wikimedia.org/r/105486
Intention:
Add a new paragraph at the bottom of a page that ended in == <nowiki/> == (not counting the category after the empty section heading).

I was hoping that adding a new paragraph underneath the blank section heading would allow me to select, and therefore to remove, the blank section heading.


Steps to Reproduce:
1. Edit a page that ends in a == <nowiki/> ==, like https://en.wikipedia.org/w/index.php?title=User:Whatamidoing_(WMF)/sandbox2&oldid=589158823

2. Place the cursor in the empty section heading.

3. Hit return.

Actual Results:  
Pressing return adds blank paragraphs *above* the empty section heading. 

If you type anything into the section heading, then it starts behaving normally.

Expected Results:  
Doing the same thing for an empty (or non-empty) section heading anywhere else on the page adds new paragraphs *under* the empty section heading.  Pressing return in a section heading should produce the same behavior everywhere on the page.

Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 160215 merged by jenkins-bot:
ve.ce.Surface: Insert new paragraphs after empty nodes rather than before

https://gerrit.wikimedia.org/r/160215
Change 160215 had a related patch set uploaded by Bartosz Dziewoński:
ve.ce.Surface: Insert new paragraphs after empty nodes rather than before

https://gerrit.wikimedia.org/r/160215
This is also reproducible with other block nodes, like preformatted text.

There's code in ve.ce.Surface#handleEnter to "If we're at the start/end of something that's not a paragraph, insert a paragraph before/after". The quirk is that it checks for the "at the start" case before checking the "at the end" case, and for empty elements both of these are true. Let's just flip the order.
On FlaggedRevs wikis: Checkbox "Accept this version (includes n pending changes)" in save dialog is missing

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=63600
Change 127388 merged by jenkins-bot:
Set context title when rendering edit notices and checkboxes

https://gerrit.wikimedia.org/r/127388
Change 127388 had a related patch set uploaded by Alex Monk:
Set context title when rendering edit notices and checkboxes

https://gerrit.wikimedia.org/r/127388
In FlaggablePageView::addReviewCheck, $this->article->isReviewable() returns false.

I made some uncommitted live hacks on deployment-apache01.eqiad.wmflabs and replayed the API request in Chrome until I got the right server. Turns out, $this->article represents the "API" title. Why is this not happening on my machine?
I see the same thing on Wikimedia sites, but cannot replicate the issue locally.
The message is <revreview-check-flag-p>. Presumably this doesn't get fetched in the new save dialog like it used to?
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 seem a few examples of what the title says. 

I couldn't reproduce because of {T61599}.

--------------------------
**Version**: unspecified
**Severity**: normal
**See also**: {T51823}
I tried reproducing this and got nothing. Feel free to reopen if I've missed something.
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.
Is this still valid?
Minor corruption:

<https://www.mediawiki.org/w/index.php?title=Architecture_Summit_2014/Straw_poll&diff=870066&oldid=870065&diffonly=1> and <https://www.mediawiki.org/w/index.php?title=Architecture_Summit_2014/Straw_poll&diff=870064&oldid=870063&diffonly=1>

More serious corruption:

<https://www.mediawiki.org/w/index.php?title=Architecture_Summit_2014/Straw_poll&diff=870067&oldid=870066&diffonly=1>

--------------------------
**Version**: unspecified
**Severity**: enhancement
Should be fixed by the new link cartouching.
@Trevor: Do you know already how you are going to handle this?
Steps to reproduce:

1) Begin with an existing wikitext table (e.g., 4 rows, 4 columns).  Open the page in VisualEditor.

2) Copy part of a different table or spreadsheet (e.g., 2 rows, 4 columns).

3) Place cursor inside a cell of the table in VisualEditor.

4) Paste the copied table.


Results:

VisualEditor places the entire new/rich-copied table, including wikitext formatting, inside the first cell.  The wikitext parser does not deal very gracefully with table-within-table formatting.


Desired outcome:

VisualEditor should overwrite the contents of the cells with the new material.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: https://en.wikipedia.org/w/index.php?diff=588462959&oldid=588405367#Create_and_copy_table.
I wasn't wrong. Done in wmf.12.
This'll be… hard, to put it mildly. We should think about whether it's what we want to achieve in terms of UX before embarking on it.
mw.user.getToken only supports edit, watch and patrol.
It should support all other types of token.

--------------------------
**Version**: 1.23.0
**Severity**: enhancement
Apologies mw.user.tokens.get
???

I can't find mw.user.getToken. mw.api.getToken exists and it supports all tokens.
screenshot of the error

Steps to reproduce:

1.Open a page using VE in Chrome browser.
2.Copy a math function or item from that page
3.Open another page with VE in FireFox
4.Paste the copied math item in this page

Observed Result:
The math item does not get copied and in the console there is an error appearing:
 TypeError:Item is undefined

See the screenshot attached.

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

**Attached**: {F12369}
Fixed a while ago
No, I mean it renders fine for me.
(In reply to Rummana Yasmeen from comment #4)
> you mean, its fine if the copied math math function does not render on the other
> page?

*Does not*

Because , right now it is not rendering unless I save the page
you mean, its fine if the copied math math function does render on the other page?
This... Appears to work now.
Not getting the error - presumably that got fixed, but the copy does not *appear* to do anything. When I run the target in debug mode, I see that we're getting mwMath entries in the model, and you can select them. They just don't render as anything.
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=26th_paste_ff&veaction=edit
screenshot of the link after copy paste

Steps to reproduce:

1.Open an editor in Firfox which contains a link
2.Copy the link 
3.Paste it into another VE and save it

Observed Result:
The link is appearing within [] bracket and with a lock icon beside it.

See the screenshot attached.

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

**Attached**: {F12199}
*** Bug 60379 has been marked as a duplicate of this bug. ***
Possibly got fixed by https://gerrit.wikimedia.org/r/#/c/106253/ as it was happening even just before wmf11 deployment in test2
This is also happening for Chrome Browser.
Test Environment should be test2 in above comment
Test Environment:betalabs
Browser: FF 25
OS: MAC OS X 10. 8. 5 
Page:https://test2.wikipedia.org/wiki/23rd_paste
[14:38] <gwicke> in native CE shift-enter inserts a newline in a pre
[14:38] <gwicke> normal enter splits it
[14:40] <gwicke> woah: shift-enter actually works in VE as long as it is not on the last line of a pre
[14:41] <gwicke> it does not work when the cursor is on the first or last char in a pre
[14:41] <gwicke> before first char a paragraph is inserted before the pre
[14:41] <gwicke> after last char a paragraph is inserted after the pre and the cursor moves there

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

Steps to reproduce:

1.Create a new page in FF
2.Copy a math function from another VE 
3.Paste it in this new page
4.Click on Save Page

Observed Result:
"Error: Creating new, empty pages is not allowed" appears

See the screenshot attached.

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

**Attached**: {F12772}
Actually, Math functions are not at all getting copy pasted in FF.For a new page it says this error "Error: Creating new, empty pages is not allowed" and for any other existing page when you copy a math function and paste it into another VE,it shows it in the edit mode but after saving it just disappears.
Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: FF 25
OS: MAC OS X 10. 8. 5
Steps to reproduce:

1.Open the editor for a page
2.Open the latex window and insert "\sqrt\pi"
3.Click on the "<" button to close the latex window
4.Copy the formula immediately
5.Paste it onto another page

Observed Result:
The math elements does not appear on the page after pasting.However after saving it appears there are multiple of those 

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

--------------------------
**Version**: unspecified
**Severity**: normal
We fixed this a while ago. :-)
Copied from bug 58347:

1.Create a page "A" with three links in three consecutive lines.
2.Create another page "B" where you will copy these links to.
3.Copy the first and second link to "B"
4.Save it.
5.Reopen the editor.
6.Now copy the third link and paste it to the third line of "B"
7.Save it.

Observed Result:
The second and the third link in page B is getting merged.

Example Pages:

A:http://en.wikipedia.beta.wmflabs.org/wiki/19th_december_source?veaction=edit
B:http://en.wikipedia.beta.wmflabs.org/wiki/19th_destination

--------------------------
**Version**: unspecified
**Severity**: normal
In ryasmeen's HTML dump the last paragraph contains both the text and the pasted citation. Apparently the VE rendering showed the citation in a separate line, so the discrepancy in the HTML emitted by VE (citation actually in the preceding paragraph) seems to be a bug in VE. Moving this to VE for that reason.
Created attachment 14240
Screenshot of template getting merged with the previous line

**Attached**: {F12624}
The original issue described in this bug is not occurring anymore but a similar issue is found not sure if they are related or not.If not, I will file a separate issue:

1.Create a page "A" with a template Cite Web
2.Create another page "B" where you will copy the template.
3.Add some text or any other element like math function/Link to Page "B"
4.Copy the CiteWeb template created in page A and paste it into the next line of B

Observed Result:
The template gets merged with the previous element/line.


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/Copy-paste6th

See the screenshot attached.
Can you provide a sample of the relevant HTML your are producing in VE?
**Author:** `prlpz`

**Description:**
I suggest including in TemplateData a field about the namespaces where the template is intended to be used. VisualEditor should use this field to suggest the template only in the right namespaces.

For example, nowadays VisualEditor suggest using template documentation templates while editing articles, but such templates should only be used in template namespace. TemplateData could make VisualEditor know that those templates shouldn't be suggested there.
@Krinkle, @Jdforrester-WMF: Any thoughts on this one? If we decided this is a good idea, we'd need to figure out which is the best format for users to express the namespaces in.
Core has a build system to generate HTML from kss-formatted CSS/LESS (docs/kss). It would be nice if this documentation appeared in doc.wikimedia.org along with other generated documentation.

This sounds like T50337. Presumably there's some Zuul job somewhere building the doc that appears.

--------------------------
**Version**: unspecified
**Severity**: enhancement
kss is still in core.
We are no longer using kss in MobileFrontend. It wasn't being maintained due to lack of visibility and shift to OOjs UI.
Seems fine: npm-run-script doc

In Jenkins Job Builder, I have generic templates for python tox and ruby bundler:

'{name}-tox-{toxenv}'
'{name}-bundle-{bundlecommand}'  https://gerrit.wikimedia.org/r/#/c/160983/

So we can probably come up with a '{name}-npmrunscript-{npmscript}' command which would be realized as:

- project:
  name: VisualEditor
  npmscript:
   - doc
  jobs:
   - '{name}-npmrunscript-{npmscript}'


And the template would contain:

 npm run-script {npmscript}

Might need to add an 'npm install' before, not sure.
(In reply to Antoine "hashar" Musso from comment #14)
> > Do you mean Grunt (which runs on node.js)?  That's the node.js build tool
> > I normally see used.
> 
> I guess npm as an entry point for jenkins (i.e. npm test) which would then
> use grunt to run a wide range of different tests :d

Hmm, thanks.  This is not a test though.

While "npm test" exists (https://www.npmjs.org/doc/cli/npm-test.html), "npm doc" does not.  There is apparently a way to have custom scripts (https://www.npmjs.org/doc/misc/npm-scripts.html , https://www.npmjs.org/doc/cli/npm-run-script.html), but we would need to standardize on a name (e.g. npm-run-script doc).

Is there such a convention already?
Change 161998 had a related patch set uploaded by Prtksxna:
kss: Add Gruntfile

https://gerrit.wikimedia.org/r/161998
> Do you mean Grunt (which runs on node.js)?  That's the node.js build tool
> I normally see used.

I guess npm as an entry point for jenkins (i.e. npm test) which would then use grunt to run a wide range of different tests :d
(In reply to Antoine "hashar" Musso from comment #11)
> Can you reach out to Timo about it?  I think for Javascript purposes he
> would like developers to define npm entry points.  So we would simply invoke
> 'npm doc' or something and publish whatever is generated under a given dir
> (ex: /doc/).

Do you mean Grunt (which runs on node.js)?  That's the node.js build tool I normally see used.
Timo is in the office this week.. Maybe you could grab him S?
Can you reach out to Timo about it?  I think for Javascript purposes he would like developers to define npm entry points.  So we would simply invoke 'npm doc' or something and publish whatever is generated under a given dir (ex: /doc/).

That would let you define whatever you want to run to build documentation which is much more scalable than having to handle defines in jenkins.
yardoc is now being used and Jenkins is populating https://doc.wikimedia.org/rubygems/mediawiki-ruby-api/ and https://doc.wikimedia.org/rubygems/mediawiki-selenium/ .  So that's something to study when implementing this.
In the interim, `ssh tools-login.wmflabs.org; become styleguide` is generating http://tools.wmflabs.org/styleguide/ in a cron job. I don't understand misc.yaml, mediawiki.yaml, zuul-config/layout.yaml enough to work on this.
*** Bug 64221 has been marked as a duplicate of this bug. ***
Since mss is a node module, we could have it added to the integration/jenkins.git repository which has tools/package.json. It currently provides:

 {
	"name": "wikimedia-integration-jenkins",
	"version": "0.2.5",
	"dependencies": {
		"grunt": "0.4.1",
		"grunt-cli": "0.1.13",
		"grunt-contrib-qunit": "0.4.0",
		"phantomjs": "~1.9.0-1",
		"grunt-contrib-csslint": "0.2.0",
		"jshint": "2.4.4"
	}
 }

So maybe add kss in there and forget about git-deploy and integration/kss.
Pending upload of kss in integration/kss.git so we can get it deployed on Jenkins slaves.  Then we need some script to generate the doc and move the generated doc under the doc website.
Change 103095 merged by Alexandros Kosiaris:
Add integration/kss to deployment repo config

https://gerrit.wikimedia.org/r/103095
I have created a .gitreview file for integration/kss.git repository so we can add it in the deployment system.
Change 103095 had a related patch set uploaded by Spage:
Add integration/kss to deployment repo config

https://gerrit.wikimedia.org/r/103095
Target url should indeed me something like one of these this:


https://doc.wikimedia.org/mediawiki-core/master/less/
https://doc.wikimedia.org/mediawiki-core/master/css/
https://doc.wikimedia.org/mediawiki-core/master/style-guide/css/

Preferences, anyone?

(where master can also be REL1_22, and in the future tags like 1.23.0)

With a shortcut from the https://doc.wikimedia.org/ home page, of course.

PS: I'm planning on renaming /mediawiki-core to /mediawiki at some point (with redirects and symlinks of course).
S, as a first step we need a way to deploy kss on the Jenkins slave.

It seems that is a nodejs application so I guess we want to use our own repository that would provide kss and ALL the required modules.  We did such a thing to provide ruby bundler (integration/bundler.git) and phpunit (integration/phpunit.git).

Could you take care of having an integration/kss.git repository created and upload there the kss + its npm modules ?


Once done, register that repository in git-deploy configuration. That is done in operations/puppet.git under manifests/role/deployment.pp.  The deployment would then be done from tin.eqiad.wmnet.


Then, we need a shell script wrapper that would execute the script (deployed somewhere under /srv/deployment/integration/kss ).  https://doc.wikimedia.org/ document root is under /srv/org/wikimedia/doc/  the following sub directories are usually: <project-name> / <branch> / <doc component>.  Example:

 /srv/org/wikimedia/doc/mediawiki-core/REL1_22/js


So I guess you would want to have kss generate the doc to  /srv/org/wikimedia/doc/mediawiki-core/master/css


Once done, we need a new job-template in Jenkins Job Builder configuration, apply it to mediawiki/core project.  The job will need to be added in Zuul configuration (integration/zuul-config.git) in the postmerge pipeline.
This causes the test 'document with meta elements: data' in ve.dm.MWConverter to fail. Not sure if it is any more serious than that.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #3)
> (In reply to comment #0)
> > This causes the test 'document with meta elements: data' in ve.dm.MWConverter
> > to fail. Not sure if it is any more serious than that.
> 
> Are you comparing a HTML serialization or the DOM attribute? A diff in the
> former is fine, but a diff in the latter would be a bug.

Actually, a diff in the *percent-decoded* DOM href attribute would be a bug.

We decode all hrefs in the serializer, so to us it makes no difference if it is encoded as %20 or a literal space in HTML.
(In reply to comment #0)
> This causes the test 'document with meta elements: data' in ve.dm.MWConverter
> to fail. Not sure if it is any more serious than that.

Are you comparing a HTML serialization or the DOM attribute? A diff in the former is fine, but a diff in the latter would be a bug.
(In reply to comment #1)
> A space is not a valid character in an URL, it must always be
> percent-encoded.
> https://en.wikipedia.org/wiki/URL#List_of_allowed_URL_characters

Are we talking about HTTP or HTML here? If it is HTML, then I'd suggest looking at the relevant HTML5 spec.
A space is not a valid character in an URL, it must always be percent-encoded. https://en.wikipedia.org/wiki/URL#List_of_allowed_URL_characters
Occasionally, cut and paste of text that includes a reference will fail in a weird way. I was able to isolate one reproducible case: 

1. The article contains text S, followed by a reference for S, some more text T, followed by a reference for T.

2. We cut (Ctrl-X) part or all of text T, including its reference.

3. We paste (Ctrl-V) somewhere in the middle of text S (*not* at the beginning of S)

Result: the article view is scrolled to the top, the pasted text is in wrong order, all of a sudden we have three references.

See https://www.mediawiki.org/wiki/VisualEditor:TestAxelBoldt#Regression_15:_Cut.2FPaste_of_references for a sandbox where you can try it out.

--------------------------
**Version**: unspecified
**Severity**: normal
I can't reproduce either.
I tired it on the page where the original test is placed- https://www.mediawiki.org/wiki/VisualEditor:TestAxelBoldt?veaction=edit#Regression_15%253A_Cut.2FPaste_of_references

- no scroll-up when pasting the text
- the text pasted correctly
Can't reproduce anymore.
Per Guillaume's request on IRC. This is namespace 100.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
Now done.
Change 101908 merged by Reedy:
Make officewiki's Report: namespace VE-enabled

https://gerrit.wikimedia.org/r/101908
\o/ Thanks :)
Change 101908 had a related patch set uploaded by Jforrester:
Make officewiki's Report: namespace VE-enabled

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

1.Open the editor.
2.Add a template
3.Save the page
4.Reopen the editor
5.Copy the template 

Observed Result:

It gives an error:Uncaught TypeError: Cannot convert null to object .However, it does get pasted correctly onto other VE.

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in test2 with MediaWiki 1.23wmf8 on page:
https://test2.wikipedia.org/wiki/19th_december
Verified the fix in betalabs:http://en.wikipedia.beta.wmflabs.org/wiki/The_destination_template
Change 101148 merged by jenkins-bot:
Check values property exists before removing attribute

https://gerrit.wikimedia.org/r/101148
For betalabs, I could reproduce for only templates which has parameters with values
Change 101148 had a related patch set uploaded by Esanders:
Check values property exists before remove attribute

https://gerrit.wikimedia.org/r/101148
Can you reproduce on beta labs?
Created attachment 14077
screenshot

**Attached**: {F12097}
Test Environment: production-https://en.wikipedia.org/
Browser: Chrome Version 26.0.1410.65 &       FF 25
OS: MAC OS X 10. 8. 5
To reproduce:

1. Edit a page with a template.
2. Click the template so the darker blue sprite appears.
3. Resize the window.

Observed: The transparent blue sprite stays at the same place on the screen.

Expected: The transparent blue sprite should move to the new location of the template of the screen.

--------------------------
**Version**: unspecified
**Severity**: normal
This is now fixed.
screenshot

<visualeditor-toolbar-insert> is showing up in the toolbar instead of More in betalabs

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

**Attached**: {F11989}
verified on test2:https://test2.wikipedia.org/w/index.php?title=13th_december&veaction=edit
Verified in Betalabs
This is now fixed in betalabs after we caused the English messages to get re-synched.
The following pages all exist on en.wikipedia.org:

* [[Bird]]
* [[Big]]
* [[Big!]]
* [[Big Ten Conference]]

When querying action=opensearch for:

* "Bir": 0 => "Bird"
   https://en.wikipedia.org/w/api.php?format=json&action=opensearch&namespace=0&search=Bir
   [input,["Bird","Birmingham",..]]

* "Bird": 0 => "Bird"
   https://en.wikipedia.org/w/api.php?format=json&action=opensearch&namespace=0&search=Bird
   [input,["Bird","BirdLife International",..]]

* "Big": 
   https://en.wikipedia.org/w/api.php?format=json&action=opensearch&namespace=0&search=Big
   ["Big",["Big Ten Conference","Big band",...]]

* "Big": 
   https://en.wikipedia.org/w/api.php?format=json&action=opensearch&namespace=0&search=Big!
   ["Big!",["Big Ten Conference","Big band",...]]

In the last two, "Big" and "Big!" are nowhere in the response.

Filing against Wikimedia for now, because this seems related to one of our search backends, not plain MediaWiki core or plain MediaWiki core with Extension:TitleKey installed.

This is currently causing issues in VisualEditor when making a link to a page called "Big", or "Big!" as it will think the page doesn't exist and suggest to make a red link, as, thus far, we've always assumed that if a page by the exact title exists, it should be the first suggestion.

It normalising casing and/or special characters is fine, but shouldn't make it not give an exact match as first result.

--------------------------
**Version**: unspecified
**Severity**: major
**Whiteboard**: cirrus-fixed
This issue is now fixed.
Some good news, at least.  Cirrus does what you'd expect.  If you have a page named "Big!" and type "Big!" into the search box it'll return Big! as the suggestion.
I'm pretty sure 'OpenSearchXml' is not the right component. Also, cc-ing search people.
VisualEditor screenshots:

- Big! http://cl.ly/image/3U3V1h1B3i0r
- Big  http://cl.ly/image/193c290i1X0z
Reproducible: Didn't try

--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://en.wikipedia.org/w/index.php?title=Toronto_Maple_Leafs&diff=585067098&oldid=584791615
Last report a year ago; presumably this was a Parsoid issue that was since fixed?
No steps to reproduce; no-one managed to reproduce; no new known occurrences for nearly a year. Setting status to STALLED.

>>! In T60282#642603, @Whatamidoing-WMF wrote:
> I'll ask the user who encountered this one:

The reply of that user was "I am using Mozilla Firefox on a Dell Inspiron One desktop computer."
Thanks!
It happened yesterday:

https://en.wikipedia.org/w/index.php?title=IPhone&curid=8841749&diff=604427150&oldid=604113181

I'll ask the user who encountered this one:

https://en.wikipedia.org/w/index.php?title=Michael_Jackson&curid=14995351&diff=603943260&oldid=603918451

since she's pretty active.
I can't reproduce this in Chrome, Safari, Opera or Firefox. Is it possible that this is a browser plug-in or a very odd browser corruption?
Here's another:  

https://en.wikipedia.org/w/index.php?title=Fandango_%28wrestler%29&curid=21330399&diff=602066359&oldid=601951852

This one broke over "&quot;"
Here's another:

https://en.wikipedia.org/w/index.php?title=The_National_%28band%29&curid=2308112&diff=600606533&oldid=600023816

This time, the ref name contained a template:  <ref name="{{BillboardURLbyName|artist=the national|chart=Billboard 200}}">

Like most of the others, this is probably the result of a sloppy script.
Other example on frwiki https://fr.wikipedia.org/w/index.php?title=Salon_international_de_l%27agriculture&curid=205829&diff=101773303&oldid=101729054

Apparently, the user didn't even modify the chapter where the problem occurs.
According to https://en.wikipedia.org/w/index.php?title=Colours_in_the_Dark_%28album%29&curid=39317223&diff=595492480&oldid=593715294 it appears that this happens on HTML codes for things other than non-breaking spaces.  #124 is a vertical bar.
Another diff, this time involving a {{nowrap}} template:  https://en.wikipedia.org/w/index.php?title=Michael_Jackson&curid=14995351&diff=595247974&oldid=595208734

This only seems to affect nbsp's that are present in ref names (where they probably oughtn't be anyway).
Another report of this: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=590211100&oldid=590159444
This also affects vertical bars ( &#124; ) as seen at ttps://en.wikipedia.org/w/index.php?title=Paper_Planes&diff=585505452&oldid=581736416
We're seeing more and more JSON files entering our repos, and there is an RfC in discussion[1] to move to JSON files for our localisation.

Please add standard JSON linting when patch sets that have Jenkins jobs configured.

[1] https://www.mediawiki.org/wiki/Requests_for_comment/Localisation_format

--------------------------
**Version**: wmf-deployment
**Severity**: major
Whether ideal for the long term or not, it was resolved by Antoine by including it in the jslint job.

For the long term, projects should include a jsonlint task in their own test pipeline.

For localisation json files in particular, see T66045#962750.
Whether ideal for the long term or not, it was resolved by Antoine by including it in the jslint job.

For the long term, projects should include a jsonlint task in their own test pipeline.
(In reply to Bawolff (Brian Wolff) from comment #26)
> (In reply to Bawolff (Brian Wolff) from comment #25)
> > Re-opening. I just managed to submit a patch (
> > https://gerrit.wikimedia.org/r/#/c/147754/ ) with a rather stupid json
> > error, and jenkins did not complain.
> 
> Its been pointed out to me that the jslint job (which is non-voting on
> TimedMediaHandler) is what verifies json files (Although
> https://integration.wikimedia.org/ci/job/mwext-TimedMediaHandler-jslint/497/
> consoleText doesn't seem to say anything about an i18n file failing). I'd
> like to suggest that the job be split. As missing a coding convention and a
> fatal error are rather different types of issues.

I agree it shouldn't be part of the jslint job. But I don't think we should change that for the time being. The jslint job in general is an older one that is being phased out by having projects adopt Grunt instead. Where they can add jshint, jscs, banana-checker, and (if they have non-i18n json files) json-lint to their pipeline.

TMH repo should be updated by adding the appropriate jshint config and ignores so that their non-voting exemption may be lifted. Because right now, obvious syntax errors in javascript files aren't caught, either. Which is just as important as json syntax errors.
(In reply to Bawolff (Brian Wolff) from comment #25)
> Re-opening. I just managed to submit a patch (
> https://gerrit.wikimedia.org/r/#/c/147754/ ) with a rather stupid json
> error, and jenkins did not complain.

Its been pointed out to me that the jslint job (which is non-voting on TimedMediaHandler) is what verifies json files (Although https://integration.wikimedia.org/ci/job/mwext-TimedMediaHandler-jslint/497/consoleText doesn't seem to say anything about an i18n file failing). I'd like to suggest that the job be split. As missing a coding convention and a fatal error are rather different types of issues.
Re-opening. I just managed to submit a patch ( https://gerrit.wikimedia.org/r/#/c/147754/ ) with a rather stupid json error, and jenkins did not complain.
All 275 jobs updated.
Change 113958 merged by jenkins-bot:
Add json-lint.php command to -jslint jobs

https://gerrit.wikimedia.org/r/113958
I forgot to deploy https://gerrit.wikimedia.org/r/#/c/113958/ last monday. Updating jobs now.
(In reply to Nemo from comment #19)
> > Will be done next Monday: March 17th.
> 
> Was it?

Seems not.

Setting severity from Siebrand's duplicate.
*** Bug 63293 has been marked as a duplicate of this bug. ***
(In reply to Antoine "hashar" Musso from comment #18)
> Mailled wikitech-l about it
> http://lists.wikimedia.org/pipermail/wikitech-l/2014-March/075092.html
> 
> Will be done next Monday: March 17th.

Was it? Another example: https://gerrit.wikimedia.org/r/#/c/121910/
All extensions should have JSON files checked for validity (locally I use a simple json_verify < $FILE.json ).
Mailled wikitech-l about it http://lists.wikimedia.org/pipermail/wikitech-l/2014-March/075092.html

Will be done next Monday: March 17th.
Change 114464 merged by jenkins-bot:
json syntax error with escaped single quotes

https://gerrit.wikimedia.org/r/114464
Change 114464 had a related patch set uploaded by Hashar:
json syntax error with escaped single quotes

https://gerrit.wikimedia.org/r/114464
I have run the json linter on all extensions and three files are not understood by PHP json_decode() :-(

hashar@gallium:~/extensions$ /srv/deployment/integration/slave-scripts/bin/json-lint.php .
./TemplateData/spec.templatedata.json: json decode error.
./VisualEditor/modules/ve-mw/i18n/qqq.json: json decode error.
./VisualEditor/modules/syntaxhighlight/rules/mysql.json: json decode error.
hashar@gallium:~/extensions$
Change 113958 had a related patch set uploaded by Hashar:
Add json-lint.php command to -jslint jobs

https://gerrit.wikimedia.org/r/113958
Change 107163 merged by jenkins-bot:
json-lint.php: recursively lint json files with PHP

https://gerrit.wikimedia.org/r/107163
(In reply to comment #11)
> Have you verified that it warns for double quotes in *.json files as well?

Yes I did (comment #4) which prompted me to repurpose this bug in writing a wrapper around PHP json_decode() which I did in Gerrit change #107163.

I guess jshint would have the same issue with trailing comma in arrays (none in json) or keys having to be enclosed by quotes.
(In reply to comment #4)
> json files requires double quotes which jshint complains about. So I guess we
> need a different job that would use jshint with a specific configuration.

Have you verified that it warns for double quotes in *.json files as well?

I don't think JSHint will parse json files exactly the same as js files, even if explicitly told to via ` --extra-ext json` because a plain JSON object is not a valid JS statement.

Meaning, if you feed { "foo": "bar" } to a javascript parser as a statement, it will not be an object (it will be a block statement with a label foo and a statement with an unassigned string "bar").

As such, using jshint to parse json files would either be
1) pointless, as it would be validated as javascript instead of json, likely causing all kinds of false positives not even related to coding or quoting style

or 2) JSHint recognises it as a JSON file and therefore one would expect it to not warn for double quotes.
Change 107163 had a related patch set uploaded by Krinkle:
json-lint.php: recursively lint json files with PHP

https://gerrit.wikimedia.org/r/107163
Change 107163 had a related patch set uploaded by Hashar:
json-lint.php: recursively lint json files with PHP

https://gerrit.wikimedia.org/r/107163
I guess one can write a basic lint script that would wrap around PHP json_decode() ?   If we can decode it, I guess we are safe :]
I have an example of invalid JSON that got merged, and caused issues in the L10n process:

Line 215 of https://gerrit.wikimedia.org/r/#/c/106460/1/data/i18n/qqq.json has a trailing comma that, when a JSON linter is there, should have blocked the merge of that patch set.
(In reply to comment #5)
> (In reply to comment #4)
> > json files requires double quotes which jshint complains about. So
> > I guess we need a different job that would use jshint with a specific
> > configuration.
> 
> If we're using JSON, we might as well do it right, so I guess those
> complaints
> are justified?

Oh, wait. Yes, of course, Antoine :).
(In reply to comment #4)
> json files requires double quotes which jshint complains about. So I guess we
> need a different job that would use jshint with a specific configuration.

If we're using JSON, we might as well do it right, so I guess those complaints are justified?
json files requires double quotes which jshint complains about. So I guess we need a different job that would use jshint with a specific configuration.
The jslint job is already present for extension and is triggered by Zuul whenever a .jshint*, *.js or *.json file is modified.

A culprit is that by default jshint does not parse .json files, so we want to instruct it to parse such files using:

 jshint --extra-ext json .
Any updates on this yet?
Timo thoughts?  Should we incorporate that in the jslint job that runs jshint ?
Merge MWMediaInsertDialog and MWMediaEditDialog into one dialog that has an insert page and an edit page, and a BookletLayout without an outline. This way we can switch between modes without closing one dialog and opening another.

--------------------------
**Version**: unspecified
**Severity**: enhancement
*** This bug has been marked as a duplicate of bug 67170 ***
Toolserver has a limited and anonimized view of the user_properties table available. This is used for reports like https://en.wikipedia.org/wiki/Wikipedia:Database_reports/User_preferences

mysql> describe user_properties;
| Field       | Type           | Null | Key | Default | Extra |
| -----  | -----  | -----   | ----- | ----- | ----- |
| up_user     | int(11)        | NO   |     | 0       |       |
| up_property | varbinary(255) | YES  |     | NULL    |       |
| up_value    | blob           | YES  |     | NULL    |       |
3 rows in set (0.00 sec)

mysql> describe user_properties_anonym;
| Field                   | Type           | Null | Key | Default | Extra |
| -----  | -----  | -----   | ----- | ----- | ----- |
| up_property             | varbinary(255) | YES  |     | NULL    |       |
| up_value                | blob           | YES  |     | NULL    |       |
| ts_user_touched_cropped | varbinary(8)   | NO   |     |         |       |
3 rows in set (0.00 sec)

Only preferences that are considered to be public are replicated, the list from enwiki_p is:
mysql> select distinct(up_property) from user_properties;
| up_property    |
| -----  |
| disablemail    |
| fancysig       |
| gender         |
| language       |
| nickname       |
| skin           |
| timecorrection |
| variant        |

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
* {T27302}
* {T21288}
The underlying data has been backfilled.
Re-opening since the `user_properties_anon` table is still missing the `upa_touched` timestamp field (per @coren earlier's comment, this is blocked on T92841).
Re-opening since the `user_properties_anon` table is still missing the `upa_touched` field (per @coren earlier's comment, this is blocked on T92841).
T66115 has been resolved, but `user_properties_anon` isn't working properly yet since `upa_touched` is null everywhere. (Depends on T92841).

Due to the lack of this column, utility queries previously common on Toolserver like "How many active users are using gadget X" are not possible. And essential queries for gadget maintainers when making decisions about deprecated gadgets being replaced, etc.

Now we get shell requests for these (or over IRC) and run them in production. But it'd be better if people can run these themselves in labs or via Quarry.
T66115 has been resolved, but `user_properties_anon` isn't working properly yet since `upa_touched` is null everywhere. (Depends on T92841).

Previously common utility queries like "How many active users are using Cologne Blue" are not possible yet. And essential queries for gadget maintainers when making decisions about deprecated gadgets being replaced.

Now we get shell requests for these (or over IRC). But it'd be better if they can run those themselves.
The view exists, and is working.  Whitelisting other properties is fairly easy, but requests for this should be made in separate tasks.
>>! In T60196#1123999, @Ricordisamoa wrote:
> AFAICS, and as noted in this task's description, the user_properties table already contains "preferences that are considered to be public", such as the ones you mentioned.
> 
> Just tried:
> ```lang=sql
> SELECT up_value FROM user_properties INNER JOIN user ON user_id = up_user AND user_name = 'Ricordisamoa' AND up_property = 'gender';
> ```

Huh, fair play. I guess most of this database report got fixed with the resolution of {T66115}.
>>! In T60196#1123825, @MZMcBride wrote:
> Thank you for <https://gerrit.wikimedia.org/r/197055>!
> 
> Looking at <https://en.wikipedia.org/wiki/Wikipedia:Database_reports/User_preferences/Configuration>, it looks like "gender", "language", and "skin" would be the easiest targets next. If anyone would prefer to close this task as resolved and file new tasks for additions to the whitelisted user properties list, I'm fine with that.

AFAICS, and as noted in this task's description, the user_properties table already contains "preferences that are considered to be public", such as the ones you mentioned.

Just tried:
```lang=sql
SELECT up_value FROM user_properties INNER JOIN user ON user_id = up_user AND user_name = 'Ricordisamoa' AND up_property = 'gender';
```
It was `user_properties_anonym` on the Toolserver and it's `user_properties_anon` now. Probably doesn't really matter, just noting.

Thank you for <https://gerrit.wikimedia.org/r/197055>!

Looking at <https://en.wikipedia.org/wiki/Wikipedia:Database_reports/User_preferences/Configuration>, it looks like "gender", "language", and "skin" would be the easiest targets next. If anyone would prefer to close this task as resolved and file new tasks for additions to the whitelisted user properties list, I'm fine with that.
Change 197055 merged by coren:
Update maintain-replicas

[[https://gerrit.wikimedia.org/r/197055]]
The view has been created (on all but size 1 wikis) but the timestamps currently return NULL because none of the user_touched values are on the replicas at this time (they are redundantly nulled during replication and in the views).
Change 197055 had a related patch set uploaded (by coren):
Update maintain-replicas

[[https://gerrit.wikimedia.org/r/197055]]
>>! In T60196#1120423, @MZMcBride wrote:
> Can we start with "gadget-*" and then decide on the others in a separate future task?

Sounds like a reasonable first pass.  I'll have to do some testing to see if wildcard matching is sufficiently efficient for the view to be usable; but otherwise I'll collect the existing gadget- names and use those as our first whitelist.
>>! In T60196#1109452, @coren wrote:
> The one thing I am missing to implement this at this time is either
> (a) the whitelist of properties to collate or
> (b) the method by which that whitelist is generated.

Can we start with "gadget-*" and then decide on the others in a separate future task?
The one thing I am missing to implement this at this time is either
(a) the whitelist of properties to collate or
(b) the method by which that whitelist is generated.
A brief summary of past discussion and verification that we understood each other.

A database view with a whitelisted set of keys is available with connections to individual accounts (`fancysig`, `language`, `nickname`, `timecorrection`, etc.). This information is already available by other means and is provided as convenience to perform queries on. This database view has since been created!

An anonymised database view will be created as follows:
* `up_user`: omit. This view will not associate preferences with users.
* `up_property`: included. As was Toolserver, the set of properties exposed may be quite large and controlled by a whitelist (to avoid exposing new sensitive properties by accident). The whitelist includes wildcard patterns for things like `gadget-*`.
* `up_value`: included.
* `_user_touched_cropped`: generated based on `user.user_touched` value where `user.user_id = up_user`. Trimmed to YYYY-MM. Values for the current month are displayed as last month's.


The reason the current month is displayed as last month's is to reduce chances of identifying users via their activity at the start of a month (which is not limited by the size of a wiki). This because using timestamps of YYYY-MD essentially reset every month. This in contrary to Special:ActiveUsers, which rolls continuously using relative timespan of "last 30 days". Without this modification, one could link a recently active user on a wiki at the start of a month. This modification would extend that timeframe from mere seconds to two full months (a user would have to be the only one active for two months). Note that this is for a timespan for two months, not one. Is that acceptable or should be still disable this view on small wikis? (Toolserver had it enabled for all wikis.)
There are, in essence, two steps.  The underlying table needs to be replicated, and a view need to be created to it.

Access to the underlying table is already there (it is used to provide the view into limited number of keys); all that is needed is the creation of a new view that carefully aggregates the data and respects the size limits, etc.

The script that creates the views is there:

https://git.wikimedia.org/blob/operations%2Fsoftware/HEAD/maintain-replicas%2Fmaintain-replicas.pl

I'm usually the one who creates views, but my schedule is a bit on the buried side.  I'd be happy to review a patch adding the view - look starting line 90, it should be fairly evident how to add one.
>>! In T60196#630652, @LuisV_WMF wrote:
> If the users are OK with the month-filtered view, and exclusion of small wikis, that seems like a workable compromise to me.

Okay, this sounds like sign-off to me.

Who does this typically? @coren or @Springle? Is there documentation for what's needed to add/remove a database table or column from Labs' views? I vaguely remember there now being two filters in place, maybe.

If anyone has links to the code repos or documentation (or even another task where we did something similar), that would likely help move this forward. At this point, it sounds like there's general consensus to move forward, this just hasn't been written out and gone through Gerrit/code review.
(In reply to Luis Villa (WMF Legal) from comment #51)
> If the users are OK with the month-filtered view, and exclusion of small
> wikis, that seems like a workable compromise to me.

Well to speed up the process and keep compatibility at the same time, it would be better to add the view now, with YYYYMMDD rewritten as YYYYMM01 on larger wikis, and as 19700101 on small wikis, and we can keep discussing afterwards...
If the users are OK with the month-filtered view, and exclusion of small wikis, that seems like a workable compromise to me.
(In reply to Silke Meyer (WMDE) from comment #49)
> * As far as we know, "live" tools depended on #64115 (filtered view) which
> has been resolved. But no live tools seem to depend on this one. Please
> correct me, if I am wrong!

http://toolserver.org/~liangent/gadget_usage/
Summary of what was discussed during office hour (https://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140611.txt, from [17:17:25] on):

* This will probably take longer for WMF Legal, so it's unlikely that it will be done before Toolserver shutdown.
* As far as we know, "live" tools depended on #64115 (filtered view) which has been resolved. But no live tools seem to depend on this one. Please correct me, if I am wrong!

Still, it would be interesting to get an update from Luis. :)
Hi Luis, do the comments 46 and 47 provide the answers you need? If not, who can help? We are ... sort of in a hurry by now.
Active editors are not the only users changing preferences on a wiki, there are also many global users changing preferences everywhere (or in many places); only user_touched knows that.
Hi Luis, thanks for the update.

(In reply to Krinkle from comment #40)
> 
> To avoid strange statistical variance like that, I'd recommend making
> timestamp of the currently running month appear as last month's. That way no
> data is excluded. This seems like a simple enough variance that tools should
> be able to work with without much hassle.

I think it is good solution. The timestamp is used mainly for filtering active vs non-active users.


(In reply to Luis Villa (WMF Legal) from comment #42)
> (In reply to Tisza Gergő from comment #35)
> > Maybe instead of a live view, this table could be generated by a query which
> > runs at the end of the day; that way no information is leaked by the timing
> > of the change. Although that still does not solve the issue for small wikis
> > since we probably want to run it more often than once a month.
> 
> If we only provide one month granularity in the answer, then it can be run
> only once a month, right? Sounds like the use cases here don't need
> precise/fine-grained answers to this question?

*My use case: the user_properties_anonym table is used for generating[[meta:Gadgets]] - statistics on the most popular gadgets accross Wikimedia projects.
* (other example for use case) User preferences statistics are provided by MZMcBride in [[en:Wikipedia:Database reports/User preferences]]
So I belive one month resolution is fine for statistics use cases, and running it once a month could be enougth.
As Krinkle wrote above, month resolution (YYYY-MM) make it hard to associate it to specific user.


However for very very small wikis I think it isn't possible to provide such statistics: refering to http://stats.wikimedia.org/EN/TablesWikipediansEditsGt5.htm (Wikipedias by active users) some languages such as Tsonga or Oromo have only one active user. I think there should be a threshold on the number of active users in a wiki.
Current status of the bug is "questions have been posed about privacy concerns". It would be helpful to have feedback from people who use the field; in particular, my question in comment 42 and response to Krinkle's last statement in comment 40 would be good.
Changing to major per previous comment.
What is the current status of the bug?
It becomes very importantly to fix it in the very soon future, as the toolserver is going to be down in 3 weeks

http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2014-June/000722.html
(In reply to Tisza Gergő from comment #35)
> Maybe instead of a live view, this table could be generated by a query which
> runs at the end of the day; that way no information is leaked by the timing
> of the change. Although that still does not solve the issue for small wikis
> since we probably want to run it more often than once a month.

If we only provide one month granularity in the answer, then it can be run only once a month, right? Sounds like the use cases here don't need precise/fine-grained answers to this question?
> To avoid strange statistical variance like that, I'd recommend making timestamp of the currently running month appear as last month's.

I don't see how that would help (other than making the window of opportunity smaller). You could still poll the data on the first day of the month to get an accurate edit timestamp. Since the attack is based on reading *when* the timestamp changes and correlating that with edit times, *what* the timestamp changes to is irrelevant. If you want users of the table to have a precision of T, you could protect users who edit more often than T by setting the timestamps to some deterministically chosen point within T so that changes within that interval are suppressed, but information would still leak about users who edit less often. For T = 1 day, that's hardly acceptable, even on large wikis.

We could randomize the last few bits of the date, that would make it hard to tell when it changes, but it would still be doable via statistical means... really the only reliable way to mitigate this is to use a temporary table instead of a view, and only update it once a day/week/whatever so that the timing of the field changing becomes completely disconnected from the timing of the edit.
(In reply to Tim Landscheidt from comment #39)
> (In reply to Krinkle from comment #38)
> > [...]
> 
> > In theory this could still be exploited by being a patient person and
> > waiting for the moment one month has ended. Then the first user to become
> > active in the new month would be the only person with a newer month
> > timestamp.
> 
> > [...]
> 
> Could this be mitigated by excluding data for the current month?

Essentially, yes. See my comment 17:

(citing comment #17 from Krinkle)
> [..] no matter how much we crop the timestamp (even if we'd crop it to the
> month or year), one could in theory still retrieve the preferences of one
> user by performing queries in a loop until the next day, month or year
> starts and correlate that to the one user currently editing on that wiki..
>
> The only way I can think of that would mitigate that is forcing the current
> matching crop of the date being delayed (e.g. all users active today on
> 2014-03-17 would be listed under 2014-03-16 until this day is over, so that
> all active users have had a chance to be active that day).

However "excluding data" isn't trivial. It'll make statistics and sum queries act very counter intuitive. If you'd exclude all rows where timestamp == current YYYY-MM, that would essentially hide all values of active users, and make them re-appear next month and back and forth like that.

To avoid strange statistical variance like that, I'd recommend making timestamp of the currently running month appear as last month's. That way no data is excluded. This seems like a simple enough variance that tools should be able to work with without much hassle.
(In reply to Krinkle from comment #38)
> [...]

> In theory this could still be exploited by being a patient person and
> waiting for the moment one month has ended. Then the first user to become
> active in the new month would be the only person with a newer month
> timestamp.

> [...]

Could this be mitigated by excluding data for the current month?
Changing the timestamp in this table based on wiki size would be a mistake in my opinion. It would make the data too arbitrary and hard to maintain. It also probably won't scale well into the MySQL mapping and relevant configuration.

The reason we don't want to provide the full timestamp is because it exposes rather detailed information that would be trivial to map to an individual on most wikis (even large wikis) based on when an edit has happened.

Shortening this to a month minimised this ability greatly, reducing it to only being able to tell that those with the current month as their last-active timestamp (YYYY-MM) are one of the users listed on Special:ActiveUsers.

In theory this could still be exploited by being a patient person and waiting for the moment one month has ended. Then the first user to become active in the new month would be the only person with a newer month timestamp.

For this particular exploit it is irrelevant how much we crop the timestamp (year, month, date, it's all the same, it only reduces how often one can make such attempt and with that the usefulness the data in the first place).

If we consider that possibility important enough to warrant a solution, then that solution will work equally for year, month and day. I don't think there is any reason to trim it further than month, nor is there any reason to bring small/medium/large into the balance.
Small/medium/big wikis have 10/100/1000 thousands total pages or more. You can see the lists at https://noc.wikimedia.org/conf/ The lists were originally made as rough indication of how expensive certain heavy database operations are (you can easily find the bugs in question).
(In reply to Luis Villa (WMF Legal) from comment #34)
> Sorry for the slow response, Liangent - email slipped through the cracks for
> some reason. Q: what's the criteria for small/medium/large? And how often is
> that updated? 

I have no idea about the criteria, but I guess generally wikis only grow larger, and if the list is not updated in time, we're just anonymizing more, not less.
(In reply to Tisza Gergő from comment #33)
> As for timestamp anonimization, showing the (truncated) date of the last
> edit of the user which did not happen in the current day(/month/year) should
> be pretty straightforward.

Nevermind, I see this comes from user_touched, not the edit log, and we do not keep a past record of that.

Maybe instead of a live view, this table could be generated by a query which runs at the end of the day; that way no information is leaked by the timing of the change. Although that still does not solve the issue for small wikis since we probably want to run it more often than once a month.
Sorry for the slow response, Liangent - email slipped through the cracks for some reason. Q: what's the criteria for small/medium/large? And how often is that updated? 

And Gergo's q is a good one too.
Is the order of rows randomized? Being able to correlate other preferences with, say, fancysig based on row number would be bad.

As for timestamp anonimization, showing the (truncated) date of the last edit of the user which did not happen in the current day(/month/year) should be pretty straightforward.
(In reply to Luis Villa (WMF Legal) from comment #31)
> So, let's keep this bug focused on the question of the "anonymized" table;
> i.e., the table that currently has most (but not all) rows, with userID
> removed but last active timestamp available. 
> 
> The current proposal is to provide this table on labs. It has also been
> suggested that:
> 
> 1) we remove the whitelist altogether and provide everything; and/or
> 2) we sample down the timestamp to YYYY-MM so that it is more difficult to
> map "last active" to editors on small wikis.
> 
> I still have a few concerns:
> 
> 1) I still don't know how we created the original whitelist, or how we plan
> to create the new one. (Note that if we trust our anonymization, having a
> whitelist probably isn't necessary.)

Note that some user_properties rows are not actually preferences. eg. watchlisttoken.

> 
> 2) I'm still concerned about the impact on anonymity of small wikis.
> Rounding to months helps, but could still be problematic in at least some
> cases (as Krinkle pointed out).

So ... wikis are already grouped as small, medium and large, then YYYYMMDD in large, YYYYMM in medium and YYYY in small wikis?

https://noc.wikimedia.org/conf/highlight.php?file=large.dblist
https://noc.wikimedia.org/conf/highlight.php?file=medium.dblist
https://noc.wikimedia.org/conf/highlight.php?file=small.dblist

> I do not have a great solution to these questions. Trying to
> brainstorm/think out loud here: maybe we could provide aggregate totals for
> all editors, for active editors, and for new editors (based on the standard
> analytics definition of active editors/new editors), instead of access to
> individually anonymized rows?
So, let's keep this bug focused on the question of the "anonymized" table; i.e., the table that currently has most (but not all) rows, with userID removed but last active timestamp available. 

The current proposal is to provide this table on labs. It has also been suggested that:

1) we remove the whitelist altogether and provide everything; and/or
2) we sample down the timestamp to YYYY-MM so that it is more difficult to map "last active" to editors on small wikis.

I still have a few concerns:

1) I still don't know how we created the original whitelist, or how we plan to create the new one. (Note that if we trust our anonymization, having a whitelist probably isn't necessary.)

2) I'm still concerned about the impact on anonymity of small wikis. Rounding to months helps, but could still be problematic in at least some cases (as Krinkle pointed out).

I do not have a great solution to these questions. Trying to brainstorm/think out loud here: maybe we could provide aggregate totals for all editors, for active editors, and for new editors (based on the standard analytics definition of active editors/new editors), instead of access to individually anonymized rows?
I'm cloning this bug so that we can have two discussions - one about the anonymized data, one about the filtered data. The discussion about a filtered view (with the handful of properties described in the original bug description and in comment #23) is now in bug 64115. I will continue the other discussion in my next comment.
FYI, a "ghost infrastructure" makes this data available to select users, per http://lists.wikimedia.org/pipermail/analytics/2014-April/001768.html : folks should/can ask [[wikitech:EventLogging]] access if they need it.
ASSIGNED != pending
There's no reason to change the status of the bug, it remains pending an all-clear from Legal and a short implementation away.
(In reply to silke.meyer from comment #24)
> Hello! What's the status on this?

No movement in 4 months: resetting status.
*** Bug 56491 has been marked as a duplicate of this bug. ***
Hello! What's the status on this?
(In reply to Luis Villa (WMF Legal) from comment #22)
> To confirm: INTERSECT here is the whitelist; DIFF 1 is properties that never
> made it onto the whitelist?

That is correct.

INTERSECT are properties present in both Toolserver's anonymized view and in wikimedia production databases.

DIFF 1 are properties present in production and not visible in Toolserver anonymized view.

DIFF 2 are properties only present in Toolserver's anonymized view (none).


The Toolserver's non-anonimized filtered view has a much stricter whitelist:

nlwiki_p at toolserver> SELECT DISTINCT(up_property) FROM user_properties;
+----------------+
| up_property    |
+----------------+
| disablemail    |
| fancysig       |
| gender         |
| language       |
| nickname       |
| skin           |
| timecorrection |
| variant        |
+----------------+
8 rows in set
To confirm: INTERSECT here is the whitelist; DIFF 1 is properties that never made it onto the whitelist?
Do we know how that whitelist was created?
(In reply to Luis Villa (WMF Legal) from comment #18)
> (In reply to Krinkle from comment #17)
> > So if I understand correctly, the whitelist of properties you approved in
> > comment 12 are in fact allowed for identifiable queries (e.g. with
> > user_id/user name attached to it), as opposed to the anonymized view.
> 
> Yes, that is correct, for those categories. 
> 
> As far as implementation, we'll want to review new fields as they are added,
> which is why I prefer a whitelist approach (review what is released; hard to
> accidentally release data accidentally) to a blacklist approach (review what
> is not released; easy to release data accidentally by not adding it to the
> blacklist).
> 
> > And when you say "OK in principle" for the anonymized view, that means all
> > properties?
> 
> Yes, based on my understanding that they are already available on toolserver
> in user_properties_anonym and/or via the API. If they aren't already public
> (via API or toolserver) we should probably review one-by-one, and/or do a
> more careful scrutiny of the anonymization procedures. Maybe that deserves a
> separate bug?

anonym on Toolserver is also whitelist based. I don't have access to the original list ts_global.user_properties_anonym_whilelist, but it's possible to sniff it with select distinct up_property from user_properties_anonym; (a slow query).
(In reply to Krinkle from comment #17)
> So if I understand correctly, the whitelist of properties you approved in
> comment 12 are in fact allowed for identifiable queries (e.g. with
> user_id/user name attached to it), as opposed to the anonymized view.

Yes, that is correct, for those categories. 

As far as implementation, we'll want to review new fields as they are added, which is why I prefer a whitelist approach (review what is released; hard to accidentally release data accidentally) to a blacklist approach (review what is not released; easy to release data accidentally by not adding it to the blacklist).

> And when you say "OK in principle" for the anonymized view, that means all
> properties?

Yes, based on my understanding that they are already available on toolserver in user_properties_anonym and/or via the API. If they aren't already public (via API or toolserver) we should probably review one-by-one, and/or do a more careful scrutiny of the anonymization procedures. Maybe that deserves a separate bug?
So if I understand correctly, the whitelist of properties you approved in comment 12 are in fact allowed for identifiable queries (e.g. with user_id/user name attached to it), as opposed to the anonymized view. That's great news. I wasn't expecting a non-anonymized view of the properties table at all. Having one with this limited set of properties can be useful indeed.

And when you say "OK in principle" for the anonymized view, that means all properties?

Good point on the user activity measure being potentially identifying on small wikis. I suppose a month crop of the timestamp (YYYY-MM) would still be good enough for practical applications and be a lot less likely to reveal identifying information.

Though no matter how much we crop the timestamp (even if we'd crop it to the month or year), one could in theory still retrieve the preferences of one user by performing queries in a loop until the next day, month or year starts and correlate that to the one user currently editing on that wiki.. The only way I can think of that would mitigate that is forcing the current matching crop of the date being delayed (e.g. all users active today on 2014-03-17 would be listed under 2014-03-16 until this day is over, so that all active users have had a chance to be active that day).
Retitling then :) 

For the filtered table: I am OK with this in principle, but would like to better understand (1) how we choose which fields to filter and (2) how we prevent new fields from leaking.

For the anonymized table: Again, OK in principle; it would be good (but not a must-have) to know more about the impact on users of small wikis.
(In reply to Luis Villa (WMF Legal) from comment #14)
> Ah! Thanks for explaining more clearly, Krinkle. The first comment now makes
> a lot more sense to me :) 
> 
> One question on the anonymization - this data is still per-wiki, right?
> Would last-active dates at the day-level allow deanonymization for those
> users?

Those are two different requests: one table (view) containing user identifiable info (user id) with fewer properties includes, and another anonymized one with more properties.
Ah! Thanks for explaining more clearly, Krinkle. The first comment now makes a lot more sense to me :) 

One question on the anonymization - this data is still per-wiki, right? Would last-active dates at the day-level allow deanonymization for those users?
Sorry, this got lost in the shuffle. To respond to Silke: I'm still not entirely clear which fields we're talking about replicating. If the list from en_wikip: 

+----------------+
| up_property    |
+----------------+
| disablemail    |
| fancysig       |
| gender         |
| language       |
| nickname       |
| skin           |
| timecorrection |
| variant        |
+----------------+

Is what we're actually talking about, then yes - no legal barrier to making that information available.
The gender gap plots by emijrp also depends on this:

https://toolserver.org/~emijrp/wmcharts/

(they don't work atm. for some other reason)
(In reply to comment #9)

> Legoktm, which of your tools depends on this to migrate?

Database reports, specifically [[Wikipedia:Database reports/User preferences]].
So, am I right in assuming there is no legal barrier to make that table available? 
Legoktm, which of your tools depends on this to migrate?
(In reply to comment #7)
> Ah, didn't know that, thanks. Though, given that the AbuseFilter has been
> giving out emailconfirmed timestamps (bug 20005), it's probably a moot point.

That seems to me a good reason to fix 20005 more than anything (especially since that isn't in the dumps).
(In reply to comment #6)
> (In reply to comment #4)
> > For example, if you go to Special:EmailUser, you can tell if a user has
> > disabled email or not (disableemail).
> 
> That's not actually correct; you can know whether someone has disabled their
> email /or/ never confirmed one to begin with (i.e.: it's emailconfirmed &&
> !disableemail).

Ah, didn't know that, thanks. Though, given that the AbuseFilter has been giving out emailconfirmed timestamps (bug 20005), it's probably a moot point.
(In reply to comment #4)
> For example, if you go to Special:EmailUser, you can tell if a user has
> disabled email or not (disableemail).

That's not actually correct; you can know whether someone has disabled their email /or/ never confirmed one to begin with (i.e.: it's emailconfirmed && !disableemail).
If a field is already exposed by the API/website, then that's fine. Just wasn't clear which of those fields that was already true for.
(In reply to comment #3)
> Legoktm, when you say "Only preferences that are considered to be public are
> replicated, the list from enwiki_p is..." is that the list of things
> currently
> considered public? Or the list of things that could be made public?

Since it's already replicated onto the Toolserver, I assume they are currently considered to be public.

For example, if you go to Special:EmailUser, you can tell if a user has disabled email or not (disableemail). fancysig/nickname are just a user's signature, which is public as soon as a user adds ~~~~ to any page. gender is also exposed by the software and the API.
I don't think we've formally set out a policy that new field replication has to run through legal, but it's a good habit to be in.

Legoktm, when you say "Only preferences that are considered to be public are replicated, the list from enwiki_p is..." is that the list of things currently considered public? Or the list of things that could be made public?
Adding Luis Villa so that he can chime in.
Coren says there's a requirement that the Wikimedia Foundation legal team sign off on changes of this nature. I'm not able to verify this requirement. The process seems to be largely undocumented, though as far as I'm aware, there was never any such requirement during the Toolserver's reign: it was merely left to root discretion.
Steps to reproduce:


1.Open the editor for a page which contains a link
2.Copy the link
3.Now open VE for another article and paste the copied link onto it
4.Save the page


Observed Result:

The copied link appears as a plain text on the read mode where as in the Edit Source/Edit mode it appears as a link

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=58138
Verified the fix on test 2
Change 108954 merged by jenkins-bot:
Relativise URLs against target document

https://gerrit.wikimedia.org/r/108954
Possibly now fixed. Hopefully.
Change 108953 had a related patch set uploaded by Krinkle:
Resolve URLs against correct document when copying.

https://gerrit.wikimedia.org/r/108953
Change 108954 had a related patch set uploaded by Esanders:
Relativise URLs against target document

https://gerrit.wikimedia.org/r/108954
Sorry 16th January :)
Ed, I tested it on 16th december(Last thursday) after the deployment on test2.So it should have been merged to test2 by that time right? Also, I am still getting it on test2
The last fix was merged on 15th Jan. The test environment you point to says it is running code from 14th Jan. Please re-open if broken with master.
*** Bug 59216 has been marked as a duplicate of this bug. ***
The testing environment is test2, wmf 11.
Broswer:Chrome/Firefox
The issue described later in this bug still exists in test.Again giving the steps here:
This issue is still occurring for following case:

1.Open the editor for a page "A" which contains a link to another page "B"
2.Copy the link and Paste it into "B"
3.Save the page

Observed Result:
The link to the same page is appearing as plain text in the read mode.
Change 105706 merged by jenkins-bot:
Support external links in MWInternalLinkAnnotation

https://gerrit.wikimedia.org/r/105706
Change 106253 merged by jenkins-bot:
Always use absolute URLs in external links in the clipboard

https://gerrit.wikimedia.org/r/106253
Change 106253 had a related patch set uploaded by Esanders:
Always use absolute URLs in external links in the clipboard

https://gerrit.wikimedia.org/r/106253
Change 105706 had a related patch set uploaded by Esanders:
Always use absolute URLs in external links in the clipboard

https://gerrit.wikimedia.org/r/105706
This issue is still occurring for following case:

1.Open the editor for a page "A" which contains a link to another page "B"
2.Copy the link and Paste it into "B"
3.Save the page

Observed Result:
The link to the same page is appearing as plain text in the read mode.

Found in :http://en.wikipedia.beta.wmflabs.org/wiki/The_paste_destination
verified the fix in test2:https://test2.wikipedia.org/w/index.php?title=13th_december
Verified in betalabs
A fix for this is going out in about 4 minutes' time. Sorry for the disruption.
Change 100493 merged by jenkins-bot:
Only strip style attributes on rich paste from VE

https://gerrit.wikimedia.org/r/100493
Change 100422 merged by jenkins-bot:
Only strip style attributes on rich paste from VE

https://gerrit.wikimedia.org/r/100422
Change 100493 had a related patch set uploaded by Jforrester:
Only strip style attributes on rich paste from VE

https://gerrit.wikimedia.org/r/100493
Change 100422 had a related patch set uploaded by Esanders:
Only strip style attributes on rich paste from VE

https://gerrit.wikimedia.org/r/100422
Page: Observe the second "Edit source" text on the page:
http://en.wikipedia.beta.wmflabs.org/wiki/To_edit_source

Test Environment: Betalabs
Browser: Chrome Version 26.0.1410.65
OS: MAC OS X 10. 8. 5
screenshot

The icon for underline option is missing in betalabs:http://en.wikipedia.beta.wmflabs.org/wiki/The_link?veaction=edit

See the screenshot attached.

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

**Attached**: {F12362}
Verified
Change 99755 merged by jenkins-bot:
Followup 418f2606e03b82a5ae0afc853406c7e9f2d1e35f: put <?xml tag back.

https://gerrit.wikimedia.org/r/99755
Change 99755 had a related patch set uploaded by Catrope:
Followup 418f2606e03b82a5ae0afc853406c7e9f2d1e35f: put <?xml tag back.

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

<ooui-toolbar-more> is showing up instead of More button in betalabs
http://en.wikipedia.beta.wmflabs.org/wiki/6th_december?veaction=edit

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

**Attached**: {F12338}
Deployment bug, now fixed.
Created attachment 14009
screenshot of the notification

**Attached**: {F12339}
Also instead of the notification message after saving a page <visualeditor-notification-saved> is appearing.

See the screenshot attached.
**Author:** `Wikifram`

**Description:**
When you have made changes to a page in VE, you can use the "undo" button to reverse these. However, the page doesn't scroll when doing this, so you don't "see" what the undo is actually doing. The same probably applies to the "redo" button, I haven't checked that one

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51911
This was probably fixed a while ago.
(In reply to Alex Monk from comment #3)
> Dupe then?

Doing it for the undo/redo stack is probably complicated, so I was leaving them distinct.
Dupe then?
(In reply to Alex Monk from comment #1)
> Hmm... Shouldn't this be a case of scrolling to the new location of the
> cursor when you undo/redo?

Pretty much, which is bug 51911.
Hmm... Shouldn't this be a case of scrolling to the new location of the cursor when you undo/redo?
Screenshot

Steps to reproduce:

1.Open the VE for a page in a User's namespace
2.Hover your mouse over the position where the link to user namespace appears in the Read mode.
3.Click on that position

Observed Result:
It redirects to user namespace from VE.

See the screenshot attached.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52243
https://bugzilla.wikimedia.org/show_bug.cgi?id=54325

**Attached**: {F12247}
Environment:Production (https://en.wikipedia.org/)
Browser:Chrome Version 26.0.1410.65 & FF 25
OS: MAC OS X 10. 8. 5
Screenshot

Steps to reproduce:

1.Open the editor
2.Place the cursor in the middle of a text
3.Then click on More>Hieroglyphics
4.The inspector does not open just the < icon in that position.
5.Save the page
6.Reopen the editor.


Observed Result:
The text after that cursor position gets shifted to the newline and a return arrow appears after reopening the editor.

For a text which is not link it just goes to the next line but the return arrow does not get added.

See the screenshot attached

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

**Attached**: {F12190}
I believe that this is now fixed… can't really check any more, though.
While going to the next line it also adds an empty <hiero> tags in that position.
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=The_something&veaction=edit
Created attachment 13994
Screenshot of the < appearing instead of the hieroglyphics inspector

**Attached**: {F12191}
Screenshot

Steps to reproduce:


1.Open the editor.
2.Select an image
3.Select the option More>Latex/Hieroglyphics

Observed Result:

A small input window opens up over the window where text can be inserted.

In the console I get the following error:
Uncaught TypeError: Cannot read property 'body' of undefined load.php:521
ve.ui.MWExtensionInspector.setup load.php:521
(anonymous function) load.php:113
proxy load.php:10
listenerWrapper load.php:98
oo.EventEmitter.emit load.php:98
(anonymous function) load.php:110
pollExternalStylesheets

See the screenshot attached

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=60804
https://bugzilla.wikimedia.org/show_bug.cgi?id=56644

**Attached**: {F12183}
Verified the fix in production
Verified the fix in test2
Change 129622 merged by jenkins-bot:
Create MWLiveExtensionInspector base class

https://gerrit.wikimedia.org/r/129622
Change 129622 had a related patch set uploaded by Jforrester:
Create MWLiveExtensionInspector base class

https://gerrit.wikimedia.org/r/129622
Change 126900 merged by jenkins-bot:
Create MWLiveExtensionInspector base class

https://gerrit.wikimedia.org/r/126900
Change 126900 had a related patch set uploaded by Esanders:
Create MWLiveExtensionInspector base class

https://gerrit.wikimedia.org/r/126900
WFM
Contrast with up/down which always keeps the cursor in view.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=68708
Seems to work now.
LQT intercepts section=new from users to add a new thread (but not via the API, see bug 41276). It'd be really awesome if Flow could let you add a new topic like this, using the old API.

https://www.mediawiki.org/wiki/API:Edit#Example

--------------------------
**See Also**: 
* {T43276}
* {T85197}
Note that will work for both wikitext and Flow, so the gadget does not need to know which the page is.

The above is for if you're trying to create the post immediately through the script.

---

It looks like for this example, you just want to prefill it (rather than use the API), then let the user edit before saving.  Flow supports that too:

https://www.mediawiki.org/wiki/User_talk:Mattflaschen-WMF?topiclist_preloadtitle=Preloaded%20title&topiclist_preload=User:Mattflaschen-WMF/Preloaded%20body%20example

The preloadtitle is inlined.  The preload is a template (in this example [User:Mattflaschen-WMF/Preloaded body example](https://www.mediawiki.org/wiki/User:Mattflaschen-WMF/Preloaded_body_example).

This is basically the same as for old-style talk pages.  For old-style, it's:

https://en.wikipedia.org/wiki/User_talk:Mattflaschen-WMF?preloadtitle=Preloaded title&preload=User:Mattflaschen-WMF/Preloaded body example&action=edit&section=new

In that case, you do currently need to check what kind of page it is, though, using prop=info:

https://en.wikipedia.org/w/api.php?action=query&titles=User%20talk:Mattflaschen-WMF&prop=info

vs.

https://www.mediawiki.org/w/api.php?action=query&titles=User%20talk:Mattflaschen-WMF&prop=info

There is a possibility to make this use case easier for script writers: {T107637}
Note that will work for both wikitext and Flow, so the gadget does not need to know which the page is.

The above is for if you're trying to create the post immediately through the script.

---

It looks like for this example, you just want to prefill it (rather than use the API), then let the user edit before saving.  Flow supports that too:

https://www.mediawiki.org/wiki/User_talk:Mattflaschen-WMF?topiclist_preloadtitle=Preloaded%20title&topiclist_preload=User:Mattflaschen-WMF/Preloaded%20body%20example

The preloadtitle is inlined.  The preload is a template (in this example [User:Mattflaschen-WMF/Preloaded body example](https://www.mediawiki.org/wiki/User:Mattflaschen-WMF/Preloaded_body_example).

This is basically the same as for old-style talk pages.  For old-style, it's:

https://en.wikipedia.org/wiki/User_talk:Mattflaschen-WMF?preloadtitle=Preloaded title&preload=User:Mattflaschen-WMF/Preloaded body example&action=edit&section=new

In that case, you do currently need to check what kind of page it is, though, using action=info:

https://en.wikipedia.org/w/api.php?action=query&titles=User%20talk:Mattflaschen-WMF&prop=info

vs.

https://www.mediawiki.org/w/api.php?action=query&titles=User%20talk:Mattflaschen-WMF&prop=info

There is a possibility to make this use case easier for script writers: {T107637}
>>! In T59989#1499951, @tarlocesilion wrote:
> I believe, I should emphasize that this gadget is old (2006) and //very// popular among experienced Wikipedians, the core of plwiki community, who are likely to be //concerned// about next Flow releases, not only on personal talk pages. Just for the record, if action=edit&section=new isn't to be supported, please, create something instead.

Our recommended solution is to use mw.messagePoster (which we implemented for this purpose).  Usage:

```
	var title = new mw.Title( 'titleString' );
	var posterPromise = mw.messagePoster.factory.create( title );
	posterPromise.done( function ( poster ) {
		poster.post( 'This is the topic title', 'This is the body of a message posted with MessagePoster' );
	} );
```

The gadget should also depend on 'mediawiki.messagePoster' and 'mediawiki.Title' (user scripts can depend on those with mw.loader.using).

If you need further technical assistance, please ask (e.g. in #wikimedia-collaboration on IRC).
I believe, I should emphasize that this gadget is old (2006) and //very// popular among experienced Wikipedians, the core of plwiki community, who are likely to be //concerned// about next Flow releases, not only on personal talk pages. Just for the record, if action=edit&section=new isn't to be supported, please, create something instead.
Note: This has consequences (breakage) for some gadgets, such as 
https://pl.wikipedia.org/wiki/Wikipedia:Narz%C4%99dzia/Odpowiedzi_z_linkami - A "replylinks" gadget at the Polish Wikipedia that adds an "`[odp]`" (or  "`[reply]`") link after all userpage links, and when clicked, it creates a new user_talkpage section, using the heading of the section that the [reply] link was in.

E.g. Clicking [reply] at: 
{F292406}
then opens that user's talkpage, and starts a new section, like so:
{F292405}
@legoktm convinced us not to take this approach, at least for now.

We're instead going to target the sources (e.g. {T91805}), inform early adopters of user talk of this risk ({T90383}), and keep an eye out for reports of missing messages (then fix, or help authors' fix, them to support Flow).
>>! In T59989#1067648, @Mattflaschen wrote:
>>>! In T59989#1067094, @Legoktm wrote:
>> I still think this is a bad idea. It makes transition just a little bit easier, but it means that bots or tools that aren't Flow-aware are just going to more serious issues later on.
>> 
>> Tools like mw.feedback should allow Flow to override them to use its API or something.
> 
> I think this will be good enough for some write-only tools (they may never need to update to explicitly be Flow-aware).  Others definitely will need to, but this will hopefully ease the transition.

There are no 'write-only' tools, they all have some read actions. What happens if a page is protected? Or they trigger a captcha? Or (spam|title)blacklist/AF is hit? Is Flow going to re-write all of those error cases into their wikitext equivalents? Are we going to strip ~~~~ from posts because (last I checked) that doesn't work in Flow?

It will ease the transition by putting a band-aid over it, but it's going to hurt a lot more when you take that band-aid off.

> We definitely plan on working towards all tools handling Flow correctly; this is just one aspect of that.

Why not just do that from the beginning? If someone tries action=edit on a Flow page, return an error so they're forced to fix the tool.
hmm, i guess we could be evil and give them the rev id of the page we just created in NS_TOPIC for it, but that probably wont be what they expect :)  Will have to ponder this a bit.
Yeah, that sounds right.  It [looks like](https://www.mediawiki.org/wiki/API:Edit#Example) we're have to do some tricks with the revid (we also need to support at least XML and JSON, preferably all the output formats).
I was initially thinking this was basically going to be a rewrite procedure:

* receive api request, rewrite to flow api request
* receive flow response, rewrite to look like normal api response.
I was initially thinking this was basically going to be a rewrite procedure:

* receive api request, rewrite to flow api request
* receive flow response, rewrite to look like normal api request.
We should discuss whether to try to make the output match, or just use the Flow output.
>>! In T59989#1067094, @Legoktm wrote:
> I still think this is a bad idea. It makes transition just a little bit easier, but it means that bots or tools that aren't Flow-aware are just going to more serious issues later on.
> 
> Tools like mw.feedback should allow Flow to override them to use its API or something.

I think this will be good enough for some write-only tools (they may never need to update to explicitly be Flow-aware).  Others definitely will need to, but this will hopefully ease the transition.

We definitely plan on working towards all tools handling Flow correctly; this is just one aspect of that.
I still think this is a bad idea. It makes transition just a little bit easier, but it means that bots or tools that aren't Flow-aware are just going to more serious issues later on. 

Tools like mw.feedback should allow Flow to override them to use its API or something.
This really doesn't have anything to do with LQT except that "It worked in LQT; it should work in Flow".  We're not proposing any change to LQT, though.
It also affects various other things, e.g. MoodBar (I know, I know, MoodBar's not widely used, but I hit it recently when testing an unrelated fix in MoodBar).

Plus, I'm sure it affects many things we're not thinking of.
We can't convert the https://www.mediawiki.org/wiki/VisualEditor/Feedback LQT page to Flow until this is fixed. :-(
>>! In T59989#602152, @Jdforrester-WMF wrote:
> See also bug 49636 which means that pointing MW's feedback tool at a Flow board won't work. Boo.

Now {T51636}
See also bug 49636 which means that pointing MW's feedback tool at a Flow board won't work. Boo.
Steps to reproduce:

1.Click on the Edit button for a page
2.Type two paragraphs
3.Add a text with reference
4.Add a reflist
5.Save the page
6.Re-open the editor
7.Delete the reference and the reflist and the second paragraph
8.Save the page
Observed Result:
The second paragraph and the text with reference did not get deleted.

--------------------------
**Version**: unspecified
**Severity**: normal
ryasmeen: If there is no identifiable code commit this should not be closed as FIXED but as WORKSFORME. See https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle
Cannot reproduce it now
Test Environment: betalabs
Browser: FF 25
OS: MAC OS X 10. 8. 5 
Example:http://en.wikipedia.beta.wmflabs.org/wiki/New_page_on_latex
Actual Results:  
When you open VisualEditor, the Print/Export section in the sidebar is still present.  It is not displayed when you open the same page in the wikitext editor.


Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: trivial
Change 129059 merged by jenkins-bot:
Hide some tools when VE is open

https://gerrit.wikimedia.org/r/129059
Change 129059 had a related patch set uploaded by Alex Monk:
Hide some tools when VE is open

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

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**: minor

**Attached**: {F12776}
Change 118357 merged by jenkins-bot:
mw.ViewPageTarget: Tag our state changes and reject foreign states

https://gerrit.wikimedia.org/r/118357
Rephrasing bug.

There is explicit logic in place to not update the url sometimes. This is for when we're reacting to a popstate event (e.g. you open VisualEditor from the read page, this activates the editor without a refresh, if you then click back, the browser has already updated the url and it is now telling us to react to that, we don't want to update the url again in that case).

Whenever the editor is initialised in Chrome by direct query parameter  (e.g. by clicking "Edit" on a page where we don't load visualeditor, e.g. MediaWiki's Edit source page), the weird initial popstate fired by Chrome was misinterpreted as a dynamic state change.

Then, when leaving the editor, we still think we're reacting to a popstate event so we don't touch the url.
Change 118357 had a related patch set uploaded by Krinkle:
mw.ViewPageTarget: Tag our state changes and reject foreign states

https://gerrit.wikimedia.org/r/118357
It should be reliably reproducible on all of the above.

It happens when you access veaction=edit directly in the url on a fresh load.

Chrome has the nasty habit of firing a popstate event (sometimes?) on a regular load that wasn't via the history.

This can be worked around by storing a piece of data with the state and using that to tell events apart (to distinguish between a state pop to one we pushed/replaced into the history, from a pop state to one some other application pushed in or one the browser is faultily firing, like Chrome does).

jquery-pjax (the plugin GitHub uses to ajax navigate everywhere, powered by popState), does the same thing. Generate an ID or tag, store that with the push/replace state, and on the popstate, use that to identify ours and ignore others.

This will fix lots of other potential bugs as well.

Assigning back to me as it's on my mind now, might as well fix it.
I can reproduce it on en.wikipedia.org but not on mediawiki.org
I can't reproduce this on mediawiki.org or en.wikipedia.org, but I can locally and on en.wikipedia.beta.wmflabs.org
This appears to be to do with actFromPopState in ve.init.mw.ViewPageTarget
*** Bug 57902 has been marked as a duplicate of this bug. ***
Screenshot

Steps to reproduce:

1.Click on Edit for a page
2.Add a reference
3.Use same reference multiple times in the page
4.Now again while adding reference click on "Use an Existing reference"

Observed Result:
On this dialog box beside the reference [1] the ref name ":0" appears.

See the screenshot attached

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

**Attached**: {F12716}
This bug seems to be back. I'm experiencing it on Chrome, and thought they were invalid references until Google-ing 
```
<ref name=":0" />
```

brought me here
Verified the fix in test2
Verified the fix in Betalabs
Change 111626 merged by jenkins-bot:
Hide automatic reference names

https://gerrit.wikimedia.org/r/111626
Change 111626 had a related patch set uploaded by Esanders:
Hide automatic reference names

https://gerrit.wikimedia.org/r/111626
I noticed this while fixing the reference content bug. We used to detect the auto numbering pattern, but not any more. I think we should hide these.
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/w/index.php?title=User:RYasmeen_(WMF)/addimage&veaction=edit
Screenshot of the error

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.Add another line with a reference
5.Add reflist to the article
6.Save the page
7.Reopen the editor
8.Press Delete (Deletes the first line)
9.Press Delete again (Nothing happens)
10.Press Undo

Observed Result:

1.Deletes all the content of the article.
2.Only the blue empty highlighted box remains at the right
3.Save Page button becomes disabled
4.Make further edit but still the "Save Page" button remains disabled for that session

See the screenshot attached.

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

**Attached**: {F12501}
Fixed by Ed as part of bug 57217.
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/twicedeleted
Currently inserting a new reference fails because of changes to newFromDocumentInsertion. The first thing that looks wrong is that the 'empty' document we generate for new references/media captions contains one paragraph and an empty internal list, I suspect we need to copy the existing internal list over.

Even with that fixed it appears we aren't generating the correct sequence of transactions so they need to be reviewed.

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed a while ago.
On fr.wp, see:
https://fr.wikipedia.org/w/index.php?title=Indicateur_du_d%C3%A9veloppement_durable&diff=98505933&oldid=98352104

https://fr.wikipedia.org/w/index.php?title=Dan_Flavin&diff=prev&oldid=98639433

Somehow, categories (and in one case, DEFAULTSORT) move from the bottom of the page and get inside a reference.

I'll very roughly translate for you the comment of Drongou, who tried to replicate but didn't manage to:

<<I can't reproduce this bug (on Mac OS X) but what they have in common is the suppression of a template at the top of the page. For the reference, I have tried to manipulate one several times but that didn't lead to anything. Since it's always the first reference which is affected, I think this [...] is probably due to the template being deleted but not in an usual way. Regards.>>

--------------------------
**Version**: unspecified
**Severity**: normal
Still happening, any plan on fixing this bug that has been reported for 6 months now ?

https://fr.wikipedia.org/w/index.php?title=Richard_Orlinski&diff=prev&oldid=103966506
(In reply to Trevor (Wikia) from comment #1)
> This may also be related to this kind of dirty diff:
> https://www.mediawiki.org/w/index.
> php?title=VisualEditor%3ATest123&diff=933910&oldid=933905
> 
> Essentially, it seems to happen if you edit right at the page end - I simply
> pressed enter on the last line of text, changed the format to a heading, and
> typed. Then pressed enter and typed a line of normal text. Saved page.
> 
> Wikia's ticket for this is VE-802

That's unrelated. The title of this bug was a red herring: the data was moved across large distances (which didn't happen in your case) into a <ref> tag (which didn't happen in your case), and it so happened that that <ref> tag was in a heading in one case. This bug isn't related to headings, it's related to references.
This may also be related to this kind of dirty diff: https://www.mediawiki.org/w/index.php?title=VisualEditor%3ATest123&diff=933910&oldid=933905

Essentially, it seems to happen if you edit right at the page end - I simply pressed enter on the last line of text, changed the format to a heading, and typed. Then pressed enter and typed a line of normal text. Saved page.

Wikia's ticket for this is VE-802
Currently commands are executed on the surface, and don't fire at all when not in a surface context (e.g. a dialog), however we want to have target level shortcuts (save, show menu, show help, etc.) that don't just fire when the document is fired.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Is this now fixed? We now have save-page, show-help and other target-level shortcuts…
We are trying to debug a failure with the way parsoid is set up in the Labs-Vagrant visualeditor role setup
<https://wikitech.wikimedia.org/wiki/Talk:Labs-vagrant#Parsoid_errors_using_VisualEditor_role>

When the client gets 404 errors, the error in /var/log/upstart/parsoid.log is just 
  ERROR in localhost:Main_Page
  Stack trace: DoesNotExistError: Page Fetch failure for null
  worker 25269 died (1), restarting.

but it doesn't say what the error is.
ebernhardson tweaked the second line to actually say what's going wrong by adding error to the output, so the second line becomes

  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"

, and now we can get somewhere :)

Two-line patch on its way

--------------------------
**Version**: unspecified
**Severity**: normal
Change 101336 merged by GWicke:
More informative DoesNotExistError logging.

https://gerrit.wikimedia.org/r/101336
Change 101336 had a related patch set uploaded by GWicke:
More informative DoesNotExistError logging.

https://gerrit.wikimedia.org/r/101336
I changed the title so we can review that we do have useful logging in all handlers and wanted to keep this open till we have actually reviewed it.
Change 98038 merged by jenkins-bot:
More informative DoesNotExistError logging.

https://gerrit.wikimedia.org/r/98038
Let us leave this bug open even after this patch is merged. We should review all our response handlers and make sure we are emitting informative log messages based on the error that is returned. Looking at the code, I see that we return early in many handlers.
Change 98038 had a related patch set uploaded by Spage:
More informative DoesNotExistError logging.

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

Steps to reproduce:

1.Click on the Edit button.
2.Add a template to a page.
3.Add another template on it.
4.Type something on the next line of second template and format it to Preformatted ,Bold,Italic,Subscript/Underlined.
5.Now type something between the two templates.

Observed Result:
The text added between two templates takes the format of the next line to the second template.

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

**Attached**: {F12332}
Fixed some time ago, it seems.
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/test2511?veaction=edit
Consequently the second time you edit a page, it thinks the save dialog already exists so it isn't set up again, and it fails to render.

We should add a "double edit" workflow to our Selenium or manual tests.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 97913 merged by jenkins-bot:
Tear down the save dialog and remove it from memory on surface teardown

https://gerrit.wikimedia.org/r/97913
Change 97913 had a related patch set uploaded by Esanders:
Tear down the save dialog and remove it from memory on surface teardown

https://gerrit.wikimedia.org/r/97913
Specifically when the surface is torn down the surface overlays are detached.
It is quite easy to create two adjacent lists that appear to be one list (but for a small amount of extra spacing) through copy/paste or deletion. More often than not this is not what the user means semantically, so such a situation should be highlighted to the user and they should be given an easy way to fixup the code.

I have yet to see an editor which does this well, but that shouldn't stop us being the first.

==Steps to reproduce==
Just as a helpful example.

1. Create a list.
1. Decide to end the list by pressing enter while on a blank bullet.
1. Change your mind and decide to continue the list by clicking the list buttons.
1. Now the document has two separate lists, but your mental model only has one.
Currently pasting a list into a list creates a sub-list. From a technical point of view this is correct (the paste contents will always be a full list) but from a user expectation point of view this will be wrong 99% of the time, so we should unwrap the pasted list so it flattens to the same list level as the target.
Timo astutely observed that no tests had to be changed in https://gerrit.wikimedia.org/r/#/c/80689 despite the change from grapheme clusters to code points. I share his feeling that there should have been tests that would have been broken by that change. It's never too late to write some :)

--------------------------
**Version**: unspecified
**Severity**: enhancement
It has a comment that says TODO: strip out calls to splitClusters then delete this method.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 165433 merged by jenkins-bot:
Getting rid of ve.splitClusters in VE core

https://gerrit.wikimedia.org/r/165433
Change 165430 merged by jenkins-bot:
Getting rid of ve.splitClusters in ve-mw

https://gerrit.wikimedia.org/r/165430
Change 165430 had a related patch set uploaded by SuchetaG:
Getting rid of ve.splitClusters in ve-mw

https://gerrit.wikimedia.org/r/165430
Change 165433 had a related patch set uploaded by SuchetaG:
Getting rid of ve.splitClusters in VE core

https://gerrit.wikimedia.org/r/165433
Hi, yes, we wrote ve.splitClusters because we wanted to make the document model be a list of grapheme clusters, instead of a list of raw Javascript characters (i.e. Unicode code units, so each surrogate pair like '\uD860\uDEE2' is treated as two separate entities '\uD860' and '\uDEE2').

However, we've subsequently decided against that, because browsers will not always agree what constitutes a grapheme cluster. The example of Malayalam, where the font can affect the number of clusters, is one example of how problematic it could be to try to match the browser's clusterings exactly.

Therefore, the DM is to remain a list of raw Javascript characters, and support related to clustering is being developed at a level on top of the DM.
(In reply to Sucheta Ghoshal from comment #1)
> Well, if we are going beyond BMP, we need to take surrogate pairs into
> account, too. JavaScript does not do that natively, AFAIK. Would code points
> be enough in that case?

I think the idea is that at the DM layer, we won't be combining anything beyond code points, but David (CC) can confirm.
**sucheta.ghoshal** wrote:

Well, if we are going beyond BMP, we need to take surrogate pairs into account, too. JavaScript does not do that natively, AFAIK. Would code points be enough in that case?
Steps to reproduce:

1.Click on the "Edit" button
2.Insert a reference with no content.
3.Save the page

Observed Result:

The error message that appears on the page is "Cite error: The opening <ref> tag is malformed or has a bad name" where as 
when you edit a reference (not first time insert) to an empty content the error message that appears is "Cite error: There are <ref> tags on this page without content in them"

The later one is more understandable for a user.So maybe we can change the message to the later one.

--------------------------
**Version**: unspecified
**Severity**: enhancement
VisualEditor does not any more allow adding empty reference, so the VE side of the issue is no more reproducible.
 
Maybe, VE was converting empty reference as <ref/> and therefore it was showing "Cite error: The opening <ref> tag is malformed or has a bad name" , which seems like expected behavior. 

Therefore, closing this bug.
The VisualEditor does not any more allow adding empty reference, so the VE side of the issue is no more reproducible.
 
Maybe, VE was converting empty reference as <ref/> and therefore it was showing "Cite error: The opening <ref> tag is malformed or has a bad name" , which seems like expected behavior. 

Therefore, closing this bug.
I'm not convinced this is a tone matter.
Error messages are controlled by MediaWiki interface pages. Enter `MediaWiki:Cite error ref no key` into the search box and it will open the interface page. These pages have a default, so if it is not customized, the page does not actually exist as such and when you edit it, it shows as if you are creating a brand new page but it shows the default message. If you go to `Special:AllMessages` you can enter `Cite error ref no key` and it will show the default and the custom if it exists. If you enter `Cite error` is will show all cite error interface pages.

Cite.php is the software extension for all of this.
https://www.mediawiki.org/wiki/Extension:Cite

The error messages are set up through `cite body.php` and then there are language files in the i18n folder.


The English Wikipedia is VERY customized. We use {{broken ref}} to control the message display and the namespace. Every message links to a help page. See https://en.wikipedia.org/wiki/Help:Cite_errors#Error_messages for a list of all messages. Each help page has a Technical section that has a link to the MediaWiki interface page.
Ah.

<ref /> is indeed invalid and triggers `MediaWiki:Cite error ref no key` which displays `Invalid <ref> tag; refs with no content must have a name` by default and is customized to `The opening <ref> tag is malformed or has a bad name (see the help page).` on the English Wikipedia which is a better description.
{F51632} 
when i entered the reference with no content still i had this error
Cite error: Invalid <ref> tag;
refs with no content must have a name
{F51634}
so what should i do
both of them are set to the same message in my en.json
"cite_error_ref_no_key": "Invalid <code>&lt;ref&gt;</code> tag;\nrefs with no content must have a name",
	"cite_error_ref_no_input": "Invalid <code>&lt;ref&gt;</code> tag;\nrefs with no name must have content",
{F51632} 
when i entered the reference with no content still i had this error
Cite error: Invalid <ref> tag;
refs with no content must have a name

{F51634}
Looking at the original issue:

----
1.Click on the "Edit" button
2.Insert a reference with no content.
3.Save the page

Observed Result

The error message that appears on the page is `Cite error: The opening <ref> tag is malformed or has a bad name.`
----

I don't see this. I create a test page with <ref></ref> and save. The page shows Cite error: There are <ref> tags on this page without content in them (see the help page). which is customized on the English Wikipedia from `MediaWiki:Cite error ref no input`. This is correct.
Looking at the original issue:

----
1.Click on the "Edit" button
2.Insert a reference with no content.
3.Save the page

Observed Result:

The error message that appears on the page is `Cite error: The opening <ref> tag is malformed or has a bad name.`
----

I don't see this. I create a test page with <ref></ref> and save. The page shows Cite error: There are <ref> tags on this page without content in them (see the help page). which is customized on the English Wikipedia from `MediaWiki:Cite error ref no input`. This is correct.
Looking at the original issue:

----
1.Click on the "Edit" button
2.Insert a reference with no content.
3.Save the page

Observed Result:

The error message that appears on the page is "Cite error: The opening <ref> tag is malformed or has a bad name."
----

I don't see this. I create a test page with <ref></ref> and save. The page shows "Cite error: There are <ref> tags on this page without content in them (see the help page)." which is customized on the English Wikipedia from 'MediaWiki:Cite error ref no input'. This is correct.
"cite_error_ref_no_key": "Invalid <code>&lt;ref&gt;</code> tag;\nrefs with no content must have a name", is already set to this in the local environment.
should i create a patch for this.
Rits: See https://en.wikipedia.org/wiki/Help:Cite_errors/Cite_error_ref_no_key
i am working on this bug i am unable to generate  "Cite error: The opening <ref> tag is malformed or has a bad name" although i am able to generate the  "Cite error: There are <ref> tags on this page without content in them" .
The test page in question includes '<ref />' which is invalid. This triggers 'MediaWiki:Cite error ref no key'.

The default error message is "Invalid <ref> tag; refs with no content must have a name"

The customized message on enwiki is "The opening <ref> tag is malformed or has a bad name (see the help page)." The linked help page explains the issue in depth.
The examples are on the English Wikipedia, where the cite errors are heavily customized.

* "Cite error: The opening <ref> tag is malformed or has a bad name" is through "MediaWiki:Cite error ref no key"


* "Cite error: There are <ref> tags on this page without content in them" is through "MediaWiki:Cite error ref no input"
(Not a VisualEditor-specific issue.)
Created attachment 13913
Screenshot of the error

**Attached**: {F12187}
Created attachment 13912
screenshot

**Attached**: {F12186}
To figure out:
* Does this work in all browsers we support? I have anecdotally confirmed support in Firefox 25 and Chrome 30
* Protocol-relative URLs in <base> are broken, because documents created this way don't have a creator context or whatever.

Benefits:
* Not a hack involving iframes :)
* Faster than the iframe hack
* Does not have issues with HTTPSEverywhere in Firefox

For the <base> issue, it looks like something like this will work:

>>> d.querySelector('base')
<base href=​"/​/​example.com">​
>>> d.baseURI
null
>>> d.querySelector('base').getAttribute('href')
"//example.com"
>>> d.querySelector('base').setAttribute('href', 'http://example.com');
undefined
>>> d.baseURI
"http://example.com/"

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 120836 merged by jenkins-bot:
Use DOMParser in ve.createDocumentFromHtml() if available

https://gerrit.wikimedia.org/r/120836
(In reply to Roan Kattouw from comment #2)
> ...or use DOMParser, which actually does *precisely* what we want. We could
> use it in browsers where it's available as a replacement for
> ve.createDocumentFromHtml, because it's supported only in FF 12+, Chrome 30+
> (!), IE 10+, Opera 17+ (!) and not at all (!!) in Safari.
This is what I ended up going with.
Change 120836 had a related patch set uploaded by Catrope:
Use DOMParser in ve.createDocumentFromHtml() if available

https://gerrit.wikimedia.org/r/120836
...or use DOMParser, which actually does *precisely* what we want. We could use it in browsers where it's available as a replacement for ve.createDocumentFromHtml, because it's supported only in FF 12+, Chrome 30+ (!), IE 10+, Opera 17+ (!) and not at all (!!) in Safari.
(In reply to comment #0)
> For the <base> issue, it looks like something like this will work:
>
I read the spec some more and it looks like the trick I outlined is actually something that the spec specifically covers and says should work.

Other issue: we can't parse doctypes or <html> tags this way, so we can't respect non-HTML5 doctypes and we won't see any attributes on the <html> element. This isn't a problem for Parsoid documents at this time, although it'll be pretty annoying if we ever want to respect things like <html lang="nl">.
https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28proposals%29&oldid=582561035#Proposed_new_Draft_namespace

I believe this discussion demonstrates sufficient community consensus to create a "Draft" namespace on the English Wikipedia.

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
**URL**: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28proposals%29&oldid=582561035#Proposed_new_Draft_namespace
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57315
Thank you Matt, Steven, and everyone else for your work on this. :-)
This is deployed to English Wikipedia.

You can also resume testing on Beta.  The old drafts are at http://en.wikipedia.beta.wmflabs.org/wiki/Special:PrefixIndex/Draft .  They can be moved back into the Draft space if desired.
Change 97675 merged by jenkins-bot:
Create "Draft" namespace on the English Wikipedia

https://gerrit.wikimedia.org/r/97675
The VE stuff has now been included into the main change (https://gerrit.wikimedia.org/r/#/c/97675/).
VisualEditor will be enabled in the namespace for opt-in users.  See https://www.mediawiki.org/wiki/Draft_namespace and https://gerrit.wikimedia.org/r/#/c/102311/ .
(In reply to comment #33)
> FYI: we're testing the new namespace on Labs
> (http://en.wikipedia.beta.wmflabs.org). Please help give it a try.

Thank you for testing.

Please hold off on creating additional Drafts for now, until it is deployed (this is due to the namespace ID change mentioned at https://bugzilla.wikimedia.org/show_bug.cgi?id=57315#c44).
**swalling** wrote:

(In reply to comment #29)
> Change 99600 merged by jenkins-bot:
> Test under-review English Wikipedia draft namespace on Labs
> 
> https://gerrit.wikimedia.org/r/99600

FYI: we're testing the new namespace on Labs (http://en.wikipedia.beta.wmflabs.org). Please help give it a try.
I used to have very strong opinions on easy with shell bugs, but that was back in the svn days where you actually needed to be shell to do anything useful on these bugs. Now anyone can submit changes, so that argument is less compelling.
(In reply to comment #30)
> We don't use easy keyword for shell bugs, as they're advertised not as "easy
> bug to write" but as "easy bugs for new contributors to discover the code".
> Shell bugs ask a knowledge of community consensus, and so they aren't
> suitable for newcomers.

I'm not sure this logic is sound. The "easy" keyword is associated with technical complexity. Couldn't we presume that the person adding the "easy" keyword is capable of making a full judgment of the bug, evaluating both the technical complexity and the social implications?

That is, committing a change for an "easy" shell ticket still allows new users to learn and experience Git and code review without them needing to be able to divine Wikimedia wiki consensus. On bugs where consensus, technical or otherwise, is unclear, there's a strong case for not marking the bug as "easy." I don't believe that's the case here or in many other cases of "shell" bugs.
(In reply to comment #8)
> (In reply to comment #6)
> > We're talking about a two-line configuration change here.
> 
> Probably a few more than two lines to create the namespace, the talk
> namespace,
> and set noindex. Maybe a half-dozen to a dozen lines? In any case, this seems
> fairly easy to implement to me.

We don't use easy keyword for shell bugs, as they're advertised not as "easy bug to write" but as "easy bugs for new contributors to discover the code". Shell bugs ask a knowledge of community consensus, and so they aren't suitable for newcomers.
Change 99600 merged by jenkins-bot:
Test under-review English Wikipedia draft namespace on Labs

https://gerrit.wikimedia.org/r/99600
Change 99600 had a related patch set uploaded by Mattflaschen:
Test under-review English Wikipedia draft namespace on Labs

https://gerrit.wikimedia.org/r/99600
**swalling** wrote:

(In reply to comment #25)
> I have a hard time understanding what is going on here? If this was any other
> wiki, we would note that their is community consensus, and implement the
> change.
> 
> The only thing slightly iffy thing here is to be able to let anons create
> pages
> in this namespace - that might require someone taking 10 seconds writing a
> hook
> (Or even better, someone fixing mediawiki so we have proper per-namespace
> permissions). However that can easily be done later. the robots thing is
> already a config option.
> 
> Furthermore, all these various "config" related changes are trivial to change
> after the fact if people discover they want something different.
> 
> New namespaces get created for other wikis all the time. This has
> traditionally
> been something that has entirely been up to the community to decide for
> themselves. I don't understand why enwiki gets treated so differently.
> 
> >Key minimum requirements for launch are being hashed out at
> >https://www.mediawiki.org/wiki/Draft_namespace 
> 
> Kind of seems odd this is being written up on mediawiki.org, for something
> that
> is in essence a config change coming out of enwikipedia community. Its not
> like
> there are non-user facing technical hurtles to surmount. There's no new db
> schema being proposed or anything like that.

I suggest you check out the mediawiki.org page and the associated bug 57315. They both include some explanation, including the technical discussions involved about implementation, and about future plans.
I have a hard time understanding what is going on here? If this was any other wiki, we would note that their is community consensus, and implement the change.

The only thing slightly iffy thing here is to be able to let anons create pages in this namespace - that might require someone taking 10 seconds writing a hook (Or even better, someone fixing mediawiki so we have proper per-namespace permissions). However that can easily be done later. the robots thing is already a config option.

Furthermore, all these various "config" related changes are trivial to change after the fact if people discover they want something different.

New namespaces get created for other wikis all the time. This has traditionally been something that has entirely been up to the community to decide for themselves. I don't understand why enwiki gets treated so differently.

>Key minimum requirements for launch are being hashed out at
>https://www.mediawiki.org/wiki/Draft_namespace 

Kind of seems odd this is being written up on mediawiki.org, for something that is in essence a config change coming out of enwikipedia community. Its not like there are non-user facing technical hurtles to surmount. There's no new db schema being proposed or anything like that.
Key minimum requirements for launch are being hashed out at https://www.mediawiki.org/wiki/Draft_namespace .  Some are pretty definite already (e.g. NOINDEX), while others are not 100% certain yet.  We may also have omitted some questions, so if you think of any that need to be resolved before launch, add them.
(In reply to comment #22)
> Ori's point was partly that acting in a hasty manner and populating the
> namespace with content right, so that it's less flexible to essential changes
> in the near future, *will* make the situation worse.

Worse than hypothetical future is not worse than the present, so it's still a gradual improvement. Populating a "drafts" namespace doesn't seem to pose any risk to me: it's completely normal to move pages in and out new namespaces (Wikipedia<->Draft in this case) and this namespace is supposed to be purged regularly anyway. If you're so worried about workload, you can run a move script yourself when it's time; the only real risk when creating namespace is forgetting to run namespaceDupes.php‎.
(In reply to comment #19)

I agree with most of what you wrote, though a lot of it is relevant to bug 57315 rather than this bug.

> Steven Walling is well-positioned to enlist some developer time within the
> Foundation for this project. If he is asking for additional time to grok the
> requirements, the sensible and gracious thing to do is to grant it. If you
> can railroad the patch through today, you can do it two weeks from now, too.

Requirements are still being gathered. As I understand it, no implementation ideas have been formally proposed yet, much less coded, and we're fast approaching the U.S. holiday season. I don't imagine we'll see any real work on bug 57315 before 2014. While it's possible to wait a few weeks (or months) to add this namespace, I don't see any benefit to doing so. The current system is so bad and so hackish that there's very little that could make it worse.
(In reply to comment #16)
> I might even support it, once it's clear what the proposed changes are (all
> I've seen spelled out so far are a new landing page and some sort of special
> permission changes, which are both still pretty vague).

It's vague because that's one of the things we're still trying to figure out (before adding the namespace).
(In reply to comment #4)
> As I stated at the other bug, these are not questions that need to block
> creation of the namespace.

There are no blockers; you can have the namespace. I do think it is being rushed, though.

I never quite understood how consensus is determined, so I may be getting this wrong, but reading over the RFC, I think a detect a shared conviction that a namespace by itself may not do the trick, and that some additional software support may be required. This much is entailed by the very thought of having a namespace in the first place, right?

Once the namespace exists, it will begin to be populated with content, and at that point the range of things you can practically do with it are severely limited. For example: MediaWiki provides an abstract framework for expressing an edit and review workflow called ContentHandler (<http://www.mediawiki.org/wiki/Manual:ContentHandler>). Taking the default content handler for articles (WikitextContentHandler) as a starting point and extending it so that it provides guided page creation and peer review interfaces seems like a potentially fruitful direction to take, and saddling it with the additional requirement of migrating existing content is a great way to ensure that it will never get done.

Steven Walling is well-positioned to enlist some developer time within the Foundation for this project. If he is asking for additional time to grok the requirements, the sensible and gracious thing to do is to grant it. If you can railroad the patch through today, you can do it two weeks from now, too.

I would recommend making the mapping of requirements collaborative by provisioning a MediaWiki instance in Labs, granting shell access to all interested parties, and using it as a staging area for hashing out how the namespace would work and how its purpose and function would be presented to editors.
(In reply to comment #17)
> I am fine with whichever proposal
> gets
> this done, as long as it does through whatever procedure it is normally
> expected to.

Don't worry: the procedure is [[m:Requesting wiki configuration changes]]. It seems to be clear that there is consensus and we already have a patch, so now you only need the patch to be approved by a shell user, after it's verified that the code in question does what asked. Typically, that takes about a week or two of waiting; namespace creation is among the simplest and most routinary configuration changes happening in here, so I don't expect any problem.
(In reply to comment #14)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Like I said on bug 57315, there are still too many unanswered questions about
> > > this namespace to roll it out in a hasty way.
> > 
> > Does anyone else share your view?
> 
> I fully share this view.  

As do I. If a quick six-lines-of-code patch can work, then that is good. But if the long run requires a more comprehensive approach, then so it be. As far as I am concerned, the enwiki just needs the namespace in a reasonable amount of time. If those two requirements are met, I am fine with whichever proposal gets this done, as long as it does through whatever procedure it is normally expected to.
**equazcion** wrote:

(In reply to comment #14)
> I fully share this view.  I've been toying with the idea of an extension here
> for some time.  There is this new namespace, there is the new userright that
> the community agreed upon, there are the common complaints that AfC templates
> and scripts don't do this or that (and can't be modified as the wiki stands
> to
> without creating an on-by-default gadget or adding code to
> MediaWiki:Common.js
> or possibly by creating a guided tour (which is a fairly new option that was
> introduced as I've been developing the extension)).  There are a LOT of
> factors
> that need to go into draft creation alone, not to mention I think (as I
> stated
> in bug 57315) that I think requested articles could be rolled into articles
> for
> creation and the whole process could be streamlined.  I'm constantly seeing
> stuff about editor retention and we need to do this and that and that is
> great,
> but what I have a problem with is the fact that our current fairly difficult
> to
> use system turns new editors away... Maybe stating the obvious, but if there
> are fewer new editors, then there is a much smaller pool to work from for
> retention.

It's fine that you share Steven's view on that -- but the question was whether these things are a block to the Draft namespace implementation. An extension may be a good idea and I don't necessarily dispute that, but it wasn't part of this proposal and it regards changes that should be proposed separately. I might even support it, once it's clear what the proposed changes are (all I've seen spelled out so far are a new landing page and some sort of special permission changes, which are both still pretty vague).
(In reply to comment #4)
> As I stated at the other bug, these are not questions that need to block
> creation of the namespace. It rather seems apparent that you saw this
> proposal
> as something other than it was -- a more substantial change to AFC that you
> had
> already envisioned prior -- but it wasn't, and the closure states that pretty
> clearly. 
> 
> Anyone is allowed to create drafts because anyone was allowed to before. This
> is just a change to their location.
> 
> Publishing drafts will continue to merely require a move to mainspace,
> because
> that's all that was required before. 
> 
> We don't need to tell anyone anything other than through altered
> documentation
> at AFC, because nothing other than that will be changing. 
> 
> Phrasing these added proposals as questions doesn't make them requirements
> that
> apply to this proposal. They are merely possible additions that should be
> proposed and discussed separately. As concerns this proposal, we need only
> create a draft namespace.

Wait, IP editors aren't allow to create pages in this new draft: namespace?  They will still have to create in Draft_talk:?  At least that's what I'm reading here, exactly the same as before only people will use "Draft( talk):" instead of "Wikipedia( talk):Articles for creation/"?
(In reply to comment #2)
> (In reply to comment #1)
> > Like I said on bug 57315, there are still too many unanswered questions about
> > this namespace to roll it out in a hasty way.
> 
> Does anyone else share your view?

I fully share this view.  I've been toying with the idea of an extension here for some time.  There is this new namespace, there is the new userright that the community agreed upon, there are the common complaints that AfC templates and scripts don't do this or that (and can't be modified as the wiki stands to without creating an on-by-default gadget or adding code to MediaWiki:Common.js or possibly by creating a guided tour (which is a fairly new option that was introduced as I've been developing the extension)).  There are a LOT of factors that need to go into draft creation alone, not to mention I think (as I stated in bug 57315) that I think requested articles could be rolled into articles for creation and the whole process could be streamlined.  I'm constantly seeing stuff about editor retention and we need to do this and that and that is great, but what I have a problem with is the fact that our current fairly difficult to use system turns new editors away... Maybe stating the obvious, but if there are fewer new editors, then there is a much smaller pool to work from for retention.
I've not read the discussion but I have to say the closure is quite straightforward: «the heart of the proposal: a new namespace for Drafts [...] This community discussion does not change the AfC process». It obviously doesn't entail any extension, nor special user permissions for the namespace for that matter; those can come later if wanted.
Change 97675 had a related patch set uploaded by MZMcBride:
Create "Draft" namespace on the English Wikipedia

https://gerrit.wikimedia.org/r/97675
(In reply to comment #6)
> > We still need to specify things like:
> > 
> > * who is allowed to create drafts. (e.g. Are anonymous users allowed to do
> > so?
> > I assume so but the proposal summary and closure don't specify.)
> > * how to publish drafts
> > * who is allowed to publish drafts
> > * how do we tell users they can create/publish drafts, on search, redlinks,
> > and other places
> > * do we want to let people make drafts of pages that already exist?
> 
> None of this is relevant to adding a new namespace and you know this.

All of those questions are relevant.  Some I certainly consider blockers.  For example, I am strongly inclined to determine an initial permission model before we deploy it (that's not the only one).  

It is irrelevant how many lines it takes to create a dumb namespace.  The questions are how it will function initially (which may include A/B testing multiple possibilities) and how it will relate to other features.
(In reply to comment #3)
> (In reply to comment #2)

> * who is allowed to create drafts. (e.g. Are anonymous users allowed to do
> so?
> I assume so but the proposal summary and closure don't specify.)

I've left Tom Morris (the RfC closer) a note asking him to clarify - [[Special:Permalink/583319065]].

That said, I don't think that question specifically blocks the creation of the namespace, a hook can be added to userCan later on to allow anon's to create pages in it.
**equazcion** wrote:

(In reply to comment #7)
> I'm not talking about articles for creation at all. That's a community
> process,
> not a software feature that has direct overlap with a drafts namespace, with
> the exception of what we want to appear on search.

The accepted proposal we seek to implement here doesn't concern any software feature. If you want one, propose one separately. You've stated nothing that couldn't also be applied without a draft namespace, or after it's already created. They are separate suggestions, and they may be useful ones, but still have no bearing on the implementation of this namespace.
(In reply to comment #6)
> We're talking about a two-line configuration change here.

Probably a few more than two lines to create the namespace, the talk namespace, and set noindex. Maybe a half-dozen to a dozen lines? In any case, this seems fairly easy to implement to me.
**swalling** wrote:

> None of this is relevant to adding a new namespace and you know this.
> 
> If you want to improve the articles for creation process, great! I've filed
> several bugs in this area. :-)  No objections from me.
> 
> But the two ideas (adding a new namespace on the English Wikipedia and
> improving the articles for creation process) are not tied to each other in
> any
> meaningful way. We're talking about a two-line configuration change here.

I'm not talking about articles for creation at all. That's a community process, not a software feature that has direct overlap with a drafts namespace, with the exception of what we want to appear on search.
(In reply to comment #3)
> This is not about consensus. We don't know basic things about how the
> namespace would work.

I'm pretty sure we know how namespaces work. :-)

> We still need to specify things like:
> 
> * who is allowed to create drafts. (e.g. Are anonymous users allowed to do
> so?
> I assume so but the proposal summary and closure don't specify.)
> * how to publish drafts
> * who is allowed to publish drafts
> * how do we tell users they can create/publish drafts, on search, redlinks,
> and other places
> * do we want to let people make drafts of pages that already exist?

None of this is relevant to adding a new namespace and you know this.

If you want to improve the articles for creation process, great! I've filed several bugs in this area. :-)  No objections from me.

But the two ideas (adding a new namespace on the English Wikipedia and improving the articles for creation process) are not tied to each other in any meaningful way. We're talking about a two-line configuration change here.
**swalling** wrote:

(In reply to comment #4)
> As I stated at the other bug, these are not questions that need to block
> creation of the namespace. 

Deciding the basics of who can do what in a new namespace, and how, are things that block creating a new namespace. 

I really don't see why you're in such a huge hurry. This is quite a large new feature, so understanding the basics of how it will function in relation to regular page creation, the permissions involved, and so on seem quite obviously basic things we need to figure out before we deploy a major new namespace to English Wikipedia.
**equazcion** wrote:

As I stated at the other bug, these are not questions that need to block creation of the namespace. It rather seems apparent that you saw this proposal as something other than it was -- a more substantial change to AFC that you had already envisioned prior -- but it wasn't, and the closure states that pretty clearly. 

Anyone is allowed to create drafts because anyone was allowed to before. This is just a change to their location.

Publishing drafts will continue to merely require a move to mainspace, because that's all that was required before. 

We don't need to tell anyone anything other than through altered documentation at AFC, because nothing other than that will be changing. 

Phrasing these added proposals as questions doesn't make them requirements that apply to this proposal. They are merely possible additions that should be proposed and discussed separately. As concerns this proposal, we need only create a draft namespace.
**swalling** wrote:

(In reply to comment #2)
> (In reply to comment #1)
> > Like I said on bug 57315, there are still too many unanswered questions about
> > this namespace to roll it out in a hasty way.
> 
> Does anyone else share your view?

This is not about consensus. We don't know basic things about how the namespace would work. We still need to specify things like:

* who is allowed to create drafts. (e.g. Are anonymous users allowed to do so? I assume so but the proposal summary and closure don't specify.)
* how to publish drafts
* who is allowed to publish drafts
* how do we tell users they can create/publish drafts, on search, redlinks, and other places
* do we want to let people make drafts of pages that already exist?

There are numerous other smaller details to work out as well.
(In reply to comment #1)
> Like I said on bug 57315, there are still too many unanswered questions about
> this namespace to roll it out in a hasty way.

Does anyone else share your view?
**swalling** wrote:

Like I said on bug 57315, there are still too many unanswered questions about this namespace to roll it out in a hasty way. Please be patient. It's only been a week since the RFC on enwiki was closed.
The browser tests for MobileFrontend should be triggered by Gerrit just like it is going to be the case for ULS (T54120) or VisualEditor (T55691).

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:
- Zeljkof  our Selenium Guru
- Arthur our Mobile scrum master

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53691
https://bugzilla.wikimedia.org/show_bug.cgi?id=52120
Reflecting the true state.
We do not have the capacity yet to had browser tests on patchset proposals. The VE (T55691) and ULS (T54120) jobs have been removed because they were too slow and ill conceived.

We will revisit it when we have improved the browser test speed (ex: {T92613}) and most importantly the CI isolation project which will provide us fresh VM to install all of what we need ensuring a clean environment.

I guess when we are ready we will poke the parent task {T55697}.
Adding Dan to this bug as his work on MF tests in Vagrant will probably inform some of this.
Change 97497 abandoned by Hashar:
QA: profile for default settings

Reason:
Indeed those preferences have been moved elsewhere (mediawiki selenium gem).

https://gerrit.wikimedia.org/r/97497
Patchset 9 of https://gerrit.wikimedia.org/r/#/c/97497/ pass on a fresh wiki with mobilefrontend having no specific configuration. That is done by ignoring any scenario relying on a specific feature/setting on the target wiki.
Most of the tests do not work against a freshly installed wiki. Either because of Watir timeout or because the test is expecting something which is only on some specific wiki.

The features definition need a bunch of improvements before we can trigger the tests from Gerrit.
Change 97497 had a related patch set uploaded by Hashar:
browsertests: profile for default settings

https://gerrit.wikimedia.org/r/97497
The fakeIme tests pass IME-like event sequences into the CE Surface and check that it behaves reasonably. Currently the tests are too weak, in that they don't detect certain problematic behaviour:

1. Calls to the simulated preventDefault do nothing at all.

2. Some tests are disabled because they fail.

3. Only plain text in a single blank paragraph is tested.

4. In real usage, changing the CE surface content/selection during input will close the candidate window and commits the candidate text. The tests currently do not check for this. The test data does not show which pieces of text are candidates, since there is no way to detect this from Javascript, but we can infer that at least any text which is subsequenctly changed was a candidate.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Intention:
Add a reference

Steps to Reproduce:
1. Took hands off the keyboard.
2. Grabbed mouse.
3. Clicked "More" menu.
4. Scrolled down.
5. Clicked on "Reference".

Actual Results:  
Works as designed.

Expected Results:  
That it would work better than as designed:  Leave hands on keyboard, press a couple of keys, and have the reference dialog pop open.

Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: enhancement
My first choice is ctrl-alt-r, which unfortunately is in use as a shortcut to open Special:RecentChanges, and command-R is in use by the browsers to reload pages.

I'll personally use this enough that I'll be able to get used to just about anything.  Maybe ctrl-alt-1, if you want this to work across multiple languages?  Adding citations has "number one" importance to many Wikipedia editors.
Let's avoid symbols not available on non-English keyboards for a start, like backslash :p
What would you suggest as the shortcut?
Copied from bug 43058 

Screenshot of editing a math block

Some small tweaks are needed to the dialog box. Editing the last equation at
https://www.mediawiki.org/wiki/VisualEditor:TestMath?veaction=edit
there are a a few problems

1) The dialog obscures the actual equation
2) The dlalog is too small to see the whole source text of the equation

This could be solved the making the dialog, moveable and resizeable.


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

//attachment missing in source//
This is only done for auto-resizing and auto-positioning, not manual resizing and positioning ("dragging") which this bug is asking for (and which depends on bug 49969). Reopening.
**physik** wrote:

Change was merged. Seems to be fixed.
**physik** wrote:

Can someone look at https://gerrit.wikimedia.org/r/#/c/105647/ ... It would be great to merge this before it has to rebased manually again.
Re-positioning of OOjs UI windows is a really major piece of work, yes.

Re-sizing is very do-able, however.
I'm still trying to get a Google Code-in task or more out of these VE Math plugin reports...

If I understand the comments, the "movable" part can't be fixed for this plugin because it depends on VE's current capacity to do so (bug 49969), right?

Can the size of the window be controlled? If so, could this be a GCI task?
(In reply to comment #5)
> Change 97750 had a related patch set uploaded by Catrope:
> Fix moving over an image with the arrow keys in Firefox
> 
> https://gerrit.wikimedia.org/r/97750

Mis-targeted, sorry!
Change 97750 had a related patch set uploaded by Catrope:
Fix moving over an image with the arrow keys in Firefox

https://gerrit.wikimedia.org/r/97750
(In reply to comment #3)
> Just to note I'm just an end user, so don't really know much about how the
> Visual Editor code works. It might be an idea to consult with the VE people
> for
> the best way to achieve this. I've not found any other VE dialog which is
> movable or resizable, so I'm not sure if there is code you can copy.

See bug 49969 (and maybe bug 49549).

> (...)
> What might also be possible would be to detect if the equation is inline or a
> block mode.

See bug 12223.
Just to note I'm just an end user, so don't really know much about how the Visual Editor code works. It might be an idea to consult with the VE people for the best way to achieve this. I've not found any other VE dialog which is movable or resizable, so I'm not sure if there is code you can copy.

What is really important is that the box is big enough. Following from Helders comment you could detect the size of the original equation and size accordingly. 

What might also be possible would be to detect if the equation is inline or a block mode. (In the tex world this would be $eqn$ vrs $$eqn$$) a larger edit window is preferred for block mode equations. Its a little tricker to detect the difference in wikitext, suronding text on the same line indicates inline mode. Being a single item in a list element <li><math> ...</math></li> indicates block mode.
Cross-posting from previous bug

@Richard/others: Thinking about making the dialog draggable and resizable...

The solution I initially think of is installing jquery.ui and then adding some
parameters to OO.ui.Window that allow it to be made resizable and/or draggable.
However, if I recall correctly one of the principles of OOJS was to be
self-contained... so would this be wrong? Could someone else with a bit more
firsthand experience chime in here?
But it should also be smart enough not to present a tiny box when the formula is already very large. E.g. the last example from
https://www.mediawiki.org/w/index.php?title=VisualEditor:TestMath&oldid=749189&veaction=edit

Otherwise the user will need to resize the box on every formula of some pages
There are many templates in Wikipedia that create right floated content other than info boxes and images.

Examples are for instance Template:Stack, but there are many similar templates. These are currently not rendering as right floated.

--------------------------
**Version**: unspecified
**Severity**: normal
I vaguely think there was another task (since fixed) which this duplicates, but I have no idea what it was called.
>>! In T59296#1154512, @TheDJ wrote:
> If I remember correctly, it would be that the right floating stack, was opened in VE as full width and left aligned, pushing all visual adjacent content to be positioned underneath the stack template.

Seems to be fixed to me - not happenning anymore: inserting Stack template(with/without specifying float- right) will position the template on the right.

Btw, left - puts the template on the left.
If I remember correctly, it would be that the right floating stack, was opened in VE as full width and left aligned, pushing all visual adjacent content to be positioned underneath the stack template.
I checked in production some samples from https://en.wikipedia.org/wiki/Template:Stack:

 {{stack |[[File:Test.png|thumb|right|Example 2a]] [[File:Test.png|thumb|right|Example 2b]]}}

Without  float=left/right parameter - default is right. Is that what's been fixed?
This seems mostly fixed to me. Is that correct team ?
This is caused by the div block surrounding it, that should receive 'similar' traits in that case.

It is worsened, because in the case of stack in particular also takes fullwidth, due to the broken implementation of inline images with captions. These currently feature a figcaption that has display block, and no width constraint (shouldn't be allowed to be wider than the image frame, but it is).
https://en.wikipedia.org/w/index.php?title=Mozarteum_University_of_Salzburg&oldid=582046262

https://parsoid.wmflabs.org/enwiki/Mozarteum_University_of_Salzburg?oldid=582046262

Yet when opened in VE, the dom shows border="1"

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to Raimond Spekking from comment #5)
> Sorry, but border=1 is very different from border=0. Your "some light
> default styling" shows a border. This means, this bug is not fixed. 
> 
> If it has no priority, ok. But please leave it open.

No. VisualEditor is not intended to be and will not reach a perfect simulacrum of read mode. First and foremost, VisualEditor is an editor; the borders are explicitly shown to make editing tables sane.
Sorry, but border=1 is very different from border=0. Your "some light default styling" shows a border. This means, this bug is not fixed. 

If it has no priority, ok. But please leave it open.
(In reply to Raimond Spekking from comment #3)
> Maybe a regression: the VE renders the table in
> https://de.wikipedia.org/w/index.
> php?title=Landschaftsversammlung_Rheinland&oldid=134477792 with border=1
> instead of the given border=0. Or is this another bug?

This is what "some light default styling" looks like.
Maybe a regression: the VE renders the table in https://de.wikipedia.org/w/index.php?title=Landschaftsversammlung_Rheinland&oldid=134477792 with border=1 instead of the given border=0. Or is this another bug?
We fixed this last week with some light default styling
*** Bug 57368 has been marked as a duplicate of this bug. ***
{{Gallery}} is implemented by a Lua template here: https://en.wikipedia.org/wiki/Module:Gallery

See example below

```
[subbu@earth lib] cat /tmp/gallery
{{Gallery
| lines = 2
| File:Arc de Triomphe de l'Etoile - Projet Chalgrin - 02.jpg|1806: Architectural drawing project of [[Jean Chalgrin]]
}}
[subbu@earth lib] node parse --dump tplsrc < /tmp/gallery
=================================
Template:Gallery
---------------------------------
<table style="background:transparent;border:1px solid #f0f0f0;margin-top:0.5em;"><tr><td><table style="width:200px;float:left;border-collapse:collapse;margin:3px;"><tr><td style="height:200px;border:1px solid #CCCCCC;background-color:#F8F8F8;padding:0px;text-align:center;">[[File:Arc de Triomphe de l'Etoile - Projet Chalgrin - 02.jpg|center|border|180x180px|alt=|1806: Architectural drawing project of [[Jean Chalgrin]]]]</td></tr><tr style="vertical-align:top;"><td style="display:block;font-size:1em;height:3.2em;padding:0px;"><div class="gallerytext" style="height:3.1em;width:187px;line-height:1.3em;padding:2px 6px 1px 6px;overflow-y:auto;margin:0px;border:none;border-width:0px;">1806: Architectural drawing project of [[Jean Chalgrin]]&nbsp;</div></td></tr></table></td></tr></table>
---------------------------------
```

So, the {{Gallery}} template emits the image in a <td> and the caption in a separate <tr> below. As far as I can tell, Parsoid therefore (correctly) duplicates the caption in both the <tr>s. However, somehow, the PHP parser magically suppresses the first caption (see https://en.wikipedia.org/w/index.php?title=User:Ssastry/sandbox&oldid=582405791)

This is based on a report on VE/F @ https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=582367222#Pages_that_go_wrong_in_VE
Seems to be covered by,
https://github.com/wikimedia/mediawiki/blob/master/resources/src/mediawiki.skinning/content.parsoid.less#L150-L158
Is this still an issue?

https://en.wikipedia.org/api/rest_v1/page/html/User:SSastry%20(WMF)%2Fsandbox/582405791 and https://en.wikipedia.org/w/index.php?title=User:Ssastry/sandbox&oldid=582405791 look identical to me.
Pretty much what the Summary says:
I would have used the new format but I keep forgetting how to reach it!
I had proposed that the link reads "Enter a new bug (guided)" but in the end everything is actually ok for me as long as it's easy to discover for everyone, obviously.
Cheers.

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
http://bugzilla.wikimedia.org/enter_bug.cgi?product=Wikimedia&component=Bugzilla now says at the top "If you prefer a simpler way to create a bug report, try the guided bug entry form." linking to it. To me this feels sufficient.
Some products need that kind of depth that the new guided form provides (i.e., VisualEditor :p ). I guess experienced users can find the way to add the link to the left column anyway, if they need to.
I wonder if that wording would be clear enough if both links provide the
same functionality.

So I have the naive idea that this could be based on how "new" (recently
registered) the Bugzilla user account is. I have no idea if I have
sufficient coding skills though. :)
bugzilla.mozilla.org displays a "(New to Bugzilla)" string next to some
user names, so it must be possible to gather such information and use
it. I (or somebody else) "just" need to investigate their code a bit...
When in debug mode the browser console always shows a message

MWDeprecationWarning: Use of "wikiGetlink" property is deprecated. Use mw.util.getUrl instead.

caused somewhere in VE's startup module. When you are trying to find uses of deprecated functions in your own scripts this message is a bit annoying, as you can't do anything about it and it shows up on every page. So please replace all calls to .wikiGetlink with .getUrl (in startup module and possibly elsewhere).

--------------------------
**Version**: unspecified
**Severity**: trivial
This was done in gerrit 94263 which is in wmf3, which will be deployed to Wikipedias on Thursday.
Steps to reproduce:


1.Click on the edit button
2.Click on a link and click on the link insertion icon.
3.Without making any change just close the link inspector

Observed Result:
The "Save Page" button becomes active though if you review the changes it will say that this revision matches the lastest version of the page.

Expected Result:
If there is not modification in the content it is probably better to keep the "Save Changes" button inactive.

Sample Page:

https://en.wikipedia.org/w/index.php?title=Tea_tree_oil&veaction=edit

Browser: Chrome Version 26.0.1410.65

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production (en.wiki)
Verified the fix in test2 running wmf 9
Now fixed by Trevor's work on the link inspector and window transactions.
Instead we should check to see if the new annotation is actually different before applying it.
Checkbox flag, category namespace only.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 126015 merged by jenkins-bot:
Add checkboxes to set some metadata on page metadata panel

https://gerrit.wikimedia.org/r/126015
Change 126015 had a related patch set uploaded by Alex Monk:
Add checkboxes to set some metadata on page metadata panel

https://gerrit.wikimedia.org/r/126015
Change 95726 had a related patch set uploaded by Jforrester:
[WIP] Create remaining meta items in DM

https://gerrit.wikimedia.org/r/95726
Syntax highlighting doesn't work with Flow.

Example input:

```
<syntaxhighlight lang="css">
.foo {
    font-weight: bold;
}
</syntaxhighlight>
```
Output is not appropriately highlighted: https://www.mediawiki.org/wiki/Topic:Sb29d13fybslwgjh
It should look like this: https://www.mediawiki.org/w/index.php?title=User:Quiddity_%28WMF%29/sandbox&oldid=1397603

----
TheDJ notes (in comment below) that this might be related (plus its blockers): {T69540}
Note: the ResourceLoader module missing is `ext.pygments`. You can load it unconditionally using `mw.loader.load( 'ext.pygments' )`, and I guess you could add this to your `common.js` to work around this bug if it’s very important :)
Ok. I make rollback to 1.28.2
No one fixes the bug.
News? Solutions? Anything?
{T174374} may solve this task. I'll ask.
Any news?
>>! In T59159#3548628, @aka_sektor wrote:
> @Aklapper : Just let them return it as it was in 1.28.2
> I do not know what exactly they broke.

I only know that this problem affects board too: https://www.mediawiki.org/w/index.php?title=Flow/Sandbox&header_revId=twwnd0zvz6kx6bhb&action=view-header
@Aklapper : Just let them return it as it was in 1.28.2
I do not know what exactly they broke.
@aka_sektor: The status of this task is "open", see the upper corner. Hence this issue is not fixed and we all know that. :) No need to comment and tell. If you would like to [[ https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker | contribute a code change ]] to fix this problem, you are very welcome to use [[ https://www.mediawiki.org/wiki/Developer_access | developer access ]] to submit the proposed code changes as a [[ https://www.mediawiki.org/wiki/Git/Tutorial | Git branch directly into Gerrit ]].
Setup 1.29.1: https://releases.wikimedia.org/mediawiki/1.29/mediawiki-1.29.1.tar.gz

Bug with syntax highlight - stiil not fixed.
Release new MW version 1.29.1: https://www.mediawiki.org/wiki/Release_notes/1.29#MediaWiki_1.29.1

Bug with syntax highlight fixed?
I'm having the same problem.

All codes is not styled.

In the log, nothing is printed.

Any help?
I'm having the same problema.

All codes is not styled.

In the log, nothing is printed.

Any help?
Another example from hewiki:
https://he.wikipedia.org/wiki/%D7%A0%D7%95%D7%A9%D7%90:T8azrr7jamnrqfuy
I just noticed this problem on Portuguese Wikipedia too:
https://pt.wikipedia.org/w/index.php?title=T%C3%B3pico:Sav6mxon1ianxj4l&topic_showPostId=sb8xryegdo65sq73#flow-post-sb8xryegdo65sq73
Flow needs 2 things here. When rendering the original page, it needs to pick up the resources and add them into the parser output, so they end up on the head. Additionally, they need to be transferred in api results, preferably similar to how action=parse does it for prop=modules.


This is probably closely related to bug 67540:

And specifically you might want to look at one of it's blockers:
Bug 51245, bug 58388 and bug 67515 which detail similar problems for VE..
On trello at https://trello.com/c/qb7ulCmy/
TheDJ notes, "ah, I see that Resourceloader modules don't work yet :)".[1]

So perhaps this bug should be expanded to cover that? 
I'll leave that up to the devs.

[1] at https://www.mediawiki.org/w/index.php?title=Talk:Flow&workflow=rxtlvx7tsc2qqf1b#flow-post-ry5zwru18qpuglqk
another example at https://www.mediawiki.org/w/index.php?title=Talk:Sandbox&workflow=050c27a75b2dcc146adc842b2b77e796#flow-post-050c27dd37d200e9aae290b11c2788d8

which is copied from https://www.mediawiki.org/wiki/Talk:About_Beta_Features#HTML

(possibly the same as bug 55533 ("VisualEditor: MWSyntaxHighlight* is badly broken") ?)
The WMF core features team tracks this bug on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/475, but people from the community are welcome to contribute here and in Gerrit.
The browser tests are acting on User:Selenium_user. On a default VisualEditor installation, the User namespace does not have VisualEditor enabled.

The easiest would be to enable VisualEditor on user page I guess.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 118029 merged by jenkins-bot:
Enable VisualEditor by default in NS_USER as well as $wgContentNamespaces

https://gerrit.wikimedia.org/r/118029
Change 118029 had a related patch set uploaded by Jforrester:
Enable VisualEditor by default in NS_USER as well as $wgContentNamespaces

https://gerrit.wikimedia.org/r/118029
Yup the VisualEditor.php entry point has:

 $wgVisualEditorNamespaces = $wgContentNamespaces;

Which does not include the User namespace.  So the tests should probably only hit the content namespaces.
Is this still true?
**jhall** wrote:

Ignore previous comment - I meant to put that comment in BZ 57103.
**jhall** wrote:

This issue was resolved with the following commit:

https://gerrit.wikimedia.org/r/#/c/99257/
I have just noticed that it is already assigned to Chris (_after_ adding him to cc).
And Chris. :)
Jeff, Željko that might be appealing to you :-]
The browser tests are assuming the user Selenium_user exist. It should instead rely on the user passed within the environment variable MEDIAWIKI_USER and its associated password in MEDIAWIKI_PASSWORD.

--------------------------
**Version**: unspecified
**Severity**: normal
The wmf6 (2013-12-05) cut hasn't been made yet, so this actually goes into the cut for today, not wmf7. :-)
**jhall** wrote:

This issue was resolved with the following commit:

https://gerrit.wikimedia.org/r/#/c/99257/
Paragraph turned into heading format

Steps to reproduce:

1.Click the edit button on a page
2.Write down a paragraph and the text for its heading 
3.Select the text to be heading of the paragraph

Observed Result:

The whole paragraph including the text turns into heading format.

See the screenshot attached

Found in:

http://en.wikipedia.beta.wmflabs.org/
(Example Page:http://en.wikipedia.beta.wmflabs.org/wiki/Test_52608?veaction=edit)

Browser:FireFox 25 
OS:MAC OS X 10.8.5

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

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

1.Click on the Edit button of a page which has multiple lines
2.Select the text in the first line by pressing command+down
3.Press on command+right 

Observed Result:

Instead of moving to the end of the line for the selected text, the cursor goes to the end of the second line.

However, when you select the text with command+right/left it goes to end of the selected line.

Found in:

http://en.wikipedia.beta.wmflabs.org/
Browser:FireFox 25, Chrome Version 26.0.1410.65
OS:MAC OS X 10.8.5

--------------------------
**Version**: unspecified
**Severity**: normal
It would be useful to have the languages that MediaWiki supports be aware of the alphabet in which they are written.

ISO 15924 writing systems code can be used for the most part, so it will be "latn" for English, French, Vietnamese, etc.; "cyrl" for Russian, Udmurt, etc.; "deva" for Hindi, Marathi, etc. - and so on.

This is useful for applying special styles that are common to all languages written in a script. For example the notorious line-height fix is applied in shared.css by element name and language code, and it could be greatly simplified by using the relevant script codes so instead of having selectors for bh, bho, hi, ks, mr, mai, ne, new, pi and sa, there would only be one selector for class deva.

Of course, it will have to take into account language variants (Serbian Cyrillic / Latin, Kazakh Cyrillic / Latin / Arabic etc.) and also special cases not covered by ISO 15924, such as the internal differences between styles of Arabic (so Arabic may use "arab" and Urdu may use something like "arab-nastaleeq").

An easy way to implement this would be to add a variable to each Messages file, similarly to $rtl. (In fact, this can make $rtl obsolete, because the direction is inherent in the writing system.)

Comment 1: In this bug, "writing system", "script" and "alphabet" are synonyms. I mentioned all to make it easier to find.

Comment 2: I vaguely recall that there is a bug for this, but I cannot find it. If there is one, please mark this one as a dupe.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Slightly related: Bug 56908
(In reply to comment #4)
> I have two points related to this bug:
> 
> 1/ Is the information of the "ISO 15924 <-> language code" somewhere in
> MediaWiki? I quickly searched and didn’t find.

Not in core, but it's available in the UniversalLanguageSelector extension's "langdb" feature. Its most readable version can be found here:
https://github.com/wikimedia/jquery.uls/blob/master/data/langdb.yaml

(It's tracked in GitHub and periodically updated in Gerrit.)

I occasionally fantasize about separating the langdb into an independent jQuery library and adding it to core.
I have two points related to this bug:

1/ Is the information of the "ISO 15924 <-> language code" somewhere in MediaWiki? I quickly searched and didn’t find.

2/ Rethinking about the CSS classes, there is a problem in adding multiple levels of CSS classes: if there is

  <html class="writing-Latn"><div class="writing-Cyrl">здесь</div></html>

then the inner <div> is affected by the classes "writing-Latn" and "writing-Cyrl", and there is no mean to know what is the most inner class between the two.
(In reply to comment #2)
Some Day Soon, when VisualEditor
> will
> have full support for marking pieces of text in another language, then there,
> too. (It's already a beta feature.)

... Just checked, and it doesn't seem to be deployed anywhere in Wikimedia. But it has been in development for months already.
(In reply to comment #1)
> Where do you think adding these CSS classes? If I understand correctly the
> structure of the page, the <html> tag has the language and directionality of
> the user interface language and the <div id="mw-content-text"> tag has the
> language and directionality of the page language. Adding these CSS classes on
> these two places?
> 
> Interwikis could perhaps also be considered.

Actually, any place where we currently use lang and dir.

<html>, <div id="mw-content-text">, interlanguage links, ULS, various elements of the Translate and Wikibase extensions. Some Day Soon, when VisualEditor will have full support for marking pieces of text in another language, then there, too. (It's already a beta feature.) Many of these are not in the core, but they will need it just as well, so there probably should be core PHP and JS functions that make it easy to add them everywhere.
Where do you think adding these CSS classes? If I understand correctly the structure of the page, the <html> tag has the language and directionality of the user interface language and the <div id="mw-content-text"> tag has the language and directionality of the page language. Adding these CSS classes on these two places?

Interwikis could perhaps also be considered.
Steps:
* Edit page
* Add heading "External links"
* Press Enter, click "Bulleted list" in toolbar
* Click on the link tool and paste a url in the link input widget
* Type a label where the cursor is

Expected:

 <h2>External links
 <ul><li> <a>Typing</a>

Actual:

 <h2>External links
 <ul><li> <a>http://example.org/foobarTyping</a>♙

--------------------------
**Version**: unspecified
**Severity**: normal
Change 98116 merged by jenkins-bot:
Close inspectors when surface is focused but selection doesn't change

https://gerrit.wikimedia.org/r/98116
Change 98116 had a related patch set uploaded by Catrope:
Close inspectors when surface is focused but selection doesn't change

https://gerrit.wikimedia.org/r/98116
Clarification:

* Create an empty list item
* Open the link inspector
* Type a link target
* CLICK to position the cursor at the SAME PLACE where it was before
* The inspector DOES NOT close
* Type
* The first key press is ignored and inserts a pawn instead, the remaining key presses insert characters before the pawn

Root cause: when the document is focused, the inspector should close. We currently close the inspector when the selection changes, and usually clicking out of the inspector does change the selection, but in creation mode this isn't necessarily true.
(In reply to comment #1)
> Is there a JS error or exception in the console?

There is not.

Reduced steps:


Steps:
* Edit page with a list (or create a new unordered list)
* Create a new list item
* Click on the link tool and enter a url (e.g. "http://example.org") in the link input widget
* Type a label (e.g. "example") where the cursor is

Expected:
<a href="http://example.org">example</a>

Actual:
<a href="http://example.org">http://example.orgxample</a>♙


Note how the first character typed was ignored.
Is there a JS error or exception in the console?
Taking user to the top of the page

Steps to reproduce:

1.Click on the Edit button for a page with long article(For Example:https://test2.wikipedia.org/wiki/First_line?veaction=edit)
2.Go to the end of the article
3.Click the button More>Language

Observed Result:
The language selector takes user at the top of the page which is a bit inconvenient for user editing long article as he has to scroll down again to the point where he was editing.

See the video attached

Browser: Chrome Version 26.0.1410.65
OS:MAC OS X 10.8.5
Environment:test2

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

**Attached**: {F12431}
This was fixed last month as part of the suite of such fixes.
A limited rich text box, defaulting to page title.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53566
https://bugzilla.wikimedia.org/show_bug.cgi?id=49076
Change 129065 merged by jenkins-bot:
Allow VE users to change displaytitle in advanced settings dialog

https://gerrit.wikimedia.org/r/129065
Change 129065 had a related patch set uploaded by Alex Monk:
Basic VE code for changing displaytitle as wikitext in metadata panel

https://gerrit.wikimedia.org/r/129065
Okays, turns out I hadn't read this properly and it's blocked on Parsoid recognising this as a meta item rather than a transclusion of 'DISPLAYTITLE'.
(In reply to Alex Monk from comment #1)
> This is more complicated than it looked.  For now we might have to just
> accept wikitext (like the edit summary) instead of using a VE surface widget
> (like the reference dialog), because DISPLAYTITLE can do crazy things like
> accept templates.

That works for now, though it's imperfect. :-)
This is more complicated than it looked.  For now we might have to just accept wikitext (like the edit summary) instead of using a VE surface widget (like the reference dialog), because DISPLAYTITLE can do crazy things like accept templates.
A checkbox, setting:

  <meta property="mw:PageProp/notoc">

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 95103 merged by jenkins-bot:
Let users set __NOTOC__ & __FORCETOC__ status

https://gerrit.wikimedia.org/r/95103
Change 95103 had a related patch set uploaded by Jforrester:
[WIP] Let users set #REDIRECT, __NOTOC__, & __FORCETOC__

https://gerrit.wikimedia.org/r/95103
See also bug 56867 comment 1
Tracking bug for support for setting #REDIRECT, __NOTOC__, etc. behavioural flags.

--------------------------
**Version**: unspecified
**Severity**: enhancement
No remaining children tickets; closing for now. We can re-open if it turns out to be necessary.
*** Bug 52248 has been marked as a duplicate of this bug. ***
tab not adding indentation to newline

Steps to reproduce:

1.Add a numbered/bulleted list in the editor 
2.Go to a newline afte the list
3.Now click on "tab" from keyboard

Observed Result:
Instead of adding indentation to the new line, it keeps on adding indentation to first line of the numbered list.

Sometimes it also selects other items outside the editor.

See the screenshot attached.

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

**Attached**: {F12204}
Check the attachment with video capture of the steps.
Created attachment 14090
video capture of the bug

**Attached**: {F12206}
This still works for me.
There is modification in the steps to reproduce this issue:

1.Add a numbered list in the document
2.Add the first item "item1"
3.Press enter and add the second item of the list "item2"
4.Place the cursor just before the text item2 and press tab.
5.Now click on bullet list icon from the toolbar
6.Go the end of second line and press enter (another bullet gets added to the newline)
7.Now press enter again.
8.Then keep on pressing tabs

Observed Result:
It is adding indentation to the first line of the page like 1.1.1.1.1 

Page:https://en.wikipedia.org/w/index.php?title=User:RYasmeen_(WMF)/wrong_serial&veaction=edit
Created attachment 13970
Screenshot of the error

**Attached**: {F12205}
I just reproduced it on production on this page:
https://en.wikipedia.org/wiki/User:RYasmeen_%28WMF%29/wrong_ref_serial?veaction=edit

Go to the last line of the page and keep pressing tab.
I can't reproduce the behaviour described. Note the expected behaviour is either nothing or the document loses focus, not that the line is indented (yet).

Re-open if you can reproduce.
Note that we don't support any sort of indentation outside of lists yet.
Browser: Chrome Version 26.0.1410.65
OS:MAC OS X Version 10.8.4
(In reply to comment #1)
> Found this bug on:
> 
> Browser:Chrome

Please *always* add your browser version.

> OS:MAC

Please *always* add your OS version.
Found this bug on:

Browser:Chrome
Environmenr:test 2
Page: https://test2.wikipedia.org/wiki/Teetly
OS:MAC
Steps to reproduce:

1.Click on the Edit button
2.Add a reference to a text from More>Reference
3.Now try to open up LaTeX window for any text in the article

Observed Result:

The math inspector does not open up after adding a reference to the article


Environment:Test 2
Page:Any
Browser:FireFox 20 and Chrome Version 26.0.1410.65
Reproducible: Yes

--------------------------
**Version**: unspecified
**Severity**: normal
This issue might got resolved.Cannot reproduce it anymore.
Currently, if I go to https://www.mediawiki.org/wiki/User:Amire80/ve-source and
edit it using VE, I can edit the content of the <source> tag. If my UI language
is Hebrew, then the <textarea> for editing the poem is RTL. I would expect it
to be always LTR by default, because source code is almost always LTR. (There are some RTL programming languages like Hebrew Logo and Arabic Alb, but these are very rare exceptions and the <source> tag doesn't support them anyway.)

This is comparable to Bug 56779, but unlike in that bug, here the request is that the direction will be explicitly set to ltr rather than the surrounding direction.

There may be other tags for which something like this would be useful, but I can't think of any at the moment.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 94424 merged by jenkins-bot:
Force LTR direction in MWSyntaxHighlightDialog

https://gerrit.wikimedia.org/r/94424
Change 94424 had a related patch set uploaded by Mooeypoo:
Force LTR direction in MWSyntaxHighlightDialog

https://gerrit.wikimedia.org/r/94424
Another nice thing to do would be to use CodeEditor instead of <textarea>.
When cite web is used, webpage title, and access date should be filled automatically for 1 click web citations.


**Status:**  Title and other information is done via #citoid, but auto-adding the current date to the access-date parameter is a problem because of {T4700}.
T96000 ?
Is it Citoid ?
Here's what I did: http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Template:Cite_web/doc&diff=prev&oldid=216044

The problem is indeed that substitution does not work inside 'ref' tags (T4700), so there's no way in its current form to autofill the 'access date' field via TemplateData.

It seems like this could be solved just within VE, though, by adding some way of directly adding the current date as the default for a field and leaving the parser out of it altogether. But! It looks like there's a shiny new patch for review for actually fixing that hoary bug!
@Capt_Swing: can you please clarify? What did you test, and where? Links are appreciated. Thank you.
@ragesoss tried this on enwiki beta, and it doesn't work: the subst; template is not rendered.
Web page title is done by citoid, I'm not sure if we can migrate the operation to the Cite web template automatically.

However (as per irc chat) filling in the date automatically is exactly what the TemplateData autofill property is for. It can be set up with a template substitution for current date, and VE will fill it in automatically.
I created https://gerrit.wikimedia.org/r/#/c/137824/ a while ago. I'll try to get around to reworking it to make it work, which will allow you to do this.
(In reply to Alex Monk from comment #3)
> It should be possible to achieve the accessdate part of this by editing
> TemplateData to use the autovalue field from bug 52029 (subst: the date in
> automatically).
> 
> Webpage title - isn't that something Citoid would do?

Unfortunately bug 2700 means this isn't very trivial…
(actually, leaving this as reopened for now due to the citoid bit...)
It should be possible to achieve the accessdate part of this by editing TemplateData to use the autovalue field from bug 52029 (subst: the date in automatically).

Webpage title - isn't that something Citoid would do?
This has not been implemented, as of the version in English Wikipedia.
Merging this with bug 50768.

*** This bug has been marked as a duplicate of bug 50768 ***
Intention:
To add a ref (incorrectly, by typing out the wikicode)

Steps to Reproduce:
1.  Open a page. 
2.  Type <ref>Whatever</ref>
3.  Discover that there is no warning about wikitext markup being detected.

Actual Results:  
Nothing.

Expected Results:  
It should display the same wikitext markup warning that typing ''' produces.

Reproducible: Always

--------------------------
**Version**: unspecified
**Severity**: enhancement
Verified in test2 with Firfox 25 on MAC OS X 10.8.5.
Example test page:
https://test2.wikipedia.org/wiki/Verify_56274
Change 94311 merged by jenkins-bot:
Add <ref> tags to wikitext detection regex

https://gerrit.wikimedia.org/r/94311
Change 94311 had a related patch set uploaded by Catrope:
Add <ref> tags to wikitext detection regex

https://gerrit.wikimedia.org/r/94311
wiki markup

Steps to reproduce:

1.Click on the Edit button for any page 
2.Type a text in the editor.
3.Add a template for example:citation needed,
4.Now select both the text and the template and press command+l or link icon
5.Apply a link to them through link inspector

Observed Result:
The wiki markup for link shows up in the view mode

See the screenshot attached.


Found this bug using firefox 20 or chrome Version 26.0.1410.65 in MAC OS

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

**Attached**: {F12078}
This appears to be fixed from what I can tell. Maybe part of the work we did in late February?
Link inspector

Steps to reproduce:

1. Click on the Edit button on any page 
2. Go to a new line by pressing enter
3. Now click at the top of the page or select the current user's name.
4. Click on the link icon or More>Language from the toolbar

Observed Result:
The link inspector and the language selector opens up at the top right corner of the page ,outside the editor

See the screenshot attached.

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

**Attached**: {F12072}
Fixed by Ed's null selection change.
Found in FireFox 20 and Chrome Version 26.0.1410.65 with MAC OS in both test2 and betalabs for any page.

For FireFox, it opens somewhere at the bottom of the page.
Created attachment 13726
Language selector

**Attached**: {F12073}
**Author:** `swalling`

**Description:**
Right now, the workflow for GettingStarted tours is as follows:

- The user gets 'gettingstartedtasktoolbarintro' once and immediately on their first view of a suggested task page. This is a one step intro tour, and then is never seen again. 
- The user is then shown the task page, with the GettingStarted toolbar. They can click "Show me how" in the toolbar, which launches the 'gettingstartedtasktoolbar' tour. 

Without changing the toolbar behavior, let's automatically launch the 'gettingstartedtasktoolbar' tour after the user completes the intro tour. Right now, only 9% of users are using the tour provided by "Show me how", which is fewer than we intended.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 107726 merged by jenkins-bot:
Auto-launch full tour, not just intro

https://gerrit.wikimedia.org/r/107726
Change 107726 had a related patch set uploaded by Mattflaschen:
Auto-launch full tour, not just intro

https://gerrit.wikimedia.org/r/107726
My understanding is it should still be auto-launched only once.  The difference is that now it's the full tour, not the one step intro.

Let me know if I have the wrong idea.
**swalling** wrote:

Note: ideally, we want to launch 'gettingstartedtasktoolbar' or 'gettingstartedtasktoolbarve' conditionally based on whether the user has VisualEditor enabled.
mw.Api has nice features now like automatically retrying bad tokens, we should migrate to it.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 186548 merged by jenkins-bot:
Use mw.Api to run requests rather than our own stuff in ve.init.mw.Target

[[https://gerrit.wikimedia.org/r/186548]]
Change 186548 had a related patch set uploaded (by Alex Monk):
Use mw.Api to run requests rather than our own stuff in ve.init.mw.Target

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

#patch-for-review
Done in https://gerrit.wikimedia.org/r/#/c/98713/ AFAICT.
Yeah, you're right, the automatic retry without regard for the user changing is not what we want.
One of the intentional functionality points in current VE is warning users when the token is bad because they user has changed (i.e. you've been logged out, or logged in as someone else), and explicitly asking for the user to consent to continue.

This avoids the repeated cause of pain for users of the current wikitext editor where if you get logged out for some reason, it just saves as your IP, outing you (and needing revision deletion, drama and anguish). We should be fixing the wikitext editor to mirror the protocol in VisualEditor.

It's unclear from how this is written whether "automatically retrying" means getting a new one, but only for a given user, or getting a new one regardless. If the latter, I think this is a WONTFIX. Advice?
When the surface is blurred, then focused, we should restore the selection. Right now we don't, and that causes section editing to break when ULS is present.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 93925 merged by jenkins-bot:
Restore selection when editor is refocused

https://gerrit.wikimedia.org/r/93925
Change 93925 had a related patch set uploaded by Catrope:
Restore selection when editor is refocused

https://gerrit.wikimedia.org/r/93925
1. Insert an image from Commons
2. Press Ctrl+Z quickly

When you undo the image insertion, there's still an API request pending. When it comes back, ve.ce.GeneratedContentNode.prototype.doneGenerating crashes because the node is now detached.

GCNode should protect against being detached, and should abort any pending requests when it's detached (the latter alone is not enough: GCNode promises aren't guaranteed to be abortable).

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #3)
> I am getting this following errors while undoing an image insertion quickly
> on
> both FireFox 25 and Chrome Version 26.0.1410.65 with MAC OS X 10.8.5.
> 
> Uncaught TypeError: Cannot read property 'imageinfo' of null
> ve.ui.MWMediaInsertDialog.teardown
> OO.ui.Window.close
> (anonymous function)
> proxy load.php:10
> 
> 
> See the screenshots.
> 
> Not sure if it is related with this bug or not.For now, I am reopening it.If
> it
> is a different issue I will create a separate ticket for that if required.

Unrelated issue caused by a buggy gadget, "popups".
Created attachment 13808
Screenshot of errors

**Attached**: {F12811}
After getting this error,cannot open the media dialog box again on that session.Attaching some more screenshots of the error.
Created attachment 13807
Screenshot of the error

**Attached**: {F12810}
Created attachment 13806
Screenshot of the error

**Attached**: {F12809}
I am getting this following errors while undoing an image insertion quickly on both FireFox 25 and Chrome Version 26.0.1410.65 with MAC OS X 10.8.5.

Uncaught TypeError: Cannot read property 'imageinfo' of null
ve.ui.MWMediaInsertDialog.teardown
OO.ui.Window.close
(anonymous function)
proxy load.php:10


See the screenshots.

Not sure if it is related with this bug or not.For now, I am reopening it.If it is a different issue I will create a separate ticket for that if required.
Change 93920 merged by jenkins-bot:
Guard against detached nodes in ve.ce.GeneratedContentNode#doneGenerating

https://gerrit.wikimedia.org/r/93920
Change 93920 had a related patch set uploaded by Catrope:
Guard against detached nodes in ve.ce.GeneratedContentNode#doneGenerating

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

1.Click on the "Edit" button
2.Click on More>Media
3.Now attempt to drag the dialog downward

Observed Result:
The dialog box for media inclusion closes upon dragging down

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed a while ago.
Amended steps to reproduce:

1. Mousedown on the title bar of the dialog
2. Move mouse (i.e. drag) onto an image
3. Mouseup on the image
4. Dialog closes and inserts the image
var $textarea = this.editSummaryInput.$input is bad, should just use .getValue() or whatever it is.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Masked by bug 71837.
Change 165597 merged by jenkins-bot:
Replacing $input in save dialog

https://gerrit.wikimedia.org/r/165597
Change 165597 had a related patch set uploaded by SuchetaG:
Replacing $input in save dialog

https://gerrit.wikimedia.org/r/165597
Empty inspector

Steps to reproduce:

1.Click on the Edit button
2.Click on More>LaTeX
3.Type something on the dialog box
4.While keeping this dialog box open , Click on More>Reference
5.Add something as reference 
6.Click the button "Insert Reference"

Observed Result:
A blank inspector comes up which also does not get closed unless user reopens the editor

See the screenshot attached.

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

**Attached**: {F12800}
Appears to work now
Ping on this bug.
*** Bug 64915 has been marked as a duplicate of this bug. ***
Indeed; but not on a non-blank page.

Minimum test:

* Open VE on new (blank) page
* Enter "a", <return>
* Insert > Formula; enter "1=1"
* Insert > Reference; enter "a"

Voilà.
Working fine locally and on beta labs with a blank page. Chrome && FF
Not for me still though,I am  giving the steps again :

1.Open the editor
2.Open the math inspector
3.Put the cursor inside the inspector and type something in it
4.While keeping the math inspector open , go to Insert>Reference
5.Type something in the reference dialog box and click on Insert Reference

Observed Result:
The following error appears in the console and a blank inspector shows up:

Uncaught Error: Cannot set attributes to non-element data 

See the latest screenshot.
Works for me.
This is not fixed in Betalabs or Test 2.I can still reproduce this one on both the environments.
*** Bug 63783 has been marked as a duplicate of this bug. ***
*** Bug 60801 has been marked as a duplicate of this bug. ***
The search text box

Steps to reproduce:

1. Click on the "Edit-beta" button on beta-labs
2.Click on the Language option from the toolbar
3. Click the button "Change language"

Observed Result:
The search textbox is going beyond the dialog box for selecting language.

See the screenshot attached.

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

**Attached**: {F12789}
This was fixed in a ULS update.
This bug is found in betalabs on MAC OS with Chrome Version 26.0.1410.65 and FireFox 20.0
I can't manage to reproduce this in MediaWiki.org with Chrome 30.0.1599.101 m and Firefox 24.0 in Windows.

ULS works properly for me. Can you share the browser and OS this happened in?
seems likely.  Ccing Amir and Zeljko
CC Moriel.

Is this a bug in ULS, perhaps?
We want to cache gzipped responses in Varnish. For this to work all clients need to send an Accept-Encoding header that includes 'gzip'.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 101454 abandoned by Jforrester:
[WIP] Accept-Encoding: gzip for read requests from Parsoid

Reason:
Abandoning for now.

https://gerrit.wikimedia.org/r/101454
Appears intractable. :-(
And also I should mention that on my local setup with no Varnish in the middle, and cURL installed, MW requests a gzipped copy from Parsoid and receives it. And decodes it properly.

If I force it to use the PHP engine instead of cURL, it requests a non-gzipped version and receives it fine. This should be fixed in core rather than VE having to change anything.
As far as I can tell from reading the code, this should currently only be necessary if the PHP cURL extension is not installed. (And it would also be necessary to decode the response you get back.)

And really it should never be necessary - see bug 61507
Varnish actually transparently decompresses stored compressed content and strips the supplied Accept header in its backend request. Since mid-November we always return compressed content, and Varnish stores it in compressed form for a much better hit rate. So the impact is not as high as I thought:

1) it causes some extra CPU load in Varnish for decompression

2) it results in a larger network transfer on the internal network

Both have a very small performance impact. The Parsoid Varnish is basically idle CPU-wise and the internal network is fast.

Lowering the priority to reflect this.
Change 101454 had a related patch set uploaded by Jforrester:
Accept-Encoding: gzip for read requests from Parsoid

https://gerrit.wikimedia.org/r/101454
This is important for performance, so setting priority to reflect that. Currently this causes Varnish to store uncompressed HTML, which reduces the hit rate significantly.
Some frequently-used templates in the Hebrew Wikipedia, for example {{ynet}} have an asterisk in the beginning, which is inserted conditionally according to a parameter.

They don't appear in the rendered article, but they appear as bullets when editing the article in VE.

For an example see the URL.

I demonstrated the issue to Moriel.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://he.wikipedia.org/wiki/%D7%A9%D7%9C%D7%93_%D7%91%D7%95%D7%A8%D7%A1%D7%90%D7%99
Possible Parsoid bug?
Created attachment 14508
A video of the behaviour in Swedish Wikipedia.

Perhaps the video might be an additional issue as the first template in the video; https://sv.wikipedia.org/wiki/Mall:IMDb-titel does not contain an conditional asterisk but just a plain one, which seem to be handled well in the parser.

**Attached**: {F12610}
I'm not sure that it happens always, but in this edit I changed the description of an image, and line breaks were added:

https://he.wikipedia.org/w/index.php?title=%D7%90%D7%95%D7%A4%D7%A7_%28%D7%A4%D7%93%D7%95%D7%9C%D7%95%D7%92%D7%99%D7%94%29&diff=14768833&oldid=13742934

It's the first change in the diff.

--------------------------
**Version**: unspecified
**Severity**: normal
Is this still happening? I can't reproduce.
OK, since Nemo added me here...

* "Beta" is kinda OK to translate in the languages that I know well, but it will probably be really understood only by techie people. Maybe that is the intention anyway.
* "Features" is an awful English word to translate. It's very common in software, and it's always hard to interpret well.
* I am working on the development of a big new Beta Feature (ContentTranslation), and everybody - everybody! - keeps confusing the word "beta" in "beta feature" and "beta labs", which is a completely different thing. At least one of these should be renamed.
10.21 < aharoni> YuviPanda|zzz: kart_ hallo.
10.21 < aharoni> it's about https://phabricator.wikimedia.org/T85106
10.21 < aharoni> beta features
10.21 < aharoni> not beta cluster
10.22 < aharoni> on the production cluster.
10.22 < aharoni> the beta feature is not installed there yet, but should be in two weeks.
10.22 < YuviPanda|zzz> aharoni: yeah, indeed. kart_ was trying to do this on the betacluster, which is why I was confused
10.23 < aharoni> WE REALLY NEED A DIFFERENT NAME FOR THE BETA CLUSTER
As suggested at <http://lists.wikimedia.org/pipermail/design/2013-November/001200.html>, we could rename the extension "FeaturesFeedback". :-)
(In reply to comment #19)
> Are extension names ever translated? I believe the canonical (English) name
> is
> always used when referring to the extension name itself.

Surely not. There is no general rule for this (every language's translators coordinate as do as they see fit), but most extensions "are" special pages and it is standard to translate the name of the special page/extension: https://www.mediawiki.org/wiki/Manual:Special_pages#The_Messages.2FInternationalization_File
In Special:Version, the name shown is not what "used when referring to the extension" but a quotation, as shown by the italics.

You could also try an ack-grep "\-desc" /mnt/user-store/git/extensions and try to find out how many translate the name when it's used in it, but in general the name lives elsewhere.
I wonder how many native English speakers in different ages/gender/geographical/technical ability distributions will be able to guess what the "Beta Feature" is.
It is an IT slang that pretends it went mainstream, that's all.
(In reply to comment #18)
> It is frustrating to see how the original issue, i.e. how to translate the
> name of that feature into other languages, is addressed.

Are extension names ever translated? I believe the canonical (English) name is always used when referring to the extension name itself.

For interface messages, we should use what makes the most sense in whatever language is being used, of course. That languages other than English don't contain the word "beta" is a non-issue: they also don't contain words like "category" or "visual" or whatever else. We approximate based on the intended meaning and context (e.g., by substituting "experimental" for "beta").

Again, this isn't to say that we'll never change the extension's name, but I don't think _not_ doing so is an insult to non-English speakers.
It is frustrating to see how the original issue, i.e. how to translate the name of that feature into other languages, is addressed.

I'll take a liberty to name it as I find appropriate in my language, then - just don't force me into "please communicate with the community" thing when the issue should be fixed in messages/ui/translations and not into wasted time explaining to surprised users, what Beta Features are.
(In reply to comment #16)
> (In reply to comment #0)
> > Just WONTFIX the bug if we can't do anything about it.
> 
> As it is, I think this bug should be marked resolved/worksforme
> (not resolved/wontfix), though as I said in comment 4, I don't
> have the same visceral reaction to the name that you do. :-)

Your wish is my command. :-)

We may wish to revisit this later, however.
(In reply to comment #0)
> Just WONTFIX the bug if we can't do anything about it.

If we hadn't gotten rid of it, I think this bug would be a reasonable case for using resolved/later ("later" being "until such a time that a better name is available for discussion"). As it is, I think this bug should be marked resolved/worksforme (not resolved/wontfix), though as I said in comment 4, I don't have the same visceral reaction to the name that you do. :-)
(In reply to comment #11)
> Face it. These are "Upcoming features". They will be deployed no matter if a
> few angry users don't like them.

Well, yeah. A few angry users don't outweigh the importance of building new, potentially better things for the good of the projects.

If we let emotion and a few individual opinions affect our ability to get things done, I doubt even the people we'd appeased by backing out would respect us. Certainly nobody else would, including ourselves.

We're not in "beta" because we expect to have to scrap the project. That's almost certainly not going to happen. We deployed to get feedback. Guess what? We got it! And now we're building an even more kickass bunch of projects for the next iteration.

(In reply to comment #14)
> Why does WMF build a separate one that can't be controlled by
> the communities and calls it "Beta" instead of what it really is?

Do you want to help maintain these projects? We have infrastructure for that. I'll happily sponsor you for +2 rights on them after a few patches and demonstrating that you're playing nice as a contributor.

> After looking at the actual implementation of the "Typography Update" I hope
> you are right. This is not even "Beta". I'm afraid deploying such "half-baked
> ideas" will make things worse, no matter how you call it.

If you're concerned, file a bug against it and make noise there. This isn't the arena for that discussion.

And now I'm going to hit "save changes", and hopefully be able to talk about this bug instead of some topic that doesn't belong here.
**mr.heat** wrote:

(In reply to comment #13)
> This comment probably adds more heat [...]

My comments aren't intended to add something. All I'm trying to do is to find honest words for what's already there.

> significant cost to Wikimedia community relations [...]

Let me put it that way: If you are being criticized for adding non-requested features why are you adding an other non-requested feature that can be criticized for the exact same reasons? It's not that we don't have a Gadget infrastructure. Why does WMF build a separate one that can't be controlled by the communities and calls it "Beta" instead of what it really is?

> I think there may be some value in explicitly marking particularly
> half-baked ideas or implementations. I think that's more honest.

After looking at the actual implementation of the "Typography Update" I hope you are right. This is not even "Beta". I'm afraid deploying such "half-baked ideas" will make things worse, no matter how you call it.
(In reply to comment #11)
> Face it. These are "Upcoming features". They will be deployed no matter if a
> few angry users don't like them. These features are coming like the Google+
> integration in YouTube. So call it what it really is, please. Be honest, at
> least.

This comment probably adds more heat than light (punintentional). Both ArticleFeedback and VisualEditor were scaled back following a barrage of negative feedback from their deployments (albeit not without significant cost to Wikimedia community relations...).

I'd recommend focusing on specific problems with each of the proposed 'beta' features rather than continuing to 'bikeshed' over the extension name.

> "Beta" doesn't mean anything nowadays. All we do in all Wikimedia projects is
> "Beta". Nothing will ever be finished.

Sure, but I think there may be some value in explicitly marking particularly half-baked ideas or implementations. I think that's more honest. :-)
(In reply to comment #11)
> These are "Upcoming features".

I actually like this proposal, simple and to the point.
**mr.heat** wrote:

Face it. These are "Upcoming features". They will be deployed no matter if a few angry users don't like them. These features are coming like the Google+ integration in YouTube. So call it what it really is, please. Be honest, at least.

"Beta" doesn't mean anything nowadays. All we do in all Wikimedia projects is "Beta". Nothing will ever be finished.
(In reply to comment #9)
> "Proving ground"? No idea how well it translates.

Sounds like "sandbox".
(In reply to comment #5)
> I still like "Laboratory", but James has a point – even though the same point
> can be made about "Beta" (I pointed out some examples in comment 0, another
> would be the beta cluster, ironically also called "beta labs").

Please, no more Labs/Laboratory names. In Wikimedia land we already have Labs, Tool Labs, IdeaLab, Labs²...

> 
> Other ideas for a name: something related to "innovation" or "pioneering"?
> (I quite like the second one, it gives off a nice vibe.)

"Proving ground"? No idea how well it translates.
(In reply to comment #2)

> * The language using the term "beta" is intentionally consistent with the
>   Mobile team's beta channel - this is the same concept (and will likely
>   cover Mobile technologies at some point too) and so should be translated
>   the same.

Excuse me, I can't understand the above paragraph at all :(

btw. I posted https://www.mediawiki.org/wiki/Talk:About_Beta_Features#Name few days back
Sure, I just set a high priority since this would be best FIXED or WONTFIXed before deployment, and deployment is happening very soon.
I'm sorry, MatmaRex, I'd love to think that this was an important bug, but it's really not. I mean, as wonderful as a pioneering-based name would be, it's not like "stop everything and work on this" sort of stuff.
Unlike those, BetaFeatures' name can probably still be changed. And we don't have Vector anymore, since I killed it (bug 45051).

I still like "Laboratory", but James has a point – even though the same point can be made about "Beta" (I pointed out some examples in comment 0, another would be the beta cluster, ironically also called "beta labs").

Other ideas for a name: something related to "innovation" or "pioneering"?
(I quite like the second one, it gives off a nice vibe.)
We have a lot of poorly named extensions ("Vector" and "AbuseFilter" come to mind). I'm not sure "BetaFeatures" is terrible, though.
(In reply to comment #0)
>     Basically, any translation of this will consist solely of
>     English/Latin loanwords in almost all languages, which may make it
>     sound "remote" or "unfriendly".

And where I said "Latin", what I actually meant was Greek for "beta" and Latin for "function".
Five points:

* The language using the term "beta" is intentionally consistent with the
  Mobile team's beta channel - this is the same concept (and will likely
  cover Mobile technologies at some point too) and so should be translated
  the same.

* "Experimental" sounds clinical, complicated and confusing in English,
  which is why it wasn't used.

* If you are translating from English into a language that doesn't use the
  Greek word 'beta', and also does not have an equivalent, calling it
  "experimental" sounds fine.

* The language using the term "features" is intentionally broad, to cover
  new functionality, new UX approaches to existing functionality, new
  design concepts, new skins, and other new things. Translations should
  use a broad, inclusive term to cover all of these.

* "Labs" is unfortunately already taken by WMF Labs. It would have been a
  great name for this, I agree, but that's life. Unless you have a time-
  machine handy, we can't fix the confusion that naming these the same
  would cause.
(In reply to comment #0)
> * We can try renaming the project. We could go with the lowest
>   friction option and call it "Experimental features", which would be
>   at least a little better.

I think this was rejected in the past because it may include features thought or meant to be stable, just too "new" to be enabled for everyone at once.

> 
> * Or we could use others' experiences and name that section
>   "Laboratory", which would also give us an obvious, clear icon to use
>   (laboratory beaker) – Google does this with their experimental
>   options and it has always seemed like a great idea to me.

No idea if "Laboratory" is better than "Beta", they seem equally generic. "Beta" is just the most common way across the web/software industry to brand something as "the last thing" and tell people not to blame you if it breaks something; it doesn't have "a meaning" apart from that. I don't know if "Laboratory" has an equally wide usage/understanding.
The main confusion here might be that not all features branded "beta" are controlled by this "beta" general switch; no idea if this is temporary.
When we open a random page, we get
wgCurRevisionId === wgRevisionId
and if we make an edit using the source editor, both variables are increased to a new Id.

On the other hand, if the edit is made using the VisualEditor, only the wgCurRevisionId is updated.

This inconsistent behavior should be fixed.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 127441 merged by jenkins-bot:
Update wgRevisionId when we change wgCurRevisionId

https://gerrit.wikimedia.org/r/127441
Change 127441 had a related patch set uploaded by Alex Monk:
Update wgRevisionId when we change wgCurRevisionId

https://gerrit.wikimedia.org/r/127441
The "<" icon on last clicked link

Steps to reproduce:

1.Click on the Edit button
2.click on a text which has link on it but do not open the link inspector
3.Now click on a blank space
4.Click on the link icon from the toolbar.

Observed Result:

The "<" icon shows up at the end of the text in step 2.

See the screenshot attached.

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

**Attached**: {F12481}
This was fixed a while ago; sorry for not catching it then.
Steps to reproduce:

-Click on the Edit button
-Click on the icon to insert a link from the toolbar or press ctrl+k or command+k -Now type a valid URL without http:// for example:yahoo.com

Observed Result:
There is no option for selecting this link as external link other than creating a new page.

It would be better if the external link option is made available to user when they type a valid URL (text with "." inside it), and then transforms it into a HTTP link if no prefix is provided.

--------------------------
**Version**: unspecified
**Severity**: enhancement
*** This bug has been marked as a duplicate of bug 50360 ***
(In reply to comment #2)
> (In reply to comment #1)
> > Change 97733 had a related patch set uploaded by Marcoil:
> > Bug 56490: Use the HTTP API in round-trip testing
> > 
> > https://gerrit.wikimedia.org/r/97733
> 
> I don't think this has anything to do with that?

Sorry! I entered the wrong bug for git-review.
(In reply to comment #1)
> Change 97733 had a related patch set uploaded by Marcoil:
> Bug 56490: Use the HTTP API in round-trip testing
> 
> https://gerrit.wikimedia.org/r/97733

I don't think this has anything to do with that?
Change 97733 had a related patch set uploaded by Marcoil:
Bug 56490: Use the HTTP API in round-trip testing

https://gerrit.wikimedia.org/r/97733
Difference in the view mode

Steps to reproduce:

1.Click on the Edit-beta button
2.Type a text to apply link on it, For example: CNN
3.Now click on the link icon from the tool bar or press ctrl+k/ Command+K
4.Now type the link as http://cnn.com as an external link.
5.Now type again another text CNN
6.Now apply link insertion onto it as : http://cnn.com as new page
7.Press the button "Save"

Observed Result:
Now observe that the link created in step 4 looks reasonable to have an external
link when the URL is specific in the link inspector.
But user wont usually want a new page while specifying the URL itself and might accidentally to do that without any intention to do that.

Also, observe the output format of step 6 looks wrong as the wiki markup for link shows up in the CE in view mode with a number.Though functionally, it works same as a link to external page.   

Expected Result:
As a suggestion,collapse the "New Page" part of the link inspector when a URL pattern detected.

See the screenshot attached.

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

**Attached**: {F12432}
(In reply to Alex Monk from comment #4)
> (In reply to James Forrester from comment #3)
> > We don't want to do this, because "http://www.amazon.com" is a valid page
> > name and someone might actually want to use it - for example, [[en:Http://]]
> > is a page (specifically, a redirect to the HTTP article).
> > 
> > However, maybe we should demote the "new" section below the external link
> > one, to make it clearer?
> 
> It looks like this has already been done? Am I missing something?

You're completely right, we did this a while ago. Never mind me! Sorry for wasting your time. :-(
(In reply to James Forrester from comment #3)
> We don't want to do this, because "http://www.amazon.com" is a valid page
> name and someone might actually want to use it - for example, [[en:Http://]]
> is a page (specifically, a redirect to the HTTP article).
> 
> However, maybe we should demote the "new" section below the external link
> one, to make it clearer?

It looks like this has already been done? Am I missing something?
We don't want to do this, because "http://www.amazon.com" is a valid page name and someone might actually want to use it - for example, [[en:Http://]] is a page (specifically, a redirect to the HTTP article).

However, maybe we should demote the "new" section below the external link one, to make it clearer?
Created attachment 13657
Difference in the review mode

**Attached**: {F12433}
Also, if I review my changes it shows the attached format.
==== Problem
The orange "You have new messages" talkpage-message Notification, currently leads just to the top of the user's Talk page. (Ie. [User talk:Quiddity])
This is potentially confusing and makes it harder for users to locate the new message.
{F26220991}

==== Proposed solution
* Tapping on "new messages" should take the user to the specific subsection (if known, and if there's just one new message); and
* Append the message with a "(view changes)" link which takes the user to the diff (if subsection is unknown, or if there are multiple new talkpage messages).

(Note: This essentially follows the same message format as shown to users of the gadget to "Display a floating alert for new talk page messages" (link to [[ https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-gadgets | gadget on enwiki ]])


// One user has requested that it *always* lead to the diff, which /would/ be more consistent, but I also understand the desire to not confront everyone with a diff (VE, newcomer friendliness, etc etc). ( https://en.wikipedia.org/wiki/Wikipedia_talk:Notifications#Two_clicks_instead_of_one:_Why.3F ) //
Change 94506 abandoned by Aude:
Link "You have new messages" to user talk diff

Reason:
since ext.echo.alert.js is deleted, shall try new approach :)

https://gerrit.wikimedia.org/r/94506
Change 94506 had a related patch set (by Aude) published:
Link "You have new messages" to user talk diff

https://gerrit.wikimedia.org/r/94506
(In reply to comment #3)
> I could have sworn this was a duplicate bug... I may be remembering the bug
> about the Echo drop-down nav thing not including a "view changes" link.

You're probably thinking of bug 54391 - which I've been told is just to do with the email bundled diff (or something).
I could have sworn this was a duplicate bug... I may be remembering the bug about the Echo drop-down nav thing not including a "view changes" link.
(In reply to comment #0)
> The orange "You have new messages" talkpage-message Notification, currently
> leads just to the top of the user talkpage. (Ie. [User talk:Quiddity])

This is one of the things I probably miss the most about the OBOD, that I could get a direct diff to the new edits.

> 
> It should lead to either:
> * the subsection (if known, and if there's just one new message), or 
> * to the diff (if subsection is unknown, or if there are multiple new
> talkpage
> messages).

From a code standpoint, either of these are probably doable.

> 
> One user has requested that it *always* lead to the diff, which /would/ be
> more
> consistent, but I also understand the desire to not confront everyone with a
> diff (VE, newcomer friendliness, etcetc).

I don't think always going to the diff is a good idea, for some of the reasons you mentioned.

Adding a "You have new messages (diff)" thing to the personal tools menu would be icky and add some more clutter. I don't know where else we could add the link.

CC'ing Jared for some design input.
The WMF core features team tracks this bug on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/395, but people from the community are welcome to contribute here and in Gerrit.
Since bug 50687 was fixed, I was wondering if wouldn't be a good idea to identify which edits made using the wikicode editor were actually started using Visual Editor. This could be useful to identify potential areas of improvement of Visual Editor, providing a list of actions which users are unable to complete using it.

A way to do this would be the use of a new tag (similar to the "visualeditor" and "visualeditor-needcheck" tags).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50687
Change 113665 merged by jenkins-bot:
Track edits where user switched into wikitext editor from VE

https://gerrit.wikimedia.org/r/113665
Change 113665 had a related patch set uploaded by Alex Monk:
Track edits where user switched into wikitext editor from VE

https://gerrit.wikimedia.org/r/113665
Split from bug 51507 which introduced Ctrl/Cmd + \ as a trigger for this.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51507
Change 116967 merged by jenkins-bot:
Add cmd/ctrl+m as alternative shortcut for clear formatting

https://gerrit.wikimedia.org/r/116967
Change 116967 had a related patch set uploaded by Esanders:
Add cmd/ctrl+m as alternative shortcut for clear formatting

https://gerrit.wikimedia.org/r/116967
Changing priority to 'normal' since 51507 was 'high' and I'm hesitant to make this 'low'; please feel free to re-adjust.
Steps to reproduce:
1.Click on the "Edit-Beta" button
2.Type a text on which to insert link
3.Press "Enter" to select the suggested links or if there is no match just press "Enter"
4.Then again press "Enter"

Observed Result:
To insert a link the step 4 is a redundant step , Pressing enter once should just add the link.

Pressing the "Enter" twice seems justified in the case, where the content of the link box is different from what user initially typed into.

[Suggested by Erik Moeller]

--------------------------
**Version**: unspecified
**Severity**: enhancement
Verified the fix in production
Verified the fix in test2
Now fixed with the changes to the link inspector.
Screenshot showing cursor at the beginning of the text "Yahoo"

Steps to reproduce:
-Click on the Edit-beta button
-Type a text on which you will insert a link.
-click on the link icon from the toolbar or use shortcut keys ctrl+k/command+k(MAC)
-Type the link on the dialog box that appears .
-Press "Enter" to apply that.

Observed Result:
The cursor position postion moves to the beginning of the text on which the link inserted making user to reposition it to the end of it to continue editing.

Expected Result:
The cursor position for newly inserted link should be at the end of the link to ease user experience.

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

**Attached**: {F12328}
This was fixed a few months ago (the cursor returns to the original position if you exit normally, or goes to the beginning of the document if you exit with escape).
VisualEditor deliberately drops <span typeof="mw:Nowiki"> annotations on changed content to prevent originally-necessary <nowiki> blocks interfering with editing. This means that HTML editors don't need to know or care about <nowiki>s, and they are just magically sorted out in the back-end so the resultant wikitext is the most like what a human would create.

However, <nowiki />s come out as a <meta typeof="mw:Placeholder">, which VisualEditor doesn't show to users but also won't ever remove, leading to potential issues where a no-longer-needed <nowiki /> sits in the wikitext, disruptively confusing to wikitext editors.

If Parsoid instead represented it as <span typeof="mw:Nowiki"></span> or similar, VisualEditor could do the same (well, a bit more work) and so drop it when the context has been edited, letting Parsoid re-generate it if needed.

--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://en.wikipedia.org/w/index.php?title=Footprints_%28film%29&curid=39472392&diff=579475542&oldid=579357688
@Jdforrester-WMF Do we actually need any work in VE? This seems to be magically working okay in my testing. If I'm missing something, is there a task?
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVo97A6WHQCSeVEJfLNq} [2017-02-14T18:39:24Z] <arlolra> Updated Parsoid to 79ccfb93 (T58381, T108216)
Thank you!
Parsoid now represents them as <span typeof="mw:Nowiki"></span>, but VisualEditor still needs to do the work to drop them when the context has been edited.
Change 281076 merged by jenkins-bot:
Treat html pre and nowiki as extension tags

[[https://gerrit.wikimedia.org/r/281076]]
Change 281076 had a related patch set uploaded (by Arlolra):
WIP: Tokenize html pre as an extension tag

[[https://gerrit.wikimedia.org/r/281076]]
Change 232313 abandoned by Arlolra:
WIP: Edited nowiki content should invalidate the nowiki

Reason:
For now ... until I pick it up again.

[[https://gerrit.wikimedia.org/r/232313]]
Change 191096 abandoned by Subramanya Sastry:
WIP: T58381: Represent <nowiki/> as a mw:Nowiki meta tag

Reason:
Once we figure out how to not generate HTML for <nowiki>s and instead add them back where needed, this is going to be irrelevant.

[[https://gerrit.wikimedia.org/r/191096]]
Change 232313 had a related patch set uploaded (by Arlolra):
WIP: Edited nowiki content should invalidate the nowiki

[[https://gerrit.wikimedia.org/r/232313]]
Change 232313 had a related patch set uploaded (by Arlolra):
T58381: Edited nowiki content should invalidate the nowiki

[[https://gerrit.wikimedia.org/r/232313]]
Works for me.
I agree that fixing nowiki issues are important. But, we should add specific nowiki corruption tasks to the board rather than have a generic longer-term solution like this. I will go over our current nowiki list and add any specific nowiki corruption scenarios to the VE Q3 board. Sound good?
>>! In T58381#1055479, @ssastry wrote:
> Based on all this, I am not sure that this task should be on the VE Q3 blocker list anymore. These fixes are more of a longer-term nature than what is required immediately for VE in Q3. @Jdforrester-WMF, thoughts?

I'm not sure. Reducing the frequency of <nowiki>s is a key "corruption" concern of users, and as such is a key blocking focus for Q3. I don't particularly see this task as the one-true-fix, and happy for this to be removed if the other work in this area addresses the concerns. What do you think?
Based on an IRC discussion y'day during the VE/Parsoid/Services check-in, it seems that more than fixing the representation for nowiki, VE wants Parsoid html2wt to be more aggressive removing existing <nowiki/> from edited content rather than emit those back as is. Something to be considered.

A related idea that came up during the discussion was: maybe Parsoid shouldn't emit the nowiki markup anymore in its HTML. This will work only if:
(a) selser is smart enough to add nowikis wherever required (even for unedited content)
(b) selser is smart enough to not introduce dirty diffs  by optimizing / moving around nowikis because of (a). This is especially a concern fwiki, itwiki, etc. where quotes are used in non-italic/non-bold scenarios more heavily. So, any fixes we do should be tested more heavily against these wikis.

A related discussion around (a)/(b) here can be found in https://phabricator.wikimedia.org/T87708#1055269 and later comments.

But, based on all this, I am not sure that this task should be on the VE Q3 blocker list anymore. These fixes are more of a longer-term nature than what is required immediately for VE in Q3. @Jdforrester-WMF, thoughts?
Based on an IRC discussion y'day during the VE/Parsoid/Services check-in, it seems that more than fixing the representatoin for nowiki, VE wants Parsoid html2wt to be more aggressive removing existing <nowiki/> from edited content rather than emit those back as is. Something to be considered.

A related idea that came up during the discussion was: maybe Parsoid shouldn't emit the nowiki markup anymore in its HTML. This will work only if:
(a) selser is smart enough to add nowikis wherever required (even for unedited content)
(b) selser is smart enough to not introduce dirty diffs  by optimizing / moving around nowikis because of (a). This is especially a concern fwiki, itwiki, etc. where quotes are used in non-italic/non-bold scenarios more heavily. So, any fixes we do should be tested more heavily against these wikis.

A related discussion around (a)/(b) here can be found in https://phabricator.wikimedia.org/T87708#1055269 and later comments.

But, based on all this, I am not sure that this task should be on the VE Q3 blocker list anymore. These fixes are more of a longer-term nature than what is required immediately for VE in Q3. @Jdforrester-WMF, thoughts?
Based on an IRC discussion y'day during the VE/Parsoid/Services check-in, it seems that more than fixing the representatoin for nowiki, VE wants Parsoid html2wt to be more aggressive removing existing <nowiki/> from edited content rather than emit those back as is. Something to be considered.

A related idea that came up during the discussion was: maybe Parsoid shouldn't emit the nowiki markup anymore in its HTML. This will work only if:
(a) selser is smart enough to add nowikis wherever required (even for unedited content)
(b) selser is smart enough to not introduce nowikis by optimizing / moving around nowikis because of (a). This is especially a concern fwiki, itwiki, etc. where quotes are used in non-italic/non-bold scenarios more heavily. So, any fixes we do should be tested more heavily against these wikis.

A related discussion around (a)/(b) here can be found in https://phabricator.wikimedia.org/T87708#1055269 and later comments.

But, based on all this, I am not sure that this task should be on the VE Q3 blocker list anymore. These fixes are more of a longer-term nature than what is required immediately for VE in Q3. @Jdforrester-WMF, thoughts?
<meta> tags will be metadata in VE, so may end up somewhere else if content is deleted. Also <meta> and <link> tags suffer from being destroyed by copy/paste and so require special treatment (we also do this for HTML comments).
Uploaded a WIP there in case that would work. The meta tag seems the right approach and fits in with the use of marker meta tags for various other wikitext constructs.
Change 191096 had a related patch set uploaded (by Subramanya Sastry):
WIP: T58381: Represent <nowiki/> as a mw:Nowiki meta tag

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

#patch-for-review
How about <meta typeof="mw:Nowiki" ../>. Can VE handle that instead?
*** Bug 59650 has been marked as a duplicate of this bug. ***
*** Bug 53659 has been marked as a duplicate of this bug. ***
*** Bug 59829 has been marked as a duplicate of this bug. ***
(In reply to comment #1)
> If we want to perform clean-up like this, then we should perhaps implement
> that in Parsoid rather than VE so that other users benefit from it as well.

Happy for it to be done in Parsoid instead, and for us to remove the dropping from VE.
If we want to perform clean-up like this, then we should perhaps implement that in Parsoid rather than VE so that other users benefit from it as well.
Blurred Autonym font

Interwiki names blurred and legible with difficulty (using the hardcoded "Autonym" font)

Firefox 25 / WinXPSP3 / standard antialiasing (= no ClearType)

--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Windows 7
**Platform**: PC
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=40874
https://bugzilla.wikimedia.org/show_bug.cgi?id=56552
https://github.com/santhoshtr/AutonymFont/issues/38
https://github.com/santhoshtr/AutonymFont/issues/50

**Attached**: {F12122}
Thanks for confirming.
(In reply to comment #87)
> (In reply to comment #86)
> > With the tofu detection that recently added into ULS, users no longer see
> > degradation of text quality for fonts they have. I think that addresses the
> > main concern of this bug report.
> 
> That was https://gerrit.wikimedia.org/r/#/c/108024/
> 
> Given https://gerrit.wikimedia.org/r/#/c/108735/ I think the change can
> currently be tested (only) on test.wikipedia.org. The main page may suffice:
> https://test.wikipedia.org/wiki/Main_Page

So, the fix is apparently not deployed on testwiki, but it *is* deployed on beta labs: http://en.wikipedia.beta.wmflabs.org/ (after you register and enable ULS). And it does seem to help there, most language names are displayed in normal fonts for me; the list still looks pretty silly with some language names being pretty and antialiased and some not, but it's definitely better.
(In reply to comment #87)
> (In reply to comment #86)
> > With the tofu detection that recently added into ULS, users no longer see
> > degradation of text quality for fonts they have. I think that addresses the
> > main concern of this bug report.
> 
> That was https://gerrit.wikimedia.org/r/#/c/108024/
> 
> Given https://gerrit.wikimedia.org/r/#/c/108735/ I think the change can
> currently be tested (only) on test.wikipedia.org. The main page may suffice:
> https://test.wikipedia.org/wiki/Main_Page

This has not fixed the issue for me; the list of languages still looks just like in the screenshots provided here.
(In reply to comment #82)
> This bug cannot be marked "fixed" but should become a tracker, [...]

But the tracked bugs are on another bug tracker; that's the difficulty.

(In reply to comment #86)
> With the tofu detection that recently added into ULS, users no longer see
> degradation of text quality for fonts they have. I think that addresses the
> main concern of this bug report.

That was https://gerrit.wikimedia.org/r/#/c/108024/

Given https://gerrit.wikimedia.org/r/#/c/108735/ I think the change can currently be tested (only) on test.wikipedia.org. The main page may suffice: https://test.wikipedia.org/wiki/Main_Page
With the tofu detection that recently added into ULS, users no longer see degradation of text quality for fonts they have. I think that addresses the main concern of this bug report.

For the fonts users don't have, the issue is still present. However, going from completely unreadable tofu to more readable autonym font is an improvement in my opinion.
(In reply to comment #78)
> ULS has been disabled on all wikis except Wikidata (bug 46306 +
> https://gerrit.wikimedia.org/r/108735), so this bug is not relevant for WMF
> wikis right now. Considering we also have two duplicate reports on GitHub I
> think it's clearer to close this one.

This isn't in keeping with standard practice. We usually tag the local bug as upstream and leave the local bug open in order to make discovery easier.

Thank you for adding the GitHub links to the "see also" section.
I'd also reopen this bug. Only because ULS can be switched off now does not mean it will not be used by people who find it useful. Additionally I could personally imagine the default state of the newly created option to be switched to "enabled" in future (therefore enabling ULS by default unless the user opts out).

The bad font rendering was one of the worst annoyances around ULS (and probably the most visible one). Especially since it basically broke something that worked without problems before.

I'd keep this bug open to track the progress of the "upstream" bug in Git.
(In reply to comment #82)
> I also agree that forcing ULS completely off is a bad situation. At least it
> should remain as an optional gadget in user preferences, possibly in the Beta
> preferences...

You can still enable it in the user preferences > User profile > Internationalisation.
I also agree that forcing ULS completely off is a bad situation. At least it should remain as an optional gadget in user preferences, possibly in the Beta preferences.

I really love the possibility of switching user langguage of the interface in one click, notably for testing translatable pages, usng the ULS icon at top of pages, even if I did not like much the ugly look of the Autonym font

Nothe that the Autonym font lacks is still lacking a BOLD version, for example in language navboxs displayinf the current language in Bold black instead of a normal link, or usable with the LangSelect template or the "multilingual" on Commonns, where all language autonyms are displayed. If the "autonym" class is present, and Autonym webfont downloaded, the browser will use synthetic bold which is almost unreadable in sme scripts like Hebrew.

This bug cannot be marked "fixed" but should become a tracker, expecting for more work to be done. IT should remain open or at least replaced by a new tracking bug collecting the efforts in ULS and all the various things to do to improve it.

So please reenable ULS at least in Beta preferences, and split ULS into several separate gadgets (Webfonts alone independantly of languages, IME, script variant selector for Chinese with automated transliterators, per-languuage font preferences with or without webfonts, and UI language selector) even if there remains a central dialog to setup all these components.
Now that ULS is disabled by default the usage of webfonts is totally broken: https://de.wikipedia.org/wiki/Benutzer:Raymond/Webfonts :-(
(In reply to comment #79)
> This still applies if somebody chooses to enable ULS. I suggest reopening.

Indeed we don't know what was the rationale for bug 46306, but I suppose it was that one will just disable ULS if one doesn't see a benefit. So if the Autonym font gives you problems you won't enable it. Unregistered users can't enable preferences, so the "if somebody chooses to enable ULS" scenario doesn't apply to them.
So, yes, technically the issue still exists but not in default code.
This still applies if somebody chooses to enable ULS. I suggest reopening.
ULS has been disabled on all wikis except Wikidata (bug 46306 + https://gerrit.wikimedia.org/r/108735), so this bug is not relevant for WMF wikis right now. Considering we also have two duplicate reports on GitHub I think it's clearer to close this one.

General discussion continues at bug 56292, bug 60304 tracks the revert of bug 46306, the future is unknown but should be bug 56433 comment 22.
*** Bug 57999 has been marked as a duplicate of this bug. ***
Nux, (In reply to comment #68)
> Hi. Not sure what you've used for generating the font, but if you've used
> fontsquirrel.com, then consider the following:
> 1. Generate SVG font (if you're not doing it already).
> 2. Use ttf above woff.
> 3. Preserve original hinting if it was available.

ULS Preserve the hints in woff and eot. See
https://gerrit.wikimedia.org/r/#/c/95987/ (Nov 20)

Documentation about how the fonts are developed: https://github.com/santhoshtr/AutonymFont/

And about how webfonts are created: see http://www.mediawiki.org/wiki/Extension:UniversalLanguageSelector#Preparing_webfonts

Note the 200% size increase in your version of the font from fontsquirrel.
> For this project, just uploading the generated fonts into the MediaWiki
repository is clearly not enough, there should exist a full project containing
or documenting the build tools used to perform these conversions.

I don't agree. The generated font is better in practice. In practice all fonts are visible and selectable (or at least in all browsers I tried).

Also note that there is a configuration in the attachment describing the process ("generator_config.txt"). So the effect should be reproducible without any problems.

If you can make a better font go ahead. Seriously. I know that the tool (fontsquirrel) is not perfect. I've converted a different font and had to do a lot tweaking to get good results. BUT we should progress to a better solution then the current one and then fix other issues (if we can).
Also the "missinglyph" item of the SVG is just mapped with an advance-width equal to the space character; it has no path for the glyph itself, where it should have a path drawing an empty box in that space.

The unselectable glyphs seem to come from an incomplete conversion tool, that does not know really how to map the glyphs selectable by OpenType features into the necessary mappings for making them selectable by the SVG font.

An SVG font cannnot use OpenType feature, because it lacks the logic included in the OpneType renderers to select these features. OpenType features have implicit selection rules from the script and character properties. Then each feature adds GSUB and GPOS rules for mapping glyph definitions. In an SVG font, all the implicit rules must be mapped (the only exception supported by current relase of the SVG font spec being the Arabic joining type). This means that Indic script cannot work with simple one-to-one mappings of a character code to a glyph, with their required features. You need to map Unicode strings (not characters) into a SVG glyph definition to support the equivalent of contextual substitutions, and use the "hkern" (or "vkern") definitions to support the equivalent of OpneType GSUB (for contextual positioning).

I think that the tool used to convert OpenType fonts to SVG font is insufficient for "complex scripts" (those that have REQUIRED features needed; see the OpenType specfiications). This means that extra manual tweaking are needed in the SVG font to make it work correctly (the existing tool is not doing things properly with its one-to-one character-to-glyph mappings, and its bogous unselectable zero-to-one mappings).

For this project, just uploading the generated fonts into the MediaWiki repository is clearly not enough, there should exist a full project containing or documenting the build tools used to perform these conversions.
I don't why are those glyphs present but I think they won't be used anyway if they don't have `unicode` attribute. If someone knows for sure they are not needed, then I guess they can be removed. BTW selecting characters (and copy&paste) works fine for me for all characters used for Main Page.
Note that the SVG version includes 76 glyphs which are not selectable at all (they have no unicode attribute and no id attribute referenced by some assigned glyph with script features. I wonder how they can be present, or if the tool converting TTF fonts to SVG fonts simply lacks info on how to map the opentype features needed to select and render these contextual glyphs. Some of these glyphs are also non-spacing (no horiz-adv-x attribute) but also not correctly selected. Some of them are for mandatory ligatures, and should be selectable by an unicode attribute specifying 2 Unicode characters, or sometimes more.
Only the contextual forms of letters in the Arabic script (up to 3 in addition to the default isolated form) are selectable.
(In reply to comment #69)
> Created attachment 13871 [details]

Nice! Thank you Maciej!
It looks great on Windows XP too (Windows 7 was the worse).

Now, could we replace the current

https://bits.wikimedia.org/static-current/extensions/UniversalLanguageSelector/data/fontrepo/fonts/Autonym/Autonym.ttf?version=20131112
and
https://bits.wikimedia.org/static-current/extensions/UniversalLanguageSelector/data/fontrepo/fonts/Autonym/Autonym.woff?version=20131112

with these uploaded by Maciej?

This should then allow us to close this bug.

**Attached**: {F12132}
Created attachment 13871
Fixed font - notice how the font is defined in stylesheet.css!

Fontsquirrel to the rescue :-). Attaching fixed font (made from automnym.ttf).

Have tested on IE 10, Opera 12, Chrome 31 and Firefox 25 (Windows 7). All glyphs in all sizes seem fine and readable beyond font size 11.

Also tested in IE compatibility modes. The font remains readable even in IE 8, though kerning seem worse in this version (better from IE 9 up). If you see this as a problem then you can set `letter-spacing:.1em`.

**Attached**: {F12132}
Hi. Not sure what you've used for generating the font, but if you've used fontsquirrel.com, then consider the following:
1. Generate SVG font (if you're not doing it already).
2. Use ttf above woff.
3. Preserve original hinting if it was available.

You might want to experiment a bit, but that was the best options for me when generating web fonts from open type font.
Autonym font is a soulution for a problem, that never existed before ULS. Even now I didn't understand the reason to serve (load) webfonts by default to Latin languages. Nowadays even problematic Indic languages have much better support in OSs, a situation which makes Webfonts less than a necessity there. So I think most favorable solution may be disabling webfonts than 'temporarily intelligent' solutions like problematic Autonym font.
Here some screenshot on Firefox 25, Windows LCD rendering (*).

12px (en.wikipedia): http://files.espace-win.org/2013/Capture.PNG
13px (fr.wikipedia): http://files.espace-win.org/2013/Capture2.PNG

(*) There are two fonts rendering mode on Windows, one with LCD support when ClearView option is enabled, one without.
Then the font in this one sidebar section would be larger than in all the other ones, which is going to look even more silly than the current state. I suggest not doing that.
To achieve comment 63 suggestion:

  #p-lang-list li {
      font-size: 0.8125em !important;
  }
(In reply to comment #62)
> The critical bad rendering occurs:
> * when rendering font sizes below 13px (for example, small text: you loose
> important pixels: don't render lists of languags with a reduced font size;
> unfortunately the default font-size of MediaWiki is reduced from the browser
> standard, so you see these effects with lost pixels).

Actually, 13px (0.8 x 16px) is the default for Vector, and Autonym looks acceptable at 13px. However, the navbar has its font-size set to 0.75em, which causes Autonym to drop to 12px, and the problem is very apparent.

Seems like a little CSS tweaking on #p-lang might solve the primary concern.
Note that it's true that the Autonym font lacks hinting; but my test page demonstrates that it should not be used with all CSS styles, but that it works quite well within some limits (font-size:13px;font-weight;normal;font-style:normal;letter-spacing:normal), provided that the browser does not zoom in, on displays with low pixel densities (96dpi).

Displays with high pixel densities look OK (example: smartphones that typically have densities around 190 dpi or more). With their default zoom (you'll experience poor readability only if you soom out).

The critical bad rendering occurs:
* when the browser zoom is around 120-150 dpi, because glyphs are just scaled up from a low dpi rendering (around 96 dpi on desktops/notebooks displays) without hinting, or
* when rendering font sizes below 13px (for example, small text: you loose important pixels: don't render lists of languags with a reduced font size; unfortunately the default font-size of MediaWiki is reduced from the browser standard, so you see these effects with lost pixels).
(In reply to comment #37)
> Against this common sense ULS was designed to load webfonts for a huge bunch
> of
> languages. Therefore we started to load additional font support for every
> Wikipedia user, even if it was most unlikely that a user actually needed it.

You're wrong! Autonym in ULS was designed to load ONLY this font instead of a bunch of fonts.

Performance tests show that
* the download bandwidth uis highly reduced because ULS no longer needs to download many fonts (OK you don't download fonts for your installed system fonts)
* the time to render the page is faster (the Autonym webfont is normally cached by your brower, it won't load again when you navigate, unless it has been updated on the server)
* the browser needs to load many less fonts to render lists of language names: with your many system fonts configured for each script or language by your CSS preferences or by your browser settings, the browser will need to load all these system fonts in memory (even if the browser also uses a font rendering cache).
* Nothing is changed for the rest of the page content (outside language autonyms): the content still uses your own choice of fonts
* You can tweak webfonts used by ULS to use other more complete (and hinted) webfonts proposed by ULS: they will override the Autonym font if the span element containing the language name does not only use the CSS class "autonym", but also sets the lang="" attribute to specify its language.
* You can tweak you own CSS rules to provide other local fonts you have for a specific language using CSS lang() selectors.
Note that the rendering of the Autonym font may be tweaked with ULS, provided that the span using the autonym class also sets the lang attribute (as it should).

So you can use ULS to select another supported webfont for each language supported by ULS. The Autonym font will be used only if you select "use system font" in ULS for that language. If you select another proposed webfont, it will override the font specified in that class (and this other webfont will be loaded by your browser to render this language).
For reference, you may look at this page which tests the Autonym font with all Active Wikimedias, under various styles:

https://meta.wikimedia.org/wiki/Wikimedia_Forum/Autonym_font_test_with_active_Wikipedias
**michael** wrote:

(In reply to comment #57)
> (In reply to comment #41)
> > (In reply to comment #37)
> > > Autonym (which will by definition never be as good as a native font like Arial on Windows)
> > 
> > I don’t understand the logic of this. Arial is hardly a great typeface
> > anyway.
> 
> Don't confuse design with legibility. Arial is the default sens-serif on
> Windows, and renders *very* well on Windows. Autonym renders *very* bad on
> Windows, because the font (and its source FreeSans) were never desigend with
> Windows in mind, and therefor lack any hinting.

Sure, the design of a typeface doesn’t matter as much if your system distorts the character shapes to fit a pixel grid. As higher-resolution displays are becoming common, screen hinting is going away and good font design is starting to be considered good font design. 

Anyway, the immediate fix is to import hinted character outlines from a better free font. Yes, easier said than done, but there’s no reason it couldn’t match Arial’s quality in any particular OS or browser.


> 
> > A simple fix for much of this would be to embrace installed fonts, and push
> > Autonym to the bottom of a font stack that includes the default sans-serif
> > fonts on the various platforms. I wonder if, indeed, “font-family:
> > sans-serif, autonym;” would work to make this font the fallback’s fallback.
> > Ideally, it should only be rendering text that would show up as tofu. Ideally.
> 
> I doubt it. Windows usually uses the first available font in the font stack
> and
> sticks with it, and revert to its default unicode font if it can't find a
> glyph
> (usually Lucida Sans Unicode).

I think it might be more complicated than that. MSIE 6 ignores fallbacks for individual characters missing from a font, but I understand that newer versions have improved on this. As far as I know, Firefox uses its own font choice and rendering engine.
(In reply to comment #41)
> (In reply to comment #37)
> > Autonym (which will by definition never be as good as a native font like Arial on Windows)
> 
> I don’t understand the logic of this. Arial is hardly a great typeface
> anyway.

Don't confuse design with legibility. Arial is the default sens-serif on Windows, and renders *very* well on Windows. Autonym renders *very* bad on Windows, because the font (and its source FreeSans) were never desigend with Windows in mind, and therefor lack any hinting.

> A simple fix for much of this would be to embrace installed fonts, and push
> Autonym to the bottom of a font stack that includes the default sans-serif
> fonts on the various platforms. I wonder if, indeed, “font-family:
> sans-serif, autonym;” would work to make this font the fallback’s fallback.
> Ideally, it should only be rendering text that would show up as tofu. Ideally.

I doubt it. Windows usually uses the first available font in the font stack and sticks with it, and revert to its default unicode font if it can't find a glyph (usually Lucida Sans Unicode).
(In reply to comment #52)
> Created attachment 13824 [details]
> ENWP Sidebar, Windows 8, IE 10

Seems like ordinary Arial. In other words, it does not use Autonym in this screenshot.

**Attached**: {F12131}
(In reply to comment #54)
> (In reply to comment #51)
> > Screenshot on a default Windows 8, IE 10
> > 
> > Good news? It seems better on Windows 8.
> 
> From your screen-shots, it seems there's something fundamentally wrong with
> your font rendering(besides anything Autonym may cause):
> - Do you notice the uneven thickness of vertical lines? This should not occur
> if Hinting works as expected.
> - You seem to have Subpixel-anti-aliasing (alias ClearType) turned off, but
> you
> seem to be still utilizing some sort of grayscale-anti-aliasing. Is this on
> purpose?

I have no idea at all. I happened to be using a Windows 8 PC (not mine) and took those screenshots.
(In reply to comment #51)
> Screenshot on a default Windows 8, IE 10
> 
> Good news? It seems better on Windows 8.

From your screen-shots, it seems there's something fundamentally wrong with your font rendering(besides anything Autonym may cause):
- Do you notice the uneven thickness of vertical lines? This should not occur if Hinting works as expected.
- You seem to have Subpixel-anti-aliasing (alias ClearType) turned off, but you seem to be still utilizing some sort of grayscale-anti-aliasing. Is this on purpose?
(In reply to comment #51)
> Good news? It seems better on Windows 8.

Could you test it with either Firefox/Chrome/Opera to make sure it's not just IE?
Created attachment 13824
ENWP Sidebar, Windows 8, IE 10

**Attached**: {F12131}
Created attachment 13823
Screenshot on a default Windows 8, IE 10

Good news? It seems better on Windows 8.

**Attached**: {F12129}
Also setting "Windows 7" as the most recent Windows cited as having the problem ("PC" is a bit too generic).
**e.martinson** wrote:

(In reply to comment #48)
> (In reply to comment #47)
> > (In reply to comment #44)
> > > @Nemo: Thanks for comment 43, very helpful!
> > > 
> > > @Erik: Could you clarify comment 36? Which other systems did you experience
> > > the
> > > problem with?
> > > 
> > > (In reply to comment #42)
> > > > It would help if this bug identified the specific code revisions (Gerrit
> > > > links) that are responsible for this recent regression.
> > > 
> > > @MZMcBride:
> > > https://blog.wikimedia.org/2013/10/28/the-autonym-font-for-language-names/
> > > links to https://bugzilla.wikimedia.org/show_bug.cgi?id=40874 which links to
> > > https://gerrit.wikimedia.org/r/#/c/84850/ and
> > > https://gerrit.wikimedia.org/r/#/c/84851/
> > 
> > Um, now I must admit I had not tested it on any other systems until now. Don't know why I thought it was cross-platform. Mea culpa.
> > --Eric
**e.martinson** wrote:

(In reply to comment #47)
> (In reply to comment #44)
> > @Nemo: Thanks for comment 43, very helpful!
> > 
> > @Erik: Could you clarify comment 36? Which other systems did you experience
> > the
> > problem with?
> > 
> > (In reply to comment #42)
> > > It would help if this bug identified the specific code revisions (Gerrit
> > > links) that are responsible for this recent regression.
> > 
> > @MZMcBride:
> > https://blog.wikimedia.org/2013/10/28/the-autonym-font-for-language-names/
> > links to https://bugzilla.wikimedia.org/show_bug.cgi?id=40874 which links to
> > https://gerrit.wikimedia.org/r/#/c/84850/ and
> > https://gerrit.wikimedia.org/r/#/c/84851/
> 
> Um, now I must admit I had not tested it on any other systems until now. Don't > know why I thought it was cross-platform. Mea culpa.
> --Eric
**e.martinson** wrote:

(In reply to comment #44)
> @Nemo: Thanks for comment 43, very helpful!
> 
> @Erik: Could you clarify comment 36? Which other systems did you experience
> the
> problem with?
> 
> (In reply to comment #42)
> > It would help if this bug identified the specific code revisions (Gerrit
> > links) that are responsible for this recent regression.
> 
> @MZMcBride:
> https://blog.wikimedia.org/2013/10/28/the-autonym-font-for-language-names/
> links to https://bugzilla.wikimedia.org/show_bug.cgi?id=40874 which links to
> https://gerrit.wikimedia.org/r/#/c/84850/ and
> https://gerrit.wikimedia.org/r/#/c/84851/

Um, now I must admit I had not tested it on any other systems. Don't know why I thought it was cross-platform. Mea culpa.
--Eric
**e.martinson** wrote:

(In reply to comment #43)
> (In reply to comment #42)
> > It would also help, for triaging, to know how many operating systems/browsers
> > are affected (or rather, what percentage of typical users)? Only Windows
> > users?
> 
> So far the only information provided pointed exclusively to Windows problems;
> Erik removed Windows from the platform/OS fields shortly after comment 36
> without clarifying why.

Sorry, I switched the platform/OS to "all" because I thought this problem was not restricted to Windows. However, just now I checked on a Mac in Firefox and Chrome and did not encounter the text-blurring problem. But I'll leave it to someone else to switch back as I have not tested it on any other systems.
--Eric
**e.martinson** wrote:

language-choice text blurring on Commons

screenshot of language-choice link text blurring, Win7 64-bit, Firefox 25, Chrome 31.0.1650.57 m

**Attached**: {F12128}
@Nemo: Thanks for comment 43, very helpful!

@Erik: Could you clarify comment 36? Which other systems did you experience the problem with?

(In reply to comment #42)
> It would help if this bug identified the specific code revisions (Gerrit
> links) that are responsible for this recent regression.

@MZMcBride:
https://blog.wikimedia.org/2013/10/28/the-autonym-font-for-language-names/ links to https://bugzilla.wikimedia.org/show_bug.cgi?id=40874 which links to https://gerrit.wikimedia.org/r/#/c/84850/ and https://gerrit.wikimedia.org/r/#/c/84851/
(In reply to comment #42)
> It would also help, for triaging, to know how many operating systems/browsers
> are affected (or rather, what percentage of typical users)? Only Windows
> users?

So far the only information provided pointed exclusively to Windows problems; Erik removed Windows from the platform/OS fields shortly after comment 36 without clarifying why.
It would help if this bug identified the specific code revisions (Gerrit links) that are responsible for this recent regression.

It would also help, for triaging, to know how many operating systems/browsers are affected (or rather, what percentage of typical users)? Only Windows users?
**michael** wrote:

(In reply to comment #37)

I don’t completely agree with Eduard Brown.

WikiMedia hosts an unusual multilingual range of websites on unusual multilingual software. Text in some languages appears broken on many computers. There is nothing wrong with aspiring to fix the breakage when the technology is available.


> Common sense dictates that users have fonts installed for their native
> languages.

An ideal. The reality is that millions of people cannot install fonts on the devices they depend on, for many different reasons. Smartphone users? Refugee immigrants relying on library computers configured in a language they barely know? They deserve access to information.


> Autonym (which will by definition never be as good as a native font like Arial on Windows)

I don’t understand the logic of this. Arial is hardly a great typeface anyway.


> I'm afraid there is definitely room for improvement right now!

True. I don’t know why this was pushed out without some basic testing on common platforms. 

Most modern browsers on modern OSes render most language scripts these days. A simple fix for much of this would be to embrace installed fonts, and push Autonym to the bottom of a font stack that includes the default sans-serif fonts on the various platforms. I wonder if, indeed, “font-family: sans-serif, autonym;” would work to make this font the fallback’s fallback. Ideally, it should only be rendering text that would show up as tofu. Ideally.
**e.martinson** wrote:

(In reply to comment #38)
> [Removing random added keywords, see
> https://bugzilla.wikimedia.org/editkeywords.cgi ]

Sorry my addition of those keywords seemed random, Andre. It wasn't, but I'm not very experienced with Bugzilla. It seemed several commenters felt this bug was not drawing enough attention, and my reading of the design and community-consensus-needed keywords led me to believe they would be appropriate here and might draw more attention.
--Eric
(In reply to comment #38)
> [Removing random added keywords, see
> https://bugzilla.wikimedia.org/editkeywords.cgi ]

https://bugzilla.wikimedia.org/describekeywords.cgi

The original link doesn't work for normal users.
[Removing random added keywords, see https://bugzilla.wikimedia.org/editkeywords.cgi ]
**e.martinson** wrote:

Comment on attachment 13809
screenshot font-rendering, en.wp in Firefox 25, Win7

Seeing problem in Commons as well in language choice link (upper right).
**e.martinson** wrote:

screenshot font-rendering, en.wp in Firefox 25, Win7

Similar to "Autonym glyphs are missing pixels" shot.

**Attached**: {F12127}
Has there been any progress with this? What is the status? Is it supposed to be fixed? (Because it's not.)
(In reply to comment #31)
> ULS master has hinting added for the Autnym font. This is active in the
> Wikimedia branch 1.23wmf3.

I see no difference. Do I need to do something? (Tested on pl.wikt, which is at wmf3 now.)
**mr.heat** wrote:

(In reply to comment #30)
> What's the plan for this bug?

I wonder why you are asking this question. There is no "plan". For the average Bugzilla report it's often like "ignore it long enough to make the users give up and stop complaining about, then pretend there is no problem". It doesn't even matter if a report is almost 10 years old and received 50 votes (e.g. bug 674). There is no developer assigned and there are no developers to assign. WMF always moves them to the next project in the moment a feature is deployed. Sometimes the original developers even left WMF. If you are lucky a volunteer will make a pull request.

I really, really don't understand why such bad changes aren't reverted (which would be simple), fixed (which may be hard) and deployed again (which is again simple). It's like WMF is more afraid of reverting something than being criticized for making bad changes. Why is that?

I'm sorry, Andre, I'm just trying to explain what many users actually think. Reports like this are just tips of the iceberg.

(In reply to comment #31)
> ULS master has hinting added for the Autnym font.

What about excluding the Wikidata link from using the font? What about excluding all Latin languages from using a font they don't need? What about delivering the font only to browsers that would show rectangles otherwise?
(In reply to comment #30)
> What's the plan for this bug?

ULS master has hinting added for the Autnym font. This is active in the Wikimedia branch 1.23wmf3.
What's the plan for this bug?
As I quickly realized, and confirmed at the Autonym website, the majority of Latin glyphs were extracted form FreeSans, possibly the worst-rendering (at leats on Windows) open source font available. FreeSans (as well as the other UCS/GNU FreeFonts) lack *any* type of hinting, on which Windows relies for proper font rendering. We could blame Windows, but that will not solve anything.

Autonym should find a better source for its Latin glyphs, preferably Nimbus Sans L (on which FreeSans is based!), which include at least some basic hinting.
(In reply to comment #0)
> Created attachment 13624 [details]
> Blurred Autonym font
> 
> Interwiki names blurred and legible with difficulty (using the hardcoded
> "Autonym" font)
> 
> Firefox 25 / WinXPSP3 / standard antialiasing (= no ClearType)

Screenshot of
https://www.mediawiki.org/w/index.php?title=UniversalLanguageSelector/AutonymFont
using FF22 on Windows XP SP3 with the latest version of font http://app.crossbrowsertesting.com/public/id1b2af101bb8ef7/livetests/1196568/snapshots/zb68cdfaa35be26924f1 , font size 13px

**Attached**: {F12122}
(In reply to comment #26)
> IE6? OK. Let's be serious. Majority of other users INCLUDING users of IE6 are
> served with a bad font.


IE 6(or anything less) will not get this font as per latest changes. Screenshot of https://www.mediawiki.org/w/index.php?title=UniversalLanguageSelector/AutonymFont using IE6 on Windows XP

http://app.crossbrowsertesting.com/public/id1b2af101bb8ef7/livetests/1196571/snapshots/z7f7810ca035e37ef94c
IE6? OK. Let's be serious. Majority of other users INCLUDING users of IE6 are served with a bad font. Users that are interested in certain language will have glyphs for the font they are interested. So using a bad font just creates a bad experience for all users.

BTW. The font looks good only for 13px. So if you must please at least change default size.

Also BTW, notice this font rendering is bad in almost any other size then 13px.
**michael** wrote:

(In reply to comment #24)
> I see that MSIE 6 accounts for 0.83% of traffic, well over the 0.1%
> threshold,

Holy Hannah, MSIE 5.5 also qualifies with 0.11%!
**michael** wrote:

Thanks for the enlightening links, all. 

I see that MSIE 6 accounts for 0.83% of traffic, well over the 0.1% threshold, and thus remains supported as a grade B browser, for reading, but not necessarily having all features working. The same applies to MSIE 7 (1.47%) and 8 (4.71%). 

All these guidelines carry out-of-date warnings, and don’t account for the conflicted grey area wherein MSIE 6 and 7 are supported for reading, but not for the ULS which provides fonts that may be necessary for reading. 

I think the gist is that if you are using MSIE 6, you are more-or-less on your own, and may need to install some fonts. Editors and developers don’t want to abandon MSIE 6 users, but no one will invest time and energy into testing MSIE 6 and 7, so the realistic support level is “good luck, mate.”

Also good to know that WikiMedia is, or was, supposed to work without CSS3, without JavaScript, and in text-only browsers.

One more question: does the ULS try to work in MSIE 6 and 7, or is it disabled in these browsers?
(Yes, that's VE, which is not going to work with IE 6, but I guess the "less than 0,1%"-rule is generic? It's also mentioned at https://www.mediawiki.org/wiki/Compatibility#Grade_B .) :)
(In reply to comment #21)
> https://www.mediawiki.org/wiki/VisualEditor/Target_browser_matrix

That's VE. :) There's also https://www.mediawiki.org/wiki/Compatibility#Software_for_using_MediaWiki in general.

https://www.mediawiki.org/wiki/Extension:UniversalLanguageSelector states:
"Not compatible with Internet Explorer 7 or lower."
Michael: here https://www.mediawiki.org/wiki/VisualEditor/Target_browser_matrix (warning, old data) I read:
"The unofficial rule for Wikimedia's browser support is that we try to support reading (and not necessarily other functions) for all browsers used by at least 0.1% of page hits based on the WikiStats data."

If I read http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm correctly, MSIE 6.0 does not meet that requirement.
**michael** wrote:

> #p-lang a[lang=ja], #p-lang a[lang=th] { ... }
> 
> Selectors like this work in all browsers including very old ones. Problem
> solved.

Doesn’t work in MSIE 6. Sadly, millions use it and I think we still intend to support it. See http://www.ie6countdown.com/

Is there any official or community statement on which browsers we do support?


> Don't you think all users
> that are able and interested in a specific language have the proper fonts
> installed? 

No. I think the point is to make wikis accessible to people who can’t or won’t install software on their machines. This means tens of millions who rely on library or work PCs, or the latest mobile devices, or almost anything in between. Not only techies need to read their own language.

That said, it would be nice if the font spec only applied to the necessary language names, whichever those may be.
**mr.heat** wrote:

(In reply to comment #18)
> something like " font-family: sans-serif, "Autonym"; "

Unfortunately this is not how it works. My suggestion was to apply the font only to language names with otherwise missing glyphs. For example, the list in the sidebar looks like this:

<ul>
<li class="interwiki-en"><a lang="en" hreflang="en">English</a></li>
<li class="interwiki-fr"><a lang="fr" hreflang="fr">Français</a></li>
<li class="interwiki-ja"><a lang="ja" hreflang="ja">日本語</a></li>
</ul>

Remove the current rule:

#p-lang ul { font-family: "Autonym", sans-serif; }

Instead use a rule set like this for all non-latin language names:

#p-lang a[lang=ja], #p-lang a[lang=th] { ... }

Selectors like this work in all browsers including very old ones. Problem solved.

At least exclude the Wikidata "Edit links" item from the rule by applying it only to items that are in an other language (this may be an other issue, please tell me if I should split this):

#p-lang a[lang] { ... }

Besides, what was the problem in the first place? Don't you think all users that are able and interested in a specific language have the proper fonts installed? In think missing glyphs or rectangles are only visible to people that aren't interested in these languages anyway. Again, I'm very sorry to say that but this looks like a fix without a real world problem to me. I'm aware that it may help a few people but the current way the font is used creates more problems than it solves.
As suggested by TMg (comment #6), is it not possible to let the browser choose the Autonym font only if there are missing glyphs? I’m not very knowledgeable about the details, but I know it is the global goal of the CSS list of fonts in font-family; is something like " font-family: sans-serif, "Autonym"; " would achieve the goal by only searching missing glyphs in Autonym?
(In reply to comment #15)
> Isn't this a regression, since it worked before?

Technically no because it's a new feature, no fonts have been served for interwikis in the last few weeks to save on bandwidth etc.
Created attachment 13681
Comparison Autonym Arial

I made a sample to show the problem: Two times "Nederlands" is shown, first with Autonym and then with Arial. The font size (height) is the same, even though Arial is slightly wider. Arial is better readable, just compare the first "e" of "Nederlands" or the lower-case "n": they seem to have holes.

**Attached**: {F12126}
I also experience this bug, with FF 24.0 on Windows 7.
Isn't this a regression, since it worked before?
**mr.heat** wrote:

Firefox/Opera 12/IE 9 with ClearType enabled

Here is an other screenshot with ClearType enabled. From left to right:

* Firefox with hardware acceleration disabled
* Opera 12
* IE 9

Same bug in Firefox and Opera, some pixels are completely missing. Enabling or disabling ClearType has no effect on this bug, obviously.

IE 9 uses hardware acceleration by default. Because of this the font looks different. But it's also distorted. The glyphs are more narrow and more blurred compared to the default font (seen in the upper half of the screenshot). Some glyphs are distorted. Look at the "g" from "English" and the "S" from "Suomi".

Enabling ClearType *and* hardware acceleration in Firefox makes it the same as IE 9. Enabling hardware acceleration *without* ClearType makes it worse. A lot worse. That's why I have no other choice than do disable both.

Why don't you use the default fonts for simple words like "English" that don't contain any problematic characters?

**Attached**: {F12125}
**michael** wrote:

The problem seems to be “missing pixels.” Only one of three screenshots shows anything “blurred” that isn’t also occurring in the default font. Might both be caused by lack of hinting, but might be two different bugs.
**michael** wrote:

The language names on en.wiktionary.org’s home page render correctly on Safari 6.1/Mac, Firefox 25/Mac, and Chrome 30/Mac (on OS X Mountain Lion).

They also renders correctly on iPad Safari (iOS 5), except that Burmese and Khmer characters are broken anyway.

But they render correctly on the Mac with the Autonym font disabled. Every language name renders every character with the font spec set to “sans-serif.” Developers, please stop trying to “fix” an OS that doesn’t need help. Just serve this font to systems that need it, and do a reasonable amount of testing before releasing.
Just for the record:

The same issue is with the <languages/> box.

(-> changing the summary to be more general)
(Strike that, answer is in comment 0; setting Platform.)
(In reply to comment #6)
> Suggested reading:
> http://www.smashingmagazine.com/2012/04/24/a-closer-look-at-font-rendering/

TL;DR: Windows is bad. Danny, do you use Windows?
**mr.heat** wrote:

(In reply to comment #6)
> Suggested reading:
> http://www.smashingmagazine.com/2012/04/24/a-closer-look-at-font-rendering/

See my "Subpixel rendering is a lie" comment there.
I'm guessing there's not hinting information in the font; Windows' TrueType font renderer is notorious for relying on good hinting for on-screen resolutions, while OS X and Linux tend to ignore it and optimize their rendering without hinting.

I've gone ahead and filed an entry on the Autonym github issue tracker and copied the images (they're viewable inline there, for easier reference): https://github.com/santhoshtr/AutonymFont/issues/38
Suggested reading: http://www.smashingmagazine.com/2012/04/24/a-closer-look-at-font-rendering/
**mr.heat** wrote:

Autonym glyphs are missing pixels

Please tell me if I should post this as a separate issue.

I'm using Opera 12 on Windows 7 with "Clear Type" rendering turned off (on purpose, because I get headaches from the red and blue blurry shadows it adds around the glyphs). Unfortunately the rendering of Autonym is a mess (sorry to say that, it's the best word to describe what I see, see my screenshot). This makes the situation a lot worse compared to the situation before where a few glyphs may be missing or displayed as rectangles. Now some pixels are completely missing. An "o" looks like an "u" and "m" looks like "rri", for example.

Proposed solution: Either fix the font or simply don't use it on systems that don't have a problem with displaying the glyphs in the interlanguage links. If I disable Autonym (using the web developers tools) everything is back to normal, no glyphs are missing and no rectangles are displayed. In other words: Don't "fix" things that aren't broken. Thanks.

**Attached**: {F12124}
Temporarily it can be fixed by adding in personal css:
#p-lang div.body ul { font-family: sans-serif; }
Created attachment 13642
Screenshot from en.wp

**Attached**: {F12123}
I am getting very similar messed up rendering on Opera 12 on Windows XP with ClearType rendering enabled.
Cannot reproduce with Win8, FF25 and 1024x768 on https://cs.wikipedia.org/wiki/ on crossbrowsertesting.com (only offering FF23 for XPSP3).
An unclosed <ref> tag on the page eats up the rest of the page, typically including the requisite <reference> tag at the bottom of the page. However, VisualEditor handles the unclosed <ref> tag more gracefully, treating it as plain text.

At the URL above, the wikitext:

    Before <ref> during
    after
    <references />

is rendered:

    Before[1]
    Cite error: <ref> tag found without <references/>

whereas VisualEditor shows:

    Before <ref> during↵after
    There are no references on this page to include on this list.

This issue was brought to my attention by an editor who somehow created the unclosed <ref> tag in VisualEditor. (See the initial revision of [[vi:Danh sách các chi tiết gợi nhớ đến Disney trong phim Enchanted]].) I’ve reached out to the editor for information on how they might’ve gotten into that state.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/User:Mxn/56306
https://gerrit.wikimedia.org/r/#/c/255258/ fixes PHP parser behavior. Nothing to do in Parsoid land.
The bug for the PHP parser is T17712.
I'm not sure; that depends what the more graceful behavior would be, but I would expect Parsoid to match Cite in any case. Does Parsoid's current behavior seem like a more reasonable way for Cite to handle unclosed <ref> tags?
So is this a request for matching the more graceful behavior in the PHP Cite implementation, or is it a request for Parsoid to truncate the page as well?
Never mind about that last part. It looks like they introduced the unclosed <ref> tag by hand, not using VisualEditor.
For many users, ULS serves no practical purpose. It is also quite large, which can be problematic if you're not on a first-world internet connection (or are in rural US), is occasionally host to somewhat problematic bugs, and generally is not worth the trouble if you're not part of the target audience.

So there should be a way for such people to just turn the thing off, not load it at all, and be happy.

I appreciate that adding an option for this has been been wontfixed, though I don't know why, but even without there being an option in the interface, there SHOULD be support in the extension itself to disable it, regardless of where it actually appears.

There should be a way for users who are truly and consistently inconvenienced by it to actually solve the underlying problem (such as with a hidden preference or cookie), instead of just hiding it. There should also be a way for third-party hosts to add such an option for their users who also fit the target audience, even if they don't necessarily want it on for everyone.

As it is it seems to inconvenience as many people as it helps on wikimedia projects, and isn't very appealing to third-party hosts, either, despite it solving some very real problems facing some of our users as well.

--------------------------
**Version**: master
**Severity**: enhancement
Things have been improved. We are no longer loading lots and lots of code before user interaction. Now I get `jquery.uls.data` (31 KB) and few other modules <10 KB.
Does someone know if this issue is still present and relevant for T15097? Seems not according to T58464#2452190
https://www.mediawiki.org/wiki/Universal_Language_Selector/Announcement_Feb2014
https://www.mediawiki.org/wiki/Universal_Language_Selector/Upcoming_development_plan
Change 113957 merged by jenkins-bot:
resources/images: Optimize all SVGs (partially by hand)

https://gerrit.wikimedia.org/r/113957
Change 113957 had a related patch set uploaded by Bartosz Dziewoński:
resources/images: Optimize all SVGs (partially by hand)

https://gerrit.wikimedia.org/r/113957
The table is from the output of mw.loader.inspect(). You can also run it from your developer tools console of your browser.

But the result of that has a few caveats. ULS has to serve a small svg file(cog icon) to UI. See https://github.com/wikimedia/mediawiki-extensions-UniversalLanguageSelector/blob/master/resources/css/ext.uls.interlanguage.css#L1

You can see the svg with 'embed' more than once. Also note that the ResourceLoader module will have css  with the image data embedded. So the RL module have  this repeated svg data at client side, it is an image, so it will have some size. While calculating the module size, the total size is javascript, css and this image data(potentially duplicated) at client side. But what matters is bandwidth usage and in this case you will see a big difference between actual bandwidth usage and the uncompressed RL module size at client side. This is because the module is gzip compressed while serving. Gzip is efficient in compressing the duplicated strings. In short, don't take the output of mw.loader.inspect literally.
(In reply to Amir E. Aharoni from comment #12)
> (In reply to Bryce Glover from comment #11)
> > I just added up how many kilobytes the ULS loader's scripts take up once
> > loaded onto client systems using my Mac's Calculator.app, and it came out to
> > 450.2 KB!!!  This definitely needs to be fixed!
> 
> In which conditions did you make this calculation?

Oops; I should have mentioned that I just used my Mac's built-in Calculator.app application to add up all of the script sizes from the right-hand side of the table provided as an attachment by MZMcBride in Comment #5.  I thought that my source would be obvious!  Now that I think about it, though, where exactly did the results provided by that table come from again?
(In reply to Bryce Glover from comment #11)
> I just added up how many kilobytes the ULS loader's scripts take up once
> loaded onto client systems using my Mac's Calculator.app

Such comments are not helpful if you do not provide exact steps to reproduce.
(In reply to Bryce Glover from comment #11)
> I just added up how many kilobytes the ULS loader's scripts take up once
> loaded onto client systems using my Mac's Calculator.app, and it came out to
> 450.2 KB!!!  This definitely needs to be fixed!

In which conditions did you make this calculation?
(In reply to MZMcBride from comment #5)
> Created attachment 13629 [details]
> Screenshot of mw.loader.inspect() from the English Wikipedia, 2013-10-30

I just added up how many kilobytes the ULS loader's scripts take up once loaded onto client systems using my Mac's Calculator.app, and it came out to 450.2 KB!!!  This definitely needs to be fixed!

**Attached**: {F12024}
So, as far as we know and until corrected the plan still is, per Erik Moeller, bug 56433 comment 22:
> OK, then I'd like to request that the language engineering team implement
> that
> approach for now, unless there are issues we're overlooking. As noted, we can
> attach EventLogging to font activation, and we could potentially also run
> notices or calls-to-action in specific affected wikis. We can figure out in
> the
> next couple weeks if we want to prioritize getting back into a default-on
> state
> for automatic font delivery for some users/languages quickly, or if this
> should
> take a backseat to the language team's other priorities.
> 
> But, considering the significant payload added by automatic font delivery, I
> think that's a reasonable compromise for now. I appreciate the team's efforts
> to improve ULS performance across the board.

https://gerrit.wikimedia.org/r/#/c/108024/ was already merged and is supposed to serve webfonts only when strictly necessary. So, once the way forward is detected, we need another report for what's needed to complete the plan.
Removed dependency on bug 56514. It no longer is relevant after gerrit 93035.
(In reply to comment #6)
> (In reply to comment #4)
> > This isn't a helpful comment.
> 
> The way to avoid this is to define when a report can be considered fixed. 
> "Make X faster" is an invalid report as everybody can disagree when it's
> considered fast enough. Instead, "Make X load within Y seconds" has clear
> criteria.

On what hardware? On what connection? Where, geographically? This is not a clear criterium either, and I'd argue that you can't define a "clear" one.
Lego, Ori, or anyone else who might know: is there a reason that ULS loads anything more than the init script by default? This is what VisualEditor does, as I understand it.
(In reply to comment #4)
> This isn't a helpful comment.

The way to avoid this is to define when a report can be considered fixed. 
"Make X faster" is an invalid report as everybody can disagree when it's considered fast enough. Instead, "Make X load within Y seconds" has clear criteria.  It's up to requesters to explain and define issues well enough to avoid invalid bug reports, so I disagree with your interpretation.
Created attachment 13629
Screenshot of mw.loader.inspect() from the English Wikipedia, 2013-10-30

**Attached**: {F12024}
(In reply to comment #3)

This isn't a helpful comment. Please don't leave unhelpful comments.

Nobody is required to justify a bug report's existence to you. If you can't understand the bug, that's a personal problem. Try following the steps laid out in comment 2 (i.e., run mw.loader.inspect() on the English Wikipedia and look at its output).
(In reply to comment #2)
> I'm re-opening this bug with a focus on making ULS more lightweight and
> acceptably performant.

As it sohuld be possible for bug reports to define when they are fixed: 
When exactly would ULS be "lightweight enough" and "acceptably performant"? 

Currently I consider this bug report unfixable (and hence INVALID) as requirements are highly subjective and it's impossible to say "and now ULS is performant and lightweight enough so we can close this bug report".
According to mw.loader.inspect(), ULS appears to be by far the largest contributor to JavaScript load on <https://en.wikipedia.org/wiki/Main_Page>:

* jquery.uls
* jquery.uls.data
* ext.uls.init
* ext.uls.webfonts.repository
* ext.uls.interface
* ext.uls.languagenames
* ext.uls.ime

And possibly others. This is all for a feature that most users do not use. This is unacceptably large given that the vast majority of users on the English Wikipedia don't use ULS. This is disproportionate resource usage and is a valid bug to address.

I'm re-opening this bug with a focus on making ULS more lightweight and acceptably performant.
*** This bug has been marked as a duplicate of bug 46306 ***
When editing a category page in VE, the page contents, such as a Subcategories heading and the list of categories in the cat, do not display.  

A requested enhancement would be to display these items using the greyed/lined out display VE uses for other non-editable items.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 290653 merged by jenkins-bot:
Genericise target initialisation across namespaces

[[https://gerrit.wikimedia.org/r/290653]]
Change 290653 had a related patch set uploaded (by Esanders):
Genericise target initialisation across namespaces

[[https://gerrit.wikimedia.org/r/290653]]
Change 171155 had a related patch set uploaded by Alex Monk:
[WIP] Show non-editable parts of pages in their normal places

https://gerrit.wikimedia.org/r/171155
*** Bug 70821 has been marked as a duplicate of this bug. ***
(In reply to comment #1)
> This

… also applies to File: pages.
This
Was introduced as a hack in https://gerrit.wikimedia.org/r/#/c/91786 but we should really find a way to make this unnecessary.
User reports:
There does not seem to be a way to delete the first of two hatnotes without leaving extra space at the top of the article. 28bytes (talk) 03:20, 15 October 2013 (UTC)

Link: https://en.wikipedia.org/w/index.php?title=Maxi_single&diff=577225537&oldid=568995072

User config: Firefox 24.0/Windows 7/Monobook, but the same's true for Safari and for Macs.

--------------------------
**Version**: unspecified
**Severity**: normal
Re-checked: seems that it's not happening  anymore - look at the screenshots {F29287} {F29290}.

Closing as Resolved.
Re-checked: seems that it's not happening  anymore - look at the screenshots {F29287} {F29290}.

Closing as Invalid.
I think this is a code regression:

The "Watch this" checkbox is always checked in Save dialog regardless of the user preference.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 95729 merged by jenkins-bot:
Move setting of minor/watch defaults from MWSaveDialog to Target

https://gerrit.wikimedia.org/r/95729
*** Bug 57191 has been marked as a duplicate of this bug. ***
Change 95729 had a related patch set uploaded by Jforrester:
Move setting of minor/watch defaults from MWSaveDialog to Target

https://gerrit.wikimedia.org/r/95729
Probably solved by https://gerrit.wikimedia.org/r/#/c/95729/ ? That fixes a bug where if you had the 'watchcreations' preference set, "Watch this" would always be checked.
I see a lot of code like this:

ve.Element.getRelativePosition( [something], this.getRoot().getSurface().getSurface().$ );

Ideally, CE classes wouldn't need to reach into the UI surface for stuff like this. Positioning against the CE surface should just work.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Seen in Reference and Transclusion, anywhere with an overlay containing a button saying 'Apply changes'. 

* Hover the cursor over an existing Reference or Transclusion. 
* Click the icon to invoke the Reference or Transclusion overlay
* Without making any changes, click 'Apply changes'

* Save page button goes from grey to active.

* Click Save page
* Click Review your changes. 

Get message "Could not start the review because your revision matches the latest version of this page."

--------------------------
**Version**: unspecified
**Severity**: minor
A single patch fixes the majority of the issues here, see the subtasks.
>>! In T57976#823066, @Krenair wrote:
> So this is now a tracker?

No, it's a single task made up of sub-tasks.
So this is now a tracker?
>>! In T57976#823009, @Krenair wrote:
> I kind of wish this had been broken into one bug for each dialog.

Done. :-)
I kind of wish this had been broken into one bug for each dialog.
Change 177944 merged by jenkins-bot:
Don't re-enable apply changes in reference dialog if the changes have been undone

[[https://gerrit.wikimedia.org/r/177944]]
Change 177944 had a related patch set uploaded (by Alex Monk):
Don't re-enable apply changes in reference dialog if the changes have been undone

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

#patch-for-review
Change 176861 merged by jenkins-bot:
Disable Apply Changes in reference dialog until changes have been made

[[https://gerrit.wikimedia.org/r/176861]]
Change 176861 had a related patch set uploaded (by Alex Monk):
Disable Apply Changes in reference dialog until changes have been made

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

#patch-for-review
*** Bug 58231 has been marked as a duplicate of this bug. ***
No, I think this still applies to the places mentioned in the description (transclusions and references).
This is not an OOUI bug, moving back to VE. Rather, it's a bug in the individual dialogs in VE that apparently commit no-op transactions when you click Apply changes without changing anything. Also, in most dialogs we disable the Apply changes button when there is nothing to change.

Since this bug was filed in 2013, I imagine it might be mostly fixed now? We have some bugs in this area (filed individually as "Apply changes is enabled even though XYZ") but my impression is that generally we're pretty good about this now.
* dm.LeafNode has (length, element), where length is ignored and forced to 0 by all subclasses except for dm.TextNode
* dm.BranchNode has (children, element), length is computed while children are added

The code in dm.Document constructing node trees needs to be aware of this, but at the same time it doesn't even use these parameters, because branch nodes are created as childless nodes that have their children added later, and text nodes are created with length zero and have the correct length set later. So we should just get rid of these parameters and make the constructors take a single element parameter, that would get them in line with other dm.Model subclasses (dm.Annotation and dm.MetaItem) as well.

While we're at it, we should also fix the documentation that claims that the element parameter is optional, it really isn't.

--------------------------
**Version**: unspecified
**Severity**: enhancement
https://gerrit.wikimedia.org/r/#/c/135878/
(In reply to comment #0)
> While we're at it, we should also fix the documentation that claims that the
> element parameter is optional, it really isn't.


It is in fact optional. The lowest class (ve.dm.Model) has:
> element || { 'type': this.constructor.static.name }
Intention:  To remove a stub template


Expectation:  That the stub template would disappear and everything else (references list, navbox) would remain the same


Steps to reproduce:

1)  Go to https://en.wikipedia.org/w/index.php?title=Gastric_volvulus&oldid=567517399 or (probably) any other article that contains these items on separate, adjacent lines:

 * A list of references (in this case, a single bulleted list item)
 * A blank line
 * A stub template
 * A navigation template

2)  Open the article in VisualEditor.

3)  Click on the the stub template to select it.

4)  Press the delete/backspace key (it's same key on a Mac) one time to delete the stub template (and nothing else).


Result:

Instead of getting the slightly shorter expected list:

 * A list of references (in this case, a single bulleted list item)
 * A blank line
 * A navigation template

this produced a single line containing both the reference list item and the navbox, with no intervening spaces or lines:

 * A list of references (in this case, a single bulleted list item)Navigation template

This broke the navbox formatting for readers.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=Gastric_volvulus&diff=577403274&oldid=576282874
Confirmed on Firefox 25/Linux

It seems from very quick experimentation that deleting a template also deletes the preceding line.
1. Create a page with two links that point to the same page or URL, and a link that points to a different page/URL
2. Inspect one of the twin links with the link inspector. The suggestions dropdown is displayed (*)
3. Inspect the other twin link. The suggestions dropdown isn't displayed
4. Inspect the third link. The suggestions dropdown is displayed again
5. Inspect the link from #3. The suggestions dropdown is displayed now
6. Close the inspector, the inspect the same link again. The suggestions dropdown isn't displayed

This is because the value in the text input doesn't change when you inspect the same link twice or inspect two links with the same target. The link inspector should consistently display the dropdown when it opens.

(*) I would argue that we should /not/ display the dropdown in this case, IMO it's useless and confusing. But the point of this bug is that we should have consistent behavior.

--------------------------
**Version**: unspecified
**Severity**: normal
This is now fixed, but anyway masked by the expedient of not opening the suggestion box until the user changes something.
Created attachment 13670
showing wrong suggestions at the end of the previously selected link

**Attached**: {F11975}
Created attachment 13669
Showing suggestions in blank space

**Attached**: {F11974}
Created attachment 13668
Showing suggestions in blank space

**Attached**: {F11973}
In step 3, if i click on the link icon from the tool bar instead of pressing ctrl+k or command+k , then the link inspector opens up at the end of the text created in step 1.

See the screenshots for more reference.
Another issue which might be related with this follows the following steps:

1.Create any link with a target URL
2.Inspect another link of the page with a different target URL
3.Now point to a blank space and press ctrl+k or command+k

Observed Result:

The link inspector appears in a swipe way from right to left and the content of the link inspector is the suggestion of the link that was created in step 1.

I am not sure how the expected result should be in this case when a user press command+k in an empty space.I think there should not be any pre-set suggestion for that.
According to https://gerrit.wikimedia.org/r/#/c/54984 , the new wikibugs code (not yet deployed) will split the wikibugs output into a myriad of channels (this is independent from the name of the default channel).

This fragmentation is very annoying because it effectively subtracts important parts of the code/development/discussion from the normal public view on the main channel (whatever its name is) even though they are offtopic, hiding them in some secondary channel.
The secondary channels should receive additional copies of the relay, but not remove them from the main channel if they are on topic (for instance, the visual editor for MediaWiki obviously is on topic for #mediawiki and #wikimedia-dev).
 
As a fallback, if people really think those products are so unimportant/trashy ("noise") as to be ignored by people on the main channel, I'd like a single unified feed somewhere, e.g. #mediawiki-feed (it's not clear to me what wm-bot4 [~wm-bot@wikimedia/bot/wm-bot] is doing there exactly).

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52529
https://bugzilla.wikimedia.org/show_bug.cgi?id=10760
Sigh. http://lists.wikimedia.org/pipermail/wikitech-l/2014-May/076522.html
Now done by pywikibugs.
+1 to all bugs continuing to go to #mediawiki. and all commit output (At least to mediawiki + ext) go to either #mediawiki or #wikimedia-dev

Having bug output in these channels helps bring new contributors in, and allows them to see what is being worked on. Moving it to #mediawiki-feed would destroy this.
Yeah, wikibugs-l is a global watcher, and wikibugs bot just relays all mail that is sent there. So *everything* goes to #mediawiki, apart from security bugs.
(In reply to comment #4)
> This bug is not about "all the feeds": pywikibot is already on another
> channel,
> because it's not sent to wikibugs-l.

Actually Pywikibot bugs show up in #mediawiki, and I wrote a python script which copies the output of wikibugs into #pywikipediabot if it's one of our bugs.
(In reply to comment #3)
> (In reply to comment #2)
> > The conversation
> 
> Where is this conversation happening? I have opinions but I'd rather read
> first
> what has been discussed.

I mean the development conversation.

(In reply to comment #2)
> The conversation is currently fragmented between #mediawiki (wikibugs) and
> #wikimedia-dev (grrit-wm).

That's another bug.

> 
> grrit-wm can also post to other channels on demand, such as #-operations and
> #-visualeditor, which is a very useful feature (both of these are completely
> useless in #mediawiki and only tangenially related in #wikimedia-dev).

This is also another issue, and only in part overlapping this (gerrit changes are apparently considered more "noisy", otherwise they wouldn't have been moved first).

> 
> A separate channel that would *mirror* all other feeds would be okay, but a
> *separate* one.

This bug is not about "all the feeds": pywikibot is already on another channel, because it's not sent to wikibugs-l.
(In reply to comment #2)
> The conversation

Where is this conversation happening? I have opinions but I'd rather read first what has been discussed.
The conversation is currently fragmented between #mediawiki (wikibugs) and #wikimedia-dev (grrit-wm).

grrit-wm can also post to other channels on demand, such as #-operations and #-visualeditor, which is a very useful feature (both of these are completely useless in #mediawiki and only tangenially related in #wikimedia-dev).

A separate channel that would *mirror* all other feeds would be okay, but a *separate* one.
+1 to having it in #mediawiki-feed so people who want the full force of the firehose can have it.
On Chrome Version 30.0.1599.69 on Mac OSX 10.8.5 the Command+Delete keyboard shortcut is ignored. In most text editors it deletes the entire line of content (try it in gmail or on bugzilla!)

The Option+Delete keyboard key (to delete the previous word) and Option+Fn+Delete (to delete the following word) do work correctly. There is no Command+Fn+Delete shortcut.

I do not have easy access to test this shortcut on other versions of Chrome, nor do I know what the shortcut is on Firefox.
Command + Delete works for me in Chrome 43 and Firefox 40 on OS X 10.10.3. Tentatively closing.
While resizing an image with live preview, the highlight on the image is updated correctly. But if you mouse over another image while resizing, then that image's highlight isn't updated for the resize. This is a problem in situations where resizing the first image moves the second image, in that case the highlight stays where it was when you first entered the image.

Maybe we just shouldn't show highlights at all while dragging?

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55789
Agreed, I think we did back in January.
I think we fixed this ages ago.
The floating code is in ve.ui.SurfaceToolbar instead of OO.ui.Toolbar, but cursory inspection of the code indicates that it doesn't reach into the surface and doesn't receive any events from the surface, apart from a minor bit that ensures the cursor isn't obscured by the toolbar.

Wanting to float a toolbar seems generic enough, so couldn't this be made into generic OO.ui functionality?

--------------------------
**Version**: unspecified
**Severity**: enhancement
Intention:  To create a block of text to check line wrapping.


Expectation:  That I'd end up with a block of plain paragraph-formatted text.


Steps to reproduce:

1)  Start with a page containing some text and a few section headings.  In my case, it was a list.  

2)  Select all the text in one section using arrow/cursor keys, including all of the last line (including the blank part at the end of the paragraph), but none of the section heading that follows.

4)  Copy this.

5)  Make a new, blank paragraph-formatted line.

6)  Paste the copied text into the new line.


Results:  You get the desired paragraph, followed by a == <nowiki /> == section heading.

See https://en.wikipedia.org/w/index.php?title=User:Whatamidoing_(WMF)/sandbox&diff=577354576&oldid=577352415

(For bonus points, if you skip step #5, you'll get your pasted text set to ==Section heading== formatting.)

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
{T52100}
{T61647}
Change 162310 merged by jenkins-bot:
For empty / whitespace-only headings, output <p> instead of <h#>

[[https://gerrit.wikimedia.org/r/162310]]
Change 162310 had a related patch set uploaded (by Jforrester):
MWHeading: Don't put self in output if contents are blank or whitespace

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

#patch-for-review
Change 162310 had a related patch set uploaded by Jforrester:
MWHeading: Don't put self in output if contents are blank or whitespace

https://gerrit.wikimedia.org/r/162310
This may be related to bug 49452 and/or bug 50100
The link to the image is dead now. Is this the same issue as T70800?
To reproduce:

1. Goto https://en.wikipedia.org/w/index.php?title=Lancaster,_Pennsylvania&oldid=576777823&veaction=edit
3. Highlight 'Brownfields'
4. Press Ctrl-K
5. Type 'brownfield land' as target.
6. Click matching entry in drop-down once to accept.
7. Click on unrelated text to hide the link widget.

The internal representation is correct (as shown in e.g. 'Review your changes'), but the displayed/rendered link goes to https://en.wikipedia.org/w/Brownfields , not the correct target.

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed by Ed's re-working of these recently, I think.
To prevent images which have just been scaled up from looking pixelated.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 89809 merged by jenkins-bot:
Re-render images after resize

https://gerrit.wikimedia.org/r/89809
Change 89809 had a related patch set uploaded by Esanders:
Re-render images after resize.

https://gerrit.wikimedia.org/r/89809
mediawiki.ui should have dialogs/modals.  The new dialogs in GettingStarted can be used as a starting point, but more work is needed.  This includes choosing the right level of abstraction, and how to implement them.

--------------------------
**Version**: unspecified
**Severity**: enhancement
The mediawiki-ui styles in core are still maintained a little while longer, but dialogs seems like quite a significant task to take on. Engineering effort that is probably better invested elsewhere.

Closing for now, though patches welcome if someone can volunteer reviewing it.
>>! In T57534#943582, @Spage wrote:
> OOUI's dialogs with the mediawiki.ui skin are probably a viable alternative.

Yeah.  If there is a general consensus to move to OOJS-UI, this is probably a WONTFIX.
Matt originally wrote:
> The new dialogs in GettingStarted can be used as a starting point, but more work is needed

Flow has implemented a general-purpose `mw.Modal` in [[ https://github.com/wikimedia/mediawiki-extensions-Flow/blob/master/modules/engine/misc/mw-ui.modal.js | mw.ui.modal.js]], see  Shahyar's e-mail to the design list in October "MW UI Modals First Version & Concept" ([[https://lists.wikimedia.org/pipermail/design/2014-October/002183.html | in ASCII]], but much easier to read the original HTML). There are a lot of features in Flow's modal tailored to [[ https://trello.com/c/uAoYLKf1/3-multi-step-modal-dialog | the design spec in Trello ]]. It use OOjs' EventEmitter.

OOUI's dialogs with the mediawiki.ui skin are probably a viable alternative.
Matt originally wrote:
> The new dialogs in GettingStarted can be used as a starting point, but more work is needed

Flow has implemented a general-purpose `mw.Modal` in
[[ https://github.com/wikimedia/mediawiki-extensions-Flow/blob/master/modules/engine/misc/mw-ui.modal.js | mw.ui.modal.js]], see  Shahyar's e-mail to the design list in October "MW UI Modals First Version & Concept" ([[https://lists.wikimedia.org/pipermail/design/2014-October/002183.html | in ASCII]], but much easier to read the original HTML) There are a lot of features in Flow's modal tailored to [[ https://trello.com/c/uAoYLKf1/3-multi-step-modal-dialog | the design spec in Trello ]]. It use OOjs' EventEmitter.

OOUI's dialogs with the mediawiki.ui skin are probably a viable alternative.
(In reply to comment #8)
> As for centring, the iframes don't particularly help there but I do know that
> in VE we have a satisfying way of centring the dialog
> vertically/horizontally.
> 
> The centring of dialogs is generally a solved problem in web development
> afaik.
> There's different ways to go about it, but there's at least 1 commonly used
> way that works.

I have a working solution, but it doesn't work in IE 6 or 7 (bug 55487).  If you have a recommendation, I'd be glad to look at it.

> On the subject, oo.ui dialogs do have an interesting aspect that is worth
> mentioning. They don't require a fixed width/height. CSS min-height /
> max-height is dynamically honoured (it can shrink/grow, and overflow:auto
> will show scrollbars if needed), and browser resizing as well.

Unfortunately, that's an example of a compatibility issue which we're going to have to grapple with.  IE6 apparently can't support both min-height and max-height on the same element (http://stackoverflow.com/questions/1467664/how-to-implement-cross-browser-min-height-and-max-height-at-the-same-time)

> As for the CSS, that's going to be the area that'll need most manual testing
> and fixing. I think most browser bugs we account for date back pretty far (we
> tend to IE8, Opera 12 and recent Firefox/Chrome).
> 
> Though IE6, IE7 and Firefox 4 (which would be the main browsers missing
> between
> VE requirements and MW requirements) do have a ton of specific quirks, afaik
> those are all bugs that can be worked around, not actual missing CSS features
> that would be blockers (aside from CSS3 enhancements, which will be absent
> but
> those degrade gracefully).

Yeah, I primarily meant CSS and rendering.  I agree some have relatively simple workarounds.  However, others are a bit more complicated.
(In reply to comment #6)
> (In reply to comment #4)
> > Are you planning to put oo.ui in core?  If so, are you going to merge it with
> > mediawiki.ui?
> oo.ui is going to be a standalone library, but we're planning for MW core to
> depend on it and bundle it, same as with e.g. jQuery.

Makes sense.

> I personally would like to make mw.ui an extension of oo.ui, making
> MW-specific things in mw.ui extensions of generic things in oo.ui, and moving 
> any generic functionality from mw.ui into oo.ui if oo.ui doesn't already have 
> it.

That seems reasonable, though it might take some practice drawing that line.

> oo.ui is about two years ahead of mw.ui in development time, but we built
> things as we needed them in VisualEditor so there might be certain kinds of
> widgets that mw.ui has that aren't in oo.ui yet. Things like dialog support,
> though, have existed in oo.ui for a long time. oo.ui also fully supports
> running all of its widgets in iframes (which is how dialogs are done as
> well).

I don't really know much about the advantages of iframes for this kind of thing.  However, I did have some issues (e.g. full horizontal and modal centering), so if it solves that, that would be nice.

We'll be supporting more browsers than VE does, so oo.ui will need to do the same if we take that approach.
(In reply to comment #4)
> Are you planning to put oo.ui in core?  If so, are you going to merge it with
> mediawiki.ui?
oo.ui is going to be a standalone library, but we're planning for MW core to depend on it and bundle it, same as with e.g. jQuery.

I personally would like to make mw.ui an extension of oo.ui, making MW-specific things in mw.ui extensions of generic things in oo.ui, and moving any generic functionality from mw.ui into oo.ui if oo.ui doesn't already have it.

oo.ui is about two years ahead of mw.ui in development time, but we built things as we needed them in VisualEditor so there might be certain kinds of widgets that mw.ui has that aren't in oo.ui yet. Things like dialog support, though, have existed in oo.ui for a long time. oo.ui also fully supports running all of its widgets in iframes (which is how dialogs are done as well).
Created attachment 13462
Modal from GettingStarted

This shows an example modal from GettingStarted.  This appearance is not necessarily exactly how the core version would look.

**Attached**: {F12155}
Are you planning to put oo.ui in core?  If so, are you going to merge it with mediawiki.ui?
(In reply to comment #1)
> Trevor and Roan mentioned that they may be trying to make ve.ui (aka oo.ui)
> dialogs available to non-VisualEditor products and wikis. Those may be
> appropriate to use/adapt for our purposes, we just need to compare it all.
A WIP for that was just put in Gerrit: https://gerrit.wikimedia.org/r/#/c/88896/
This should include the grey overlay as well.  Ideally, this dialog code will be general enough that GuidedTour can be ported to use it as well.
**swalling** wrote:

For reference, the dialogs being used in the currently-released GettingStarted A/B test are in Extension:GettingStarted's resources. 

Trevor and Roan mentioned that they may be trying to make ve.ui (aka oo.ui) dialogs available to non-VisualEditor products and wikis. Those may be appropriate to use/adapt for our purposes, we just need to compare it all.
Another bug discovered:

On every click in the edit area in the dialog, an error appears in the console:

TypeError: e.innerText is undefined
parseInt(e.getAttribute('idx'),10) + e.innerText.length > model);

in VisualEditor/modules/syntaxhighlight/ve.ui.MWSyntaxHighlightSimpleSurface.js
line #1252
Patch to disable SyntaxHighlight is now merged, so this problem will be suppressed with the production push tomorrow morning; restoring to "ASSIGNED".
Change 88901 merged by jenkins-bot:
Remove SyntaxHighlight from the experimental set

https://gerrit.wikimedia.org/r/88901
Change 88901 had a related patch set uploaded by Catrope:
Remove SyntaxHighlight from the experimental set

https://gerrit.wikimedia.org/r/88901
Transclusions can currently affect arbitrary parts of the page by producing unbalanced HTML. This makes both WYSIWYG editing and efficient updates difficult. We would thus like to move towards properly nested templates as much as possible. For existing multi-transclusion content we would like to enforce nesting as a unit, possibly using a <domparse> extension-like tag wrapping such a content block. This would still let us reuse expansions for multi-template content, which is important for large list pages like http://fr.wikipedia.org/wiki/Liste_des_premiers_pr%C3%A9fets_fran%C3%A7ais_(1800-1815).

The solution should:
* work with old and new revisions, with predictable HTML diff behavior
* support multi-transclusion/extension content reuse
* support a mix of transclusions, extension tags and page content
* work well with the VisualEditor preview

--------------------------
**Version**: unspecified
**Severity**: normal
Lowering the priority a bit, as other issues are more pressing currently.
This is roadmap item https://www.mediawiki.org/wiki/Parsoid/Roadmap#Research_.2F_prototype:_Enforce_proper_nesting_of_most_templates.2C_and_encapsulate_compound_content_blocks_.5Bhard.2C_Q3-Q4_2013.5D
From https://integration.wikimedia.org/ci/job/mwext-cldr-phpcs-strict/1/console:

11:21:52 FILE: ...nkins-slave/workspace/mwext-cldr-phpcs-strict/CldrNames/CldrNamesMy.php
11:21:52  643 | ERROR   | Line exceeds maximum limit of 120 characters; contains 162
11:21:52  648 | WARNING | Line exceeds 100 characters; contains 109 characters

These are the lines in question:

	'UM' => 'ယူနိုက်တက်စတိတ် အပြင်ထွက် နေသည့် သေးငယ်သောကျွန်းများ',
	'VC' => 'စိန့်ဗင့်ဆင့်နှင့် သည်ဂရဲနာဒင်းစ်',

Assuming tab width is 4, the line lengths are 67 and 48 respectively.

--------------------------
**Version**: wmf-deployment
**Severity**: minor
I have retriggered the original build:

https://integration.wikimedia.org/ci/job/mwext-cldr-phpcs-strict/4/console

The phpcs command being run is:


 phpcs -v -s . --encoding=utf-8 \
  --standard=/var/lib/jenkins/tools/mwcodesniffer/MediaWiki \
  --extensions=php,php5,inc,sample \
  '--ignore=languages/messages/Messages,*.i18n.php,*.i18n.alias.php' \
  --report-checkstyle=checkstyle-phpcs.xml \
  --report-full

And the result is a SUCCESS.  So the fix was indeed to pass '--encoding=utf-8' to phpcs :-]
All jobs got refreshed. That should fix the issue now, if that is actually the case I guess we can close the bug report.
(In reply to comment #5)
> Have the jobs been pushed? The change is merged but in
> https://integration.wikimedia.org/ci/job/mwext-VisualEditor-phpcs-HEAD/1524/
> console
> I don't see --encoding being passed.

Good catch Timo. Something went wrong when I refreshed the jobs :(

Refreshing them:


$ grep 'encoding=utf' /var/lib/jenkins/jobs/*phpcs*/config.xml
/var/lib/jenkins/jobs/mwext-AbuseFilter-phpcs-HEAD/config.xml: --encoding=utf-8 \
/var/lib/jenkins/jobs/mwext-ActiveAbstract-phpcs-HEAD/config.xml: --encoding=ut-8 \
/var/lib/jenkins/jobs/mwext-AdminLinks-phpcs-HEAD/config.xml: --encoding=utf-8 \
Have the jobs been pushed? The change is merged but in https://integration.wikimedia.org/ci/job/mwext-VisualEditor-phpcs-HEAD/1524/console I don't see --encoding being passed.
Change 88743 merged by jenkins-bot:
Specify encoding of source files as utf-8

https://gerrit.wikimedia.org/r/88743
Change 88743 had a related patch set uploaded by Siebrand:
Specify encoding of source files as utf-8

https://gerrit.wikimedia.org/r/88743
Our PHP files should be UTF-8 encoded, so we should run CodeSniffer in that mode. I'll see if I can submit a patch...
phpcs defaults to iso-8859-1 defined in PHP_CODESNIFFER_ENCODING

CodeSniffer/Standards/Generic/Sniffs/Files/LineLengthSniff.php uses strlen(), whenever the encoding is not iso-8859-1 it would use:

  iconv_strlen($lineContent, PHP_CODESNIFFER_ENCODING);

So need to pass:

 --encoding=UTF-8
Right now jQuery.IME is horrendously, horribly broken when using VisualEditor (a quick perusal of bugs that make it unusable include bug 54421, bug 53700, bug 53701, bug 53705, bug 53706, bug 53711, bug 54283, bug 54331, bug 54334 and others).

Having the jQuery.IME icon show up when it is actively broken makes a promise to the user that we can't possibly hope to meet right now.

Please disable jquery.IME from VisualEditor surfaces entirely until we can get some proper testing and work done.

--------------------------
**Version**: master
**Severity**: normal
> We will probably just ride the train on
> Thursday rather than introduce an out-of-sequence deployment if that's OK.

Preferred.
(In reply to comment #5)
> Patch merged. I think you can deploy HEAD of master of ULS whenever it's
> convenient for you guys, James. There have been no functional changes but
> this one in the past week.

Thank you, Siebrand and Santhosh. We will probably just ride the train on Thursday rather than introduce an out-of-sequence deployment if that's OK.
Patch merged. I think you can deploy HEAD of master of ULS whenever it's convenient for you guys, James. There have been no functional changes but this one in the past week.
Change 88727 merged by jenkins-bot:
Disable jquery.ime for VE till IME support is improved

https://gerrit.wikimedia.org/r/88727
Change 88727 had a related patch set uploaded by Santhosh:
Disable jquery.ime for VE till IME support is improved

https://gerrit.wikimedia.org/r/88727
Just to be clear, VE and jQuery.IME are making incompatible assumptions about the javascript event sequences expected when entering text in an IME.

To be fair, that's not really anyone's fault because (a) de jure, the standards are still emerging, and (b) de facto, every single browser/OS/IME combination seems to generate a different weird and wonderful sequence of events.

We're currently refactoring the VE CE Surface code to make as few assumptions as possible about IME events. I expect we can do work from the jQuery.IME side too, to bring the two into line.
Not sure I like the framing. VE mangles IME input horribly and horrendously, not the other way around may be more accurate.

We can disable jQuery.IME in content editable divs of VisualEditor because it cannot handle input methods. Which class identifies editable divs of VisualEditor?
When adding a template that also adds a category, after saving the list of categories is not updated until the page is reloaded.

To reproduce:

1. Load any page in VE
2. Add any template that also adds a category, e.g. {{user en}}
3. Save page

Expected behaviour: The list of categories includes the newly added category, e.g. [[Category:User en-N]]
Actual behaviour: The list of categories is not updated.

It doesn't seem to matter whether the category is plain or hidden.

Firefox 24 on Linux using Monobook skin

--------------------------
**Version**: unspecified
**Severity**: minor
With wikitext editing, people work around this by writing long articles in word, or relying on browsers remembering form data if it crashes.

Perhaps with local storage we can take periodic snapshots of DM HTML, or even the entire surface state (DM data, IV store, internal list, transaction history etc.) and offer to restore it if the changes went unsaved.

See also:
* T39992 - Review and deploy Drafts extension to Wikimedia wikis
* T75241 - Auto-save to increase chances of lost edits recovery
>>! In T57370#3924115, @cscott wrote:
> This would be a good use of a general "fork storage" mechanism: the edit-in-progress would get stored as an unmerged fork of the main revision.

Cool idea. But what if there is no main revision (creating a new page)?
This would be a good use of a general "fork storage" mechanism: the edit-in-progress would get stored as an unmerged fork of the main revision.
Proposed to #community-wishlist-survey-2017
>>! In T57370#3601942, @Esanders wrote:
> 
> do our own memory management

...or use someone else's, e.g. https://github.com/monsur/jscache
>>! In T57370#3416020, @Jdforrester-WMF wrote:
> silently fail when the user's machine either has local storage disabled or is full?

Well given we will be writing to LocalStorage every time a new edit session is started, this is going to happen often (and we can't rely on the edit session being closed 'gracefully'). It appears that most browsers will throw an exception when storage is exceeded, so if we do our own memory management and keep track of VE save sessions, we can prune the LRU session until their is enough free space. We can also prune sessions older than N minutes/hours so other users can still use LocalStorage (e.g. ResourceLoader).
I am sorry, I wanted to close and merge the other way. I try to fix it.
(wrong tab)
@Whatamidoing-WMF
I am admittedly stretching the limits of what I know about javascript, but it appears something like
```
textarea.on('input', ...
```
solves that issue. I'm unsure, but a little extra code may be needed to catch cut/paste via right click.
@Whatamidoing-WMF
I am admittedly stretching the limits of what I know about javascript, but it appears something like
```
textarea.on('input', ...
```
does exactly that. I'm unsure, but a little extra code may be needed to catch cut/paste via right click.
Alsee, the 2010 WikiEditor doesn't know whether or not you've typed anything in the editing window yet, and therefore it cannot know whether there are any changes to be saved.
>>! In T57370#3490603, @Whatamidoing-WMF wrote:
> Because it isn't actually possible in the older wikitext editors.  

My apologies, but I have to question your technical expertise on that point. I find it very difficult to imagine any reason that data-storing javascript could be added to one editor, but couldn't be added to the other.

The community [[ https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey/Categories/Editing#Auto-saving_edits | requested this feature]]. Nearly two-thirds of the people supporting the request use VE for **zero percent** of their edits. They were quite obviously requesting this feature for the only editor that they use. 85% of supporters use Visual for 8% or less of their edits. They were also quite obviously requesting this feature for substantially-the-only-editor they use. Exactly one person uses Visual for more than half of their edits (57.6%). I'm sure no one objects to implementing autosave in the secondary editor as well.

There is already a task open for this request: T75241

Unless there is some clear reason not to do so, this task should be merged into  T75241 as a duplicate.
If there is a desire for separate tasks for the two editors, the first priority work should be on the primary editor. I guess that would make this a subtask of T75241.
>>! In T57370#3490603, @Whatamidoing-WMF wrote:
> Because it isn't actually possible in the older wikitext editors.  

My apologies, but I have to question your technical expertise on that point. I find it very difficult to imagine any reason that data-storing javascript could be added to one editor, but couldn't be added to the other.

The community [[ https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey/Categories/Editing#Auto-saving_edits | requested this feature]]. Nearly two-thirds of the people supporting the request use VE for **zero percent** of their edits. They were quite obviously requesting this feature for the only editor that they use. 85% of supporters use Visual for 8% or less of their edits. They were also quite obviously requesting this feature for substantially-the-only-editor they use. Exactly one person uses Visual for more than half of their edits (57.6%). I'm sure no one objects to implementing autosave in the secondary editor as well.

There is already a task open for this request: T75241

Unless there is some clear reason not to do so, this task should be merged into  T75241 as a duplicate.
If there is a desire for separate tasks for the two editors, **the first priority work should be on the primary editor**. I guess that would make this a subtask of T75241.
>>! In T57370#3490603, @Whatamidoing-WMF wrote:
> Because it isn't actually possible in the older wikitext editors.  

My apologies, but I have to question your technical expertise on that point. I find it very difficult to imagine any reason that data-storing javascript could be added to one editor, but couldn't be added to the other.

The community [[ https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey/Categories/Editing#Auto-saving_edits | requested this feature]]. Nearly two-thirds of the people supporting the request use VE for **zero percent** of their edits. They were quite obviously requesting this feature for the only editor that they use. 85% of supporters use Visual for 8% or less of their edits. They were also quite obviously requesting this feature for substantially-the-only-editor they use. Exactly one person uses Visual for more than half of their edits (57.6%). I'm sure no one objects to implementing autosave in the secondary editor as well.

There is already a task open for this request: T75241

Unless there is some clear reason not to do so, this task should be merged into  T75241 as a duplicate.
If there is a desire for separate tasks for the two editors, **the first priority work should be on the primary editor**.
>>! In T57370#3490603, @Whatamidoing-WMF wrote:
> Because it isn't actually possible in the older wikitext editors.  

My apologies, but I have to question your technical expertise on that point. I find it very difficult to imagine any reason that data-storing javascript could be added to one editor, but couldn't be added to the other.

The community [[ https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey/Categories/Editing#Auto-saving_edits | requested this feature]]. Nearly two-thirds of the people supporting the request use VE for **zero percent** of their edits. They were quite obviously requesting this feature for the only editor that they use. 85% of supporters use Visual for 8% or less of their edits. They were also quite obviously requesting this feature for substantially-the-only-editor they use. And I'm sure no one objects to implementing it in the secondary editor as well.

There is already a task open for this request: T75241

Unless there is some clear reason not to do so, this task should be merged into  T75241 as a duplicate.
If there is a desire for separate tasks for the two editors, **the first priority work should be on the primary editor**.
>>! In T57370#3490428, @Alsee wrote:
> Why is this described as a Visual Editor task? Visual Editor is a minor secondary editor, only used for a small percentage of edits. If auto save is implemented, it's certainly reasonable to also implement it in the secondary editor as well (VE).

Because it isn't actually possible in the older wikitext editors.  

Most modern browsers can preserve text within the older wikitext editors (e.g., if you accidentally click the 'back' button while you're editing, then your changes are usually there if you click the 'forward' button to go back to the editing window), but that they can't do this with VisualEditor (either mode).  So, in effect, the team is planning to cover for a limitation in browsers by building this capability internally.  If you are interested in this subject, then you may want to read about HTML textareas (used in the older wikitext editors) and ContentEditable (used in online rich-text editors, including VisualEditor).
Why is this described as a Visual Editor task? Visual Editor is a minor secondary editor, only used for a small percentage of edits. If auto save is implemented, it's certainly reasonable to also implement it in the secondary editor as well (VE).
>>! In T57370#3415924, @Esanders wrote:
>>>! In T57370#2976776, @Esanders wrote:
>> The main concern is what happens when we run out of storage.
> 
> The workaround for local storage limitations is remote storage, with the downsides:
> * slower (potentially several seconds for long articles and slow connections, but it's background and async so meh)
> * doesn't work offline, obviously
> * infrastructure costs of storing all the extra data
> * would probably need user consent

The trump concern is legal issues arising from holding server-side information subject to expensive discovery mechanisms, as I understand it (I'm not a lawyer, //etc.// //etc.//).

How about we just go ahead with this as-is, persisting last-edit-state so restarting browsers get back to the state before the crash/whatever, and silently fail when the user's machine either has local storage disabled or is full?
>>! In T57370#2976776, @Esanders wrote:
> The main concern is what happens when we run out of storage.

The workaround for local storage limitations is remote storage, with the downsides:
* slower (potentially several seconds for long articles and slow connections, but it's background and async so meh)
* doesn't work offline, obviously
* infrastructure costs of storing all the extra data
* would probably need user consent
Also the caveat for txs is that we need access to the original document state. That is fine for regular MW edits, but if they're using a restbase stash after switching that may be a problem. In those cases we could either store initial HTML or disable auto-save.
Also the caveat for txs is that we need access to the original document state. That is fine for regular MW edits, but if they're using a restbase stash after switching that may be a problem (although we could just disable auto-save :/ )
Twice HTML => maybe 3.4MiB for Obama => two unsaved edits and we've over-flowed Firefox's local storage, that sucks quite a bit, which would steer us to Transactions. OTOH, the growth characteristics of Transactions for long edits (the ones where this would be particularly useful) make me a little uncomfortable about whether it'd be better….
The main concern is what happens when we run out of storage. A single document is unlikely to do this, but with multiple documents saved this would be quite common. We would need to do our own memory management to throw away old stashes.
| | **Transactions** | **HTML** | **Entire linear model** |
| **Initial storage** | None. With the caveat that we will have access to the initial document state the user saw at a later date. Could be problematic if user has switched from WT mode. Could instead use HTML storage for initial state, then transactions for changes, but wipes out storage advantage. | proportional to article size (~1.7MB for Obama) | About twice HTML |
| **Incremental storage** | ~400 bytes to type a single character. Typing a 200 word / 3 sentence paragraph with a few annotations took 60k. | Not much more than a few bytes per character | About twice HTML |
| **Storage edge cases** | Blanking whole document / pasting in large sections multiple times will results in really large transactions, more that the initial storage of ‘Entire linear model’ | None really, just the document length. | << |
| **Undo stack** | Preserved | Not preserved | << |
| **Save performance** | Very fast, small JSON.stringify | Can be a few hundred ms for long articles. If waiting for N seconds of user inactivity this may not be a big issue, but in some cases esp slow machines, edit area will become momentarily non-responsive. | Fairly fast, large JSON.stringify |
>>! In T57370#2558298, @Ltrlg wrote:
> @Jdforrester-WMF I have been working on a Confluence wiki with (server-side) auto-save for several months and they have something your current proposal do not include: being able to see a diff before choosing. It is really useful, because I often do not remember what I was doing exactly when I closed the editing page 2 or 3 days before editing again.

Hmm. That's certainly a possibility, but I don't think it's a good idea to try to shoe-horn that into the first version. In particular, I'd rather we had (at least) designs for {T105173} (so that users didn't have to know wikitext to understand what they're shown) and possibly {T39931} as a better, more fluid way of showing that to users as they edit. I've created {T143341} for this idea.
@Jdforrester-WMF I have been working on a Confluence wiki with (server-side) auto-save for several months and they have something your current proposal do not include: being able to see a diff before choosing. It is really useful, because I often do not remember what I was doing exactly when I closed the editing page 2 or 3 days before editing again.
Hopefully
I lost some work recently when I accidentally closed the wrong tab.  Will your current plan solve that problem?
OK, so, dusting this off, my current proposal is as follows:

* As you edit, we stash a copy of the edited document whilst you're editing it into indexDB or whatever (locally on your machine); this would apply both to VE and the NWE surfaces.
* When you save, once we get confirmation back that it's saved we delete from the local machine the in-process edit.
* On load, if there's a draft for this page which based off the current revision, we prompt you to either resume the edit, or start a fresh edit (and discard the draft), with something looking roughly like:
{F4357662}

This means that //e.g.// if your computer crashes, you lose network/power, or whatever, you can resume edits. It's optional, so if somehow you've made an edit that causes the editor to crash you can avoid re-triggering it (so you're not caught in a loop).

The main downside is that it doesn't let you move computers during an edit (which is not a common issue for users right now, but is a bit of an 'oh well').

If you load and there's a partial edit based on an out-of-date revision it probably isn't possible for us to help out automatically — we can't do an edit merge at that point, as that's a DB/server-side operation, and we can't tell whether or not the edit will save cleanly. Maybe just discard it silently?
See also: Wikitext editor patch for this: https://gerrit.wikimedia.org/r/#/c/5130/
*** Bug 52988 has been marked as a duplicate of this bug. ***
If local storage is going to be seriously considered, with pages being auto-saved, some issues to consider:

How many open VE's can be autosaved?  Only saving one VE session makes management very simple, but it is probably sufficient for only a small subset of the editing community.

The local storage limit of 5 MB in most user agents is going to be a problem.  Also VE needs to intelligently handle the case where the offline storage is not available or the origin has exceeded its limit.  The user needs to know when their session isnt being auto-saved due to client side factors.

Are these autosaved versions going to persist across browser sessions?

If the VE sessions do persist, how will VE determine which VE autosaved versions are no longer needed and can be deleted to allow more VE sessions to be autosaved in the future.  Will the user be able to manage which autosaves they no longer need?
(In reply to comment #1)
> Why not deploy the drafts extension, and add any VE support needed?

Have commented there explaining.
(In reply to comment #1)
> Why not deploy the drafts extension, and add any VE support needed?

[[mw:Extension:Drafts]], for those unfamiliar.
Why not deploy the drafts extension, and add any VE support needed?
Hi
When I run parsoid linked to a wiki which is https only, it doesn't work. This can be reproduced in any installation.

I set port 80 to be a redirect to port 443, and the parsoid URL is https://wiki.name/api.php in localsettings.js

--------------------------
**Version**: unspecified
**Severity**: enhancement
Shall we close this? I know that VE functions happily on wikitech.wikimedia.org now, which always uses HTTPS.
I wanted to update this bug with my findings. I now have 1.23wmf7 and the latest builds of Parsoid and VisualEditor working happily with SSL as the default (and forced) connection method for users.

In my LocalSettings.php I have the following:

//Hook it up to Parsoid
$wgVisualEditorParsoidURL = 'http://my.site.com:8000';
 
$wgVisualEditorParsoidPrefix = 'localhost';


In localsettings.js I have:

parsoidConfig.setInterwiki('localhost' , 'http://my.site.com:81/w/api.php');

You can see that we're directing traffic over port 81 to allow Parsoid access.

The issue I was experiencing related to saving a page was due to having an older version (pre 1.9) of Semantic MediaWiki installed with 1.23.
I've followed the troubleshooting guide and I'm still having issues connecting to a https-only host.

From the server I can run the following with success:

curl http://my.site.com:81/w/api.php

I opened port 81 to allow for http access to the api endpoint.

However I cannot seem to connect to Parsoid, the app in question. 

curl http://my.site.com:8000 returns the human-readable landing page for the Parsoid web service.

curl http://my.site.com:8000/localhost/Introduction

returns no message via the command line.

I can start Parsoid via node server.js

I can launch VisualEditor and edit a page normally, everything works.

server.js spits out the following:

starting parsing of localhost:Introduction
completed parsing of localhost:Introduction in 1660 ms

As soon as I go to save an edit, a small note appears under the Summary box.

Error: Unknown error.

server.js reports nothing


While Parsoid is running (node server.js) and I attempt the following

curl http://my.site.com:8000/localhost/Introduction

I see the message:

starting parsing of localhost:Introduction
redirected localhost:Introduction to revision 62067
I know it works, it's a workaround. I am hosting the site in a CentOS server, but despite the research I have done some time ago I couldn't install the certificate in the system root, so neither PHP and node.js see the certificate. 

I will try again now. Is there any documentation you know about this? (sorry if it's off-topic)
(In reply to comment #8)
> I am sorry, I can't pay for a real certificate. Is there a way to add my root
> certificate to Parsoid? Does it use the system certificates?
> 
> Or as a workaround, is there a way to permit self-signed authorities?

Your wiki actually works by setting the API URL to http://wiki.mc128k.info/api.php.

Nodejs uses openssl, so I'm guessing that you can install additional CA certs in /etc/ssl/certs/ (assuming you are using Debian).
I am sorry, I can't pay for a real certificate. Is there a way to add my root certificate to Parsoid? Does it use the system certificates?

Or as a workaround, is there a way to permit self-signed authorities?

Thanks.
Parsoid is only using HTTP, so trying to connect to it via HTTPS is going to fail. It can connect to MediaWiki using HTTPS though when configured to do so in localsetting.js. Please check the steps in https://www.mediawiki.org/wiki/Parsoid/Troubleshooting to make sure Parsoid is working.

> https://wiki.mc128k.info

Your SSL cert does not seem to be signed by a trusted CA, which likely explains your issue. Try with a signed SSL cert.
Addition:
Changing $wgVisualEditorParsoidURL to 'https://my.wiki.com:8000'; results in a different error.

Error loading data from server: parsoidserver-http-curl-error: SSL connect error. Would you like to retry?


Headers below:

Start request POST /w/api.php
HTTP HEADERS:
HOST: my.wiki.com
CONNECTION: keep-alive
CONTENT-LENGTH: 60
AUTHORIZATION: Basic bWVtY2FjadGU6cGFzc3dvcmQ=
ACCEPT: application/json, text/javascript, */*; q=0.01
ORIGIN: https://my.wiki.com
X-REQUESTED-WITH: XMLHttpRequest
USER-AGENT: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36
CONTENT-TYPE: application/x-www-form-urlencoded; charset=UTF-8
REFERER: https://my.wiki.com/w/index.php?title=Main_Page&veaction=edit
ACCEPT-ENCODING: gzip,deflate,sdch
ACCEPT-LANGUAGE: en-US,en;q=0.8
COOKIE: infoLoggedOut=1386191878; __utma=198203634.1203293077.1386191715.1386191715.1386191715.1; __utmc=198203634; __utmz=198203634.1386191715.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); infoUserID=378; infoUserName=Clkoerne; info_session=4f15c368d4244cc2b9e72e06f65adc12; wikiEditor-0-booklet-characters-page=latin; wikiEditor-0-toolbar-section=advanced; vector-nav-p-Repository=true; vector-nav-p-tb=true
CACHES: MemcachedPhpBagOStuff[main] MemcachedPhpBagOStuff[message] MemcachedPhpBagOStuff[parser]
[cookie] session_set_cookie_params: "0", "/", "", "1", "1"
LocalisationCache: using store LCStoreDB
Unstubbing $sfgFormPrinter on call of $sfgFormPrinter::setInputTypeHook from SFSelect_formSetup
Unstubbing $wgParser on call of $wgParser::setHook from ExtDynamicPageList::setupDPL
Parser: using preprocessor: Preprocessor_DOM
Connected to database 0 at lnxvmiptdbt01
Class UniversalLanguageSelectorHooks not found; skipped loading
Fully initialised
User: got user 378 from cache
User: loading options for user 378 from override cache.
User: logged in from session
ApiMain::setCacheMode: setting cache mode private
IP: 10.29.122.24
Debug log from parsoid:
 - worker(23680) ready
{
  "0": "WARNING: RETRY:",
  "1": {}
}
Retrying Page Fetch request for null, 4 remaining
{
  "0": "WARNING: RETRY:",
  "1": {}
}
Retrying Page Fetch request for null, 3 remaining
{
  "0": "WARNING: RETRY:",
  "1": {}
}
Retrying Page Fetch request for null, 2 remaining
{
  "0": "WARNING: RETRY:",
  "1": {}
}
Retrying Page Fetch request for null, 1 remaining
{
  "0": "WARNING: RETRY:",
  "1": {}
}
Retrying Page Fetch request for null, 0 remaining
{
  "0": "WARNING: RETRY:",
  "1": {}
}
ERROR in localhost:Main_Page:
Page Fetch failure for null
Stack trace: DoesNotExistError: Page Fetch failure for null
worker 23671 died (1), restarting.
 - worker(23690) loading...
 - worker(23690) ready


I don't know if the API works from the external network, this is a protected wiki, I hope login won't be necessary.

https://wiki.mc128k.info
I just tested this with 'enwiki' and

parsoidConfig.setInterwiki( 'enwiki', 'https://en.wikipedia.org/w/api.php' );

We don't set the port explicitly and use the API uri as-is, so in theory https-only APIs should work. Do you have a public https-only API URI we can test with?
I'm sorry, I thought Parsoid was part of VisualEditor. Corrected. Thanks.
Latest git versions, of parsoid, mediawiki, visualeditor.
Hmm, shouldn't this be filed under product "Parsoid"? :)
Which Parsoid version and which MediaWiki version is this about?
This has now been fixed.
* Open a document in a language that is not your default language,
  for example:
  https://fr.wikipedia.org/wiki/Cumul_des_mandats_en_France?veaction=edit
  (if you're not French).
* Assuming your browser does have a French dictionary, the article should
  have few to 0 red-underlined words.
* Click on a [1] reference.
* Observe suddenly almost every word is spellcheck invalidated by red lines
* Moving the cursor by keyboard arrows still keeps them invalid.
* As soon as you actually use the mouse to click for a cursor move, that is
  when it switches back to the correct language (or perhaps it disables
  spellcheck)

Not sure, but I think this is a regression.

--------------------------
**Version**: unspecified
**Severity**: normal
I simply deleted a word from the leading paragraph in the article below, and got this as diff:
https://he.wikipedia.org/w/index.php?title=%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9%3ANurick%2F%D7%91%D7%93%D7%99%D7%A7%D7%95%D7%AA_-_%D7%A2%D7%95%D7%A8%D7%9A_%D7%97%D7%96%D7%95%D7%AA%D7%99&diff=14670508&oldid=14667916

To reproduce: Revert to the previous version in that diff, edit the article in VE, and delete a word from the leading paragraph.

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