I experienced this on [[Narayana_Gosain_Temple]] which cutting '==References==\n{{reflist}}\n", which may have also cut "{{coord missing|Odisha}}" which follows it.
**ajc11123** wrote:

I experience the same bug on Chrome 28.  Chrome crashes (displaying its characteristic "Aw snap" error page) when I try to cut certain templates, notably {{citation needed}}, {{who}}, and other in-line templates.  This does not happen with copying.  In addition, I could not reproduce the bug in my own userspace, only in article space.
This also happens on Chrome 28 with reference blocks, looks like. Not sure if the same problem - try cutting the ref block on https://en.wikipedia.org/wiki/Lumpectomy
It seems when I put a breakpoint in onCut and onCopy and step through slowly, it doesn't crash.
I don't think I manage to remove templates only with CTRL-X, but if I select some text along and then try to cut, Chrome's tab will crash as well.
**bi.llybob** wrote:

Also crashes when I try to cut multiple templates in Chrome. For example, if I select the two hatnotes at the top of https://en.wikipedia.org/wiki/Mauritius
**bi.llybob** wrote:

(Chrome 27, Windows) I can't seem to text-select the template, and don't see "Cut" on the right-click menu when the cursor is over the template. However, I do get an error tone when I select the template and press Ctrl-X.
The content makes its way into the clipboard, but yes, I can reproduce.
Intended edit (ve-edit + fixup):

https://www.mediawiki.org/w/index.php?title=Wikimedia_technical_search&diff=715707&oldid=715705

-  [https://github.com/search?l=&q=wgWellFormedXml+%40wikimedia Search]
+  [https://github.com/search?l=&q=ResourceLoader+%40wikimedia Search]

Actual edit saved by Parsoid/VisualEditor:


https://www.mediawiki.org/w/index.php?title=Wikimedia_technical_search&diff=715706&oldid=715705

-  [https://github.com/search?l=&q=wgWellFormedXml+%40wikimedia Search]
+  [https://github.com/search?l=&q=ResourceLoader+%2540wikimedia Search]


Note how the % got encoded to %25.

--------------------------
**Version**: unspecified
**Severity**: major
We might later want to prettify the percent encoding. Basically decode everything but some vital percent-encoded values ([%? ], probably more). But for now this is fixed.
Change 71082 merged by jenkins-bot:
Bug 50042: Don't percent-encode modified external link hrefs

https://gerrit.wikimedia.org/r/71082
Change 71082 had a related patch set uploaded by GWicke:
Bug 50042: Don't percent-encode modified external link hrefs

https://gerrit.wikimedia.org/r/71082
Looks like a Parsoid bug. Works fine when data-parsoid is present, but for new annotations URLs are encoded.

<a rel="mw:ExtLink" href="https://github.com/search?l=&amp;q=ResourceLoader+%40wikimedia">Search</a>

serialises to:

[https://github.com/search?l=&q=ResourceLoader+%2540wikimedia Search]
Screenshot

I am unable to insert a media with a given file name from Commons.

Neither

File:Kölnisches Stadtmuseum - 125 x gekauft - geschenkt - gestiftet-1120.jpg

nor

Kölnisches Stadtmuseum - 125 x gekauft - geschenkt - gestiftet-1120.jpg

is accepted (and any other file name)

The "insert media" button is still inactive, see screenhot.

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

**Attached**: {F11348}
Unable to replicate this bug in CirrusSearch. As we're in the process of migrating from Lucene to CirrusSearch, I'm marking this bug as RESOLVED WONTFIX.
Searching without the dashes finds the document.  Looks like -XXX excludes all matches with XXX.  I'd advise removing the dashes, at least for now.
Still an issue. Trying to add [[Commons:File:Kölner Dom - Abbau südöstliches Gerüst Nordturm-2933.jpg]] to [[de:Traverse (mechanischer Träger)]].

This is really annoying. Makes testing the VE impossible :-(
This is… exceptionally odd. VisualEditor is just using the built-in search system from the cluster, and as you can see your image doesn't come up with that (or several sub-strings of that) as the search string:

https://en.wikipedia.org/w/index.php?title=Special:Search&search=K%C3%B6lnisches%20Stadtmuseum%20-%20125%20x%20gekauft%20-%20geschenkt%20-%20gestiftet-1120.jpg&fulltext=Search&profile=images&redirs=1

https://en.wikipedia.org/w/index.php?title=Special:Search&search=K%C3%B6lnisches%20Stadtmuseum%20-%20125%20x%20gekauft%20-%20geschenkt%20-%20gestiftet-1120&fulltext=Search&profile=images&redirs=1

https://en.wikipedia.org/w/index.php?title=Special:Search&search=K%C3%B6lnisches%20Stadtmuseum%20-%20125%20x%20gekauft%20-%20geschenkt%20-%20gestiftet-1120&fulltext=Search&profile=images&redirs=1

https://en.wikipedia.org/w/index.php?title=Special:Search&search=geschenkt%20-%20gestiftet-1120&fulltext=Search&profile=images&redirs=1

Interestingly, it does come up under:

https://en.wikipedia.org/w/index.php?title=Special:Search&search=gestiftet-1120&fulltext=Search&profile=images&redirs=1
See, for example, https://en.wikipedia.org/wiki/Kaveri_River

--------------------------
**Version**: unspecified
**Severity**: normal
This is a very odd bug that appears to be due to an old mis-cached version of the Parsoid result (it was marking each of the images as about="null"); we've flushed the caches, and it no longer appears AFAICT. Please re-open if it recurs.
Compare https://en.wikipedia.org/w/index.php?title=User:Edgepedia/sandbox3&diff=prev&oldid=560957268 to https://en.wikipedia.org/w/index.php?title=User%3AEdgepedia%2Fsandbox3&diff=560957359&oldid=560957268

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed (I think) in gerrit 70357 which we've just deployed - if we get a repeat, please re-open.
*** Bug 50116 has been marked as a duplicate of this bug. ***
Inez is already working on this, but I don't think we have a bug for it?
I hope this is a false alarm... but it seems to be real.

Compare [[Locomotive]] (images visible - en is currently on 1.22wmf7) with [[testwiki:VisualEditor:Locomotive]] (no images - test is on 1.22wmf8).

Seen on Firefox latest and Chrome latest.

--------------------------
**Version**: unspecified
**Severity**: critical
Aha, I can now reproduce on that link - and looking at the HTML we get back from Parsoid, the first image comes back as

<meta typeof="mw:Placeholder" data-parsoid='{"src":"[[File:Net.jpg|thumb]]","optList":[{"ck":"thumbnail","ak":"thumb"}],"dsr":[0,22,null,null]}'>

… and so VisualEditor dutifully doesn't display an image. Marking as a duplicate of the Parsoid bug, even though that is higher-numbered. Sorry about this. :-(

*** This bug has been marked as a duplicate of bug 50035 ***
It seems to be mostly working again, although I couldn't see any images just a few hours ago. 

I still can't see the first image on [[testwiki:Net]]. This just may be the Parsoid cache though.
(In reply to comment #1)
> … with what browser …

And, of course, you told me that. Sorry! :-( Can't reproduce on latest master or in latest push of wmf8.
I'm afraid I can't reproduce this - was this a transient issue, or do you still get it, and if so, with what browser, and are there any error messages on the console?
Currently scheduled for w/c 15 July. It's anticipated that this will not be possible for some wikis due to failings in VisualEditor and/or Parsoid; exact list to be determined closer to the time.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51792
https://bugzilla.wikimedia.org/show_bug.cgi?id=33126
https://bugzilla.wikimedia.org/show_bug.cgi?id=33077
https://bugzilla.wikimedia.org/show_bug.cgi?id=52202
(In reply to comment #14)
> (In reply to comment #13)
> > The patch was committed and merged (but the notification bot incorrectly
> > reset the status), so I'm setting this back to FIXED again as the original
> > request that this bug report is about (see subject line) has been fulfilled.
> 
> I'm not sure the original request ("top 15" Wikipedias) has been fulfilled,
> but I'm also not sure that's still the goal. I'll leave this bug to James to
> sort out.

Re-titled for clarity. I feel that this is closed.
Change 76199 merged by jenkins-bot:
Enable anonymous use of VisualEditor on es/fr/he/it/pl/ru/sv

https://gerrit.wikimedia.org/r/76199
(In reply to comment #13)
> The patch was committed and merged (but the notification bot incorrectly
> reset the status), so I'm setting this back to FIXED again as the original
> request that this bug report is about (see subject line) has been fulfilled.

I'm not sure the original request ("top 15" Wikipedias) has been fulfilled, but I'm also not sure that's still the goal. I'll leave this bug to James to sort out.
The patch was committed and merged (but the notification bot incorrectly reset the status), so I'm setting this back to FIXED again as the original request that this bug report is about (see subject line) has been fulfiled.
Note that this is not any kind of statement refering to bug 52202, it's just to reflect the current situation. For the German Wikipedia deployment, please refer to bug 52202 instead. Thanks!
**wikipedia** wrote:

(In reply to comment #11)
> They more than likely mean all the major bugs that cause issues with editing
> (eg: dirty diffs, randomly inserting pawns to name two)

Exactly, thank you for clarification.
(In reply to comment #10)
> (In reply to comment #8)
> > 3) VE to be opt-in only until all bugs are fixed: 430 votes (!)
> 
> Personal opinion: I am not aware of a single software that is proven to be
> completely bug-free. This is an impossible requirement that cannot be
> fulfiled.

They more than likely mean all the major bugs that cause issues with editing (eg: dirty diffs, randomly inserting pawns to name two)
(In reply to comment #8)
> 3) VE to be opt-in only until all bugs are fixed: 430 votes (!)

Personal opinion: I am not aware of a single software that is proven to be completely bug-free. This is an impossible requirement that cannot be fulfiled.
bug 52202 has been created based on the German Wikipedia poll.
**wikipedia** wrote:

In the quick poll (see #7) the results at the moment are as following:

1) enabeling VE as default for all users: 21 votes
2) VE as default for logged-in users: 6 votes
3) VE to be opt-in only until all bugs are fixed: 430 votes (!)
4) enabeling VE under another link name (suggestion was "Visual Editor (beta)" instead of "Bearbeiten" ("edit")): 31 votes

According to this large majority of users who oppose defaulting VE by tomorrow, I hereby ask you to put VE back to opt-in for logged-in users until the most important bugs are fixed. Thank you.
the German wikipedia just started a quick poll over the weekend to at least postpone this activation for anonymous users on monday:

https://de.wikipedia.org/wiki/Wikipedia:Umfragen/VisualEditor_Opt-in

the poll has currently also a option for the previous state where VE was Opt-in for users instead of Opt-out if this is still possible.

It would be appreciated to take the outcome on monday into account and postpone this activation for dewiki if desired.
It's unclear whether the German Wikipedia wants this: <http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070807.html>.
Change 76199 had a related patch set uploaded by Jforrester:
Enable anonymous use of VisualEditor on de/es/fr/he/it/pl/ru/sv

https://gerrit.wikimedia.org/r/76199
This is now done.
Change 75543 merged by jenkins-bot:
VisualEditor into beta on de/es/fr/he/it/pl/ru/svwiki for logged-in only

https://gerrit.wikimedia.org/r/75543
Change 75543 had a related patch set uploaded by Jforrester:
VisualEditor into beta on de/es/fr/he/it/pl/ru/svwiki

https://gerrit.wikimedia.org/r/75543
According to [[meta:Tech/News/2013/30]] the list is:
German  (de), 
Spanish (es), 
French  (fr), 
Hebrew  (he) - RTL, 
Italian (it), 
Dutch   (nl), 
Polish  (pl), 
Russian (ru) and 
Swedish (sv).
Currently scheduled for w/c 1 July.

--------------------------
**Version**: unspecified
**Severity**: normal
This is now complete.
Change 73852 merged by jenkins-bot:
Stop the prevention of anons getting VisualEditor for enwiki

https://gerrit.wikimedia.org/r/73852
Change 73852 had a related patch set uploaded by Jforrester:
Stop the prevention of anons getting VisualEditor for enwiki

https://gerrit.wikimedia.org/r/73852
Now done for logged-in users. Will be done for the rest next week, assuming all is well.
Change 71261 merged by jenkins-bot:
Enable VisualEditor for all logged-in users (but not anons) on enwiki

https://gerrit.wikimedia.org/r/71261
Change 71261 had a related patch set uploaded by Jforrester:
Enable VisualEditor for all logged-in users of the English Wikipedia

https://gerrit.wikimedia.org/r/71261
… with 'all users' (logged in and otherwise) for w/c 8 July.
After spending some time with VE in our various test environments, it would be convenient to have all features available in VE available in all of our test environments.  Right now it is possible to create citations in mediawiki.org but not in test2wiki, and VE in beta labs is not usable at all. 

test2wiki gives us a production wiki where it is possible to make destructive or nonsense edits that are not welcome on mediawiki.org

beta labs gives us an environment to test possibly risky merged changes that are not yet deployed

Enabling all of VE features in all test environments would be useful for testing.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49703
Change 70440 abandoned by Cmcmahon:
Enable VE experimental mode on test2wiki per Bug 49963

Reason:
overtaken by history

https://gerrit.wikimedia.org/r/70440
VE seems to be working correctly now in beta labs, test2wiki, and mw.o

Please re-open if you find otherwise.
Related URL: https://gerrit.wikimedia.org/r/70440 (Gerrit Change I72b68e3e0db86eb5372cd303223ef8f81111271c)
When editing a page which has an image with table data in its caption, the table is dropped (only its closing tab is kept). The rest of the caption is dropped as well.

Test edit: https://hu.wikipedia.org/w/index.php?title=Vall%C3%A1s&diff=13696305&oldid=13696296

You don't need to interact with the image in any way for this to happen, just edit the page, change anything and save.

--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://hu.wikipedia.org/wiki/Vall%C3%A1s?oldid=13696307
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61064
Change 107172 merged by Subramanya Sastry:
(Bug 49942) Tables can show up in image captions

https://gerrit.wikimedia.org/r/107172
Change 107172 had a related patch set uploaded by Subramanya Sastry:
(Bug 49942) Tables can show up in captions

https://gerrit.wikimedia.org/r/107172
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
(In reply to comment #3)
> (In reply to comment #2)
> > If this image is not modified by the user it should still round-trip
> > correctly,
> > but on modification the table would be lost.
> 
> The table is lost even if the user does not interact with the image in any
> way.
>
> See [[hu:Vallás]] - the image caption gets garbled as soon as you open the
> article for editing.

The corruption even if you don't touch it is a bug in VisualEditor related to munging the captions of images, which we're fixing today; sorry for that.
(In reply to comment #2)
> If this image is not modified by the user it should still round-trip
> correctly,
> but on modification the table would be lost.

The table is lost even if the user does not interact with the image in any way. See [[hu:Vallás]] - the image caption gets garbled as soon as you open the article for editing.
This is a tokenizer issue. The table is not tokenized as such, likely because syntax stops prevent a pipe from being matched.

If this image is not modified by the user it should still round-trip correctly, but on modification the table would be lost.
Horrible, relatively-rare case for Parsoid, is the use of wikitext tables inside image captions. Currently, the following wikitext:

[Start]
[[Image:Foo.jpg|thumb|200px|This is an example image thumbnail caption with a table

{|
! Foo !! Bar
|-
| Foo1 || Bar1
|-
| Foo2 || Bar2
|}

… and some more text.]]
[End]

… turns into the following output from Parsoid:

[Start]
<figure typeof="mw:Image/Thumb" data-parsoid="…">
  <a href="./File:Foo.jpg" data-parsoid="…">
    <img resource="./File:Foo.jpg" src="http://upload.wikimedia.org/wikipedia/commons/thumb/0/06/Foo.jpg/200px-Foo.jpg"
      height="131" width="200" data-parsoid="…">
  </a>
  <figcaption class="mw-figcaption" data-parsoid="…">}

… and some more text.
  </figcaption>
</figure>
[End]

… whereas nominally it should be (generated using an HTML table rather than a wikitext one, which seems to work fine without DOM diffs from VE end):

[Start]
<figure typeof="mw:Image/Thumb" data-parsoid="…">
  <a href="./File:Foo.jpg" data-parsoid="…">
    <img resource="./File:Foo.jpg" src="http://upload.wikimedia.org/wikipedia/commons/thumb/0/06/Foo.jpg/200px-Foo.jpg"
      height="131" width="200" data-parsoid="…">
  </a>
  <figcaption class="mw-figcaption" data-parsoid="…">This is an example image thumbnail caption with a table

    <table data-parsoid="…">
      <tbody data-parsoid="…">
        <tr data-parsoid="…">
          <th data-parsoid="…">Foo</th>
           <th data-parsoid="…">Bar</th>
        </tr>
        <tr data-parsoid="…">
          <td data-parsoid="…">Foo1</td>
          <td data-parsoid="…">Bar1</td>
        </tr>
        <tr data-parsoid="…">
          <td data-parsoid="…">Foo2</td>
          <td data-parsoid="…">Bar2</td>
        </tr>
      </tbody>
    </table>

… and some more text.
  </figcaption>
</figure>
[End]
1. In VE, highlight some text and open the link inspector
2. Type some characters into the textbox, but quickly click out of the link inspector before the autocomplete dropdown appears

The dropdown appears in the top-left corner of the page.

--------------------------
**Version**: unspecified
**Severity**: major
Not completely fixed; see bug 51415.
Fixed and will go out soon.
Change 72849 merged by jenkins-bot:
Be sure lookupMenu input is focused before showing

https://gerrit.wikimedia.org/r/72849
(Cite bug 51077 comment #0)
> Created attachment bug 51077 12810 [details]
> Screenshot of ripped-apart link inspector
> 
> I can consistently reproduce the following:
> 
> * Select an unlinked word
> * Create the insert link button (with intention to turn the word into a link)
> * If you hit Return immediately after (before it has finished opening) it
> will
> replace the focussed node with a new line. Though that is a separate bug and
> arguably an invalid use case (why would one be pressing Return at this point,
> the user hasn't even seen the options yet. It interpreting it as intend to
> replace the node isn't entirely unreasable, but that's a separate bug - bug
> 51075).
> * At this point the link inspector dom has blown up. Part of it is gone, and
> the other part is left half-way across the screen at a seemingly arbitrary
> offset (see attachment).
*** Bug 51077 has been marked as a duplicate of this bug. ***
Change 72849 had a related patch set uploaded by Robmoen:
Be sure lookupMenu input is focused before showing inputMenu.

https://gerrit.wikimedia.org/r/72849
(This happens particularly often on Opera for me, by the way. I haven't yet investigated the issue.)
I am raising the severity on this, because it is not just a display bug, but also causes the intended link target to be ignored -- if the user confirms the link with enter, only the link title is used and the link target is quietly discarded.
Confirmed. This also happens if you type too quickly and press enter.
1. Go to [[mw:VisualEditor:TTO]] and edit in VE
2. Double-click on a link in order to select it, or drag-select the whole link
3. Type a new link text

Only the first character you type remains linked, instead of the whole text you type.

--------------------------
**Version**: unspecified
**Severity**: normal
With bug 51463 closed, this is now complete. Marking as fixed.
See bug 51463
(In reply to comment #5)
> That's all well and good, but now if my document ends in a link (a common
> case if I link the last thing I typed) I can't put plain text after it, which
> is the very reason we disabled trailing annotations for links in the first
> place...

You can - you just need to press the "clear annotations" button, or press return to get a new context with no pre-annotations. However, yes, these suck for discoverability. I think not-extending-over-whitespace is the best solution, though it's fiddly and difficult to support.
That's all well and good, but now if my document ends in a link (a common case if I link the last thing I typed) I can't put plain text after it, which is the very reason we disabled trailing annotations for links in the first place...
Change 73902 merged by jenkins-bot:
Continue links

https://gerrit.wikimedia.org/r/73902
Change 73902 had a related patch set uploaded by Catrope:
Continue links

https://gerrit.wikimedia.org/r/73902
I agree that this behaviour is not great for users; we should reverse the decision to abandon "pre-annotation" (that is, if you're typing, we'll apply the same formatting as the character immediately before the one you've just typed in the same paragraph) for links.

Our concern was that having links always extent would be more tiresome for editors, which I still agree with, and that extending but not over whitespace would be confusing, which I think is arguable, but the current behaviour is worse.
A related problem is, when you change only the first character of a link, that first letter is no longer part of the link. For example, if you change [[edinburgh]] to [[Edinburgh]], it becomes E[[dinburgh]].
Steps to replicate:

(1)Click "Edit" and make some change
(2)Click "Save page". The cursor is now blinking in the "Describe what you changed" box.
(3)Click on another dialogue box, such as the WP search box. The cursor now blinks there.
(4) Click back into "Describe what you changed". Bupkis.

Chrome 27.0.1453.116, Firefox 21.0, Windows 7.

--------------------------
**Version**: unspecified
**Severity**: normal
Bug fixed
See screenshot, which is of https://en.wikipedia.org/wiki/Craig_Short - Firefox 21.0, Windows 7.

--------------------------
**Version**: unspecified
**Severity**: normal
Follow up:  https://en.wikipedia.org/wiki/Leo_Strauss?veaction=edit is still screwed up.
Shall do.
(In reply to comment #18)
> Unless the patch hasn't been deployed yet, I guess.

It hasn't. Deployed on Monday alongside the config change. Not sure if the example in comment 17 will be entirely fixed by it though - please check after release?
Unless the patch hasn't been deployed yet, I guess.
Crud

It doesn't :(. See new screenshot.

**Attached**: {F11120}
*** Bug 50416 has been marked as a duplicate of this bug. ***
The above patch fixes this bug, we believe. Marking as such.
Change 71109 merged by jenkins-bot:
Stop floated transclusions floating out of themselves

https://gerrit.wikimedia.org/r/71109
Change 71109 had a related patch set uploaded by Jforrester:
Set renderHtmlAttributes to false, for both block and inline transclusions

https://gerrit.wikimedia.org/r/71109
*** Bug 50381 has been marked as a duplicate of this bug. ***
+another example: https://en.wikipedia.org/wiki/Aranath?veaction=edit
For some reason wrapper in which we put transclusions/templates gets HTML attributes of the transclusion/template carried over - including CSS classes - that should not happen, and wasn't happening in the past.

I will investigate it, however adding Roan to this ticket, it seems like it is his area.
Screenshot

This is likely a blocker for any beta rollout on Monday. I've attached a screenshot to show how bad it can get, and why :/.

**Attached**: {F11119}
(In reply to comment #4)
> I thinks it depends on the skin: Monobook might be causing this.

That's a different bug - created bug 50057.

This is about CE's rendering of floated templates - I've attached some example screenshots to demonstrate.
Created attachment 12614
what the template does look like when selected

**Attached**: {F11118}
Created attachment 12613
what the template does look like (once in VE)

**Attached**: {F11117}
Created attachment 12612
what the template should look like (read mode)

**Attached**: {F11116}
I thinks it depends on the skin: Monobook might be causing this.
I don't think I can see your attachment, Oliver, but I think the bug may have to do with to these sshots, which both refer to adding a link: in the first one, the recycle bin can barely be seen as it gets hidden, the second one shows the link icon not being displayed as a square. Looks like this can happen both with Chrome and Firefox.
Created attachment 12609
not displaying properly

//attachment link icon not square.jpg ignored as obsolete//
Created attachment 12608
not displaying properly

//attachment overlapping recycle bin.jpg ignored as obsolete//
In this call http://en.wikipedia.org/w/api.php?action=query&prop=imageinfo&titles=File%3APowderfinger-My_Happiness-23s.ogg&iiprop=size%7Curl&iiurlwidth=200 it returns thumbwidth="1913" thumbheight="-1" as a size of an thumb, which is completly wrong.

--------------------------
**Version**: master
**Severity**: normal
This backport is now live; as such, marking this bug as fixed.
Change 71393 merged by Catrope:
Clean up transform dimension height handling

https://gerrit.wikimedia.org/r/71393
Change 71393 had a related patch set uploaded by Catrope:
Clean up transform dimension height handling

https://gerrit.wikimedia.org/r/71393
(In reply to comment #2)
> Related URL: https://gerrit.wikimedia.org/r/69869 (Gerrit Change
> Ide7208394f8495f5b143cbba215d4645598f1a50)

This has been merged, and went out with wmf9. However, given that wmf8 is on the servers for an extra week and it makes really not-nice behaviour in VisualEditor, we probably want to back-port this.
Related URL: https://gerrit.wikimedia.org/r/69869 (Gerrit Change Ide7208394f8495f5b143cbba215d4645598f1a50)
There are actually two bugs going on here.

First, TimedMediaHandler isn't normalizing dimensions for audio files, which means that the height=-1 being passed to indicate "don't limit by height" is being misinterpreted.

And second, TimedMediaHandler is using an incorrect calculation when the height is the limiting factor on the thumbnail dimensions, leading to the width of 1913. The same happens if you pass something like iiurlwidth=220&iiurlheight=10.

Since both of these are in TimedMediaHandler, I'm going to reassign this there. I'll also submit a patch momentarily.
See https://en.wikipedia.org/w/index.php?title=User%3AEdgepedia%2FVE%2FMet&diff=560772671&oldid=560563847 for example; I have no idea why (problem with the template itself?)

--------------------------
**Version**: unspecified
**Severity**: normal
I believe we have fixed this bug; if it recurs, please re-open.
Two users have reported on this. 

See:
http://en.wikipedia.org/w/index.php?title=User:AussieLegend/Vandals_etc&diff=prev&oldid=560719781

And:
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Font_colors_in_signatures_changed

I realize that this is probably tied into other behavior, but I lack code-fu to determine what. :)

Maggie

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=42803
Merged and will go out tomorrow.
Change 73523 merged by jenkins-bot:
HACK: Don't merge adjacent annotations from Parsoid

https://gerrit.wikimedia.org/r/73523
*** Bug 51234 has been marked as a duplicate of this bug. ***
Change 73523 had a related patch set uploaded by Esanders:
HACK: Don't merge adjacent annotations from Parsoid

https://gerrit.wikimedia.org/r/73523
Adding Parsoid bug 42803 as a dependency. We do add nowiki between most cases of adjacent quotes to ensure at least correctness, but the markup will indeed not be optimal.
*** Bug 50291 has been marked as a duplicate of this bug. ***
All we need to do is turn off similar annotation comparisons in VE completely, but Parsoid is not ready for that yet, for example adding new bold text next to Parsoid-generated bold text would create:

<b data=parsoid="">Old bold text</b><b>New bold text from VE</b>

which Parsoid should obviously merge to:

'''Old bold textNew bold text from VE'''

but doesn't yet.

Once this is all handled correctly, we can turn off similar annotation comparisons and the two bolds in <b>Foo</b><b>Bar</b> will no longer be merged (as they have will have different data-parsoid's). Of course Parsoid will not want to merge them either so that will factor into their logic.
(In reply to comment #6)
> I still see annotation merging on this test case:
> 
> http://www.mediawiki.org/wiki/User:GWicke/TestDoubleFormatting?veaction=edit
> 
> Steps to reproduce:
> 
> * append a char to 'baz'
> * preview the change
> 
> Result: The bold ranges are merged, leading to a dirty diff
> Expected result: no merging and no dirty diff
That should be the only remaining annotation merging issue. I've been meaning to file a bug about it but I keep forgetting.

Ed, we need to preserve the difference between <b>Foo</b><b>Bar</b> and <b>FooBar</b> somehow. Feel free to hit me up on IRC if you want to talk about how we should do that.
I still see annotation merging on this test case:

http://www.mediawiki.org/wiki/User:GWicke/TestDoubleFormatting?veaction=edit

Steps to reproduce:

* append a char to 'baz'
* preview the change

Result: The bold ranges are merged, leading to a dirty diff
Expected result: no merging and no dirty diff
Several of these issues are actually on the VE side, so reopening.
*** This bug has been marked as a duplicate of bug 48194 ***
*** This bug has been marked as a duplicate of bug 42803 ***
This is the same as bug 49478. We are dependent on it being in Parsoid first, otherwise we would reintroduce bug 48110.
In this case:

  <span style="color:green;">Aussie</span><span style="color:gold;">Legend</span>

… is being simplified by DM into:

  <span style="color:green;">AussieLegend</span>

… which, unsurprisingly, Parsoid assumes means we wanted to combine them. :-)
Click "add template", then "apply changes" without adding a template (or add one, then remove it.

Expected wikitext: none

Actual wikitext: <span property="mw:PageProp/noindex" data-mw="{&quot;parts&quot;:[]}"></span>

We're clearly putting in a placeholder that we don't delete if the block is empty; because we don't display content blocks that don't render in read, you can't see these, which sucks and lets users do The Wrong Thing(tm).

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 49831 ***
Something's gone wrong with our PHP parser re-render call; on re-render of block templates only, you get {{template call|param}} rather than nice lovely HTML. Presumably something to do with our hack yesterday? Plzfixkthxbai.

--------------------------
**Version**: unspecified
**Severity**: major
(In reply to comment #7)
> I'm not sure if this is the same bug, but English Wikipedia users report that
> when editing an infobox piped wikilinks display as [[word|word]] rather than
> as it will appear on save. It saves correctly.
> 
> I managed to replicate this. If this should be split off into another bug,
> sorry!

That's bug 50801 which we're working on right now; re-closing this one. No worries. :-)
I'm not sure if this is the same bug, but English Wikipedia users report that when editing an infobox piped wikilinks display as [[word|word]] rather than as it will appear on save. It saves correctly.

I managed to replicate this. If this should be split off into another bug, sorry!
*** Bug 50361 has been marked as a duplicate of this bug. ***
*** Bug 50328 has been marked as a duplicate of this bug. ***
This should now be fixed and we will push it out this afternoon.
Change 70865 merged by jenkins-bot:
Fix escapeParams in transclusions to not escape other transclusions

https://gerrit.wikimedia.org/r/70865
Change 70865 had a related patch set uploaded by Esanders:
Fix escapeParams in transclusions to not escape other transclusions

https://gerrit.wikimedia.org/r/70865
*** Bug 49730 has been marked as a duplicate of this bug. ***
Reproduce:

1. Open page with a protected node
2. Click edit (visual editor)
3. Quickly mouse over the protected node (while VE loads)
4. See that the editor has slid the content down but the phantom is rendered under the mouse

Perhaps the local overlay should be a peer of the documentNode.

--------------------------
**Version**: unspecified
**Severity**: normal
Merged and will go out in the next few minutes.
Didn't investigate yet but able to reproduce.
Reported initially in bug 49596:

ptwiki ("direita,right"): https://pt.wikipedia.org/w/index.php?&diff=36119075

plwiki ("prawo,right"): https://pl.wikipedia.org/w/index.php?diff=36790309

This feels like a Parsoid issue (VisualEditor doesn't know about localisations of these terms :-)) but Inez can tell us more details.

--------------------------
**Version**: unspecified
**Severity**: normal
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
https://gerrit.wikimedia.org/r/70343 (Gerrit Change I9717e9d4b3b79cc9e583fb74e3537fbb5112a7bf) | change APPROVED and MERGED [by jenkins-bot]
Related URL: https://gerrit.wikimedia.org/r/70343 (Gerrit Change I9717e9d4b3b79cc9e583fb74e3537fbb5112a7bf)
AFAIC, there is nothing wrong in using the localized version. The problem is to use both.
These magic words are translateable at (for example for Polish) http://translatewiki.net/w/i.php?language=pl&module=words&title=Special%3AAdvancedTranslate - the entry for "right" says "prawo, right", which means both "prawo" and "right" are accepted and mean the canonical "right".

This looks as if Parsoid was calling (implicitly?) .toString() on an array of these terms instead of taking its first entry: ['prawo', 'right'].toString() == 'prawo,right'.
**winne2i** wrote:

(I also mentioned "/ramka/ means /frame/" but I suppose "ramka" would be localised "thumb"…?)
**winne2i** wrote:

It's not a
 (localised 'thumb'),right
this is
 (localised 'right'),right
as I mentioned in bug 49596 comment 6.
Correct - it is a Parsoid bug. Somehow it is similar to https://bugzilla.wikimedia.org/show_bug.cgi?id=48665 but definitely not a duplicate.
Whenever you think that you've fixed that damn script, you suddenly realize there's something else that's still wrong.


Testing the fix for bug 49758, looking at its results:

Created reports per component:
VisualEditor           General                       33
MediaWiki extensions   UniversalLanguageSelector     27
VisualEditor           Editing Tools                 25
VisualEditor           MediaWiki integration         12
Wikimedia              Bugzilla                      11

Created reports per product:
MediaWiki                     43 
Wikimedia                     45 
MediaWiki extensions          104
Security                      3  
Tools                         5  

it is clear that the "product" list does not list those products with the **highest** number of new tickets in the last week.

This can be also seen on
https://bugzilla.wikimedia.org/report.cgi?x_axis_field=&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfield=[Bug+creation]&chfieldvalue=&chfieldfrom=-7d&chfieldto=Now&j_top=AND&f1=noop&o1=noop&v1=&format=table&action=wrap

which right now lists these top 5 products:

MediaWiki extensions  104
VisualEditor          95
MediaWiki             48
Wikimedia             47
Parsoid               23

--------------------------
**Version**: wmf-deployment
**Severity**: normal
Deployed.
Shizzle, /me blind. "ORDER BY foo DESC" is teh win!
Related URL: https://gerrit.wikimedia.org/r/69629 (Gerrit Change Iecdc7439463f58be272cf0b73f662ac91d0b061b)
Looking back at the very first revision of operations/puppet/templates/misc/bugzilla_report.php it already says:

getBugsPerProduct() uses
SELECT name, count(*) FROM bugs
but
getBugsPerComponent() uses
SELECT name, count(*) as total FROM bugs

That's the only difference I can spot in the query designs.
TemplateSpecModel currently doesn't expand aliases, so if it knows something as "foo" with an alias of "1" and the dialog asks about "1", it returns nothing.

--------------------------
**Version**: unspecified
**Severity**: normal
See https://www.mediawiki.org/wiki/Extension:TemplateData#Defining_a_TemplateData_block

Example:

{
  params: {
    image: {
      label: 'File name',
      ...,
      aliases: ['1', 'Image', 'Filename', .. ]
    }
  }
}
More a question that a bug. How do you specify an alias using templateData? There are lots of examples which use alternate capitalisation for parameters. For example {{Infobox World Heritage Site}}
http://en.wikipedia.org/wiki/Template:Infobox_World_Heritage_Site
uses both 'Image' and 'image' to specify an image. To specify both makes the documentation clumsy. An alias would be ideal.

Also {{Quote}}}
http://en.wikipedia.org/wiki/Template:Quote
can be given in two forms, either positional:
{{quote|phrase|person|source}} 
or named:
{{quote|text=phrase|sign=person|source=source}}
Currently both are documented but it would be nicer to use aliases.
Related URL: https://gerrit.wikimedia.org/r/70111 (Gerrit Change I37ec0e152df905844ac58ed1834fca29dccb4eec)
Using Chrome27.0.1453.110 m
Replicated on Firefox 21.0

Attempting to remove a template using the puzzle piece and "remove" function seems to succeed but leaves behind the following code:
<span data-mw="{&quot;parts&quot;:[]}" class="metadata plainlinks ambox ambox-style ambox-Orphan" style></span>

See:
http://en.wikipedia.org/w/index.php?title=Cocking-cloth&diff=560630933&oldid=324780702

and 
http://en.wikipedia.org/w/index.php?title=Cocking-cloth&diff=560631541&oldid=560631467

--------------------------
**Version**: unspecified
**Severity**: normal
*** Bug 49970 has been marked as a duplicate of this bug. ***
Merged and will be going out with next push.
Related URL: https://gerrit.wikimedia.org/r/69686 (Gerrit Change Ic5d4fbf73f3d1be9cf877bc8b98096de9e98991a)
*** Bug 49855 has been marked as a duplicate of this bug. ***
*** Bug 49835 has been marked as a duplicate of this bug. ***
When a user inserts [[links]] or {{templates}}, VisualEditor automatically wraps them into <nowiki> tags. Experienced contributors who are very used to using this syntax sometimes add it inadvertently.

It would be a nice touch to show an unobtrusive warning to remind users that they need to use VisualEditor's menu to insert links, templates & other wikisyntax. LiquidThreads does this well when users insert their signature manually with ~~~ into their post

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49686
https://bugzilla.wikimedia.org/show_bug.cgi?id=50527
https://bugzilla.wikimedia.org/show_bug.cgi?id=50601
The issue that caused this to be reopened (bug 52093) has been fixed and will be deployed soon; consequently, reclosing this.
Change 76701 merged by jenkins-bot:
Set links in wikitext warning to load in new window

https://gerrit.wikimedia.org/r/76701
(In reply to comment #27)
...
> I realize that smarter users can right-click and then open the link in either
> another tab or a new page, avoiding the question of whether they want to
> leave
> their editing session. But if we're aiming at the average user, it would be
> great if this link were pre-defined as opening another window, so that a
> simple
> click on the link didn't result in a perturbed user.

Reported on bug 52093.
(In reply to comment #27)
> If it's not one thing, it's another ...

Welcome to software development.
Change 76701 had a related patch set uploaded by Esanders:
Set links in wikitext warning to load in new window

https://gerrit.wikimedia.org/r/76701
If it's not one thing, it's another ... The popup message is now visible no matter where in a page the wikitext is being entered. So that's progress.

The popup is still too inconspicuous for my tastes (and a great opportunity for A/B testing), but that's not what I'm posting about. My concern is with the link that the popup message includes (the label is "wikitext"; the target is [[Help:Wiki markup]]). If that link is clicked, the system **asks the user whether he/she wants to leave the editing page**. That's a bit user-unfriendly.

I realize that smarter users can right-click and then open the link in either another tab or a new page, avoiding the question of whether they want to leave their editing session. But if we're aiming at the average user, it would be great if this link were pre-defined as opening another window, so that a simple click on the link didn't result in a perturbed user.
(In reply to comment #24)
> The continued flow of markup errors shown by
> http://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchFilter=550
> is a pretty good indication that the warning either isn't obtrusive enough or
> clear enough. We're still seeing about 20 articles an hour corrupted because
> of
> this.
> 

there was a problem with the message (it opened at top of page instead of top of screen), because of bug 50870. since this bug is fixed, the message will become more effective (afaik, this fix was deployed on July 22).

personally, i think that the right solution is outlined in bug 51897. however, ATM 51897 is marked as "low". if you think like i do, maybe you should lobby to bump up the priority of 51897.


peace.
Another possibility: provide a side by side view of the two options the user has, and ask for confirmation:
https://en.wikipedia.org/w/index.php?oldid=564535137#bug49820
**kwwilliams** wrote:

The continued flow of markup errors shown by http://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchFilter=550 is a pretty good indication that the warning either isn't obtrusive enough or clear enough. We're still seeing about 20 articles an hour corrupted because of this.

I think this really needs a positive checkoff dialog, and the article shouldn't be saved until the editor has agreed that he really wants strings of brackets and pipes in his text. Having these in legitimately is an extremely rare case, especially for a novice editor. I'd block the edit with the edit filter if I could, but VE isn't able to display edit filter messages properly.
(In reply to comment #19)
> Depends on bug 51432

This was already reported as bug 50870, adjusting.
**ignatzmice.wiki** wrote:

(In reply to comment #21)
> What about having the balloon (https://github.com/wikimedia/jquery-tipsy ?)
> pointing exactly to the position where the wikitext was found?

That might work pretty well too, especially if the balloon is a prominently "warning" color (as suggested somewhere by someone). I personally would be in favor of a big in-your-face notification, but I accept that not everyone will.
What about having the balloon (https://github.com/wikimedia/jquery-tipsy ?) pointing exactly to the position where the wikitext was found?
**ignatzmice.wiki** wrote:

(In reply to comment #18)
> Created MW bug for position fixed. Due to the possibility of false positives,
> having a blocking confirmation box may be too obtrusive.

I dunno. I don't see a lot of false positives coming out of Filter 550. If you're really concerned, there could be a setting in the VE prefs to turn it off. (I definitely would NOT want a "don't show again" in the popup itself—too easy to get rid of it without clearly understanding what it means.)
Depends on bug 51432
Created MW bug for position fixed. Due to the possibility of false positives, having a blocking confirmation box may be too obtrusive.
Actually this is a general problem with jsMessages is general. They should be placed at a fixed position on the page.
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Wikitext_warning_probably_won.27t_be_seen_by_most_editors for some more detailed info on pieces of it.
I'm reopening this as it seems to be the best place. There is definitely an issue with the warning being only on top and so you really don't have to be scrolled down that much before you don't see the warning.
**ignatzmice.wiki** wrote:

The little box is not nearly obtrusive enough. It should be a popup (like the "are you sure you want to thank this user?" popup) that says the same thing as the warning, but requires confirmation (even a sole "OK" button would be fine, so long as it actually disrupts the editor's typing).
Just tried this out - seems to be an issue.  If you are scrolled down far enough on an article, the warning is never seen.  It's tied to the top of the page. You can go all the way through the save process and only see the message once the new version loads.  I suspect this might be reducing the effectiveness of the notice.  (FF 22, OS 10.6.8)
Feature to do this is now merged and will be deployed tomorrow.
Change 73569 merged by jenkins-bot:
Warn users when they are typing wikitext

https://gerrit.wikimedia.org/r/73569
Change 73569 had a related patch set uploaded by Catrope:
Warn users when they are typing wikitext

https://gerrit.wikimedia.org/r/73569
**ignatzmice.wiki** wrote:

(In reply to comment #7)
> (In reply to comment #6)
> > A permanently dismissible first-use reminder may be sufficient. I suggest we
> > try that and see if it significantly reduces incidents of wikitext insertion.
> > See bug 50601 for discussion.
> 
> Habits die hard. When you've been entering wikitext manually for the past 12
> years, it's _really_ hard to change your habits. I really doubt a "first-use
> reminder" will be enough.

Yes, this. I recognized the problem first time I did it, and it still happens.
(In reply to comment #4)
> I have already suggested bug 50527 as a possible solution to this problem. An
> automatic tag and then manual correction would be a simple-to-implement
> interim
> measure, if not long term.

Bug 50527 proposes that the edit go through, WITHOUT warning the editor of his/her mistake; instead, the edit summary gets a tag showing that a problem exists with the *completed* edit. Given that the software can detect this error, it makes more sense to give the editor who made the mistake a chance to fix it *before* the edit is completed - ideally, not to allow the edit to be completed with the error intact within in. That way, (a) the editor is more likely not to make the mistake again, and (b) if the editor who made the mistake fixes it before finalizing his/her edit, there is no need for a second (corrective) edit (and no need for someone to be monitoring recent changes for the tag proposed in bug 50527).
(In reply to comment #6)
> A permanently dismissible first-use reminder may be sufficient. I suggest we
> try that and see if it significantly reduces incidents of wikitext insertion.
> See bug 50601 for discussion.

Habits die hard. When you've been entering wikitext manually for the past 12 years, it's _really_ hard to change your habits. I really doubt a "first-use reminder" will be enough; I still expect people to add [[ inside VisualEditor in 5 years. All drivers learn what the speed limits are before they get their driving license, but there are still speed limit signs on the roads :)

A guided tour is indeed a great idea, but _in addition_ to an always-shown-when-wikitext-is-detected warning, not as a replacement, imho.
A permanently dismissible first-use reminder may be sufficient. I suggest we try that and see if it significantly reduces incidents of wikitext insertion. See bug 50601 for discussion.
And bug 50093 for an alternative [[ suggestion.
I have already suggested bug 50527 as a possible solution to this problem. An automatic tag and then manual correction would be a simple-to-implement interim measure, if not long term.
%%%*** Bug 50581 has been marked as a duplicate of this bug. ***%%%
"What Chris said". I'd like to know the rationale for the priority rating on this; it's the biggest source of article corruption.
Why is this marked low priority? It is causing problems on the live wiki with people unable to figure out why their edit has not worked - the VE hides the nowiki tags it has inserted so its impossible to determine the cause unless one knows about this feature (which I've not seen in documentation) or uses the misnamed edit source.
screenshot

When selecting some templates in VisualEditor, a blue rectangle appears in the top left corner of the browser's window, and disappears when the template is unselected.

Encountered on https://en.wikipedia.org/wiki/User:Jdforrester_%28WMF%29/Sandbox?veaction=edit (see screenshot)

Firefox 21.0 on openSUSE 12.3

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

**Attached**: {F11783}
Appears resolved.
(In reply to comment #7)
> As noted by JamesF in 50161, this still occurs (Vector, Chrome, Win 7).
> Screenshot while editing ref. #6 in
> http://it.wikipedia.org/wiki/Utente:Syrio/Bozzoli , you need to click at
> least
> a few times on the sentence before the puzzle piece pops up. It will allow
> you
> to edit the reference and save the page as usual. It might be worth noting
> that
> the page features a page title and a magic word. Thanks.

I now can't reproduce this - can you check too? (We did a new release today which should have fixed this for good.)
As noted by JamesF in 50161, this still occurs (Vector, Chrome, Win 7).
Screenshot while editing ref. #6 in http://it.wikipedia.org/wiki/Utente:Syrio/Bozzoli , you need to click at least a few times on the sentence before the puzzle piece pops up. It will allow you to edit the reference and save the page as usual. It might be worth noting that the page features a page title and a magic word. Thanks.
Created attachment 12812
Light blue bar issue still occurring

**Attached**: {F11784}
Fixed and will go out in the next release.
Change 71118 merged by jenkins-bot:
Don't draw highlights over hidden elements.

https://gerrit.wikimedia.org/r/71118
Change 71118 had a related patch set uploaded by Robmoen:
Don't draw highlights over hidden elements.

https://gerrit.wikimedia.org/r/71118
Confirmed, happens in firefox and chrome.
%%%*** Bug 50074 has been marked as a duplicate of this bug. ***%%%
Encountered on: https://en.wikipedia.org/wiki/Westplex?veaction=edit
Firefox 21.0 on openSuse 12.3

When opening the "Media settings" overlay by clicking the icon on the image, the title shows <visualeditor-dialog-media-content-section> instead of what I assume should be the actual system message.

--------------------------
**Version**: unspecified
**Severity**: trivial
Fixed by gerrit 69497 which we will try to get pushed today.
Like we do with the link inspector.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This fix will be pushed to production later this afternoon; closing as such.
Change 70946 merged by jenkins-bot:
Close dialogs on escape

https://gerrit.wikimedia.org/r/70946
Change 70946 had a related patch set uploaded by Trevor Parscal:
Close dialogs on escape

https://gerrit.wikimedia.org/r/70946
See, for example, http://en.wikipedia.org/w/index.php?title=Audie_Murphy&diff=560382883&oldid=560374610 - the line "ad a private-pilot license and" (image description) is clearly being taken from the article text "had a private-pilot license and a reported 8, 000 hours of flying time", but I have no idea how.

--------------------------
**Version**: unspecified
**Severity**: normal
These were fixed by Inez's new code from Thursday.
**molly.white5** wrote:

A user just came to IRC asking about this same issue. The user had made this edit: http://en.wikipedia.org/w/index.php?title=Harry_Belafonte&diff=560738876&oldid=560738222

The user had only intended to make the changes that appear between lines 98 and 108; all of the other changes appear to be a product of this bug.

The same issue occurred for the user in http://en.wikipedia.org/w/index.php?title=Harry_Belafonte&diff=560737462&oldid=560717280.
Steps to reproduce:

1) Visit https://en.wikipedia.org/wiki/Deliciosamente_amoral?veaction=edit

2) Attempt to manipulate the contents of the infobox by clicking the puzzle piece icon associated with it.

Expected behavior:

Infobox parameters should be editable.

Actual behavior:

Template editor invocation fails with the following error on the console:

Uncaught TypeError: Cannot read property 'description' of undefined 

Chrome/Ubuntu

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49493
Yes, this is a dupe of bug 49493; sorry!

*** This bug has been marked as a duplicate of bug 49493 ***
This might be linked to bug 49493 - Timo, any quick thoughts?
Example screenshot of the issue

In the given link, for reference 7's template; only in Firefox - works fine in Chrome.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/w/index.php?title=VisualEditor:TestReferenceContents&oldid=713075

**Attached**: {F11716}
Patched and merged: https://gerrit.wikimedia.org/r/#/c/70119/
https://en.wikipedia.org/wiki/List_of_highways_numbered_147?veaction=edit

I selected an inline image in the editor (in itself strange, because it doesn't seem you can edit it). I then hit cmd-c, and the inline image was replaced by the pawn char.

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed (I think) in gerrit 69503 which we will deploy this afternoon.
Actually, Safari 6 for me.
Yet again, a Firefox bug. *sighs*

(Editing images will be possible very very soon. :-))
<b><b>Foo</b></b> == <b>Foo</b> so it's not /so/ bad if VE corrects it (but it's still a bit dirty, but <small><small>Foo</small></small> != <small>Foo</small> (and the same with <big> and <sup> and …)

--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://en.wikipedia.org/w/index.php?title=User:JohnCD/draft&diff=560430675&oldid=560430611
Now fixed.
Fixed on the VisualEditor side; the Parsoid upstream issue in Domino is patched but not yet released. Not marking as fixed until that's done.
Change 72133 merged by jenkins-bot:
Make all annotations additive

https://gerrit.wikimedia.org/r/72133
Change 72133 had a related patch set uploaded by Esanders:
Make all annotations additive

https://gerrit.wikimedia.org/r/72133
(In reply to comment #4)
> The fix sets big/small/sup/sub to be additive.
> 
> Arguably we should make all annotations additive, as you could add
> 'style="font-size:110%"' to anything, although I haven't thought through how
> this might affect the toolbar interactions yet.

+1. This will also avoid dirty diffs on such content.
Change 71716 merged by jenkins-bot:
Allow annotations to be additive

https://gerrit.wikimedia.org/r/71716
The fix sets big/small/sup/sub to be additive.

Arguably we should make all annotations additive, as you could add 'style="font-size:110%"' to anything, although I haven't thought through how this might affect the toolbar interactions yet.
Change 71716 had a related patch set uploaded by Esanders:
Allow annotations to be additive

https://gerrit.wikimedia.org/r/71716
This causes round-trip failures.
%%%*** Bug 49756 has been marked as a duplicate of this bug. ***%%%
The reference editor allows me to group references, and allows me to include a ref name parameter to make them reusable, but has no way of actually calling that ref name.

--------------------------
**Version**: unspecified
**Severity**: normal
This feature is now written and merged, and will be going out in a few minutes.
Change 70364 merged by jenkins-bot:
Reference insertion, new and existing

https://gerrit.wikimedia.org/r/70364
... this is already what's meant to happen with master; it seems that it's broken a little in this regard, so we'll need to fix.
Proposing for July 4 milestone (alt. July 11). This is imho not a nice-to-have but a requirement since re-using of references is quite common and without it, it would seem incomplete.

The ability to create such references or turn existing ones into it may be less important than the ability to edit such references (e.g. a <select> with all ref-names available on this page).
Screenshot

See associated character; italics in the reference editing interface causes a pawn to appear.

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

**Attached**: {F11627}
*** Bug 49877 has been marked as a duplicate of this bug. ***
*** Bug 49888 has been marked as a duplicate of this bug. ***
Fixed in gerrit 69503 which we will deploy this afternoon.
Actually, neither the console nor firebug show any errors.

It is an italicised or bolded pawn, however, so we can confirm that works.
Please check your browser's JS console, there should be an error message that appears there at the same time that the pawns appear in the editor.
Also adding a pawn on bolding.
See associated screenshot; an attempt to add 'foo' to the infobox on https://www.mediawiki.org/wiki/VisualEditor:Template_test

--------------------------
**Version**: unspecified
**Severity**: normal
This is an artefact of a Parsoid serialisation bug that has now been fixed.
Screenshot

**Attached**: {F11626}
**Author:** `rachelqa99`

**Description:**
Make a reference, then type text into Name content, and change format to Heading 5 or Heading 3.  When you save the file, you see the wikitext displayed for the heading format. 

See page: https://www.mediawiki.org/wiki/User:Rachel99/testing_edit_source

On the bottom of the page, it looks like that.

    ↑ ===test===
    ↑ =====Book reference=====
    ↑ ===footnote text===
    ↑ =====test5=====

--------------------------
**Version**: unspecified
**Severity**: major
Merged and will be deployed very soon.
Related URL: https://gerrit.wikimedia.org/r/69867 (Gerrit Change Ic823a90398dafca1caf8fa4142d98133ab661d7c)
Yes, this is a definite issue - there's a wider bug about the technical functionality, bug 49657, but this is a specific example we need to do (and so soon).
on beta labs only, not seen in mediawiki.org: 

On any article e.g. http://en.wikipedia.beta.wmflabs.org/wiki/0.0924627428112147 

Click Edit to invoke VE

Page content is a different article.  In the case of http://en.wikipedia.beta.wmflabs.org/wiki/0.0924627428112147 I see the content for an article on "TAT-1"

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49963
This was fixed yesterday by Roan.
Related URL: https://gerrit.wikimedia.org/r/70582 (Gerrit Change Iacc9e88ec83e9037abe9ace53deccafcf68a6bbb)
This is my fault, I broke this in https://gerrit.wikimedia.org/r/#/c/68133/ . We should revert that change and figure out a way to keep deployment-parsoid2 up-to-date.
Created attachment 12594
modal upon review or save

**Attached**: {F11548}
This still happens after upgrading VE to the latest version, with error saying "invalid token", see screen shot
Alongside the "minor" and "watch" checkboxes in the save dialog, for pages with FlaggedRevs switched on and outstanding unaccepted revisions, add a checkbox to "accept pending revisions".

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50852
Merged and will get deployed in a few hours' time.
Change 75555 merged by jenkins-bot:
Render check boxes from EditPage

https://gerrit.wikimedia.org/r/75555
Change 75555 had a related patch set uploaded by Catrope:
Render check boxes from EditPage

https://gerrit.wikimedia.org/r/75555
*** Bug 51833 has been marked as a duplicate of this bug. ***
(In reply to comment #6)
> I note this has been posted as an enhancement; however, as flagged revisions
> are applied to *all* pages in article space on certain Wikipedias (de and ru
> in particular) I'd urge that this be resolved prior to introducing VisualEditor
> to those projects. For them, the absence of this would be more than the minor
> inconvenience it is on English Wikipedia, where PC is applied to a very small
> number of pages and could be switched to semi-protection if really needed.

Absolutely.
(In reply to comment #0)
> Alongside the "minor" and "watch" checkboxes in the save dialog, for pages
> with
> FlaggedRevs switched on and outstanding unaccepted revisions, add a checkbox
> to
> "accept pending revisions".

I note this has been posted as an enhancement; however, as flagged revisions are applied to *all* pages in article space on certain Wikipedias (de and ru in particular) I'd urge that this be resolved prior to introducing VisualEditor to those projects.  For them, the absence of this would be more than the minor inconvenience it is on English Wikipedia, where PC is applied to a very small number of pages and could be switched to semi-protection if really needed.
(In reply to comment #2)
> Just as an addition to this: I'm not sure if just the checkbox is what is
> needed. The current work flow has a whole separate page because we need to
> show the diff involved for the review. I imagine that can be done without
> going to a new page but either way they should be able to review the diff
> (and preferably leave a comment like you can in the review page now) before
> checking any kind of approve box since they become somewhat responsible for
> those edits.

Yes, indeed; I was imagining:

* on load, an alert in the edit notices saying "You will need to accept the outstanding changes before saving" (or whatever the current message is) - possibly with a link to the below?
* on entering the save dialog, the save button will be disabled with another copy of the "You will need to accept the outstanding changes before saving" text (in the same place as the edit conflict / CAPTCHA / DOM corruption warnings)
* in the line of buttons ("Save page", "Review your changes") there should be a third button, "Review outstanding changes", which on click pops up the diff of outstanding changes, with a text box for the optional review comment and an "accept these changes" button that takes you back to the save dialog, now with the save button enabled.

Feels a little clunky, though - perhaps we could make the process in-line with the edit summary message?
(In reply to comment #0)
> Alongside the "minor" and "watch" checkboxes in the save dialog, for pages
> with
> FlaggedRevs switched on and outstanding unaccepted revisions, add a checkbox
> to
> "accept pending revisions".

I don't find that an acceptable solution, because there is a requirement that reviewers actually review the edit they are accepting; they cannot do that if they're just ticking a box.  

See https://commons.wikimedia.org/wiki/File:Cropped_edit_source_admin_edit_with_existing_PC.png for what the screen looks like using Edit Source.  Note that the diff includes ALL unreviewed changes.
Just as an addition to this: I'm not sure if just the checkbox is what is needed. The current work flow has a whole separate page because we need to show the diff involved for the review. I imagine that can be done without going to a new page but either way they should be able to review the diff (and preferably leave a comment like you can in the review page now) before checking any kind of approve box since they become somewhat responsible for those edits.
*** Bug 50852 has been marked as a duplicate of this bug. ***
https://en.wikipedia.org/wiki/Template:Contradictory, on https://en.wikipedia.org/wiki/Necessity - in the VisualEditor it displays as ﻿[<span title="This text contradicts text in the article "Necessity in English law" (3 May 2011)">contradictory]﻿. Reproduced in Chrome 27/Safari 6.0.5 on a Mac, Firefox 21.0 on Windows 7.

--------------------------
**Version**: unspecified
**Severity**: major
I changed the Contradict-inline template and that fixes this problem.

https://en.wikipedia.org/w/index.php?title=Template%3AContradict-inline&diff=560522227&oldid=471439681
This amounts to accepting <span title=""foo"">bar</span> as a valid span-tag. Ugh! The PHP parser seems to accept this quite fine.  Parsoid would have to perform the same magic.

See http://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&oldid=560521020

Hover over the two foos and see the difference. PHP parser drops the title attribute 'bar' on the first foo since it is ofcourse a bug.

Seems like a reasonable fix the Fix templat -- but I assume Fix is used in a lot of places and fixing the callers would be a lot of work ... so, we may need some ugly hack in Parsoid to support this.
Reduced test case: {{Fix|text=foo|title="bar"}}

It is the quotes around "baz" that trips up Parsoid (probably the tokenizer).  Investigating more.
This is actually [[Template:Contradict-inline]] that appears broken in Parsoid - see http://parsoid.wmflabs.org/en/Template:Contradict-inline - shunting over.
See https://en.wikipedia.org/wiki/Hermann_M%C3%BCller_%28politician%29 for example; found in Chrome 27 on a Mac. In Safari 6.0.5 it displays differently (a large space appears, rather than a missing icon signifier) but is still broken. Not replicatable in Firefox 21.0/Windows 7.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://parsoid.wmflabs.org/en/Hermann%20M%C3%BCller%20(politician)
The original bug was rendering of [[:Media:Hermann Müller.ogg]].

The rendering of [[File:Hermann Müller.ogg]]/[[File:La_Marseillaise.ogg]] is a different problem, as that renders as a player in source editor.  There are some underlying problems in Parsiod and even the mw API if I am understanding bug 49896 correctly.
Seems to me, this is still buggy !

Have tried the following code at http://parsoid.wmflabs.org/_rtform/:
[[File:La_Marseillaise.ogg]]

This gives:
<img resource="./File:La_Marseillaise.ogg" src="//upload.wikimedia.org/wikipedia/commons/3/30/La_Marseillaise.ogg" data-parsoid="{&quot;a&quot;:{&quot;resource&quot;:&quot;./File:La_Marseillaise.ogg&quot;},&quot;sa&quot;:{&quot;resource&quot;:&quot;File:La_Marseillaise.ogg&quot;}}" width="200">
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
This is now fixed in production for Parsoid (and so for VisualEditor). Sorry for the bug!
It's inserting a thumbnail image at fixed 200px width.

<img resource="./File:Hermann_Müller.ogg" src="http://upload.wikimedia.org/wikipedia/commons/d/d3/Hermann_M%C3%BCller.ogg" width="200" data-parsoid="{&quot;a&quot;:{&quot;resource&quot;:&quot;./File:Hermann_Müller.ogg&quot;},&quot;sa&quot;:{&quot;resource&quot;:&quot;:File:Hermann Müller.ogg&quot;}}">
Bug title may be a bit confusing; essentially, a user has suggested that the VE auto-convert wikimarkup entered ''into'' the VE, on save. The use case is users who keep typing [[link]], basically.

My feelings on this are mixed; I think it's perfectly possible that this would be useful, but it sounds like a ton of work and it's also perfectly possible that, once we go live, muscle memory will adapt and there'll be no point to this. For now, sticking it in as a potential future enhancement.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49820
https://bugzilla.wikimedia.org/show_bug.cgi?id=51899
https://bugzilla.wikimedia.org/show_bug.cgi?id=47779
(In reply to Amalthea from comment #40)
> I really don't get why you're fighting this so hard.

It should be obvious by now that VE's development has been made an ideological matter. This feature request involves some degree of the "old way" of doing things, thus is forbidden.
I'll clarify that "it shouldn't happen" means just that it is not useful/desirable to have it IMHO, or at least I can't think of a situation where it would be.
48891 and 53974 cover that specific problem. The wikimarkup warning is just a warning, it does not stop you from doing anything. 
As for [[[[this situation]]]], of course it shouldn't happen. I can't recall the bug number though, right now, and since a quick search did not seem successful, I'll come back on that later.
**Wikifram** wrote:

What I mean is that you start with wikimarkup visible in the VE editing mode. When you add something (''not'' wikimarkup) inside such wikimarkup, you get the wikimarkup notice at the top right; but on saving, the existing wikimarkup remains. [https://www.mediawiki.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandboxVE&diff=794444&oldid=794415]

So my questions are; why is the existing wikimarkup accepted and displayed here, why is it recognised by the wikimarkup detection error, but why is it then not changed on saving? 

This behaviour may give a clue as to how wikimarkup can be accepted in VE after all (but then again, perhaps not), but it certainly is baffling me.
Hi there, I don't think I see your VEdit there. I did https://www.mediawiki.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandboxVE&diff=794415&oldid=794413 and https://en.wikipedia.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandbox&diff=575429594&oldid=575429509 instead, nowikis are added as the only expected outcome. Which conversion should have happened when VEditing? Thanks.
**Wikifram** wrote:

Can someone explain why [https://www.mediawiki.org/wiki/Communication?veaction=edit this page] seems to accept wikitext markup, even in VE mode? On saving, it gives the "nowiki" warning, but it doesn't actually convert the existing "[[" and "]]" into wikitext. A very strange page in VE mode, that one.
**Amalthea.wikimedia** wrote:

(In reply to comment #39)
> [...] this bug is - by definition of the product - a WONTFIX.

James, this is simply not true. See comment #36 about auto formatting logic in other visual word processors.
I really don't get why you're fighting this so hard.
(In reply to comment #10)
> Marking as WONTFIX per my earlier comments and Erik's.

… again. Bug 51897 is indeed different; my apologies for merging it based on my reading of the bug as filed. However, this bug is - by definition of the product - a WONTFIX.
user John Broughton at en.wp comments:
"Rather than focus on improving [the warning about entering wikitext], a better direction to go would be for VE to be able to convert wikitext to its equivalent in VE. Thus if one typed [[New York City]], for example, VE would convert that to its format for an internal link. This is fairly straight-forward, programming-wise: after VE adds a closing nowiki tag for some text, it would examine it for conversion possibilities: external link? internal link? footnote? template?"
**Amalthea.wikimedia** wrote:

Erik:

(In reply to comment #18)
> it's a matter of ensuring we can provide a user experience that's not modeled
> on markup, but on best user experience practices.

I don't think that was the suggestion above?

Word processors have long supported text-based auto formatting logic, and they certainly aren't focusing on underlying markup. For example, to this day, you can *bold* and _italicize_ text in OpenOffice Writer and Microsoft Word by using the traditional markup, or define numbered and bulleted lists simply by starting the first item with "* ", "- ", or "1. ".

Adding auto-formatting logic does not impair the goals of the visual editor: defining a link via square brackets won't be the obvious way, and it will likely not be advertised anywhere except possibly in some settings page. It can be helpful without taking anything away from the vision.
**Wikifram** wrote:

Note that this question is included in the large [[Wikipedia:VisualEditor/Default State RFC]] on the en.wikipedia, as question 5. The current tally, for what's it worth, is 28 supporting and 22 opposing, but with many conditional comments on both sides ("yes for X but no for Y"). Many of the opposes are "no, because this is a WYSIWYG", but in reality, of course, this isn't a wysiwyg but a hybrid anyway... (you still need to know wikimarkup to do a lot of things in the new editor in mainspace as well)
**Wikifram** wrote:

Erik Moeller, do you have any idea how many hours are spent on correcting these "nowikis" every day? Do you, on the other hand, have any data on how many "correct" nowiki tags are added? Is there any reason why what should be a no-brainer (not per se an easy one technically, but a no-brainer from the should-be-done point-of-view) improvement is so drastically rejected? 

Have any of you considered that, as of now, new editors using only VE and only editing the mainspace still need to know the [[ ]] syntax anyway? A simple example: on the English wikipedia, I opened [[HKBK College of Engineering]] with the VE, and clicked on the infobox. Click on a parameter, e.g. city, and what you are confronted with is [[Bangalore]]. So new editors ''need'' to use it in the infobox, but are ''not allowed'' to use it in the article text, and this is supposed to be an improvement why? 

What is actually the reason (apart from perhaps "technical difficulty") that square brackets are no longer allowed as an alternative method of creating wikilinks? No one is asking to disable the VE wikilinking methods, but no one seems to understand the insistence of the WMF on disallowing the square brackets method either.
(In reply to comment #31)
> I think that James' marking your bug as a duplicate was likely caused by his
> misunderstanding your request. He is part of the VE team but I have met him
> at Wikimeets a few times and I can assure you he is human.


the last line makes me think that maybe some of my comments can be read in a way that does not fully match the spirit in which they were written.

although i have criticism, especially toward the perceived attitude of VE team towards their user base, i never meant to say or hint any of them is a bad person or less than brilliant developer.

as i already said in this thread, i think VE itself is a great thing, we want it, we need it, and we want it to succeed. 

hope that heated and less-than-polite things said in this (and maybe other) discussions will not be taken as attacks - it is/was never the intention to attack anyone.

peace.
(In reply to comment #28)
Thank you for clarifying the two requests, Chris. That was super-helpful. :-)

(In reply to comment #29)
> maybe instead of coming here, what i should have done is to reopen and remove
> the "duplicate" designation. 

My apologies, kipod. Thank you for patiently putting up with me. Indeed, I think bug 51897 is not a duplicate of this bug. My comments were strictly related to the original request here on bug 49686.

I don't know what the VisualEditor team's view is on your request at bug 51897, so I'm going to go ahead and un-dupe bug 51897 now. Bug 51897 may also eventually be marked resolved/wontfix, but it doesn't seem to be within the scope of this bug, so it should be handled separately.
I think that James' marking your bug as a duplicate was likely caused by his misunderstanding your request. He is part of the VE team but I have met him at Wikimeets a few times and I can assure you he is human.

As for Bug 51899, yes that is a perfect match. Thank you.
oh, and what you describe as "the ideal solution", sounds a lot like bug 51899 to me.

peace.
i think you are correct stating that these two "definitions" of the enhancement request are not identical.
however, i came here to bug you guys with "my" definition of the request after Forrester closed  bug 51897 with "duplicate". the bug he closed listed my request exactly.
maybe instead of coming here, what i should have done is to reopen and remove the "duplicate" designation. 

my guess is that it wouldn't make a huge difference - the team would have closed it as "WONTFIX" instead of closing it as "DUPLICATE". i took them on their word about these two request being one and the same - maybe it was a mistake. (afaik, Forrester is part of VE team).

as to "[[" being ambiguous: i did not dive deeply into it, and did not conduct extensive tests, but i think that typing "[[" anywhere on the page will cause VE to jump the "wikicode detected" popup. as a wikicode, "[[" is not ambiguous at all, i think. it means "start internal link here".


peace.
i still do not think you understood the request. 
it's not about transforming [[Foo]] to a link, it's about not getting [[Foo]] into the page in the first place: as soon as the user types "[[", the "[[" should be removed from the page and interpreted as <Ctrl>+K.


as to your questions about File:Foo.jpg or Category:Foo: what does VE do today when someone presses <Ctrl>+K and then feeds "File:Foo.jpg" or "Category:Foo" ?
whatever it does today, this is what i expect it to do when someone types "[[" and then feeds in the link form "File:Foo.jpg" or "Category:Foo".


> (In reply to comment #25)
> ......
> And, of course, a certain percentage of users will want to actually include
> brackets ("[" and "]") in their edits. How do they undo the magical
> transformation?
> 

these are just straw arguments. 
there are many many many things one can't do now using VE. it will not at all be so bad if the extremely rare case of having to add "[[" to the page within "nowiki" tags will be one of them. 
definitely much much better than current situation, where hundreds of edits with "[[" enclosed inside "nowiki" tags are added to enwiki daily, when the editors actually intended to add a link (i did not count them myself - this is what i'm led to believe based on reports of editors who actually clean this mess).

peace.
i am not sure you understand the precise nature of this request, so let me elaborate:

what we ask (at least, this is what i asked - see bug 51897, which was marked as duplicate of this one) is that when the user types "[[", VE will remove the "[[" from the page, and behave as if the user typed <Ctrl>+K, i.e. open the "Link" form.

simple and easy, VE already recognizes that the user typed "[[" - all we ask is that instead of jumping less-than-useful-and-often-out-of-screen popup, VE will do something good and useful for the community, for society, and for humanity.

in the same way, when the user types "{{", remove it from the page and behave as if she clicked on the puzzle piece, instead of jumping the less-than-useful popup.

easy to do, simple, and does not go against any principle in UI design, except sheer stubbornness of the VE team.

unfortunately i am not able at this time to provide a patch, but 92.24% of the code is already in place - just find where VE jumps the popup, and do something useful instead.

peace.
(In reply to comment #23)
> well, in all this products, when i misspell a word, the thing silently and
> valiantly just fix my mistake, instead of shouting at me[1]. 
> generally, this is known as "Auto correct" (sometimes also [[DWIM]]: "Do
> What I Mean").
> 
> [...]
> 
> when you recognize that the user did something they did not mean to do, such
> as mispelling a word (in M$ word) or typing [[Something something]] in VE,
> just Do What the User Meant.

Computers can't read minds and they monumentally struggle with understanding context. When I type "subst" into OS X (as in template substitution), it autocorrects to "subset" because surely that's what I meant, right?

I completely agree with you that [[muscle memory]] here is an issue. And I completely agree that we need to find ways to make linking as painless as possible in VisualEditor (we're not there yet). But part of meeting user expectations is to take input (such as "[[foo]]", which displays as "[[foo]]" in VisualEditor) and output it as the user saw it in the editor.

These type of magical transformations won't be supported in VisualEditor and I think that's a reasonable position to take. However, it should be completely possible to create a JavaScript gadget that can enhance the user experience for those who have a deep understanding of the difference between source editing and visual editing and who would like a hybrid option. I'd pursue this. :-)
please look above: in comment 15, Forrester did some namedropping: "Microsoft
Word, OpenOffice, Google Docs, Apple Pages and more".

well, in all this products, when i misspell a word, the thing silently and valiantly just fix my mistake, instead of shouting at me[1]. 
generally, this is known as "Auto correct" (sometimes also [[DWIM]]: "Do What I Mean").

if really you use these products as your role model, please pick the good stuff, not the crappy stuff. who cares if the shortcut for "link" is <Ctrl>+K or <Ctrl>+L ?

why can't you adopt the real valuable features from them instead of the completely anecdotal ones?

when you recognize that the user did something they did not mean to do, such as mispelling a word (in M$ word) or typing [[Something something]] in VE, just Do What the User Meant.


peace.


[1] i cheated - i am not actually sure if it's really "in all those products". i know it's in most of them.
We're listening, but in this case we're saying no, and that decision is final. We can elaborate a bit more on the why if that helps, but parsing wikitext in VisualEditor is absolutely not going to happen.

If accidental insertion of wikitext is still an issue, we should focus on other ways to mitigate that issue.
(In reply to comment #17)
> So, let's calm down here.
> 
> We're not "pissing on" anyone; 

yes you are.
if you look at the different wikis, and if you search here with "product=visualeditor" and "search word=nowiki", you will find that one of the main complaints of editors in many projects (specifically enwiki and nlwiki), is the fact that users type "[[something something]]", and VE wraps it with "nowiki". this is clearly not what the editor meant to do

true, VE also jumps a popup message telling the editor "this is probably not what you meant", but there are two issues with that:
1) because of unrelated bug, this popup message is usually not even seen by the editor.
2) if the thing is cleaver enough to know that this is not what i meant, why can't it just Do the Right Thing (tm) ? (answer: of course it can, but the team decided to WONTFIX it).


this attitude of VE team - pissing on and pissing off the user base at the same time, already caused the editors in nlwiki to vote not to activate it in the planned date (and they can do it - you guys removed the switch - we can bring it back through common.js or through gadgets, and we can also make it "default". is a fight with the user base really what you need right now?).


why does it seem, with this and other bugs (specifically, insisting on hiding the preference to disable VE), that the VE team made a conscious (or maybe  unconscious) decision to ignore the community and shun it?
what does the VE team expect to accomplish this way?


we want VE and we like VE, but you guys should do a better job listening to us when we tell you where it hurts.

peace.
Thank you very much for the clarification, Erik. I was just about to ask, following comment 17, whether this was truly a wontfix (i.e., patches will not be accepted) or whether it was simply a very low priority. :-)
"other user interfaces optimized for markup" -> "other user interfaces optimized for completing actions quickly in VisualEditor that are fast to do in markup"
Sorry, but this is not something we'll ever do, as I explained in comment 9. It's not simply a matter of prioritization - it's a matter of ensuring we can provide a user experience that's not modeled on markup, but on best user experience practices. As James said, we provide keyboard shortcuts, and will provide other user interfaces optimized for markup. But parsing markup within the visual editing context is completely off the table.
So, let's calm down here.

We're not "pissing on" anyone; we're choosing to prioritise. Right now the devs have got a lot of open bugs for the VisualEditor - things that actively /don't work/. They've got a lot of features still to build, and a lot of expectations about the project. Personally, I'm incredibly impressed with the speed of change and the patches that have been submitted so far - it's a fantastic workrate. But that doesn't change the fact that there's still a lot to do.

Now: we /can/ have wikitext converted to VE-compatible elements. But there are a few costs. First: from my conversations with the developers, I understand that doing it on the fly would slow the VE down very substantially. You'd have to automatically parse and re-render the page. Second: if they work on this, there's a lot of stuff that is going to get pushed back.

We have a VisualEditor. It's great, it's miles better than anything else produced to do this job in MediaWiki, but it still needs a lot of work and still has a lot of active bugs - problems parsing content, problems rendering content. If enhancements such as this (which would certainly be nice) are worked on, active breakage will take a back seat: those areas where it simply doesn't have features will take a back seat. I'm not comfortable with saying that we rate "being able to type markup into the VisualEditor" higher than "being able to manipulate tables".

As you note, the source editor is still available in all namespaces. Users who are actively prioritising familiarity with syntax, and their muscle memory, are welcome to use it. It's not going away. In the meantime, the VE development process should be focused on making it work full stop, not making it work for the users who are highly comfortable with source editing. That's nice, and it's something I'd love to see, but it's not going to happen if actual bugs aren't fixed first.
(In reply to comment #15)
> If you want an "accelerator key" for making links, use the standard one:
> Ctrl +
> K (or Cmd + K if you're on a Mac). This is the same shortcut as in Microsoft
> Word, OpenOffice, Google Docs, Apple Pages and more.

and "[[" is the same one as used by tens of thousands of wikipedia editors.
it's not even "a thing of the past" - source editor remains the only editor in many name spaces, and is still available in _all_ of them.

pissing on your user base is not a good way to handle software projects.

peace.
If you want an "accelerator key" for making links, use the standard one: Ctrl + K (or Cmd + K if you're on a Mac). This is the same shortcut as in Microsoft Word, OpenOffice, Google Docs, Apple Pages and more.
**turingt** wrote:

For what it's worth, I find that "[[" is a very good accelerator key - mainly because it's already known and remembered by a huge portion of your user base, myself included.

And Erik, wikitext is still awesome today - it's the only known way to allow users to create semantic-enhanced content. The VisualEditor is good for laying out formatted text on a page, but the relations between concepts placed at different pages are better created by adding tags (links, categories, templates...) to the content. The current VE interface mostly hides those tags and requires handling complex dialogs to introduce or edit them, which makes it less convenient for introducing semantics than wikitext. That's why people is requesting smoother and seamless ways to switch between the VE and the source editor.
based on:

bug 51554
bug 51944
bug 51462
bug 50527

and a dozen or so more (as seen here:
https://bugzilla.wikimedia.org/buglist.cgi?query_format=specific&order=relevance%20desc&bug_status=__open__&product=VisualEditor&content=nowiki&list_id=219956


i changed this one to "reopen" and marked it "high".

peace.
*** Bug 51897 has been marked as a duplicate of this bug. ***
**nrp** wrote:

WTG guys, piss off the user base even more with a WONTFIX on a no-brainer...
Marking as WONTFIX per my earlier comments and Erik's.
Indeed, I think we should close this as WONTFIX. We should improve any efficiency or discoverability issues in VisualEditor, and help give users experienced with wikitext clues to not accidentally insert it in VisualEditor. See bug 50601 for one potential approach to the latter problem.

Wiki markup was an awesome in invention in 1995, helping users not have to type HTML in order to format documents. But that doesn't mean the most efficient conceivable user experience in 2013 ought to be bound to the same design principles. (Nor should we blindly copy existing point and click interfaces -- for navigating the complexity of templates and such, we may have to come with some truly novel interfaces.)
(In reply to comment #7)
> (In reply to comment #6)
> > > (2) it requires the use of a mouse to add a link. :-(
> > 
> > Not true, as discussed; I don't use the mouse to add links with VE (Ctrl+K
> > plus keyboard-based selection, as in other editors).
> 
> Ah, right. I vaguely remember that cmd-K controls the hyperlink functionality
> in Microsoft Office products. I have no idea how anyone would glean this from
> VisualEditor.

Hover over the button; the tooltip tells you the keyboard shortcut. :-)
(In reply to comment #6)
>> (2) it requires the use of a mouse to add a link. :-(
> 
> Not true, as discussed; I don't use the mouse to add links with VE (Ctrl+K
> plus keyboard-based selection, as in other editors).

Ah, right. I vaguely remember that cmd-K controls the hyperlink functionality in Microsoft Office products. I have no idea how anyone would glean this from VisualEditor.
(In reply to comment #5)
> (In reply to comment #4)
> > I'm ambivalent about whether we would ever let this go live, given how
> > complicated it would make editing for people that don't know wikitext -
> > consequently, marking as lowest priority for now.
> 
> You and I discussed this idea at some point (thanks for filing this as a bug,
> Oliver). The current issues I'm seeing with VisualEditor are that:
> 
> (1) it's much more time-consuming to add a link (i.e., typing "[[]]" is quick
> while finding and using the link dialog box is slow, especially multiple
> times); and
> 
> (2) it requires the use of a mouse to add a link. :-(

Not true, as discussed; I don't use the mouse to add links with VE (Ctrl+K plus keyboard-based selection, as in other editors).

> Perhaps we need a "I'm old school" checkbox somewhere in VisualEditor. ;-)

If users are sufficiently new-school that they can't remember Ctrl+K I don't think there's much hope for them. :-)
(In reply to comment #4)
> I'm ambivalent about whether we would ever let this go live, given how
> complicated it would make editing for people that don't know wikitext -
> consequently, marking as lowest priority for now.

You and I discussed this idea at some point (thanks for filing this as a bug, Oliver). The current issues I'm seeing with VisualEditor are that:

(1) it's much more time-consuming to add a link (i.e., typing "[[]]" is quick while finding and using the link dialog box is slow, especially multiple times); and

(2) it requires the use of a mouse to add a link. :-(

Adjusting VisualEditor to interpret [[]] as a link would be a nice enhancement, though I see the danger in heading down this road.

Perhaps we need a "I'm old school" checkbox somewhere in VisualEditor. ;-)
I'm ambivalent about whether we would ever let this go live, given how complicated it would make editing for people that don't know wikitext - consequently, marking as lowest priority for now.
Another possibility I mentioned in bug 49820 is to display a warning of some sorts to remind people that wikicode isn't supported (similar to how LiquidThreads reminds users who insert ~~~~ that their signature will be automatically inserted). Automagical conversion might be better, but a warning could be a good first step.
Sorry, just clarifying, this wasn't intended to happen "on save". This should probably happen as soon as (e.g.) the ]] is typed after a link, à la AutoCorrect.
(In reply to comment #0)
> a user has suggested

This was me. Here's my comment from [[Wikipedia:VisualEditor/Feedback]]:

> If you look through many of the comments on this page (in some cases you 
> need to read between the lines), you will see that people are trying to 
> create a wikilink in VisualEditor using [[ ]] wikitext syntax. I am 
> suggesting that, to accommodate these users, a sort of autocorrect be 
> implemented, so that when [[ ]] links are entered, they are automagically 
> converted into proper VE-style links

As well as a helpful "transition" feature from wikitext to VE, it might also be useful in the long run as a shortcut for power users, since keystrokes are generally faster than mouse interaction.

Probably a lower priority enhancement though :)
On Swedish Wikipedia, we have quite a few bot generated articles (some hundreds of thousands) like this one: https://sv.wikipedia.org/wiki/Macrothemis_ultima

When in editing mode, somehow the first line of text cannot be edited. 

If an article has a second line, it is possible to edit that one (but still not the first line), e.g. https://sv.wikipedia.org/wiki/Lepidosaphes_lithocarpi

--------------------------
**Version**: unspecified
**Severity**: normal
Sorry for the disruption; glad we fixed it for you.
No, I cannot reproduce it anymore. The update must have taken care of it!
I cannot reproduce this, but we did just update production to the latest code - do you still get this effect?

If so, what browser/OS are you using? Is it possible to do a quick screencast video of how it doesn't work, and attach it to this bug? Thanks!
[From bug 48429 comment 18]

| It would be ideal to have section-edit links for [edit] and [edit source].
| ie.
|   Sandbox [edit]
| replaced with:
|   Sandbox [edit] [edit source]
| 
| I believe this would prevent a LOT of complaints in the short term, and it
| would permit a lot of us to continue being active beta testers
| (section-editing is my most frequent type of edit), that it should be High
| priority, if at all possible. Thanks.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48429
https://bugzilla.wikimedia.org/show_bug.cgi?id=49621
https://bugzilla.wikimedia.org/show_bug.cgi?id=47779
https://bugzilla.wikimedia.org/show_bug.cgi?id=56337
This matter is fixed. If you want to suggest additional/alternative implementations, please open a new feature request, not re-open a closed one.
Edit and edit source links so confusing I had to disable Visual Editor in preferences today. So you have lost another beta tester. A good one too since I have written many comments and bug reports about VE here and on the Wikipedia feedback page.

I disabled Visual Editor (VE) in preferences today due to constantly clicking the "edit" link instead of the "edit source" link. I am talking about section editing.

The source editing link only shows up after unintuitively mousing over the edit link and so I am constantly clicking the wrong link. 

I almost always prefer editing with the source editor since I make frequent edits to tables, images, navboxes, templates, and reference formatting. All at a deep level of formatting, placement, refactoring, etc.. I am very fast in the source editor, and VE only edits partially and poorly at deeper levels, if at all.  

It would be better to use an icon for the "edit source" links for sections. For ideas:
*[[commons:User:Timeshifter/Sandbox 10]]
*[[commons:Category:Square brackets]]
*[[commons:Category:MediaWiki brackets]]

"edit source" can show up after mousing over the icon. That is much more intuitive. I did not notice the "edit source" link at all for awhile, since I was rapidly clicking the edit link. 

This could drive away many editors. Anonymous editors especially. They have no ability to fix the problem by turning off visual editor in preferences. Many anonymous editors just do not like to log in, and are very used to editing in source editor. Some will be very irritated by the confusing clicking and mousing, just like me.
**swalling** wrote:

(In reply to comment #22)
> I was doing my volunteering editing at http://ca.wikipedia.org when all of a
> sudden I realized the new section double-editing links... 
> 
> Well done! I'm glad about everything I said against them, but it is true that
> I'm also glad about your implementation. A good bridge indeed.


+1. If we have to live with both edit/edit source for now, this is a pretty elegant implementation.
Huge thanks. This looks and acts wonderfully.  A good mix of minimal-visuals and maximal-options. Much <3
I was doing my volunteering editing at http://ca.wikipedia.org when all of a sudden I realized the new section double-editing links... 

Well done! I'm glad about everything I said against them, but it is true that I'm also glad about your implementation. A good bridge indeed.
This was done in gerrit 69984 which is now merged and will go out this afternoon. Thanks, MatmaRex!
*** Bug 49950 has been marked as a duplicate of this bug. ***
Edit. Edit source [[]].

Edit. [[]].

-----------------

Edit source [[]]. - At the top of the page. This should be one link covering both the text and the icon. 

That way people are introduced to the shortcut icon for "edit source". One possibility: [[]]

Headers will have just the shortcut icon link for "edit source": [[]]

Some possibilities for the icon are found here:
*[[commons:User:Timeshifter/Sandbox 10]]

The graphics lab can quickly produce different icons and variations: 
*[[Wikipedia:Graphics Lab]]
*[[Wikipedia:Graphics Lab/Illustration workshop]]
Using an arrow is unintuitive and confusing (no indication what the arrow is actually for; can cause the user to expect the word next to it to be the label for the dropdown, not a separate option entirely especially given the way such arrows operate elsewhere in the skin; results in an extra step/click for something that really might as well be right there; etc). Also doesn't make sense when there are only two options anyway. Just do what James said at the beginning and put in two links.

Later they can stick the edit source option into a tab or something in VE itself, but for now there is no reason to overcomplicate things elsewhere. 

Good:

Sandbox [edit] [edit source]
(In reply to comment #7)
> (In reply to comment #6)
> > I like this idea.  It would be nice if it worked for at least Monobook (in
> > addition to Vector).
> 
> Completely agree. Not sure quite whether this treatment is suitable for
> Monobook or whether we should invent a different one there?

The section edit links look the same in all skins, this shouldn't look bad. Monobook already has some Vector-y bits tacked on top and this would be just a small icon.


(In reply to comment #10)
> There are also a lot of section edits on most large articles, sometimes in
> close succession. I think we should be really cautious about enabling
> multi-level controls and options on something this ubiquitous on a single
> page.

I'm afraid this doesn't support your argument :)

Only showing one link will prevent users from editing sections of wikitext until they learn to disable the option (or just disable VE entirely), which has been my point all along. Wikitext section editing is the "default" mode of operation for many users (at a quick glance at recent changes, around 30-50% of en.wp edits are section edits) and it'd be awful for VE to make it unaccessible.
I like these bracket icons for the edit source links on headers: 
[[commons:User:Timeshifter/Sandbox 10]]
(In reply to comment #14)
> The only other short options would be [edit (source)] or [edit (code)], but
> they're not perfect.

The main problem with that route (which I should have listed, sorry) is that though "Edit (source)" works OK in English, it's not a safe expectation for non-English languages to be able to split the actions into two call-to-action labels, one of which is a left sub-string of the first, sadly. Also, it's a bit clunky.
I agree with James and Matthew on this. 

A preferences toggle, is for things you want to change permanently. 

Whereas this is an instance where I might use VE-section-edit, and use source-section-edit, many times each day, for many months to come.

I really like the arrow-dropdown idea. The cog idea is also good, but would be my second choice. 

The only other short options would be [edit (source)] or [edit (code)], but they're not perfect.
(In reply to comment #11)
> (In reply to comment #8)
> > Personally I think one of these two are the only viable options. The dropdown
> > arrow or cog is too much unnecessary choice.
> 
> I was assuming if you just click 'edit', it would do the same thing as
> clicking 'edit' up top (i.e. VE for those users with VE enabled).  Only if 
> you click the arrow would you see the choice.

Yes, that's exactly our plan - sorry if this wasn't clear. It's available, but not intrusive, and if you click the word "edit" link you'll end up in VE at that section.
(In reply to comment #11)
> I was assuming if you just click 'edit', it would do the same thing as
> clicking 'edit' up top (i.e. VE for those users with VE enabled).  Only if you 
> click the arrow would you see the choice.

If we do want to avoid the drop-down for non-power users, one idea is to have the preference be like this (possible default shown)

[✓] Show VisualEditor section link
[ ] Show wikitext section link

You could check either, both (in which case you get some control for choosing, possibly the drop-down), or neither (no section links, which is already an option).
(In reply to comment #8)
> Personally I think one of these two are the only viable options. The dropdown
> arrow or cog is too much unnecessary choice.

I was assuming if you just click 'edit', it would do the same thing as clicking 'edit' up top (i.e. VE for those users with VE enabled).  Only if you click the arrow would you see the choice.

> Most new editors will appreciate defaulting to VE, and
> for power users who need edit source, this is where having a preference to 
> change your default to edit source would come in handy (a preference I am 
> guessing would free us up to also move "Edit source" at the top of the page in 
> to a dropdown).

As a power user, I agree with James.  Having both available on every section greatly increases the odds I'll continue to test VE when possible (and report bugs), while using wikitext when I know I have to.  Having power users opt out for all VE section edits is not conducive to that.
(In reply to comment #8)
> > * "[edit]" going to one place unless you've got a preference in which case it
> > goes to another is… confusing
> > 
> > * "[edit]" OR "[edit source]" if you've got a preference is a bit messy, but
> > not that bad
> 
> Personally I think one of these two are the only viable options. The dropdown
> arrow or cog is too much unnecessary choice. The point of section edit links
> is to enable speedy editing of single sections, so introducing a dropdown is
> overloading things. Most new editors will appreciate defaulting to VE, and
> for power users who need edit source, this is where having a preference to
> change your default to edit source would come in handy (a preference I am
> guessing would free us up to also move "Edit source" at the top of the page in
> to a dropdown).

I disagree. I would say that, as an axiom, preferences are bad; they add complexity for coders (expensive), bug testers (irritating) and most importantly users (alienating).

In this case, we would also lose momentum as many power users might early-on opt out of VisualEditor for section edits, and so never use it as much as we'd hope. We would lose their input, their bug reports and most importantly their enculturation for new users of this being the 'right' way to edit. We don't want another Vector roll-out disaster on our hands; ever day that Monobook remains on the servers is another notch on that failure yardstick. :-(
**swalling** wrote:


> * "[edit]" going to one place unless you've got a preference in which case it
> goes to another is… confusing
> 
> * "[edit]" OR "[edit source]" if you've got a preference is a bit messy, but
> not that bad

Personally I think one of these two are the only viable options. The dropdown arrow or cog is too much unnecessary choice. The point of section edit links is to enable speedy editing of single sections, so introducing a dropdown is overloading things. Most new editors will appreciate defaulting to VE, and for power users who need edit source, this is where having a preference to change your default to edit source would come in handy (a preference I am guessing would free us up to also move "Edit source" at the top of the page in to a dropdown).
(In reply to comment #6)
> I like this idea.  It would be nice if it worked for at least Monobook (in
> addition to Vector).

Completely agree. Not sure quite whether this treatment is suitable for Monobook or whether we should invent a different one there?
I like this idea.  It would be nice if it worked for at least Monobook (in addition to Vector).
Having discussed, we think we've found a design that's consistent with other usage: instead of having "[edit | edit source]" or "[edit ⚙]", we will have "[edit ▾]" with the down-arrow expanding to a menu (in the same way that Vector does) for "edit source"). This is still easily accessible for users and open for all users, not just those with a preference, but does not take lots of screen estate (problem with the first possibility), and is easily discoverable (second possibility).
(In reply to comment #3)
> I like "[edit ⚙]" more - what do you think? MatmaRex discussed this with me
> last night.

So if you click 'edit', it always goes to VE, and if you click ⚙ (first time I saw the 'gear' character, but good usage), it always goes to wikitext?

That seems reasonable if the wikitext target is big enough that it's not frustrating to click.
(In reply to comment #2)
> There is much discussion at bug 48429 about the need for both types of edit
> links on every header. 
> 
> What might also work is an "edit" link (for VisualEditor) and an icon that
> when
> clicked will take one to the source editor for that section. The icon would
> have a popup tooltip that says "edit source". It would show up when the mouse
> cursor is run over the icon.

My concern with this area is three fold:

* "[edit] [edit source]" is a huge amount of extra chrome/clutter to enable for all users

* "[edit]" going to one place unless you've got a preference in which case it goes to another is… confusing

* "[edit]" OR "[edit source]" if you've got a preference is a bit messy, but not that bad

I like "[edit ⚙]" more - what do you think? MatmaRex discussed this with me last night.
There is much discussion at bug 48429 about the need for both types of edit links on every header. 

What might also work is an "edit" link (for VisualEditor) and an icon that when clicked will take one to the source editor for that section. The icon would have a popup tooltip that says "edit source". It would show up when the mouse cursor is run over the icon.
See comment 23 and 24, at Bug 48429 wherein Bartosz Dziewoński has submitted a patch to Gerrit.

("https://gerrit.wikimedia.org/r/68868 (Gerrit Change
I13bbb9549c999bb7301bbcf530706a813184425d)")

If his patch isn't accepted, then I would again urge High Priority for an alternative fix.
In general, "everything" is allowed (text; annotations; inline and block images; headings; lists; HTML blocks; entities; transclusions; references; etc.), except for:

Image captions
-> No lists

References
-> No references (but transclusions of {{#tag:ref|text}} get around this for one level as an out ref; eww)

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50459
This was completed by the toolbar re-write that was merged for the 12 September release; moving bug 50459 from a blocker (which was wrong anyway) to a see-also.
The references dialog has no references button already. Not sure about image captions as their broken on my local copy, but the code is there to specify the toolbar for each dialog.
Re references: yeah, that struck me as highly likely to confuse people (and highly unnecessary) when I saw it.
Examples for captions:

https://www.mediawiki.org/wiki/VisualEditor:TestImageCaptions

Examples for references:

https://www.mediawiki.org/wiki/VisualEditor:TestReferenceContents
From bug 49602 comment 0:

| The VisualEditor edit tag (Tag: VisualEditor) should show on diffs, too.
| This will probably require a core change.  However, I'm filing it here, both
| so you're aware of it, and because it might need to be configurable (it might
| be we don't want all tags, such as AbuseFilter, etc. to show on diffs).

This is said request for a core change for this to be possible. :-)

--------------------------
**Version**: 1.22.0
**Severity**: enhancement
%%%*** This bug has been marked as a duplicate of bug 25824 ***%%%
https://en.wikipedia.org/wiki/User:%C3%8F%C2%BF%C2%BD?veaction=edit

If a template has no output (such as <https://en.wikipedia.org/wiki/Template:Lowercase_title>), it has no visible output and becomes very easy to silently remove using VisualEditor.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49667
(In reply to comment #2)
> Is this the same as bug 49806? (I know that's newer but it has a lot more
> discussion)

It is indeed; merged.

*** This bug has been marked as a duplicate of bug 49806 ***
Is this the same as bug 49806? (I know that's newer but it has a lot more discussion)
I don't see how this is an enhancement request. It's trivial to accidentally remove a template that has no output, resulting in damage to the page (irreversible damage in the context of using only VisualEditor).
https://en.wikipedia.org/wiki/Digital_Forensics_XML?veaction=edit

I went there, I changed a header from h3 to h2 by selecting the header and using the drop-down menu. When I click "Page settings" and then close the dialog box without making any changes, my change to the header is inexplicably lost.

--------------------------
**Version**: unspecified
**Severity**: normal
Merged and will go out with wmf8.
Related URL: https://gerrit.wikimedia.org/r/69316 (Gerrit Change Ieb2e9e361afe057af93c4d374acc85df58bfb4c3)
Not quite, it's just doing it without checking if a new breakpoint was actually added.
This looks like the code to "undo changes made in the dialog when they don't apply them" is doing that once too often.
If there are 2 blank lines (line breaks) then the paragraph immediately after is uneditable (green striped overlay).

Confirm here: http://en.wikipedia.org/w/index.php?title=User:Quiddity/sandbox&oldid=560048320

and see thread here: http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Paragraph_editing_disabled.3F.3F.3F

--------------------------
**Version**: unspecified
**Severity**: major
This now works; you won't get blank lines causing the next line to be unable to be edited. Thanks for the bug report!
This (and similar issues if you have an HTML comment on a paragraph double-line  before some content) is caused by bug 47403; I won't mark this as a duplicate of that one because we're still trying to get a comment as to what will break in VE if Parsoid reverts the hack that causes this.
VisualEditor should display HTML comments, which are often used as notes or warnings to other editors.  It would be nice if they were editable too.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49608
https://bugzilla.wikimedia.org/show_bug.cgi?id=46440
https://bugzilla.wikimedia.org/show_bug.cgi?id=49806
https://bugzilla.wikimedia.org/show_bug.cgi?id=53659
Change 140773 merged by jenkins-bot:
[BREAKING CHANGE] Show comments inline to the user

https://gerrit.wikimedia.org/r/140773
Change 140773 had a related patch set uploaded by Jforrester:
[WIP] Show comments inline to the user

https://gerrit.wikimedia.org/r/140773
*** Bug 52036 has been marked as a duplicate of this bug. ***
*** Bug 51732 has been marked as a duplicate of this bug. ***
(And of course, this means comments can not be easily deleted right now, in case they display obsolete information, for example.)
It should go without saying, but another consequence of this, beyond the comment being ignored, is that it can easily be misplaced, ending up in places where it does not belong and it does not make much sense, as user:Fram points out at en.wp today.
I've just discovered that, at present at least, <!-- blah --> does not get nowikied so html comments are creatable in VE but not visible once saved so this functionality really very useful yet.
Other HTML tags do get nowikied so this behaviour may subsequently change - see [[Wikipedia:VisualEditor/Feedback#HTML comments not nowikied - should they be?]]
Like Pam I think it is best that these notices are visible and in-your-face so there is no doubt that you have seen them. Hover also causes issues on touch screen devices I think.

One thing that would be possible would be for there to be an icon associated with the comment that collapsed it to get a more WYSIWYG view (and then expanded it again on a subsequent click). The default display would be shown. I guess that custom css/js to have them hidden by default would be possible if people wanted, but I don't suggest the devs do anything other than make it possible for users to write this. I don't know how difficult any of this would be to program though.

On the issue of rendering, I know that some comments contain links, for example from [[Patrick Stewart]]: <!--Do not change this to KBE, see [[Knight Bachelor]]-->
Obviously this is shown like any other link in the source editor, but it makes it clear that it is a link to an article and people with navpopups can select it and get a preview of the link. If VE could parse links (and I guess external links) then that would be a nice to have.
(In reply to comment #18)
> In terms of isolating hidden (aka "invisible") comments, the logic is pretty
> much the same as for templates, except easier: look for <!-- as the left
> boundary, then look for --> as the right boundary. Treat the result as a
> block that can be deleted or moved.

The parsing part is solved.  Comments are already preserved (as HTML comments) in the Parsoid DOM.
resetting priority to high. I didn't intend to change it and didn't realise I had, sorry.
John Broughton suggests as a first step that hidden comments could very easily be made visible but not editable. He suggests putting the comments in a different colour, possibly white on black, to distinguish them from regular content.

Obviously being able to edit hidden comments is needed functionality too, but that is less urgent than displaying them.
It has been reported on en.wp today that a user of VE was:
[..] continually making changes to articles contrary to comments in the wikisource (''two examples of such comments being "<!-- DO NOT CHANGE THIS NATIONALITY WITHOUT DISCUSSION ON TALK PAGE -->"  and "<!-- This is, as Wikipedia guidelines suggest, as he self-identifies and by long-term consensus -->")

This bug is already marked as high priority and has been for over 2 months. It really needs to be fixed before much longer.
**ignatzmice.wiki** wrote:

Bump. https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=567981801
Another example: http://en.wikipedia.org/w/index.php?title=Jacques_Lacan&diff=566246717&oldid=561090875 We are getting multiple reports about this specific issue, so thanks for your attention on this.
Example of edit where displaying the hidden comment would have been very useful (because the edit goes against what is stated in the comment) :
http://en.wikipedia.org/w/index.php?title=List_of_English-language_book_publishing_companies&curid=746089&diff=564359255&oldid=563535930
Is there any progress or movement on this? Specifically, will hidden comments at least be displayed by the Monday deployment?
(In reply to comment #9)
> (In reply to comment #8)
> > I don't think it was officially decided.  Most likely, it will be wikitext
> > first, but that could change if the VE API is ready.
> 
> I don't know what you mean by "the VE API", let alone it being "ready". :-)
> 
> We negotiate with people to build whatever hooks they need (and we felt were
> justified) in the normal way. However, a commenting system like this feels
> more like core VE work than a plugin

Okay, based on that, I think it makes sense not to use VE for the inline comment prototype.
(In reply to comment #8)
> I don't think it was officially decided.  Most likely, it will be wikitext
> first, but that could change if the VE API is ready.

I don't know what you mean by "the VE API", let alone it being "ready". :-)

We negotiate with people to build whatever hooks they need (and we felt were justified) in the normal way. However, a commenting system like this feels more like core VE work than a plugin (so it wouldn't be a matter of hooks available for code in general); it'd sit well with the planned real-time collaborative editing functionality we're building in the new financial year, for which a chat/comment-like tool would be wanted.
I don't think it was officially decided.  Most likely, it will be wikitext first, but that could change if the VE API is ready.
(In reply to comment #6)
> (In reply to comment #5)
> >The second phase might be postponed indefinitely if the "co-ment" work comes to something. A treatment for in-line comments will be needed; possibly just a span of some kind. Will look at this.
> 
> I'm mentoring that (along with Tyler).  I don't think Richa's looked yet at
> integrating with VE.  But it's still early. If you think the VE API is mature
> enough that it integration is feasible, you can suggest that at bug 46440.

I know - see your own comment at bug 46440 comment 13 :-) - but I thought that the proposal was to build this for wikitext editor and then we'd take on porting it over to VE once it was done?
(In reply to comment #5)
>The second phase might be postponed indefinitely if the "co-ment" work comes to something. A treatment for in-line comments will be needed; possibly just a span of some kind. Will look at this.

I'm mentoring that (along with Tyler).  I don't think Richa's looked yet at integrating with VE.  But it's still early. If you think the VE API is mature enough that it integration is feasible, you can suggest that at bug 46440.
(In reply to comment #4)
> Quiddity, yeah, I know, I just filed that (bug 49608).

For clarity, that's a problem with HTML comments in transclusions rather than in general, which does still work. Sorry. :-(

We'd probably need to do this enhancement in stages - first, show comments and let them be deleted; later, make them editable and creatable. The second phase might be postponed indefinitely if the "co-ment" work comes to something. A treatment for in-line comments will be needed; possibly just a span of some kind. Will look at this.
Quiddity, yeah, I know, I just filed that (bug 49608).
That bug isn't fixed then (or was re-broken), because Hidden Comments are being deleted when we save.

(This problem is now worse, because it is now only noticeable if we opt to "Review your changes" before saving.)

See http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox
and test with adding text anywhere in the article http://en.wikipedia.org/wiki/Bleak_House for example. It always removes the comments from the infobox.

There are additional threads on that page mentioning the same thing.
I don't think so.  That one's just about preventing them from being silently removed on save.  This is about actually displaying them to the editor.
I think this is a duplicate of Bug 42124 ?

It doesn't specifically mention HTML or Hidden, so I'm not positive.
VisualEditor caused this dirty diff (https://en.wikipedia.org/w/index.php?title=List_of_South_Korean_idol_groups_%282010s%29&diff=559356009&oldid=559228059) when editing a table.  Note the removal of the empty small elements, and the change to the align syntax.

--------------------------
**Version**: unspecified
**Severity**: major
(In reply to comment #0)
> VisualEditor caused this dirty diff
> (https://en.wikipedia.org/w/index.
> php?title=List_of_South_Korean_idol_groups_%282010s%29&diff=559356009&oldid=5
> 59228059)
> when editing a table.  Note the removal of the empty small elements, and the
> change to the align syntax.

The removal of empty text annotations has been fixed as of wmf7 (gerrit 68213 and gerrit 68190), which is now deployed a week early on enwiki to fix this and other issues - sorry about that. This will stop "the removal of the empty small elements", and consequently the changes to the table syntax that Parsoid does on lines that aren't otherwise changed.

The non-semantic syntactical change of the HTML syntax is, I believe intentionally  done by Parsoid to normalise the wikitext; it is only done on lines of wikitext that are changed anyway by user action (unless there's a bug in VisualEditor which causes the contents of the HTML to change unexpectedly, as was the case here).

Consequently marking as "fixed".
Per Roan - "we were initially going to use this for references and captions, and then chose to use separate documents instead, but this is not compatible with the collaborative editing work; a VE instance should be able to collaborate with another instance on the same page, although I suppose there was some stuff about limiting the scope successfully as well".

--------------------------
**Version**: unspecified
**Severity**: enhancement
Instead we're going to go with sub-documents directly.
Clicking the section edit link into VE has three minor issues:

* The cursor is positioned at the start of the heading of that section; it should probably go to the start of the next element straight after the section (in most cases, a paragraph)
* The page doesn't actually scroll to the correct area; ideally the page should be deliberately scrolled to that section (as it happens, you normally end up on roughly the right part because the page is already scrolled, but there are cases where VE pages are lengthier or shorter than PHP pages and so this can't be relied upon).
* The toolbar only appears once you scroll (because it's triggered on page movement, and the page doesn't move at first to get to the section because it's already there) - this means that it suddenly pops into view a bit too late.

--------------------------
**Version**: unspecified
**Severity**: normal
Both changes merged, so marking as fixed.
#3 in your list is fixed by #2
^^^ Moves cursor to next non-heading
Related URL: https://gerrit.wikimedia.org/r/70238 (Gerrit Change I6fcc463aeeae40278f5caf04ae251c8ecfe65472)
^^^ Fixes scroll
Related URL: https://gerrit.wikimedia.org/r/70229 (Gerrit Change I3a57e64f54289a3263814b4fbfe00c63de4a490b)
We have plans to use ResourceLoader which will fix a lot of this, but noting it here.

Most obviously, the toolbar has two sections which in LRT appear as ABCDE  1234; in RTL they should be 4321  EDCBA, but instead appear as EDCBA  4321. Also issues in dialogs etc.

--------------------------
**Version**: unspecified
**Severity**: major
(In reply to comment #2)
> This is fixed in general by the introduction of Roan and Trevor's css-frame
> fixes, and the popup menu fixes (in TextMenuWidget) - and I think that the
> rest would likely result in spot-fixes, like the ones with the transclusion
> editor.
> 
> Also, as far as I could see, the toolbar bug was fixed as well.
> 
> I think we can close this bug and rely on the main BIDI/RTL tracking bug to
> continue work on any individual bugs as they happen.

OK, done.
This is fixed in general by the introduction of Roan and Trevor's css-frame fixes, and the popup menu fixes (in TextMenuWidget) - and I think that the rest would likely result in spot-fixes, like the ones with the transclusion editor.

Also, as far as I could see, the toolbar bug was fixed as well.

I think we can close this bug and rely on the main BIDI/RTL tracking bug to continue work on any individual bugs as they happen.
I went through the Link Inspector CSS issue and it gave me an insight into what may be happening here. 

Using CSSJanus will probably help 90% of this problem, but it might not completely solve it. A lot of the position settings are inline, calculated dynamically and inserted into the element itself. I'm not entirely sure CSSJanus knows how to deal with those. We may have to split the calculation up into RTL and LTR positions, or find some other solution to the popups that are calculated dynamically.
This is a particular problem with 'note' sections, and references used as notes; they commonly include citations for their statements, and you end up with markup that looks like <ref> some text here <ref> a citation for that text</ref></ref>

The VE is for some reason displaying it as a citation template, "some text here", a second citation template and a random </ref> tag. See note 1 in https://en.wikipedia.org/wiki/Fomitiporia_ellipsoidea for example.

--------------------------
**Version**: unspecified
**Severity**: normal
This is now "fixed" (but we may want to make it a nicer experience in the future).
This is because Parsoid doesn't support the "#tag:ref" hack to let you do multi-level references (which were explicitly not allowed because of the insanity this creates :-)).

Creating a secondary bug (VE currently assumes you can't have nested references, which is indeed what Parsoid gives us), bug 49555. Once Parsoid supports this, we'll need to check that we correctly handle this from a UX perspective (amongst other things).
See https://upload.wikimedia.org/wikipedia/en/8/8f/Visual_editor_pulldown_menu_problem.png

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed in the re-write of the toolbar two weeks ago; sorry for not updating until now.
(In IE9, I'd note).
Have a link [[Foo]] which is a redirect to [[Foobar]].

Inspect link; it will suggest:

New pages
  Foo
Existing pages
  Foobar

This is because "Foo" does not come back in the list of pages you can link to - which is filtered to remove redirects - but we should special-case the existing link.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50240
AFAICT this underlying bug was fixed in October; the issue that MediaWiki's search system sometimes comes back with bad results from time to time (falsely claiming that short titles don't exist) is distinct, as part of bug 54361.
Another couple of examples I found:
I write Indian religion, select the two words and try to add the relevant link; it doesn't recognize the page as an existing redirect, while it lists Indian religions as "matching page".
Same story for Tafkap; in this case, a couple of all caps variants are listed as redirects.
In these cases the "click in the text field" trick didn't work.
There are a bunch of bugs about this, so I'm pretty sure I'm adding my comment to the wrong one :D
Anyway, it is possible that the inspector does not recognize immediately a page as an existing redirect. See https://en.wikipedia.org/wiki/File:VE_wrong_link_state_in_link_editor.png .
https://en.wikipedia.org/wiki/New_York_Kennedy is a valid redirect page.
Unfortunately this is not easy to reproduce. 
(I never managed to do it by just typing New York Kennedy and then wikiling those words, anyway.)
I sometimes managed to reproduce by selecting a completely random word (or even more than one), clicking on the chain icon, writing New York Kennedy in the dialog. Every time though it does correct itself if, after observing the same result from the screenshot above, you click again in the text field, so the page will correctly appear as a blue link listed as a redirect.
James couldn't either so RESOLVED WORKSFORME
I can't reproduce this bug.
Many redirects exist because they respond to expected (simplified) alternative names, plurals, synonyms, non-complete names of people and places, and popular uses in general. It is likely that these popular uses are also used in articles. When selecting a word, the difference between VE recognizing or not these redirects is important:

* If the redirect is recognized and the destination page is shown, most editors will understand the difference and will choose the complete name.

* If the redirect is not shown then you can be a lazy editor and insert the link (having no idea whether it will result in a red or blue link), you can avoid the link altogether just in case, or you can be a good editor (as I try to be), open a new tab, and search that term only to find that many times such term is a known redirect.

Do the latter 20 times in a long article and you will come to this bug report as I did. I found this to be a big nuisance in real editing. (with the side benefit that I tested Cirrus Search more and I even found a bug, thanks to these deviations caused by VE)

PS: or simply show the redirects in italics, as they are already displayed in some MediaWiki lists.
*** Bug 59208 has been marked as a duplicate of this bug. ***
I'd say the desired behavior would be that the link inspector show the existing redirect in different way (such as blue but with a parenthetical note that this is a redirect).

In most cases, the link to the target article is the preferred link choice, but in many cases the redirect is also valid. For cases where the redirect points to a subsection, the redirect is probably the preferred link most of the time.
*** Bug 50274 has been marked as a duplicate of this bug. ***
In my local copy, the redirect URL is not filtered out, but I did notice another bug in that code: https://gerrit.wikimedia.org/r/69871
*** Bug 49540 has been marked as a duplicate of this bug. ***
If someone capitalises a character(see https://en.wikipedia.org/w/index.php?title=Founder_effect&diff=559607253&oldid=558757694 for example) the VisualEditor does not recognise it as an alteration to page text and rejects their edit.

--------------------------
**Version**: unspecified
**Severity**: normal
Filed 53210 for my last comment which I see it now, it was unrelated.
It is actually being reported now on itwp: in order to do this http://it.wikipedia.org/w/index.php?title=DNasi_attivata_da_caspasi&diff=60101664&oldid=60089990 I had to delete the word and link it back again. Our guidelines about style require pages in that section to appear with the capital letter. I'll also add a link to https://bugzilla.wikimedia.org/show_bug.cgi?id=50452 which looks related. Thanks.
Ed's fix on Friday corrected this; sorry for the bug. Now live in production.
Screenshot

See associated screenshot - this is for https://www.mediawiki.org/wiki/Template:Extension

When clicking the inspector icon, the window opens up but remains entirely blank and happily sits there like it for minutes* at a time. More worryingly, if I follow the normal workflow for a broken element (hit the X, make it go away, try and open it again) the inspector refuses to open at all, not just for that template but for other elements on the page.

*I gave up waiting; it may load, eventually, or never load.

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

**Attached**: {F11051}
*** Bug 50016 has been marked as a duplicate of this bug. ***
*** Bug 49958 has been marked as a duplicate of this bug. ***
Related URL: https://gerrit.wikimedia.org/r/69806 (Gerrit Change I0b661744d0388345561897c9631f15e691737031)
*** Bug 49797 has been marked as a duplicate of this bug. ***
*** Bug 49862 has been marked as a duplicate of this bug. ***
I found this as well. Here are the steps to reproduce:

1. Open up [[mw.VisualEditor:Template test]] in edit mode.
2. Click on any template, then click on the icon to open the template inspector.
3. Click on the cross in the top-right-hand corner to close it.
4. Click on the template inspector icon for the same template again. (It appears to still be there from the first time it was clicked.) This time the inspector appears blank.
5. Click on the cross in the top-right-hand corner to close it again.
6. Now, clicking on the template icon for any template on the page will have no effect (i.e. the template inspector doesn't load at all).
Never loads. Trevor, is it selecting the wrong thing, so can't fetch it, or selecting the right thing, but can't fetch it for some other reason?
Screenshot

Screenshot attached - from https://www.mediawiki.org/wiki/Extension:Syntax_Highlighting

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

**Attached**: {F11040}
Marking as fixed.
1. Make a change and press save
2. close the save dialog (^)
3. Press save again

Note there is now a back button (<) which does nothing.

--------------------------
**Version**: unspecified
**Severity**: normal
Related URL: https://gerrit.wikimedia.org/r/70113 (Gerrit Change I297a7d1458e5a1c33b9dcb85272fe5f40893dd88)
From a bug report in /mnt/bugs on parsoid.wmflabs.org.

The edited HTML snippet in question looks like this:

"<a href="./Turkish_sparrow" rel="mw:WikiLink" data-parsoid='{"a":{"href":"./Turkish_sparrow"},"sa":{"href":"Turkish sparrow"},"stx":"simple","dsr":[92,111,2,2]}'><a href="American%20sparrow" rel="mw:WikiLink">American sparrow</a></a>"

The editor may tried to edit a link from Turkish -> American sparrow

--------------------------
**Version**: unspecified
**Severity**: normal
Speculatively marking as fixed; please re-open if it recurs.
I think this is one of the bugs that has been fixed by https://gerrit.wikimedia.org/r/70434
Another instance from /mnt/bugs/2013-06-11T19:33:15.924Z-VPN_blocking (on enwp)

<a rel="mw:WikiLink" href="protocol%20tunnel"><a rel="mw:WikiLink" href="protocol%20tunnellng">protocol tunnell</a></a><a rel="mw:WikiLink" href="protocol%20tunnellng">ing</a>
From: /mnt/bugs/2013-06-10T19:18:14.190Z-Golden-Crowned_Sparrow (editing done on mediawiki.wikimedia.org).
Right now, we have to do the following in ve.ui.MWReferenceDialog and ve.ui.MWMediaDialog to set up the sub-editor's surface correctly:

this.referenceSurface.addCommands( ve.init.mw.ViewPageTarget.static.surfaceCommands );

Instead of accessing ve.init.mw (and assuming all surfaces with MW*Dialogs will be instantiated by ve.init.mw.ViewPageTarget), we should just be able to say "initialize this new surface based on this existing surface".

--------------------------
**Version**: unspecified
**Severity**: enhancement
Not just inherit, but also block from inheritance for specific instantiations (e.g. the caption of an image inside a reference can't take a reference - bug 58270).
Stylesheets should be inherited as well (and be loaded by the surface rather than the dialog) so we don't have to do things like

ve.ui.MWReferenceDialog.static.addLocalStylesheets( [
	've.ce.Node.css',
	've.ce.Surface.css',
	've.ui.Surface.css',
	've.ui.Context.css',
	've.ui.Tool.css',
	've.ui.Toolbar.css'
] );
**Author:** `swalling`

**Description:**
When attempting to remove an entire section with an h2 header, removing the text of the header does not remove the line separator underneath the header. 

Additionally, one additional delete/backspace action deleted the entire preceding section, and it seems from the resulting content that I merely blanked the header but the wikitext for it remains.

--------------------------
**Version**: unspecified
**Severity**: normal
AFAICT this is now fixed - marking as WORKSFORME. Please re-open if it recurs.
Change 70949 had a related patch set uploaded by Inez:
(bug 49424) Add empty lines before/after new block level images

https://gerrit.wikimedia.org/r/70949
Could someone provide step by step instruction how to reproduce this problem?
The latter; my apologies for not reading correctly! :)
The first part of this bug is a duplicate of bug 49452 ("Whitespace-only headings should be collapsed to (blank) paragraphs"), so re-purposing to be about the deletion issue.

@Steven - could you give more details about this bug with deletion magically hiding large blocks of text but not deleting them - was it in Chrome/Mac? Does it happen reliably (and can you reproduce now) or is it occasional?

@Oliver - is the "this" that users have seen the deletion causing a paragraph to no longer appear but still be there, or the heading-not-being-fully-deleted issue?
This has also been reported by other users, and is something I observed in the usertesting videos we did, too.
**swalling** wrote:

Result

Note empty header

**Attached**: {F11801}
**swalling** wrote:

Diff

**Attached**: {F11799}
You can select it but the inspector menu doesn't trigger. Works fine if there's any content before the block.

--------------------------
**Version**: unspecified
**Severity**: normal
Now fixed and will be put into production very soon.
Related URL: https://gerrit.wikimedia.org/r/69707 (Gerrit Change I8bcdea0f7a6951216bf8368865d23ef6246880ea)
Happens if it's a block or floated template, or an inline or floated (thumb) image. Doesn't happen on an inline template or an inline-block template.
Editing a page in a Hebrew wiki (possibly also in other RTL languages), adding a link does not show the popup. The word automatically becomes a wiki-link, no option to change the destination or make it an external link.

The link seems to work well in English wikis.

Tested on both my local install with the latest VE (VE-wmf6+) and on the hebrew wikipedia (VE-wmf5) and on both Firefox and Chrome.

--------------------------
**Version**: unspecified
**Severity**: critical
Change 69281 abandoned by Mooeypoo:
[WIP] Link surface fix for RTL

Reason:
Fixed in master.

https://gerrit.wikimedia.org/r/69281
This works for me and seems to work in the hebrew wikipedia. Can be marked as resolved.
Give Moriel the credit given that she's done all the work on this bug so far - we'll try to get the patch properly reviewed so we can (hopefully?) merge and deploy it very soon.
I've been working on a fix for this but I may need some help with an issue.

The position definition had to be changed in RTL, as it is hard-coded (calculated by the location of the word/selection.) That was completed successfully and the link surface appears correctly below the marked word in both LTR and RTL. 

However, I am running into problems setting up the proper "right" dynamically-calculated value for the sub-popup TextInputMenuWidget, and my attempts to play around with left/right and windowWidths has failed. It appears "almost right" (a little to the left, a little to the right, skewed, etc) and I think I may be missing a property.

I wonder if there is a possibility to get the "right" value of the link surface (that appears correctly) to implement it in the TextInputMenuWidget without having to call the element specifically.

The fix below is still work in progress (Don't Merge!) but it should be completely fixed if I manage to figure out the position of the TextInputMenuWidget.
Related URL: https://gerrit.wikimedia.org/r/69281 (Gerrit Change I312610ca630a8f75f1a0778e97f227f35a003b41)
And the opposite is also true: The inspector is visible in the Hebrew Wikipedia if the interface language is English.
This also happens in the English wikipedia when the user interface is set to any rtl language.

I tested with ?uselang=he ?uselang=ar and ?uselang=fa
Screenshot of VisualEditor on the English Wikipedia

I'm not even really sure how to explain this. I'll just include a screenshot.

I went to <https://en.wikipedia.org/wiki/Ready,_Willing_and_Able_(Daron_Norwood_song)> and clicked "edit this page". This is what appeared.

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

**Attached**: {F11769}
I am assuming this is not an issue any more given that we have had no reports after launch.  The launch should have caused a lot of corruptions if this bug had been around.  Closing.
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
Please let us know if there are any new cases.
Still happening - PamD reports that {{User sandbox}} on enwiki displayed in Japanese and gave the wrong user name (Apparently she's now User:Ichiro Kikuchi). It's stopped, but...worrying.
https://gerrit.wikimedia.org/r/69905 (Gerrit Change I495c294a5dbafadac133c0b377b576d297ca529d) | change APPROVED and MERGED [by jenkins-bot]
Related URL: https://gerrit.wikimedia.org/r/69905 (Gerrit Change I495c294a5dbafadac133c0b377b576d297ca529d)
https://gerrit.wikimedia.org/r/69880 (Gerrit Change I52abbc10e5fe6a6b9d97ef6d842943809c8f6d6d) | change APPROVED and MERGED [by jenkins-bot]
Related URL: https://gerrit.wikimedia.org/r/69880 (Gerrit Change I52abbc10e5fe6a6b9d97ef6d842943809c8f6d6d)
*** Bug 49939 has been marked as a duplicate of this bug. ***
New report: But 49939
Since there are no new reports it seems that this bug has been fixed by our config clean-up. Please reopen if you encounter this bug again.
I think this is now fixed.
*** Bug 49687 has been marked as a duplicate of this bug. ***
We deployed a few clean-ups to our wiki configuration handling recently which might have improved the handling of API errors when retrieving the per-wiki config fails. Has this bug been seen in the wild recently?
We've seen a bunch of reports of content from different wikis showing up, usually German content (plus one case of Russian, and now one of French apparently). Moving this to Parsoid.
Happened for me on pl.wp earlier today, too, with "Vorlage" as well. I didn't make a screenshot and I don't remember the aricle, sorry.
Created attachment 12510
Screenshot of VisualEditor on the English Wikipedia being all weird

"Vorlage"? Blergh.

My suspicion is Parsoid cache pollution.

**Attached**: {F11771}
In attachment 12508, we can see that instead of the templates being shown with a green striped area atop them, there is "Modèle:Infobox Single↵", "﻿Modèle:Lari White↵↵↵↵↵" and "﻿Modèle:1990s-country-song-stub﻿".

I'm not sure what language this is (French, maybe?), but my account is set to use English and the site is supposed to be in English.
Create a document:

Foo <ref>Bar</ref> Baz
<references />

=>

Foo [1] Baz
1. Bar


==Test==
1. Select and copy from '[' to ']' (no whitespace)
2. Try to paste
3. Note you now just have plain text [1]
4. Note also if you make a larger selection (e.g. from 'o' to 'B'), copy/paste works fine.

This might be to do with whitespace truncation, and probably applies to other inline nodes.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52271
https://bugzilla.wikimedia.org/show_bug.cgi?id=54410
No, this was and remains fixed. Test in Chrome or Firefox, for example.
I think this is still occurring (https://it.wikipedia.org/w/index.php?title=Utente%3AElitre_%28WMF%29%2FSandbox&diff=68973564&oldid=68973535 ).
I'm using Safari, and I don't know if this is related to Bug 70143.
Change 83222 merged by jenkins-bot:
The Great [...] Rewrite of 2013: Clipboard edition

https://gerrit.wikimedia.org/r/83222
Change 83222 had a related patch set uploaded by Esanders:
The Great [...] Rewrite of 2013: Clipboard edition

https://gerrit.wikimedia.org/r/83222
This is still broken in FF, see bug 53375
Fixed in master; will be deployed on Thursday as part of the regular push.
Change 80301 merged by jenkins-bot:
Copy-paste data fixes

https://gerrit.wikimedia.org/r/80301
Change 80301 had a related patch set uploaded by Jforrester:
Copy-paste data fixes

https://gerrit.wikimedia.org/r/80301
https://gerrit.wikimedia.org/r/#/c/80301/ fixes
Note this behaviour also occurs with templates
*** Bug 52212 has been marked as a duplicate of this bug. ***
**bi.llybob** wrote:

Note that, at least in Chrome, whitespace is <i>not</t> enough to count as additional text.
*** Bug 50594 has been marked as a duplicate of this bug. ***
On attempting to edit and restore an oldid, everything works fine (oldid contents appear, diff shows correct wikitext change, etc.) but on save VE appears to send the wrong page version (presumably the 'newer' version that's meant to be replaced?) to MW so nothing gets saved.

--------------------------
**Version**: unspecified
**Severity**: critical
Merged and will go out with next deployment.
Related URL: https://gerrit.wikimedia.org/r/69344 (Gerrit Change Icacaa5101386e52309278c8d9871ca1193aa86a9)
Ed is exactly right. EditPage appears to set basetimestamp this way as well.
I can reproduce it. Tellingly, if you make a change and then press save you get an edit conflict. I suspect the problem is we are providing the timestamp of the version you choose to edit as the 'basetimestamp' which I don't think is right. When you hit save the API thinks all the versions ahead of the version you're editing were created since you loaded the page (hence the edit conflict scenario).

I think 'basetimestamp' should always be populated with the timestamp of 'cur', regardless of which version you are editing, but would like confirmation from someone who knows the MW API better.
I can't reproduce this bug. I'll keep the assignment to Ed but it looks like this has been resolved in the mean time.
1. Focus a node which triggers an inspector icon
2. Hit save
3. http://i.imgur.com/5YPyQL5.png

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49275
https://bugzilla.wikimedia.org/show_bug.cgi?id=49059
Merged and will go out later today.
Related URL: https://gerrit.wikimedia.org/r/69614 (Gerrit Change I2fbc4c8af943f1b096b8912191924961405d5c47)
Probably related: http://i.imgur.com/E5SFyv0.png
Because we want to be able to make certain properties non-cloneable, e.g. in ve.dm.MWReferenceNode.prototype.getClonedElement we strip 'contentsUsed'.

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed and will go live in a few minutes.
Change 70913 merged by jenkins-bot:
Invoke getClonedElement() on each element on copy

https://gerrit.wikimedia.org/r/70913
"We should verify..."
We should very that copy/pasting a named reference with contents, doesn't copy the contents.
Change 70913 had a related patch set uploaded by Catrope:
Invoke getClonedElement() on each element on copy

https://gerrit.wikimedia.org/r/70913
Screenshot of VisualEditor on the English Wikipedia using the Monobook skin, 2013-06-06

VisualEditor's review dialog box can be obfuscated by the green striped area from restricted areas of a page. This is when using Monobook, at least. Maybe Vector too, I don't know. I've attached a screenshot.

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

**Attached**: {F11508}
We solved this specific issue as part of the minor re-work of the save dialog, but see bug 50096 and bug 49059.
Yes, this is a mess; phantoms' z-index is higher than the review panel (which is bad), and trigger when the mouse moves over them even though you're in a "different" interface component. This would be solved by switching to the new dialogs (as they're iframes), but we don't have time for that.
*** This bug has been marked as a duplicate of bug 43015 ***
This is odd - I thought this was fixed, but I can reproduce on enwiki but not on MW.org.

I think this may be fixed by the new image code the Inez has written (which is still 'experimental' and so not available in production except for MW.org). Will check with him and update you.
**Author:** `swalling`

**Description:**
Screenshot

In attempting to test (as anon) on the MediaWiki.org sandbox, the page header template overlaps the diff and save functions, preventing me from saving my edit.

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

**Attached**: {F11481}
Merged and will go out later today.
Related URL: https://gerrit.wikimedia.org/r/69614 (Gerrit Change I2fbc4c8af943f1b096b8912191924961405d5c47)
Just a note that this also happens with editable elements like images, as their blue overlay extends on top of the VE menu bar.
Instead of an arms race between z-index, the much easier solution would be to ensure the DOM structure of these two elements are nested properly so that their natural order is correct. z-index can be used to adjust display, but it is not capable (by design) to transcend the relative DOM position.

I haven't tested the following so this exact example could be wrong, but generally it means that in the following sample:

 <div style="position: relative;" id="foo"> </div> 
 <div style="position: relative;" id="bar"> </div> 


Naturally #bar will be on top of #foo as it comes later in the DOM. Though #foo and #bar can be interchanged at the root (through their common parent), any child of #bar will always be on top of any child of #foo.

So not only is DOM ordering easier to manage (due to not having to worry about conflicting numbers), in some cases it is the only way.

I'll see what the easier way to fix this is, we can perfect it later if suboptimal.
And I had a similar issue attempting to save a page with an (uneditable) InfoBox on the right hand side. Luckily a simple workaround for the moment is to scroll down!

Obviously the proper solution is to ensure the zorder of the "Review your changes" and "Save your changes"/"Report a problem" is above the "phantoms".
Whoops, thanks for the spot, Steven!
Necessary for beta rollout. Wording needs to be smithed carefully to ensure that it's clear that this is a temporary option.

--------------------------
**Version**: unspecified
**Severity**: minor
Done and deployed.
Related URL: https://gerrit.wikimedia.org/r/68569 (Gerrit Change I5ce7ea8c1e47e8243b619fc61aa957f767d22b48)
For example in the second line of the multibyte.html test file in the standalone demo (after '<tt>香港</tt>' [Hong Kong])

--------------------------
**Version**: unspecified
**Severity**: normal
Above fixed is merged and will go out with wmf7 from Thursday.
Related URL: https://gerrit.wikimedia.org/r/67971 (Gerrit Change Iff1dfb90130685bb710821f8386cfa2f296f2f95)
Visual Editor doesn't behave correctly when editing and adding text with combining diacritics.

For example insert the text "ɛ́" (ɛ is character U+025B, combining acute is U+0301).
When the cursor is behind "ɛ́":
- pushing the left arrow doesn't move the cursor
- adding text like "ɛ́abcdef" is fine but:
  - pushing backspace gives "ɛ́abcda" instead of expected "ɛ́abcde"
  - pushing return ives "ɛ́abcde\na"

Some languages require combining diacritics, many keyboard layouts allow their input or user can insert them by copying and pasting from somewhere else.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51472
(In reply to comment #10)
> I believe this is related (or a dupe?) of this:
> https://bugzilla.wikimedia.org/show_bug.cgi?id=51472

Related but not a dupe, I think; adding a see-also.
I believe this is related (or a dupe?) of this: https://bugzilla.wikimedia.org/show_bug.cgi?id=51472
Great! It works as it should now.
Thanks a lot!
Now fixed and will be deployed very soon; sorry for this.
Related URL: https://gerrit.wikimedia.org/r/69814 (Gerrit Change If9c0860e2fe7b01eb0b27aae67c671062799a0fa)
Yes, this is still reproduceable on Chrome and Firefox on Ubuntu, Chrome, Firefox and Safari on OS X, Chrome, Firefox, IE on Windows 8.
The steps I tried on http://en.wikipedia.org/wiki/User:ESanders_(WMF)/Sandbox are :
- move cursor to end of "ɛ́abcdef"
- type g
- press return
result: "ɛ́abcdeff" and new line instead of expected "ɛ́abcdefg" and new line.
Denis, can you still reproduce (and if so, where and with what browser/system)?
Can't reproduce in master or live, except for a bug where if I select all then paste an exception is thrown (but that is unrelated).


See:
http://en.wikipedia.org/wiki/User:ESanders_(WMF)/Sandbox
Reopening and assigning.
Yes this is still reproduceable on en.wikipedia.org or fr.wikipedia.org as well as www.mediawiki.org. I guess "on the cluster everywhere as of yesterday" means the bug 48630 is fixed so this is not a duplicate.
Or is there a specific place I should try to reproduce the bug on where this has been fixed?

Quickly looking at bug 48630 it seems the behaviour described here is different, although the solution to 48630 might fix this one, just not the current solution.

Furthermore there are other broken behaviours.
- In some situations the line following "ɛ́" would just be duplicated every unknown time interval until the input cursor is moved.
- If the "ɛ́" is in the middle of a line, some following characters are duplicated each interval with or without the combining diacritic on them.
- If inputing two base characters with each a combining character, an unexpected next line return is produce when finishing the sequence.
- When moving the cursor past the base character with the combining character, the cursor jumps to the next line even if there are still characters on the current (actually now previous) line.
This appears to be a duplicate of an already-fixed bug (bug 48630), which is live on the cluster everywhere as of yesterday. Can you reproduce this now, and if so, on what wiki? Support for graphemes like this is important for us, as you can imagine, and it's worrying to hear that it's not working?

*** This bug has been marked as a duplicate of bug 48630 ***
grey text, no diff appears after Review and save

Seen in IE9 and below, works OK in FF and Chrome: 

Make an edit with VE
Click Review and save

Page text is greyed out; no diff appears; Review and save button remains clickable; user cannot complete edit

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

**Attached**: {F11329}
This is working for me now: I saved https://www.mediawiki.org/w/index.php?title=User:Catrope%2FSandbox&diff=1137641&oldid=740030 in IE10.
*a user
An user reports:
<<I just got a Edit beta tab on The Adventure of the Reigate Squire, even though I'm in IE 10. What's weirder is that this is the only page where I've seen a VE tab. Also, I can't make any edits with it: I changed a few words in one sentence and added an edit summary, but the thing's just hanging there. I got a message of Warning: Your edit may have been corrupted – please review before saving. However, I've been unable to find anything corrupt, even though I reviewed everything that I'd done. Nothing of WP:EF came up, either. 2001:18E8:2:1020:202A:8DD6:6403:B77 (talk) 16:25, 21 August 2013 (UTC)

After several minutes of fruitless waiting, I gave up and reloaded the page. I then tried to add Category:Reigate and Banstead to the article (it's where the story is set), but after typing an edit summary of "Add category", I was forced to see that it's just been hanging there again. 2001:18E8:2:1020:202A:8DD6:6403:B77 (talk) 16:30, 21 August 2013 (UTC) >>

Is this due to some tests or deployment sanity checks? Thanks.
*** Bug 50086 has been marked as a duplicate of this bug. ***
Relabelling; this is a blocker to IE9/10 use.
IE10 exhibits the same behaviour.
Related URL: https://gerrit.wikimedia.org/r/70108 (Gerrit Change I2ee2e33c89cac58863c9911fc3ad250c72a46206)
I can consistently reproduce:

* Saving the page results in an uncaught exception "Permissions denied" originating from ve.bind -> $.proxy -> line "proxy = function () { return fn.apply( .."
  Presumably this is caused by IE9 (undocumented?) non-standard security model
  that rejects certain interaction between functions originating from different
  http requests (regardless of the origin, e.g. in this case they're both from
  load.php on the local wiki, no CDN involved)

* Generating a diff ("Review changes") has a silent failure, no notification
  is emitted that allows us to hide the spinner or display an error message.
IE8 and below aren't supported at all (and you shouldn't ever manage to get to use VE with them); assigning.
* Move cursor to start/end of document
* Press left (start) or right (end)
* An exception is thrown by handleLeftOrRightArrowKey

--------------------------
**Version**: unspecified
**Severity**: normal
Apparently fixed by gerrit 66322.
--------------------------
**Version**: unspecified
**Severity**: normal
Related URL: https://gerrit.wikimedia.org/r/68618 (Gerrit Change I1463d06db4900083dd4c565292bbabef09194b43)
It works fine in Chrome, but Firefox does not preserve the order in the attributes array:


>>> var div = document.createElement('div')
undefined
>>> div.innerHTML='<a href="foo" data-parsoid="bar"></a>';
"<a href="foo" data-parsoid="bar"></a>"
>>> div.children[0]
<a data-parsoid="bar" href="foo">
>>> div.children[0].attributes
[data-parsoid="bar", href="foo"]
So that we can correctly calculate boundaries in unicode.wordbreak.js

--------------------------
**Version**: unspecified
**Severity**: major
Basic support added. Leaving open to work on full grapheme boundary detection.
This is fixed in the above commit, which is merged and will go out with wmf6.
Related URL: https://gerrit.wikimedia.org/r/66123 (Gerrit Change I202b98199d2780534d1e02519b72579ba796f08f)
Currently we don't -> lots of broken imagery in /w/index.php etc. entry points.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=59196
Change 90952 merged by jenkins-bot:
Render resolved URLs for href and src attributes in CE

https://gerrit.wikimedia.org/r/90952
Change 86065 merged by jenkins-bot:
Resolve rendered URLs according to the provided <base>

https://gerrit.wikimedia.org/r/86065
Change 90952 had a related patch set uploaded by Catrope:
Render resolved URLs for href and src attributes in CE

https://gerrit.wikimedia.org/r/90952
(In reply to comment #13)
> Change 86065 had a related patch set uploaded by Catrope:
> Resolve rendered URLs according to the provided <base>
> 
> https://gerrit.wikimedia.org/r/86065
This addresses the most common symptoms of this bug. It fixes rendering of link targets for internal links (at least on initial rendering; the href attribute doesn't update correctly when the link is edited), and it fixes href and src attributes of things inside of generated content nodes (templates, mostly).

While the change in Gerrit fixes href/src attribute rendering for uneditable href/src attributes, we still have to do something for models that manage their own href/src and edit it, or generate it from another editable attribute.

ve.dm.LinkAnnotation, ve.dm.MWExternalLinkAnnotation: href attribute is edited directly; in practice MWExternalLinkAnnotation is a full URL and LinkAnnotation isn't used in the MW integration, but we should still fix them.

ve.dm.MWInternalLinkAnnotation: Generates href based on title attribute, which can be edited. Links that came directly from Parsoid now render correctly due to a hack (see bug 51487), but edited links don't render correctly.

ve.dm.ImageNode, ve.dm.MWInlineImageNode, ve.dm.MWBlockImageNode: src attribute is edited directly; in practice, the MW ones use full URLs (the user doesn't edit the src directly, and the UI widget gets full URLs from the API) and ImageNode isn't used in the MW integration, but we should still fix them.

ve.dm.MWCategoryMetaItem, ve.dm.MWLanguageMetaItem: these manage hrefs that can be edited, but they're never rendered and always absolute, so we don't really care
Change 86065 had a related patch set uploaded by Catrope:
Resolve rendered URLs according to the provided <base>

https://gerrit.wikimedia.org/r/86065
*** Bug 53190 has been marked as a duplicate of this bug. ***
Fun fact: this is the most often duped VE bug ever, and it's in the top 30 of most often duped open bugs on our entire bugzilla, alongside classics such as bug 738 or bug 156. https://bugzilla.wikimedia.org/duplicates.cgi
*** Bug 53491 has been marked as a duplicate of this bug. ***
*** Bug 50466 has been marked as a duplicate of this bug. ***
Also reported today at it.wp (this was the result https://it.wikipedia.org/w/Tsonga_%28popolazione%29 ). Thanks.
To hopefully help people find this bug, here is the description from bug 51122 "link targets assumed to be same namespace when opened with ctrl+click" updated to reflect that it now happens with all links, not just those in image captions:

When opening a link from the editing interface using ctrl+click (or "open in a new tab" from the right button menu) the link target is assumed to be in the same namespace as the currently edited page.

For example a link to [[Bridgnorth Cliff Railway]] from the page [[User:Thryduulf/sandbox]] is opened as [[User:Thryduulf/Bridgnorth Cliff Railway]]. A link to [[User:Thryduulf/sandbox2]] on the same page opens [[User:Thryduulf/User%3AThryduulf%2Fsandbox2]]. A link to that sandbox page
from a page in the article namespace opens as [[User%3AThryduulf%2Fsandbox2]], but this does get you to the correct page.
Come on guys, this is "high major" since May.
*** Bug 51122 has been marked as a duplicate of this bug. ***
*** Bug 51585 has been marked as a duplicate of this bug. ***
*** Bug 50764 has been marked as a duplicate of this bug. ***
*** Bug 50216 has been marked as a duplicate of this bug. ***
Timo says we can get the browser to do the resolution by getting the .href and .src properties in the original Parsoid document, so all we need to do is figure out which attributes are affected. I can think of href and src, are there others?
Pressing Ctrl-Backspace deletes a word in a <textarea> in Firefox. It works the same way in VisualEditor when the wiki's language is English, but if it's Hebrew, it only deletes one character.

A GWT testing scenario for this would be something like this:

Given $wgLanguageCode is 'he'
        And I am editing an article
        And I wrote 'אחת שתיים שלוש'
When I press Ctrl-Backspace
Then the remaining text is 'אחת שתיים '

--------------------------
**Version**: unspecified
**Severity**: normal
According to my test, this was fixed, and the behavior is as predicted on my local install. It doesn't work properly in the VE that exists in he.wikipedia, so whatever was done is new.

The fact this works without fixes is incredibly weird, since the handleDelete() function uses offsets, and those are supposed to be opposite between Hebrew and English. I'm checking into potential causes, but as far as I've seen, Inez' re-implemented code works.

Amir, if you can verify this works on your local installation, that'll be helpful. I am a bit concerned about this since it doesn't make sense (it *shouldn't* work) and I am concerned that it doesn't work on he.wiki. I want to verify it isn't some local fluke before we close this bug as resolved.
This will (should?) get fixed when Inez does the re-write of this area, but assigning to Moriel to bug him and make sure he does it right. :-)
Place the cursor at the first position of some heading (before the heading's first character). Hit Enter. As expected, an empty line appears before the heading, but the cursor is unexpectedly advanced by one position and is now located *after* the heading's first character.

--------------------------
**Version**: unspecified
**Severity**: normal
*** Bug 50168 has been marked as a duplicate of this bug. ***
This was fixed and is now deployed.
Open the VisualEditor on the page https://en.wikipedia.org/wiki/Battle_of_Paris_(1814) . The two images are placed side by side between the lead paragraph and the infobox; they should be placed below the infobox. 

It appears that the VisualEditor generally arranges two images horizontally rather than vertically, unlike the wikitext renderer.

--------------------------
**Version**: unspecified
**Severity**: normal
This is now fixed in master and will go live from tomorrow.
*** Bug 49010 has been marked as a duplicate of this bug. ***
This is because we haven't been rewriting the image HTML to be like the normal display mode; this is now done for thumbs (you can see it as experimental code on MediaWiki.org) and mostly done for inline images, and will be deployed next week.
This is to make the categories pane less lonely; we will want to do this 'properly' (writable) later, though this is… challenging given the Wikidata complexities.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Related URL: https://gerrit.wikimedia.org/r/67245 (Gerrit Change I897da1cf06c79ee40e29fb632d09cddb57144ada)
Now merged and will go out with wmf6.
This is being done in gerrit 65432.
This is using Firefox under Ubuntu 13.x:


The problem:
If the wiki is RTL (Hebrew, for instance), start editing an empty page. The caret appears on the left side and the typing is done LTR.


I did a quick check, and noticed that there is a class added to the content box - "ve-ui-surface mw-content-ltr" even when the page language is rtl (defined in the <html dir="rtl"..>

I found this addition in the ve.init.mw.ViewPageTarget line 786:
this.surface.$.addClass( 'mw-content-' + mw.config.get( 'wgVisualEditor' ).pageLanguageDir );

In my system this produced "mw-content-ltr" despite the fact the page language was Hebrew and the html direction was defined as rtl. 

However, I then tried to forcefully change it to rtl, just to test, and while the class appeared correctly (mw-content-rtl), the direction of the typed text was still LTR. It remained LTR when I changed the language to English.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Linux
As agreed.
Select an inline node (e.g. an inline image) on it's own (i.e. no whitespace either side of it), and trying to copy will throw an exception (ve.dm.Document.js:786 selection[0].range is undefined)

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed in master; will be deployed on Thursday as part of the regular push.
Change 80301 merged by jenkins-bot:
Copy-paste data fixes

https://gerrit.wikimedia.org/r/80301
Change 80301 had a related patch set uploaded by Jforrester:
Copy-paste data fixes

https://gerrit.wikimedia.org/r/80301
https://gerrit.wikimedia.org/r/#/c/80301/ fixes
Nope, ignore comment 5, it adds the linebreaks no matter which way the selection is generated. Similar outcome but apparently independent.
The second half of comment 4 might be bug 51538
No exception now, it just fails to copy at all if you select a focusable node.

In what looks like a separate bug, if you select around a focusable node, pasting creates a new paragraph, e.g.

Foo "Bar [1] Baz" Quux

copy range marked with double quotes ([1] is a reference) then paste in the middle of Qu_ux and you get:

Foo Bar [1] Baz Qu
Bar [1] Baz
ux

instead of

Foo Bar [1] Baz QuBar [1] Bazux
I can't reproduce this now in Chrome or Firefox…
@Ed, @Christian: In which browsers are you guys able to confirm it?
**orbit** wrote:

ooh... that's true.
I used VE in Firefox 21.0 on Ubuntu to edit https://www.mediawiki.org/wiki/Backporting_Fixes . I changed a few headings, then pressed Enter between a heading and a numbered list below it to insert a new line (not sure if the caret was on the end of the heading or the start of the first item, I'm not sure if I started typing.

VE began inserting the first sentence of the numbered list but with its link changed to two snowmen, about 15 times. Every time I clicked it would prepend some more.  Even scrolling would trigger this.

Before, the document contained

== WMF Cluster Backports ==
# Make sure there is a bug registered in [[mw:Bugzilla|Bugzilla]] for the issue.

I couldn't edit the document, but VE's review and save button worked fine. The new document showed as

== ==
# Make sure there is a bug registered in ☃☃ for the issue.Make sure there is a bug registered in ☃☃ for the issue. <repeated 269 more times>Make sure there is a bug registered in [[mw:Bugzilla|Bugzilla]] for the issue.

I don't know what happened to the heading, I didn't blank it out. I might have attempted a cut and paste, maybe that's what's going haywire, though I'm pretty sure the last thing I did was pressed Enter to add a sentence after the heading.

I assume this is an Easter egg in the VE codebase: if you manipulate the document near an exhortation to file a bug, Parsoid detects it and repeats the phrase, with snow people 8-)

--------------------------
**Version**: unspecified
**Severity**: normal
I /believe/ that we fixed this (rather worrying bug) last week with some changes on the CE side; if it recurs, please re-open!
See https://fr.wikipedia.org/w/index.php?title=COE&diff=prev&oldid=93166267 for example.

I only removed the link, but VisualEditor added a space before the colons.

Another example: https://fr.wikipedia.org/w/index.php?title=MSS&diff=prev&oldid=93166411

There was already two spaces, but VisualEditor added a third.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51024
According to a cs.wp editor such changes are intentional, so possibly no need to investigate further. Thanks.
(Sorry if I'm adding to the wrong task, I think a more relevant one was closed as dupe of this one. I haven't heard from cs.wp yet but it looks like there are [[ https://cs.wikipedia.org/w/index.php?title=Speci%C3%A1ln%C3%AD:Z%C3%A1znam_filtr%C5%AF_zneu%C5%BEit%C3%AD&wpSearchFilter=69 | too many occurrences ]] to be the case, IMHO).
@Elitre: This doesn't look like space before colons or links .. Could they be null edits / edit undos that might have left behind spaces in VE that Parsoid is preserving?
Can it be this is happening again? At cs.wp [[ https://cs.wikipedia.org/wiki/Speciáln%C3%AD:Filtry_zneužit%C3%AD/69 | they are filtering ]] edits adding extra spaces, like [[ https://cs.wikipedia.org/w/index.php?title=Románská_architektura&diff=prev&oldid=12201516 | this ]] or [[ https://cs.wikipedia.org/w/index.php?title=Ptakopysk&diff=prev&oldid=12204327 | this ]] (I haven't much info ATM).
Change 84701 merged by jenkins-bot:
(Bug 48570) Fix subtle selser bug handling separator-only nodes

https://gerrit.wikimedia.org/r/84701
*** Bug 50637 has been marked as a duplicate of this bug. ***
Change 84701 had a related patch set uploaded by Subramanya Sastry:
(Bug 48570) Fix subtle selser bug handling separator-only nodes

https://gerrit.wikimedia.org/r/84701
Confirmed on simple test case. Investigating.
---------------------------------------

[subbu@earth tests] echo "foo : bar" > /tmp/wt
[subbu@earth tests] node parse < /tmp/wt > /tmp/old.html
[subbu@earth tests] cat /tmp/old.html | sed 's/bar/bars/g;' > /tmp/new.html
[subbu@earth tests] node parse --html2wt --selser --oldtextfile /tmp/wt --oldhtmlfile /tmp/old.html < /tmp/new.html
foo  : bars
Bug 51024 has several more examples of this bug occurring if anyone is looking for them.
*** Bug 51024 has been marked as a duplicate of this bug. ***
See also bug 51024
Still present: see https://fr.wikipedia.org/w/index.php?title=Julot,_l%27Apache&diff=96678299&oldid=95213076 for example.
This looks like 1. a Parsoid issue, 2. fixed in master. Reassigning to Parsoid to confirm.
Ignore last comment, should be: Could the fix to bug 52035 be related to this?
Could the fix to bug 2035 be related to this?
It's not just ' either, also seen when removing - and " in my sandbox https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox&diff=566841354&oldid=566840716

spaces were added before internal and external links, except in the first instance where a space was added before a colon instead.
We unfortunately can:
http://en.wikipedia.org/w/index.php?title=Little_Mosque_on_the_Prairie&diff=prev&oldid=566820635

It seems to be triggered by removal of '.
Another user verified this (not actually saving, only preview mode) in http://en.wikipedia.org/wiki/Indian_Bank , removing the ' after "Binny&Co" would cause a whitespace to be added right before the next wikilink.
(In reply to comment #0)
> See https://fr.wikipedia.org/w/index.php?title=COE&diff=prev&oldid=93166267
> for example.
> 
> I only removed the link, but VisualEditor added a space before the colons.
> 
> Another example:
> https://fr.wikipedia.org/w/index.php?title=MSS&diff=prev&oldid=93166411
> 
> There was already two spaces, but VisualEditor added a third.

These have been now fixed - sorry for the difficulty.

(In reply to comment #1)
> The same happens when you edit the first word of a sequence "word + word +
> wikilink", it will add an unnecessary space before the link. Examples,
> http://it.wikipedia.org/w/index.php?title=Amazon.
> com&diff=prev&oldid=59604951 - 
> http://it.wikipedia.org/w/index.php?title=Google&diff=59622535&oldid=59377529
> (<<talmente popolare ch in  [[lingua inglese|inglese]] >>).
> This last one is a deliberate vandalism from me to check the issue, I later
> rollbacked.

I *think* this is also fixed but I'm not absolutely sure; please re-open if you can still reproduce this.
The same happens when you edit the first word of a sequence "word + word + wikilink", it will add an unnecessary space before the link. Examples,
http://it.wikipedia.org/w/index.php?title=Amazon.com&diff=prev&oldid=59604951 - 
http://it.wikipedia.org/w/index.php?title=Google&diff=59622535&oldid=59377529 (<<talmente popolare ch in  [[lingua inglese|inglese]] >>).
This last one is a deliberate vandalism from me to check the issue, I later rollbacked.
--------------------------
**Version**: unspecified
**Severity**: normal
Change 81876 merged by jenkins-bot:
Make the save dialog an actual dialog

https://gerrit.wikimedia.org/r/81876
Change 81876 had a related patch set uploaded by Jforrester:
Make the save dialog an actual dialog

https://gerrit.wikimedia.org/r/81876
*** Bug 50903 has been marked as a duplicate of this bug. ***
Removing from a milestone; as discussed, we're not going to have time to get to this before next week, and the EventLogging integration needs to be done RSN.
Setting milestone to 2013-06-27 since it is marked as blocker for "Beta" (2013-07). It may be moved to an earlier milestone as we see fit. But no later than 06-27. Setting it since I use milestone to sort "My bugs".
Trevor has some thoughts about this. :-)
Not sure how to reproduce, but I get two items in the "Matching categories" section; I can only move to the top one, and pressing down doesn't work (but pointer-highlighting and selection does).

--------------------------
**Version**: unspecified
**Severity**: major
Now fixed by Trevor.
Related URL: https://gerrit.wikimedia.org/r/68130 (Gerrit Change If48e001b92c217bee0a35b6da41d1c1ff0e3271c)
(In reply to comment #3)
> I can't reproduce this on master.

But I can. :-(

Requires two extant (on page and in wiki) categories which start with the same character sequence (I have "DoG and "DooooG")

On suggesting 'd', I get:

New category
  d
Move this category here
Matching categories     <--- This should not be here at all
  DoG                   <--- This should be in the "Move this category here" block
  DooooG                <--- This should also be in "Move this category here"
I can't reproduce this on master.
Seemingly not; Trevor investigating.
Now fixed in master.
--------------------------
**Version**: unspecified
**Severity**: trivial
Related URL: https://gerrit.wikimedia.org/r/65314 (Gerrit Change Ie87a3c7dde2f29c3898c08d4cade5c0ba2f937dd)
Merged and will go out in wmf5.
Related URL: https://gerrit.wikimedia.org/r/65303 (Gerrit Change Ibf63329a53bcd8043d46315239c19be4e681a18a)
We will also want to kill the non-Category panels (or populate them, if you're feeling sprint-y).
Do we need to trigger a re-render of the catlinks div? Can we?

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52403
Verified the fix on test 2
Change 107036 merged by jenkins-bot:
Update categories HTML on page save

https://gerrit.wikimedia.org/r/107036
Change 107036 had a related patch set uploaded by Esanders:
Update categories HTML on page save

https://gerrit.wikimedia.org/r/107036
*** Bug 57924 has been marked as a duplicate of this bug. ***
Note that the categories on the page are not refreshed even after multiple VE sessions.  i.e. VE add category -> save -> VE add category -> save : results in a page that _displays_ only the categories at the beginning of the process.

Categories added via templates are also not displayed.
*** Bug 56683 has been marked as a duplicate of this bug. ***
*** Bug 50737 has been marked as a duplicate of this bug. ***
*** Bug 50072 has been marked as a duplicate of this bug. ***
It depends on what we get back from the server.

If we get back something that is compatible with what api.php?action=parse gives (prop.categorieshtml, from Skin::getCategories), which is what live preview in core uses as well, then we can just update it by replacing the old with the new html.

If we can't get that, we'll have to re-implement Skin::getCategories in javascript. However I'd like to avoid that since it is skin-specific (skins can do all kinds of weird stuff to it, hard to predict. Ideally this would fall under the parts of the page output (like mw-content-text, htmlhead and script loader) that has a fixed html layout that skins can't alter the html itself of (it has enough css hooks to style anyway they like, they shouldn't need to modify the html). But that's not the reality.

--

Oh wait, this isn't from the server (not MediaWiki, not Parsoid). I mean, it shouldn't. This is reflected live when editing the document. We'll have to do it in javascript somehow I'm afraid.
The button should probably not do anything if the inspector is already open.

--------------------------
**Version**: unspecified
**Severity**: normal
Merged and will go out with wmf5.
Related URL: https://gerrit.wikimedia.org/r/64818 (Gerrit Change Ia97b6e3d862e02f5c55cac3f490fd8f26052027a)
If the image has focus when you click back on the 'Read' tab, the four circles stay on the page.

--------------------------
**Version**: unspecified
**Severity**: minor
Merged and will go out with wmf5.
Related URL: https://gerrit.wikimedia.org/r/64917 (Gerrit Change I807a0f32d3d1eb490456d887f7bf867bdb896df4)
Once it exists being the relevant part. :-)

--------------------------
**Version**: unspecified
**Severity**: normal
Change 127362 merged by jenkins-bot:
Use Parsoid API for action=parsefragment

https://gerrit.wikimedia.org/r/127362
Change 127362 had a related patch set uploaded by Esanders:
Use Parsoid API for action=parsefragment

https://gerrit.wikimedia.org/r/127362
Does the API actually exist yet?
This should be done sooner rather than later.
*** Bug 62516 has been marked as a duplicate of this bug. ***
https://www.mediawiki.org/wiki/Parsoid#The_Parsoid_web_API has the API docs.
More detail please?
Not going to make beta at this rate.
In ve.init.mw.ViewPageTarget.prototype.tearDownToolbar, this.toolbar is undefined if the editor hasn't finished loading.

--------------------------
**Version**: unspecified
**Severity**: normal
Merged; will go out with wmf5.
Related URL: https://gerrit.wikimedia.org/r/64333 (Gerrit Change Ide5def0e983bab49108b40008fc170957c7fc2a2)
Actually, this is distinct.
*** This bug has been marked as a duplicate of bug 47813 ***
Screenshot of problem

Scenario:
* Document contains " ... esams ... "
* Wiki has a page called "Esams".
* Wiki does not have case-sensitive first character in the main namespace.
* Select "esams" and turn it into a link
* UI shows:
  [ esams            ]
  New page:
    <redlink> esams
  Matching page:
    Esams
    Esams cluster
    Esams patches

That first redlink is incorrect, it should show the same as when the input is "Esams" (with capital E), namely no "redlink" since the first match is in fact the input.

It needs to account for the $wgCapitalLinkOverrides and $wgCapitalLinkOverrides configuration etc. This is abstracted in PHP by MWNamespace::isCapitalized, which is exposed in javascript as 'wgCaseSensitiveNamespaces' in mw.config.

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

**Attached**: {F10838}
Related URL: https://gerrit.wikimedia.org/r/64867 (Gerrit Change I66f5fc56554984af58d6223dc6cd76b3ab9940bd)
Basically any normalisation causes this bug.

also things like user:krinkle -> User:Krinkle, and localized namespaces and alias namespaces (Image>File).
*** Bug 48433 has been marked as a duplicate of this bug. ***
1 Go to a page with several paragraphs. Edit with VisualEditor.

2. Place cursor at the end of paragraph N and press Enter to create a new line. See the cursor blinking in a new line after paragraph N.

3. Select "Heading 2" in the dropdown menu.

EXPECTED

A Heading 2 line appears at the end of paragraph N.


ACTUAL OUTCOME

A Heading 2 line appears at the end of paragraph N-1.


As a matter of fact I find no way to place the header where I want, unless going to the end of paragraph N+1 only to trick the bug. Selecting an existing line and trying to make a header out of it doesn't seem to work either (but this is probably a different bug).

Happens at least in mediawiki.org with Firefox 22.0a2 (2013-05-07).

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #2)
> Yes, this works now. Thank you!
> 
> Just a little usability detail: after selecting the type of heading there is
> no
> cursor blinking. You can type and characters will appear where expected, but
> of
> course our old friend cursor-blinking is missed.

Yes; Rob noticed this too, and is working on it - just created bug 50338 to track.
Yes, this works now. Thank you!

Just a little usability detail: after selecting the type of heading there is no cursor blinking. You can type and characters will appear where expected, but of course our old friend cursor-blinking is missed.
I believe we've fixed this now in production - please re-open if it recurs.
When I go to use the VisualEditor (e.g., <https://www.mediawiki.org/wiki/Wikimedia_Engineering/2012-13_Goals> --> click "edit"), there's a bothersome notice every time the VisualEditor form loads about how it's the alpha version of the tool. There's no way to dismiss the notice and it gets a bit grating after a while.

--------------------------
**Version**: unspecified
**Severity**: trivial
Merged and will go out with wmf7 tomorrow.
Related URL: https://gerrit.wikimedia.org/r/68128 (Gerrit Change I725beec4e76dadfb1ccca873758f8f37b7f58a73)
Change-Id: Ie289c39b963072e8a20aa29926dee1d199b6e4e8
To do just before the "alpha" becomes a "beta".
Tracker for the bugs/enhancements that should be done for the beta.

--------------------------
**Version**: unspecified
**Severity**: normal
[adding the #tracking project to tasks blocking (now deprecated) T4007 as part of T93366]
Bugs tracking bugs that track bugs aren't hugely useful; let's kill this one.
[[:File:SpecialPage_Filter_JS.png]]

is being converted to:

<a rel="mw:Image" href="../File:SpecialPage_Filter_JS.png" data-parsoid="{&quot;tsr&quot;:[21446,21481],&quot;src&quot;:&quot;[[:File:SpecialPage Filter JS.png]]&quot;,&quot;dsr&quot;:[21446,21481,null,null]}"><img src="../Special:FilePath/SpecialPage_Filter_JS.png?width=200" alt="SpecialPage_Filter_JS.png" width="200" style="vertical-align: middle;" data-parsoid="{}"></a>

It should be an <a> without the <img> inside it.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: http://parsoid.wmflabs.org/mw/User:Dantman/Code_Ideas
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
*** Bug 49891 has been marked as a duplicate of this bug. ***
Fixed by https://gerrit.wikimedia.org/r/#/c/69612/.
(In reply to comment #2)
> This affects VisualEditor on the English Wikipedia.

I'm adding bug 48426 as a blocker.
*** Bug 49384 has been marked as a duplicate of this bug. ***
*** Bug 48669 has been marked as a duplicate of this bug. ***
This affects VisualEditor on the English Wikipedia.
*** Bug 48596 has been marked as a duplicate of this bug. ***
Putting this in DM because it seems the most likely suspect.

Original bug occurred on enwiki (text in the test stolen from there). This feels like a bit of bug 43543 - which was fixed?

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://www.mediawiki.org/w/index.php?title=VisualEditor:TestAutolinks&diff=688670&oldid=688669
Confirmed as fixed in master.

*** This bug has been marked as a duplicate of bug 43543 ***
This was happening with <ref>s, but it looks like it'll be an issue with an paragraph that ends with an inline alien:

| Foo.<ref>Ref</ref>
| Bar.

Backspace with the cursor to the left of the 'B', or delete with the cursor to the right of the <ref> block, has no effect.

The problem with <ref>s will go away(?) when that node handler code is enabled, but is this a wider issue?

--------------------------
**Version**: unspecified
**Severity**: minor
This seems to be not an issue anymore - since I rewrote handleDelete method.
Inez has some ideas about how to do this, so marking to him for now. Would be nice to document here /home/ we want to do this so someone can pick it up at some point. :-)

--------------------------
**Version**: unspecified
**Severity**: major
Now merged and will go out with wmf8 from Thursday 20 June.
https://gerrit.wikimedia.org/r/68296 (Gerrit Change Ie00becf1162f145134f006b0b4514ba874de9c43) | change APPROVED and MERGED [by jenkins-bot]
Related URL: https://gerrit.wikimedia.org/r/68296 (Gerrit Change Ie00becf1162f145134f006b0b4514ba874de9c43)
Go to http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services
Put the cursor somewhere in the text.
Type "Enter" 2 times.
Type "Up".
Type a
Type Enter
Type b
Type Up
Type Left
Press Shift and hold it
Type Down

Expected: selection of 1 line
Actually: selection of 2 lines

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed in the above.
Change 71143 merged by jenkins-bot:
Firefox misplaces cursor when moving between lines

https://gerrit.wikimedia.org/r/71143
Change 71143 had a related patch set uploaded by Christian:
Firefox misplaces cursor when moving between lines

https://gerrit.wikimedia.org/r/71143
Can confirm in Firefox (and not in Chrome); it sometimes occurs upwards as well as downwards.
Go to http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services
Put the cursor somewhere in the text.
Type "Enter" 2 times.
Type "Up".
Type "Tab"

Wild pawn appears.

--------------------------
**Version**: unspecified
**Severity**: normal
This is a duplicate of bug 48022 which was fixed for wmf4 (so should now work beautifully on enwiki). Sorry for the delayed response.

*** This bug has been marked as a duplicate of bug 48022 ***
Examining with user what browser/etc. to investigate.

--------------------------
**Version**: unspecified
**Severity**: major
**URL**: http://en.wikipedia.org/w/index.php?title=Indo-Pakistani_War_of_1965&diff=prev&oldid=552704403
On review, this is already fixed in master and will be deployed (as part of wmf4) to the English Wikipedia on 20 May.
(In reply to comment #4)
> To me it looks like the VE is dropping a link (with template encapsulation
> info) near '165 Pakistan tanks' when editing
> http://en.wikipedia.org/w/index.php?title=Indo-
> Pakistani_War_of_1965&oldid=551447483.
> So it looks like a VE bug to me. Can you verify?
That bug is fixed in the most recent VE release, which is live on mw.org but hasn't hit enwiki yet. Compare https://en.wikipedia.org/wiki/User:Catrope/India-Pakistan and https://www.mediawiki.org/wiki/User:Catrope/India-Pakistan .
To me it looks like the VE is dropping a link (with template encapsulation info) near '165 Pakistan tanks' when editing http://en.wikipedia.org/w/index.php?title=Indo-Pakistani_War_of_1965&oldid=551447483. So it looks like a VE bug to me. Can you verify?
Can you provide us with a test case and verify that the DOM change looks sane?
Gabriel - As far as I can tell, this bug is coming from Parsoid rather than VisualEditor - can you confirm? I can replicate in VE and Parsoid master locally.
There was a Parsoid bug to this effect earlier, maybe it came back?
--------------------------
**Version**: unspecified
**Severity**: normal
Trevor's commit has been merged; assigning to Inez for the IE-specific fixes to come.
Related URL: https://gerrit.wikimedia.org/r/62481 (Gerrit Change I5f279b06b098960be7bd4ad3f5e6f74b67e31d1a)
This doesn't happen in IE.

1. Place the cursor at the end of a link.
2. Type some text
3. See that the text doesn't appear to be linked, but the link inspector option is available

Short term solution as decided by Trevor, Inez and James: Make links not auto-extend in the model, and fix IE so it doesn't auto-extend in the view (to make it work like other browsers).
unexpected untyped characters

Upon loading page in VE: 

Click CTRL-B and type some characters; 
click CTRL-I and type some characters; 

* often but not always reproducible, seen in Chrome/OSX, also reported in IE and FF: upon typing after ctrl-B or ctrl-I for "bold" or "italic", characters appear that have not been entered.  see screen shot

* possibly related, seen but not reproducible:  some combination of actions will cause VE to type a string into a page over and over and over without any action on the part of the user.  I'll file a new bug if I can figure out how to repron that behavior.

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

**Attached**: {F11070}
I believe we fixed this with the new insertion logic last week. Please re-open if you can reproduce still.
@James: Feel free to assign to me.
From this bug report on parsoid.wmflabs.org: /mnt/bugs/2013-05-04T01:11:28.439Z-Style_guide%252FAssets_and_gallery

"I typed some text in this paragraph that is styled as a span italic, and VE decided to close and reopen the span on either side of the link. I think that happened before I made the text a link. (This is User:S Page (WMF) here.)"

Relevant diff line below:

− 	
:<span style="font-style: italic;">See Also: [[Commons:Category:MediaWiki style guide]]</span>

+ 	
:<span style="font-style: italic;">See also: </span>[[Wikimedia Foundation Design/Agora Icon Set]] and<span style="font-style: italic;"> [[Commons:Category:MediaWiki style guide]]</span>

--------------------------
**Version**: unspecified
**Severity**: minor
(In reply to comment #3)
> Can you explain more clearly how this is still broken? What do you mean by
> pre-annotation?

On re-testing, this comes down to copy-and-paste inserted content not continuing the existing annotations of the styles into which it had been inserted. Marking as such.

*** This bug has been marked as a duplicate of bug 48720 ***
Can you explain more clearly how this is still broken? What do you mean by pre-annotation?
OK, we've fixed the secondary issues I was having; have narrowed down the original bug to pre-annotations not being applied to the insertion of text into this context - changing this to suit.
I think that this partially interacts was a bug that Ed found independently - bug 48110 (now fixed in master). I do not get the span adjusted, but instead get:

:<span style="font-style: italic;">See Also: <a href="Wikimedia_Foundation_Design%2FAgora_Icon_Set" rel="mw:WikiLink">Wikimedia Foundation Design/Agora Icon Set</a> and [[Commons:Category:MediaWiki style guide|<nowiki/>]]<a href="Commons%3ACategory%3AMediaWiki" rel="mw:WikiLink">Commons:Category:MediaWiki</a> style guide</span>

... which is a total mess.
If you add a link to the last word in your paragraph (quite common I'd imagine if you're in the middle of typing a sentence), the insertion annotation behaviour makes any text typed after the link part of that link - which in most cases is not what you meant to do.

Insertion annotations make sense for text style annotations, but not link annotations. This is what Google Docs & LibreOffice do aswell.

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed by https://gerrit.wikimedia.org/r/#/c/62481/
This is a regression - it used to be that there were two types of annotations - one (bold/italics/etc.) would pre-annotate over word breaks, and the other wouldn't. I believe that the code to do this used to sit in CE - has it been removed, or is it not working somehow?
Currently we steal all the things on action=edit for veaction=edit (so Ctrl-Option-e goes to VisualEditor, leaving nothing for the wikitext editor). We should add a new one - Ctrl-Option-s (for *s*ource) - though that's used for save in the wikitext editor, which is a bit odd. Ideas?

--------------------------
**Version**: unspecified
**Severity**: minor
Fixed in master.
Related URL: https://gerrit.wikimedia.org/r/63231 (Gerrit Change I598177bc75ed84dea35952a3b2b1b2111aac89b2)
Change of plans:
* Leave -e for the wikitext editor tab
* Add -v for the VisualEditor tab
I changed a link here: http://sv.wikipedia.org/w/index.php?title=Intellektuell_s%C3%A4rbeg%C3%A5vning&diff=21539781&oldid=21539483

In the VisualEditor interface, the word "Känsla" is showed with a lower case k, but when you are looking at the article, or source it is K.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #4)
> As we're generating the correct HTML surely this is just a Parsoid bug, not a
> VE bug.

Yeah, point.

*** This bug has been marked as a duplicate of bug 48477 ***
As we're generating the correct HTML surely this is just a Parsoid bug, not a VE bug.
Depends on a Parsoid regression being fixed.
I just hit the same again.

* Text "foo".
* Link it, page "Foo" exists.
* Close link editor.
* Page shows "text <a href="./Foo">foo</a> text".
* Saving turns it into [[Foo]], thus ignoring the case of the label.
Thank y(In reply to comment #0)
> I changed a link here:
>
> http://sv.wikipedia.org/w/index.php?diff=21539781&oldid=21539483
> 
> In the VisualEditor interface, the word "Känsla" is showed with a lower case
> k, but when you are looking at the article, or source it is K.

Thank you for your bug report, Jan! Hope to get this fixed soon.
All the pawns

See attached image, basically the idea is that indenting or de-indenting a list item will cause there to be a pawn in the list item. Also, when I used the arrow keys to navigate past some images, it put pawns next to the images.

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

**Attached**: {F10767}
This is now fixed in wmf4 (which is the current in-production version); marking as such.
Nothing about the list or indenting, just the cursor keys trigger it (Firefox only).
The order should be Edit then Edit tab. Looks like a hard-coded left somewhere?
Change 381217 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] ve.init.mw.DesktopArticleTarget: Fix the code to reorder tabs

[[https://gerrit.wikimedia.org/r/381217]]
Change 381217 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/VisualEditor@master] ve.init.mw.DesktopArticleTarget: Fix the code to reorder tabs

[[https://gerrit.wikimedia.org/r/381217]]
After trying to verify the fix during the SWAT deployment, I found out that this entire feature (fixing up the tab order if wgVisualEditorTabPosition was changed and we're seeing cached HTML with the tabs in wrong order) is actually entirely broken and just does nothing. The deployment was essentially a no-op. This is actually convenient because had it worked, it would have been messing up the tabs.
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AV7ItYHmF4fsM4DBdIoK} [2017-09-28T13:38:12Z] <zfilipin@tin> Synchronized php-1.31.0-wmf.1/extensions/VisualEditor/modules/ve-mw/init/targets/ve.init.mw.DesktopArticleTarget.init.js: SWAT: [[gerrit:381210|ve.init.mw.DesktopArticleTarget: Remove hack for reversed tabs in RTL in Vector (T50017)]] (duration: 00m 50s)
Change 381210 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@wmf/1.31.0-wmf.1] ve.init.mw.DesktopArticleTarget: Remove hack for reversed tabs in RTL in Vector

[[https://gerrit.wikimedia.org/r/381210]]
Change 381210 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/VisualEditor@wmf/1.31.0-wmf.1] ve.init.mw.DesktopArticleTarget: Remove hack for reversed tabs in RTL in Vector

[[https://gerrit.wikimedia.org/r/381210]]
Change 381167 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] ve.init.mw.DesktopArticleTarget: Remove hack for reversed tabs in RTL in Vector

[[https://gerrit.wikimedia.org/r/381167]]
(This will need to be backported to 1.31.0-wmf.1.)
Change 381167 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/VisualEditor@master] ve.init.mw.DesktopArticleTarget: Remove hack for reversed tabs in RTL in Vector

[[https://gerrit.wikimedia.org/r/381167]]
With the underlying issue T48947 being fixed, our workaround is now unnecessary and in fact reintroduces this issue. We should remove it.
*** Bug 47684 has been marked as a duplicate of this bug. ***
Merged into master.
Related URL: https://gerrit.wikimedia.org/r/63153 (Gerrit Change Ie1214b08450aefed893739a2b862cb1e9b23a2ef)
This is caused by bug 46947 – the HTML order of tabs is reversed, then reversed again in the CSS...
There are probably two solutions - make it work - or disable list buttons while in block slug.

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed and will be deployed later today.
Change 71353 merged by jenkins-bot:
Allow creating lists in block slugs

https://gerrit.wikimedia.org/r/71353
Change 71353 had a related patch set uploaded by Jforrester:
(bug 47947) Allow creating lists while selection is collapsed and in block slug

https://gerrit.wikimedia.org/r/71353
Change 71353 had a related patch set uploaded by Inez:
(bug 47947) Allow creating lists while selection is collapsed and in block slug

https://gerrit.wikimedia.org/r/71353
*** Bug 50242 has been marked as a duplicate of this bug. ***
Make it work is better. :-)
The user was trying to edit http://de.wikipedia.org/w/index.php?title=Reiniger,_Gebbert_%26_Schall&direction=prev&oldid=117917379 to remove the first heading but keep the image. The result was http://de.wikipedia.org/w/index.php?title=Reiniger,_Gebbert_%26_Schall&direction=next&oldid=103767568 and the didn't manage to do it without adding the ♙.

--------------------------
**Version**: unspecified
**Severity**: normal
I think our changes related to pawns also has fixed this bug; marking as closed.
Sorry, yes. It's Firefox (20.0.1, Windows 7).

Steps to reproduce according to user:
* open http://de.wikipedia.org/w/index.php?title=Reiniger,_Gebbert_%26_Schall&oldid=103767568
* edit with VisualEditor
* select first heading "Aufbau und Expansion des Unternehmens"
* remove using del-key
* ♙ appears
Lydia: Any response on that?
I asked at http://de.wikipedia.org/wiki/Wikipedia:Technik/Text/Edit/VisualEditor/Alpha2013-04#Absatzmarker_.28.E2.99.99.29
I think it might be the FF specific bug for which we already have fix (but it is not released yet).
Could you provide steps to reproduce (I tried and I can't) and information about browser/OS?
This just means supporting their use, not being able to set their parameters, but will de-alienate a large amount of content for trivial work at our end. The parameter setting/editing will need to come later.

--------------------------
**Version**: unspecified
**Severity**: minor
Merged; will go out with wmf4.
(In reply to comment #1)
> Feel free to assign it to me.

Too late, already written the code. :-)
Related URL: https://gerrit.wikimedia.org/r/61737 (Gerrit Change I794927a881082e0113c0ce8ee8f1d908b0960899)
Feel free to assign it to me.
Screenshot of LQT thread with </div> in title

Should be treated the same as regular page titles: Escape everything.


Or, if we want to keep wikitext parsing (e.g. for wikilinks, sometimes done in section headings), then parse as inline block (not allowing any block level elements like <div> or <table>) and make sure open/close tags match (run Tidy).

--------------------------
**Version**: unspecified
**Severity**: major
**URL**: https://www.mediawiki.org/wiki/Thread:Project:Support_desk/visible_html_on_pages%3A
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=31244
https://bugzilla.wikimedia.org/show_bug.cgi?id=29564

**Attached**: {F10533}
LiquidThreads has been replaced by #Flow on all Wikimedia production wikis (except one, which will be done soon). It is no longer under active development or maintenance, so I'm re-classifying all open LQT tasks as "Lowest" priority.
A similar problem in a topic named "Handling <pre><ref></pre> with trailing slash does not work correctly":
https://www.mediawiki.org/wiki/Thread:VisualEditor/Feedback/Handling_ref_with_trailing_slash_does_not_work_correctly
This is one of the many places with poor or inconsistent escaping in LQT.
(In reply to comment #1)
> @Krenair: You change the summary to include "with wgUseTidy = true;" Are you
> saying that when Tidy is disabled this bug does not happen?


Yes. I have to add that to my configuration to replicate this bug.
@Krenair: You change the summary to include "with wgUseTidy = true;" Are you saying that when Tidy is disabled this bug does not happen?

Seems more like the opposite?
VisualEditor (50e8693)
Parsoid (ba0b080)
MW: 1.22/wmf2 (814f75e)

While editing a page in Firefox 20.0, the existing page content is blank in the editor.

The issues seems to be an issue with Firefox only, as Chrome and Safari work as expected.

--------------------------
**Version**: unspecified
**Severity**: critical
**OS**: Mac OS X 10.7
**Platform**: Macintosh
We have identified this bug and fixed it in live (for mediawiki.org - other wikis will be going out in the next few days); sorry for the difficulty.
Is this on the Wikimedia cluster or locally? If on the cluster, is it on all pages or just one or two?
VE error when not completely loaded

on any page editable by VE:

invoke VE
immediately click Preferences or other live link

an alert appears saying "Error loading data from server: error. Would you like to retry?"

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

**Attached**: {F10400}
Merged; will go out with wmf5.
Related URL: https://gerrit.wikimedia.org/r/64333 (Gerrit Change Ide5def0e983bab49108b40008fc170957c7fc2a2)
Actually, this looks like a different bug (but in the same loop).
From Ed's comment:

In ve.init.mw.ViewPageTarget.prototype.tearDownToolbar, this.toolbar is
undefined if the editor hasn't finished loading.
*** Bug 48520 has been marked as a duplicate of this bug. ***
Hi,

The problem is that when I have created a bullet list in Visual Editor and try to erase back the text using Backspaces, the numbers or bullet points don't delete even if I have deleted the whole text. Here is a trivial demonstration :

1. Hello1
2. Hello2
3. Hello3

Now when I try to delete it from the Hello3 using backspaces, all the text upto first bullet is deleted, but those bullet points are left as it is. 

1.

2.

3.


Images:

https://docs.google.com/file/d/0B3eGCB261PalaDhqa1ZhcmFPUk0/edit?usp=sharing
https://docs.google.com/file/d/0B3eGCB261PalbndsZEFSdXpEZGM/edit?usp=sharing

Tested on Firefox 20.

--------------------------
**Version**: unspecified
**Severity**: normal
And now fixed in wmf4.
This is now broken again in master. :-(
*** Bug 48293 has been marked as a duplicate of this bug. ***
Wmf4 which will begin deployment on 13 May. :-)
Fixed here: https://gerrit.wikimedia.org/r/61520
It is not released yet, James, can you put appropriate milestone tag?
Thanks for the bug report; I can confirm in Chrome and Safari as well.
Add button to WikiEditor and VisualEditor for switching back and forth.

* Only shown if in WE you have VE enabled (otherwise don't show)
* If no changes, switch immediately
* If there are changes, prompt the user (with the same OOUI message dialog we use in VE) whether to switch with or without their changes
Change 250965 merged by jenkins-bot:
Target init: Add edit mode switch icons to VE and WE toolbars

[[https://gerrit.wikimedia.org/r/250965]]
Change 250965 had a related patch set uploaded (by Jforrester):
Target init: Add edit mode switch icons to VE and WE toolbars

[[https://gerrit.wikimedia.org/r/250965]]
Change 250939 merged by jenkins-bot:
Target init: Add edit mode switch icons to VE and WE toolbars

[[https://gerrit.wikimedia.org/r/250939]]
More prominent VE switcher:
{F2913511}

WikiEditor switcher (top right):
{F2913515}
Change 250939 had a related patch set uploaded (by Esanders):
Target init: Add edit mode switch icons to VE and WE toolbars

[[https://gerrit.wikimedia.org/r/250939]]
Change 245593 merged by jenkins-bot:
Allow switching from wikitext to VE

[[https://gerrit.wikimedia.org/r/245593]]
Change 245593 had a related patch set uploaded (by Alex Monk):
[WIP][POC][DONOTMERGE] Allow switching from wikitext to VE

[[https://gerrit.wikimedia.org/r/245593]]
>>! In T49779#1172521, @Jdforrester-WMF wrote:
>>>! In T49779#1172511, @Krenair wrote:
>> We should talk to #Parsoid to work out what dependencies this has from them, if any
> 
> It's mostly a RESTbase dependency, at this point.

Perhaps we should make a separate task for the RESTbase/Parsoid dependencies here.
This would be a great enhancement!
>>! In T49779#1172511, @Krenair wrote:
> We should talk to #Parsoid to work out what dependencies this has from them, if any

It's mostly a RESTbase dependency, at this point.
We should talk to #Parsoid to work out what dependencies this has from them, if any
(In reply to Alex Monk from comment #17)
> So with the resolution of bug 50687, this is effectively "Provide a way for
> the user to switch from the wikitext source editor to VisualEditor, keeping
> changes but not saving", right?

Yes, as I understand it.  Adding that direction would then allow bidirectional switching.
So with the resolution of bug 50687, this is effectively "Provide a way for the user to switch from the wikitext source editor to VisualEditor, keeping changes but not saving", right? Or have I misunderstood?
Sweedish Wikipedians including User:Jan Ainali and User:FrankieF are discussing/requesting an enhancement to VisualEditor here [1] and translate the thread as follows:

"What we are missing is way to easily switch between wikitext and VE without saving or loosing stuff. Just like you can in Wordpress between the WYSIWYG and HTML editor." 

[1]
https://sv.wikipedia.org/wiki/Wikipedia:VisualEditor/%C3%85terkoppling#Saknade_funktioner_i_Redig.l.C3.A4get
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #12)
> > > This functionality was requested back in December 2011 in bug 33124.
> > 
> > No? The diff view of the wikitext is not even a read-only view of the entire
> > document's wikitext, let alone an editable one? Also, quickly editing the
> > diff
> > in a pop-over window is fundamentally different paradigm from having a proper
> > wikitext editor available to all users at all times, and being able to switch
> > back and forth, which is what this bug requests.
> 
> From what I remember about the feature which existed in the prototype which
> motivated the request made on bug 33124, it actually displayed the entire
> document's wikitext (not just the diff).

Oh, yes, you are right. My apologies.

This means that that bug is even further from "this functionality", however.
(In reply to comment #13)
> (In reply to comment #12)
> > This functionality was requested back in December 2011 in bug 33124.
> 
> No? The diff view of the wikitext is not even a read-only view of the entire
> document's wikitext, let alone an editable one? Also, quickly editing the
> diff
> in a pop-over window is fundamentally different paradigm from having a proper
> wikitext editor available to all users at all times, and being able to switch
> back and forth, which is what this bug requests.

From what I remember about the feature which existed in the prototype which motivated the request made on bug 33124, it actually displayed the entire document's wikitext (not just the diff).
(In reply to comment #12)
> This functionality was requested back in December 2011 in bug 33124.

No? The diff view of the wikitext is not even a read-only view of the entire document's wikitext, let alone an editable one? Also, quickly editing the diff in a pop-over window is fundamentally different paradigm from having a proper wikitext editor available to all users at all times, and being able to switch back and forth, which is what this bug requests.
This functionality was requested back in December 2011 in bug T35124.
This functionality was requested back in December 2011 in bug 33124.
(In reply to comment #10)
> Im not immediately inclined to work on SE->VE, as that could facilitate
> people
> playing games with the wikitext in order to put dodgy entries into the
> 'VisualEditor' tagged edit list, which would be impossible to debug.

That could be mitigated with an editfilter or some other indication that an editor had used both modes. Whether such would be possible or desirable is another matter
I have built a script which switches from VE to SE.
https://en.wikipedia.org/wiki/User:John_Vandenberg/switch_editor

I havent looked at whether the API and VE codebase can support switching from SE back to VE, but it seems like JS could obtain rendered HTML (action=parse?) and load it into VE.

Im not immediately inclined to work on SE->VE, as that could facilitate people playing games with the wikitext in order to put dodgy entries into the 'VisualEditor' tagged edit list, which would be impossible to debug.
*** Bug 50698 has been marked as a duplicate of this bug. ***
(In reply to comment #7)
> See also:
> * [[Thread:VisualEditor/Feedback/ Side-by-side view (no more?)]]

Helder. I corrected the link (I hope):
* [[mw:Thread:VisualEditor/Feedback/ Side-by-side view (no more?)]]

See: [[WP:Bugzilla]] and the section currently titled "Links from within Bugzilla".

Hey Helder. Maybe you can develop a preview mode for Bugzilla? :) Bugzilla needs a "preview" mode:
*https://bugzilla.mozilla.org/show_bug.cgi?id=40896
See also:
* [[Thread:VisualEditor/Feedback/ Side-by-side view (no more?)]]
* Old demo with side-by-side view:
http://blog.wikimedia.org/2011/12/13/help-test-the-first-visual-editor-developer-prototype/visual-editor-demo-2/
Adding 'source' to subject line to make this easier to search.
*** Bug 49986 has been marked as a duplicate of this bug. ***
**winne2i** wrote:

I'm asking again if this is very difficult to achieve this by adding (even temporarily!) a regular Preview button, which will allow us to see the source code of already changed content? As I said before we can already see diffs so seeing a preview should be quite easy IMO.

As far as refs are concerned – I agree that's very important. But let me notice that introducing such Preview button would allow to add references in that later step (editing the source code). That would be a great instant (but somewhat temporary) solution for both problems. Then one may work on pretty way of adding refs.

Doesn't it sound good? :)
(In reply to comment #2)
> Just pointing out that this is very frequently requested by enwiki users at
> [[Wikipedia:VisualEditor/Feedback]]. 
> 
> I know bug priority is technically up to the developers, but just letting you
> know that a lot of people want this.

We understand, and I really want to be able to provide this, but in the choice between this and being able to add references (say) we have to prioritise. However, I'm going to see if we can try to get it done in the next few weeks. Sorry for not being able to make a firm commitment.
Just pointing out that this is very frequently requested by enwiki users at [[Wikipedia:VisualEditor/Feedback]]. 

I know bug priority is technically up to the developers, but just letting you know that a lot of people want this.
**winne2i** wrote:

To me that doesn't seem to be compliacted to acheive. The way could be to add a button which opens regular Preview (with wikitext editing).
We already can see the diff, so adding regular preview should not be difficult.

And this can be a big convenience because it's easier to edit in VE but we still can't edit/insert some elements like templates.
Right now you get | Edit | Edit source | on read and on VE edit (which are the same thing) but nowhere else, which is confusing.

(Whilst we're at it, logs, diff view pages, and probably a few dozen others have edit links which will need to be replaced or augmented.)

--------------------------
**Version**: unspecified
**Severity**: normal
This was fixed by Ed in his commit last week.
Once we're deployed for all users, we could simply replace the "Edit" message with "Edit source" in core which would manage the first half; we'd still need to add the (VE) "Edit" tab to these extra places (and the other stuff like "(edit)" links in diff views).
Setting "High" for action=edit; the others can be fixed, I guess.
In [[en:User:Yamaha5/sandbox]] I tested it for Farsi every thing was OK except <div dir="rtl"><div> which cause the test disable. in fa.wiki because of mixture of farsi and english or LTR Math formulas we use direction inside the text so it will cause problem for RTL languages

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 95051 merged by jenkins-bot:
MediaWiki language inspector updates

https://gerrit.wikimedia.org/r/95051
Change 95051 had a related patch set uploaded by Jforrester:
MediaWiki language inspector updates

https://gerrit.wikimedia.org/r/95051
Splitting the block level items into bug 60187.
The main work is merged. Some designs tweaks are still needed, but now language for <span>s can be set.
Change 72634 merged by jenkins-bot:
Language Inspector UI

https://gerrit.wikimedia.org/r/72634
Change 72634 had a related patch set uploaded by Mooeypoo:
Language Inspector UI

https://gerrit.wikimedia.org/r/72634
Change 70560 merged by jenkins-bot:
Language Inspector: CE / DM

https://gerrit.wikimedia.org/r/70560
Change 70560 had a related patch set uploaded by Mooeypoo:
Language Inspector: CE / DM

https://gerrit.wikimedia.org/r/70560
*** Bug 41009 has been marked as a duplicate of this bug. ***
(In reply to comment #5)
> Oy, I mean Bug 41009. Both speak of the same features that the Language
> Inspector will attempt to solve.

Given that this is more advanced in discussion, I'll up-merge that into this.
Oy, I mean Bug 41009. Both speak of the same features that the Language Inspector will attempt to solve.
I think this is a dupe of Bug 47759
Work on this has began, we will be using <span lang='xx' dir='yyy'> tags to start with and add functionality for broader usages in the future.
This would be a task for a language inspector, presumably? Marking as an enhancement - this might be something for Moriel if she is going to be working with us on language support.
Clarification: the bug report is about text within <div dir="rtl"></div> being alienated. I'm not sure how we can intelligently not alienate text with such a direction override.
Ubuntu/Firefox
Go to http://en.wikipedia.org/wiki/Alfresco_%28software%29
At the end of a line, add a space and remove it
Click "Save"
No changes should have happen, but there actually are changes, in the infobox:

| caption = Alfresco Share / Repository Browser <br/> (Community Edition)
became
| caption =Alfresco Share / Repository Browser <br></table> (Community Edition)

--------------------------
**Version**: unspecified
**Severity**: major
(In reply to comment #10)
> http://en.wikipedia.org/wiki/Anne_Hendershott still shows the same symptoms.
> Is
> this fix not yet deployed?

Sorry, the meaning of "VE-deploy-2013-05-13" is meant to be pretty clear, but evidently isn't! It'll go out with 1.22wmf4, so on the English Wikipedia on 20 May.
http://en.wikipedia.org/wiki/Anne_Hendershott still shows the same symptoms. Is this fix not yet deployed?
We're now three bugs fixed into this stack. Closing. Others should be opened as other bugs.
Related URL: https://gerrit.wikimedia.org/r/61919 (Gerrit Change I42daaf142e548e5b221ff0a52df0ad24ec6a4fd0)
I tested the following 4 pages and am recording my findings here.  Once we go through the other pages, we should close this bug and create new bugs where necessary.

On the following two pages, I can reproduce in Firefox, but the edit is clean in Chrome.  So, this is definitely Firefox specific, not sure if it is JQuery-related or something else.

* http://en.wikipedia.org/wiki/Timeline_of_portable_computers
* http://en.wikipedia.org/wiki/Neritina_rubricata

On the following two pages, I can reproduce the spurious diffs in both Firefox and Chrome even though I didn't edit the relevant areas. I haven't looked at the diffs yet.  So, this is quite likely some kind of whitespace change in the DOM that VE sends Parsoid.

* http://en.wikipedia.org/wiki/Timeline_of_portable_computers -- It appears that the table is being marked as edited even though I didn't edit the table.

* http://en.wikipedia.org/wiki/Anne_Hendershott -- the list is being marked as edited because of some whitespace normalization when VE loads/saves the DOM.
(In reply to comment #4)
> Do you mean all of the problem mentioned on this page are due to this bug?

Please open separate bug tickets for each bug in future. :-)
I believe the whitespace changes are a separate issue. Reopening so that those don't get lost.
Do you mean all of the problem mentioned on this page are due to this bug?
Cheers!
Nicolas
This is an instance of the jQuery bug 47737 - marking as a duplicate.

*** This bug has been marked as a duplicate of bug 47737 ***
http://en.wikipedia.org/wiki/Anne_Hendershott
http://ja.wikipedia.org/wiki/BMW_801
On the contrary, here spaces got inserted.

http://en.wikipedia.org/wiki/List_of_Mexican_telenovelas
* ''[[Mañana Es Para Siempre]]-''Tomorrow Is Forever''
becomes
* ''[[Mañana Es Para Siempre]]-''Tomorrow Is Forever

http://en.wikipedia.org/wiki/Sonic_the_Hedgehog_Vocal_Traxx:_Several_Wills
http://ja.wikipedia.org/wiki/%E6%9C%A8%E6%A2%A8%E3%82%AC%E3%82%A4%E3%83%89%E3%83%BB%E9%80%B1%E6%9C%AB%E3%81%AE%E9%81%94%E4%BA%BA
http://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%83%89%E3%82%B7%E3%83%A5%E3%83%A2%E3%82%AF%E3%82%B6%E3%83%A1
<br/> becomes <br></table>

http://en.wikipedia.org/wiki/Barunga,_Northern_Territory
| pop = 282 (2006 Census)<ref name=Census2006Y />
becomes
| pop =282 (2006 Census)<ref name=Census2006Y ></span>

http://en.wikipedia.org/wiki/Aerial_toll_house
whole references are duplicated

etc... using http://en.wikipedia.org/wiki/Special:Random and http://ja.wikipedia.org/wiki/%E7%89%B9%E5%88%A5:%E3%81%8A%E3%81%BE%E3%81%8B%E3%81%9B%E8%A1%A8%E7%A4%BA about half of the articles don't roundtrip.
Other faulty roundtrips:

http://en.wikipedia.org/wiki/Neritina_rubricata
Removes space at end of line

http://en.wikipedia.org/wiki/Timeline_of_portable_computers
--> || becomes -->||

Should I continue reporting space removals like these 2 ones?
Or are these spaces removed on purpose?
Edit an article
Press down your keyboard's SHIFT key
While maintaining SHIFT pressed, press the RIGHT key a few times

EXPECTED: Characters are selected
ACTUALLY: Characters are deleted

Ubuntu/Firefox

Looks like https://bugzilla.wikimedia.org/show_bug.cgi?id=41062 which had been fixed in October.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #8)
> Still actin' crazy: firefox 20.0, linux.  I hard-refreshed just in case.

You may have hard-refreshed, but you didn't wait for the deployment train which was only three hours ago. :-) Sorry for not mentioning that it's "fixed pending deploy" (it'd be great if Bugzilla had that as a status).

Can confirm that it's now fixed in live in Firefox 20.0/Mac.
This bug is currently fixed in master. It is going to be live on Wikipedia by Wednesday next week. In the meantime it is possible to test on mediawiki.org. However currently (for another 2-3 hours) VE on mediawiki.org is completly broken for FF.
It would be worthwhile to mention the bug 47795 here, with similar nature of problem.
Sorry, comment #10 has been split off into bug 47817.
Okay, the turd was a separate bug:

1. Edit a page with an unordered list.

2. Delete all the text on the last line.

3. Press the <delete key>. The bullet should be erased.  Instead, it will remain and the cursor will move to the end of the previous line.

4. down-arrow

5. down-arrow off of the empty line.

Turd appears in the empty line.

6. I did something else with the arrow keys, all of the document's lines were erased (not all part of the <ul>), and the undo buffer could not step backwards.  Aaaa, will reproduce later.
Confirmed. It still doesn't work in Firefox 20.0. Shift+Selection Keys isn't working in normal way. When up or down keys are pressed, the text is selected for the first time, but pressing them for second time gets the selected text deleted.
Still actin' crazy: firefox 20.0, linux.  I hard-refreshed just in case.

In fact, I had some text highlighted and tried to use <ctrl>-<shift>-left to extend the selection.  My text was deleted, plus a character or two, and then a freakin snail character appeared.  I have yet to find the unicode for that.  It wasn't 1F40C, OMG it was 1f4a9 I was just about to say it looked more like a turd than snail.
And /now/ it's fixed. :-)
https://gerrit.wikimedia.org/r/61055 (Gerrit Change I1aff295a0958b75697c4d362e0d6095283f37fe8) | change APPROVED and MERGED [by jenkins-bot]
Just for my sanity, marking as unfixed until it's merged.
Fixed in here: https://gerrit.wikimedia.org/r/#/c/61055/
Related URL: https://gerrit.wikimedia.org/r/61055 (Gerrit Change I1aff295a0958b75697c4d362e0d6095283f37fe8)
Confirmed, will work on it.
Confirm that this occurs in Firefox but not in Chrome.
Steps to reproduce:

1. Open http://en.wikipedia.org/wiki/CMIS
2. Press Edit
3. Press your keyboard's Down key
4. Wild pawn ♙ appears

Also reproduced on http://ja.wikipedia.org/wiki/%E3%83%95%E3%83%AB%E3%83%BC%E3%83%AB%E3%83%BB%E3%83%89%E3%83%BB%E3%82%BB%E3%83%AB

--------------------------
**Version**: unspecified
**Severity**: major
Fixed in here: https://gerrit.wikimedia.org/r/#/c/61055/
Confirmed, will work on it.
Reproduced on Firefox 20 on OS X 10.8. 


Following error reported in console when pressing down key.

[19:49:36.737] TypeError: this.storeIndexes.slice is not a function @ http://bits.wikimedia.org/ja.wikipedia.org/load.php?debug=false&lang=zh-hans&modules=ext.visualEditor.core%2Cicons-raster%7Cext.visualEditor.viewPageTarget.icons-raster%7Crangy%7Cunicodejs.wordbreak&skin=vector&version=20130426T114825Z&*:48



Reproduced even when everything is in English:

https://zh.wikipedia.org/w/index.php?title=User:Bencmq-test/2&diff=26351189&oldid=26351184


No issue on Chrome or Safari. I took the liberty of marking it as FireFox only.
If you keep the Down key pressed, the caret will travel down, dumping a pawn at the end of some paragraphs.
I am not sure how pawn leaving is decided: For the same paragraph of the same article, sometimes a pawn is dumped and sometimes not.
From user report:

'externalLink', { '$$': menu$$, 'label': 'External link' }
'newPage', { '$$': menu$$, 'label': 'New page' }
'matchingPages', { '$$': menu$$, 'label': 'Matching page' }

--------------------------
**Version**: unspecified
**Severity**: major
In the end fixed by gerrit 60700 just to be confusing; now merged and will be deployed in the Monday deploy train.
Fixed by gerrit 61035. Thanks for the catch!
https://he.wikipedia.org/w/index.php?title=%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:Matanya/%D7%90%D7%A8%D7%92%D7%96_%D7%97%D7%95%D7%9C_2&diff=14076208&oldid=14076205

https://he.wikipedia.org/w/index.php?title=%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:Matanya/%D7%90%D7%A8%D7%92%D7%96_%D7%97%D7%95%D7%9C_2&diff=14076218&oldid=14076208

(Others.)

User says they get this when switching he/en and back again.

--------------------------
**Version**: unspecified
**Severity**: normal
I cannot reproduce it any more (Firefox 22, Fedora 18). Marking WORKSFORME, but reopen if it still happens.
Steps to reproduce:

1) open https://he.wikipedia.org/w/index.php?title=%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:Matanya/%D7%90%D7%A8%D7%92%D7%96_%D7%97%D7%95%D7%9C_2&diff=14076208&oldid=14076205

in VE mode.

2) open a new line and go to the beginning of the line. switch for he to en or vice versa on your keyboard.

3) you have a pawn. 

tested on firefox 21 on ubuntu 13.04
Ping to Amir / matanya for steps to reproduce.
I still can't reproduce this one. Can I get step-by-step instruction please?
I don't think this is a dupe of bug 41067 - pawns appearing can have lots of causes (all bugs, but not necessarily the same bug).
*** This bug has been marked as a duplicate of bug 41067 ***
Firefox 20 on ubuntu 13.04 too. 

Didn't see any error in the JS console.
I saw it in Firefox 20 on Fedora 18.
Also - it would be very valuable to know if there are any errors in JS console.
Any information about web browser and OS?
EditPage.php has a prominent notice that users are editing an oldid page; VE should have something similar, probably in the "notices" functionality.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Merged and will go out with wmf5 on 27 May.
Related URL: https://gerrit.wikimedia.org/r/65291 (Gerrit Change I216cdd68014173aa65cad42ddd3d870334be9ead)
(In reply to comment #2)
> EditPage uses msg: editingold[1].
> 
> [1] https://www.mediawiki.org/wiki/MediaWiki:Editingold/en

Ah, yes, whoops. Good catch.
EditPage uses msg: editingold[1].

[1] https://www.mediawiki.org/wiki/MediaWiki:Editingold/en
This looks to be <Revision-info>. :-)
Edit a page in VE, press save; enter VE again.

What should happen: You edit the newly-updated page.

What does happen: You edit the content of the page before you updated it (and VE doesn't know it's doing this).

--------------------------
**Version**: unspecified
**Severity**: minor
*** Bug 48395 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 47420 ***
*** Bug 48021 has been marked as a duplicate of this bug. ***
The VE becomes active on .js and .css pages in the user namespace, even though it is not capable of handling this content type.

--------------------------
**Version**: unspecified
**Severity**: minor
**URL**: https://en.wikipedia.org/wiki/User:TheDJ/common.js
*** Bug 48471 has been marked as a duplicate of this bug. ***
Merged by Catrope.
Gerrit change 63341
*** Bug 47768 has been marked as a duplicate of this bug. ***
Yup, we should expand this more generally to all things that have a different ContentHandler type. We already depend on MW 1.21 in general, so I guess(?) this shouldn't be too much of a problem.
If in a page you click 'Edit source', the tab does not receive the 'selected' styling/class as it is supposed to.

This was confirmed with Safari 6 mac.

--------------------------
**Version**: unspecified
**Severity**: trivial
*** Bug 48316 has been marked as a duplicate of this bug. ***
Now merged and will go live with wmf4.
Related URL: https://gerrit.wikimedia.org/r/62145 (Gerrit Change Ic2d42bb3034be25f388b587a00c3f523cfcc163c)
Pretty sure I made this work a couple of weeks ago, but it might have been broken by the more recent changes to this code.
a </table> tag is sometimes inserted into data-parsoid when set on a table element, for example in the 'Infobox settlement' at http://en.wikipedia.org/wiki/Beale_Township,_Juniata_County,_Pennsylvania.

Original data-parsoid (part of):
Beale Township,<br/>Pennsylvania\n

VE output (editedHtml):
Beale Township,<br></table>Pennsylvania\n

--------------------------
**Version**: unspecified
**Severity**: normal
*** This bug has been marked as a duplicate of bug 47417 ***
If you have lines like so:

| A
| B
| 
| C

Deleting backwards from up-page of C, or from within the blank line above C, causes the cursor to move (as expected) but no deletion.

Deleting forwards from down-page of B, of from within the blank line below B, causes the cursor to stay (as expected) but no deletion.

--------------------------
**Version**: unspecified
**Severity**: normal
This is now fixed with the deletion re-write.
(a) open a page in VE and edit it
(b) save in VE 
(c) reopen the same page right away in VE

The previous version (rather than saved version) is fetched.  I looked at POST params in chrome and looks like revision id (oldid) being sent is of the older version rather than the saved version.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #11)
> That is bug 50441.

Yes; sorry! :-)
That is bug 50441.
Re-closing; new breakage is being tracked as bug 47420.
This bug was closed as fixed on May 3 but I am still seeing this behavior on mediawiki.org. The second edit after saving loads the previous version of the page, not the current version. A warning "You are editing an out-of-date revision of this page" appears, but that doesn't help.
*** Bug 48021 has been marked as a duplicate of this bug. ***
*** Bug 47682 has been marked as a duplicate of this bug. ***
Now merged and will go into wmf4.
Related URL: https://gerrit.wikimedia.org/r/62168 (Gerrit Change I12ce27c8dc57f7aa753bcf5840635d5fea6b4e80)
(In reply to comment #3)
> The JSON we get back after a save only contains the plain html and some
> timestamps. In order for us to update this.oldid we'll need Parsoid to tell
> us what it is, I think.

Parsoid doesn't know; it's VisualEditor.php which does the actual saving to the DB.
The JSON we get back after a save only contains the plain html and some timestamps. In order for us to update this.oldid we'll need Parsoid to tell us what it is, I think.
This is because we don't update this.oldid after saving.
Feels like we need to properly review how the integration around oldids works, given the number of issues. :-(
See https://en.wikipedia.org/w/index.php?title=User:Fluffernutter/Kinne&diff=551148728&oldid=551148307

To investigate.

--------------------------
**Version**: unspecified
**Severity**: major
This is an instance of the jQuery bug 47737 - marking as FIXED (in the specific instance) but we need a wider fix.
*** Bug 47430 has been marked as a duplicate of this bug. ***
(In reply to comment #7)
> (In reply to comment #6)
> > This is a bug in jQuery. To reproduce:
> 
> That confirms my suspicion. The bug appeared first after you started using it
> to avoid dropping figure elements.
Yup, which is why we can't just go back, because that would break <caption> elements again.

Filed upstream as http://bugs.jquery.com/ticket/13821
The reason this doesn't happen in Chrome is because Chrome normalizes < to &lt; in attribute values in .innerHTML. Firefox doesn't do this and gives us the original < as originally provided by Parsoid.

The presence of these <> then triggers a jQuery regex looking for self-closing tags:

/<(?!area|br|col|embed|hr|img|input|link|meta|param)(([\w:]+)[^>]*)\/>/gi

...which believes our span (!) is self-closing because it starts with <span and contains /> later, so it helpfully "fixes" our HTML and replaces the /> with </span>
Ed's quick hack is now merged, but we still need to fix this - upstream bug in jQuery or just a work around?
(In reply to comment #6)
> This is a bug in jQuery. To reproduce:

That confirms my suspicion. The bug appeared first after you started using it to avoid dropping figure elements.
This is a bug in jQuery. To reproduce:

>>> $( '<div>' ).html( '<span data-parsoid="{&quot;src&quot;:&quot;<ref name=\&quot;Foo\&quot; />&quot;,&quot;tsr&quot;:[32,50],&quot;dsr&quot;:[32,50,null,null]}">' ).html();

"<span data-parsoid="{&quot;src&quot;:&quot;<ref name=&quot;Foo&quot; ></span>&quot;,&quot;tsr&quot;:[32,50],&quot;dsr&quot;:[32,50,null,null]}"></span>"
This is what I see using wget, FF, and the parse.js in the shell:

<span id="cite_ref-rfc3092-1-0" class="reference" about="#mwt5" typeof="mw:Object/Ext/Ref" data-parsoid='{"src":"<ref name=\"rfc3092\" />","tsr":[416,438],"dsr":[416,438,null,null]}'><a href="#cite_note-rfc3092-1" data-parsoid="{}">[1]</a></span><meta typeof="mw:Ext/Ref/Marker" about="#mwt5" group="" name="rfc3092" content="" skiplinkback="0" data-parsoid='{"tsr":[416,438],"selfClose":true,"src":"<ref name=\"rfc3092\" />","dsr":[416,438,22,0]}'>

Make sure you are not looking at a pretty-printed inspect tool. Either use innerHTML (which will use non-smart quoting) or the actual page source (ctrl-u in Firefox).

From what I see Firefox parses our HTML just fine on the way in, with the entire JSON string being parsed as the attribute value. Do you actually see a parsing difference on the way in resulting in a different DOM?

Changing the title back, as I am pretty sure this is not a bug on our end.
The problem appears to be with the output from Parsoid with regard to <ref> tags not being escaped.

To give http://parsoid.wmflabs.org/en/Foobar as an example, in Chrome this looks fine:

<span id="cite_ref-rfc3092-1-0" class="reference" about="#mwt5" typeof="mw:Object/Ext/Ref" data-parsoid="{&quot;src&quot;:&quot;<ref name=\&quot;rfc3092\&quot; />;&quot;,&quot;tsr&quot;:[416,438],&quot;dsr&quot;:[416,438,null,null]}"><a href="#cite_note-rfc3092-1" data-parsoid="{}">[1]</a></span>
<meta typeof="mw:Ext/Ref/Marker" about="#mwt5" group="" name="rfc3092" content="" skiplinkback="0" data-parsoid="{&quot;tsr&quot;:[416,438],&quot;selfClose&quot;:true,&quot;src&quot;:&quot;&lt;ref name=\&quot;rfc3092\&quot; /&gt;&quot;,&quot;dsr&quot;:[416,438,22,0]}">


... but in Firefox the browser presumably doesn't like the un-escaped "<ref name=... />" in the attribute of the <span> and so it does this:

<span id="cite_ref-rfc3092-1-0" class="reference" about="#mwt5" data-parsoid="{"src":"<ref name=\"rfc3092\" />","tsr":[416,438],"dsr":[416,438,null,null]}" typeof="mw:Object/Ext/Ref"></span>
<meta typeof="mw:Ext/Ref/Marker" about="#mwt5" group="" name="rfc3092" content="" skiplinkback="0" data-parsoid="{"tsr":[416,438],"selfClose":true,"src":"<ref name=\"rfc3092\" />","dsr":[416,438,22,0]}"></meta>

I.e., closing the <span> early and throwing away the contents. Note that the following meta is also fragile as it contains unescaped JSON as well.

The result of this is that <ref name="…" /> is wrongly expanded to <ref name="…" ></span> and so corrupted on save by Firefox users.
Related URL: https://gerrit.wikimedia.org/r/60840 (Gerrit Change Ib6a0cfb880e769f28b42c9fa63ddc1abc75c399d)
*** Bug 47419 has been marked as a duplicate of this bug. ***
This seems to be Firefox specific.  I am seeing this on a lot of pages in Firefox, but not in Chrome.  Gabriel can reproduce as well.
Screenshot of the problem

On the "page" view, when an outdated translation is opened, the editor shows a disabled "save translation" as the main action.

It should show an enabled "Confirm translation" button instead (as it is the case for the "list" view).

I found the bug on outdated translations at https://translatewiki.net/w/i.php?title=Special:Translate&group=ext-visualeditor&language=ca&filter=&action=page

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

**Attached**: {F10395}
Ordinarily there's an accesskey (e.g. alt+shift+E in Firefox) on the "Edit" tab in Vector. The accesskey is made known to the user through a tooltip. VisualEditor eliminates this accesskey and tooltip, and adds a new "Edit source" tab without an accesskey or tooltip. 

Ideally both the "Edit" and "Edit source" tab should have accesskeys and tooltips to allow quick switching between the modes for power users.

--------------------------
**Version**: unspecified
**Severity**: normal
Code is now merged and will go out on Thursday.
Change-Id: If598552fac639da645a8b1273c5fc6028695fcc1

> @@ -777,10 +778,10 @@ ve.init.mw.ViewPageTarget.prototype.setupSkinTabs
>  			this.veEditUri,
> -			$caEdit.text(),
> +			$caEditA.text(),
>  			$caEdit.attr( 'id' ),
> -			$caEdit.attr( 'title' ),
> -			$caEdit.attr( 'accesskey' ),
> +			$caEditA.attr( 'title' ),
> +			$caEditA.attr( 'accesskey' ),
>  			caVeEditSource
>  		);
>  	}
Related URL: https://gerrit.wikimedia.org/r/60241 (Gerrit Change If598552fac639da645a8b1273c5fc6028695fcc1)
When mw.ViewPageTarget has its tabLayout in "replace" mode (where it replaces the regular Edit tab with a VE-version and adds an Edit source tab) the code explicitly copies over the label, tooltip and accesskey.

It appears this isn't working anymore. I worked a week ago. The code hasn't changed so it looks like something else has broken it.

Moving bug to Integration (perhaps the component should be renamed to "MediaWiki integration")
1. Open http://ve-change-marking.instance-proxy.wmflabs.org/wiki/Test
2. Double-click a word and type a single-char
   (you see that the selected word continues to show in the interface after the char you typed)
3. Look at review-and-save.
4. The word has actually been deleted => the interface is not updated as it should

(4) causes the user (=me in this case) to repeatedly try and delete that word and is instead deleting newer words which will all show up in the diff without realizing that they are being deleted.

--------------------------
**Version**: unspecified
**Severity**: major
Inez fixed this.  Possibly https://gerrit.wikimedia.org/r/#/c/59965/
What browser/version are you using? I cannot reproduce in Chrome/Mac or Firefox/Mac - see http://ve-change-marking.instance-proxy.wmflabs.org/srv/mediawiki/index.php?title=Test&diff=45&oldid=44 for a successful run. (Or maybe the code got fixed between the report and my looking at it?)
When loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end. This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to comment #3)
> This might be fixed by bug 48344.
It most probably is, yes (bug 48344 is only fixed when selser is on, but it's on in production so that's fine). Closing this bug unless and until someone can get a newline to show up again.
This might be fixed by bug 48344.
Eh, disregard that link- belongs to bug 47419.
Example edit: https://en.wikipedia.org/w/index.php?title=User:Fluffernutter/Kinne&curid=37842561&diff=551148728&oldid=551148307
For performance reasons, we should lazy-update SurfaceFragments rather than updating them through a transact event handler.

The performance problem occurs when you create a bunch of fragments, then throw them away. The fragments are never actually destroyed, if only because the surface still has references to them because of the event binding. The discarded fragments continue to receive events about transactions and update themselves in response, but no one is using them any more.

Instead, I propose the following:

* The surface should have an ordered array of [transaction, direction] pairs that tracks everything that has ever been applied. This is not the same as the undo/redo stacks: this particular array is append-only
* Every SurfaceFragment has a property indicating which transaction (by index in the big array) is the last one that it knows about
* SurfaceFragments do not listen for transact events
* Instead, every time getRange() is called, the fragment asks the surface whether there are new transactions (with indices greater than the stored index), and if so it translates its range for them
** For this to work, all internal uses of this.range need to be changed to this.getRange()

This'll make the fragment lazy-update its range, and we won't spend any time updating fragments that aren't being used.

--------------------------
**Version**: unspecified
**Severity**: normal
Now merged.
Related URL: https://gerrit.wikimedia.org/r/60256 (Gerrit Change I9e9818da1baa8319a3002f6d74fd1aad6732a8f5)
Trevor is adding a bunch of .destroy() calls to SurfaceFragment uses to mitigate the problem. These should be removed once this is implemented.
In advance of fixing bug 47328 (which will probably be after the July release), we need to prevent the broken behaviour outlined by C. Scott in bug 47328 comment 1 - so just refuse to load on a page which is a redirect?

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=47328
Merged; will go out with wmf5.
Related URL: https://gerrit.wikimedia.org/r/64275 (Gerrit Change I68836156c35c796aa2156c382992b0c105ae34cf)
(In reply to comment #3)
> It seems like it would be trivial to check whether the page is a redirect and
> simply disable VisualEditor if so. I'm adding the "easy" keyword to this bug.

It gets a bit trickier if the page does not yet exist, though.
It seems like it would be trivial to check whether the page is a redirect and simply disable VisualEditor if so. I'm adding the "easy" keyword to this bug.
(In reply to comment #1)
> For me, if you tried to edit a redirect page, it loads with the redirected
> page.

Yes, this is current behaviour from Parsoid that will be fixed by fixing bug 47328, but that will leave users with a very confusing blank page. That is why I made this bug. :-)
**dayuloli** wrote:

For me, if you tried to edit a redirect page, it loads with the redirected page.
In ve.init.mw.Target.prototype.reportProblem, we pass an HTMLDocument to getDataFromDom(), but this function now takes two parameters, with the IVStore coming first, so it fatals with "doc is undefined".

In addition to passing in a store, we'll also need to expand the returned data before transmitting it, per bug 47318.

--------------------------
**Version**: unspecified
**Severity**: normal
This is now merged.
Related URL: https://gerrit.wikimedia.org/r/59642 (Gerrit Change I761523d22e51ac560e37ae991d01a6b84224ca40)
--------------------------
**Version**: unspecified
**Severity**: normal
Related URL: https://gerrit.wikimedia.org/r/60925 (Gerrit Change I4819cf06d1bd0ae4f8b896052e278ca75c9551bf)
We're cloning html/data-parsoid which Subbu tells me messes with selser correctness

--------------------------
**Version**: unspecified
**Severity**: normal
This is now merged.
Related URL: https://gerrit.wikimedia.org/r/59836 (Gerrit Change I428becf95c70d0ed8af5b0c408e3966dc47fd8c3)
Roan clarified on IRC that this is not happening right now, but about and typeof attributes should not be cloned either. Just adding here to track info. in one place.
To give an example:
mediawiki.page.ready.js runs on mobile (it specifies targets=>mobile) however attempts to lazy load the tablesorter plugin which is not available on mobile (it specifies targets=>desktop)

This currently throws an exception.

Avoiding a bike shedding conversation about whether jquery.tablesorter should be available on mobile, it is wrong to make the assumption that a module will always be available.

Expected: Instead of seeing an exception I would like to allow the user to handle the error themselves - allowing optional modules to die silently.

e.g.
mw.loader.using( 'jquery.tablesorter', function () {
	$sortableTables.tablesorter();
}, function( e ) {
throw e;
});

or 
mw.loader.using( 'jquery.tablesorter' ).done( function () {
	$sortableTables.tablesorter();
});

Another example of this being a problem is on the edit page which asumes mediawiki.action.edit is available:

mw.loader.using("mediawiki.action.edit"

Currently there is a hack in MobileFrontend to get around this [1]


[1] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/MobileFrontend.git;a=blob;f=includes/skins/SkinMobile.php;h=27ab4ef44fc138566bbf3e1ab32cd5af20daf246;hb=HEAD#l241

--------------------------
**Version**: 1.22.0
**Severity**: normal
I'll tentatively close this, then, to have less stuff seemingly blocking the release.
I am happy for someone to agree with Krinle and close this as WONTFIX
The mobile skin doesn't load mediawiki.page.ready now since we introduced Skin::getDefaultModules so the original problem isn't a problem.

If someone really wants to load something optionally they can use a try / catch
Is this blocking the release, and if yes, why has nobody done anything about it? I sympathise with Krinkle's comment 7.
As the Target Milestone on this ticket has been set to 1.22.0:

According to http://lists.wikimedia.org/pipermail/wikitech-l/2013-September/072030.html "MediaWiki 1.22 is slated for release on November 30th, at the very latest."

If this is still intended to get fixed for 1.22.0, a patch is needed soon.
This is now less of a problem in mobile as we have reduced the possibility of this happening to only situations where a module has been renamed/typed incorrectly/ is not available due to being in mobile mode rather than desktop. The tablesorter exception is no longer called.

My main worry about this is that since ResourceLoader concatenates code one module failing can prevent the execution of another module. This seems wrong. I can understand an entire module from throwing an exception and not executing but stopping all javascript from executing seems wrong.

I really don't understand the need for an exception under all circumstances. Could we not default the error handler to throwing an exception to at least allow developers to override it. For example a gadget might want to do something with a module if it's available but fail silently if it's not so it can be used on as many wiki's as possible that may or may not have the module it does something with)

// module 1
mw.loader.using( 'foobar', function() {
} );

// module 2
(function(){ alert( 4 ); })()

On a similar subject it would be great to see mw.loader.using return a jQuery.deferred object.
See bug 47882 to discuss my side note about mediawiki.page.ready - please leave discussion on this bug simply about behaviour for when a module doesn't exist.
For the curious, you can find the problematic behavior exemplified on:
https://en.m.wikipedia.org/wiki/Wikipedia:Sortable_table
**jgonera** wrote:

Krinkle, I agree. If we deprecate the error callback, then throwing an error is OK. But let's make it consistent.

Also, Jon, this particular mediawiki.action.edit case will become less important to us because we can, and hopefully soon will, provide our own custom edit form, instead of the one generated by EditPage.php.
(In reply to comment #5)
> That change should go out during next Tuesday's regular deployment

For the deployment I think it is more feasible to simply enable jquery.tablesorter on mobile. We can decide whether to surpress error reporting on missing dependencies later.
Re-opening. Please don't mark bug fixed until they are approved and landed in master.
That change should go out during next Tuesday's regular deployment
Related URL: https://gerrit.wikimedia.org/r/60346 (Gerrit Change Ic2f81b725acac2086178e33033f10c4c80ae1573)
Well it's more a historic problem. If a module has been added via out->addModules previously requesting a module vs mw.loader.using was unlikely to throw an exception.

Now with the targets property this becomes more muddled.. a module may or may not be there - it's at the mercy of the current target.

My suggestion is to alter the implementation mw.loader.using so instead of throwing an error it accepts an error callback or even better is rewritten to return a deferred object.

It should be up to the developer to throw an exception.
**jgonera** wrote:

So what is the problem exactly? How the proposed solutions fix it? Why wouldn't the developer do:

try {
    mw.loader.using( ...
} catch ( e ) {
    ...
}
"allow the user to handle the error themselves" should read "allow the developer to handle the error themselves"
Our current setup for custom hashing objects to to give them a method .getHash() which looks like this:

T.prototype.getHash = function () {
  var someSubsetOfT = // code here
  return ve.getHash( someSubsetOfT );
}

and to invoke we use

 ve.getHash( instanceOfT );

However ve.getHash( instanceOfT ) === ve.getHash( ve.getHash( someSubsetOfT ) )
which isn't really what we want.

One solution would be to rename getHash to getHashableObject (or something) and have it return just someSubsetOfT directly.

--------------------------
**Version**: unspecified
**Severity**: normal
Reopened for 58241, but now that is done am closing again.
Ed, did you re-open because there's more to do, or because Jenkins dying meant the changes weren't merged? :-)
Related URL: https://gerrit.wikimedia.org/r/58241 (Gerrit Change I6a9b42facd97fbf49042d3a082121ec93659b9f1)
Related URL: https://gerrit.wikimedia.org/r/58235 (Gerrit Change If11071d4b04a01e25102ffb57240882f650ee10d)
e.g. inserting <p>c</p><p>d</p> into <p>ab</p> between a and b results in

<p>a</p><p>c</p><p></p><p>d</p><p>b</p>

This is because fixUpInsertion fixes c & d separately and after inserting c (by closing out a) it decides to re-open the paragraph it closed (sensible), but the d comes along as splits that new paragraph (not sensible), resulting in a blank paragraph between the two.

--------------------------
**Version**: unspecified
**Severity**: normal
NB: this bug is not restricted to paragraphs
https://gerrit.wikimedia.org/r/#/c/55791/
e.g. inserting a <p>Bar</p> into <p>Foo</p> after the last 'o' results in:

<p>Foo</p><p>Bar</p><p></p>

The original paragraph is split, then the Bar is inserted, then the paragraph is reopened again.

Or in transaction terms:

insert: '<p>Bar</p>'

coverts to

insert: </p><p>Bar</p><p>'

--------------------------
**Version**: unspecified
**Severity**: normal
Gerrit 61048 is now merged; marking as fixed - will go out in Monday's deploy train.
For some reason the bug isn't reporting this: https://gerrit.wikimedia.org/r/#/c/61048/ addresses this and is waiting for jenkins-bot to merge it.
This is in preparation for performing transactions on templates and having to update the html asynchronously.

--------------------------
**Version**: unspecified
**Severity**: normal
This has been done in https://gerrit.wikimedia.org/r/#/c/57326/
If Parsoid has a meta thing for defaultsort that is

--------------------------
**Version**: unspecified
**Severity**: normal
This is now merged.
Related URL: https://gerrit.wikimedia.org/r/61374 (Gerrit Change I604a79c25e5b0315f7e6437da657977b0efa77db)
Now defined as:

  {{DEFAULTSORT:foo}}

->

  <meta property="mw:PageProp/categorydefaultsort" content="foo">

From https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Category_default_sort_key

[Parsoid does not yet support editing of these items.]
I am just trying at w:en:Vojníkov hyperlink from "Louka" to "Louka (village)". The actual link is incorrect. Using VisualEditor and FF 19.0 or G Chrome 25.0.1364.152 m. If I start to type "Louka" it adds "Loukas Vyntra" automaticaly. If I use backspace it allows me to delete "Vyntra" and when I delete "s" of "Loukas", it adds again "Loukas Vyntra".

--------------------------
**Version**: unspecified
**Severity**: normal
Confirming that this is now fixed. Sorry for the delay in responding.
Thanks for the report; this is a known issue - I think we've fixed it but it's not yet pushed to live - throwing to Trevor to confirm.
VisualEditor should be deployed to the Hebrew Wikipedia as soon as possible. I did some basic testing on my machine, and I see that it's more or less as functional as it is on the English - basic formatting works, and even basic RTL is correct.

Obviously, there are many RTL issues to test there. I am doing such testing myself every now and then, but letting more people test will be far more beneficial.

Of course, I am talking about a dark launch at this point - it should only be available to users who specifically request it.

--------------------------
**Version**: unspecified
**Severity**: enhancement
\ס/

Thank you!
This is now deployed to hewiki (and 13 others).
Related URL: https://gerrit.wikimedia.org/r/60293 (Gerrit Change Ic9ee32df65ee9d885bf19a1592e1e8e3a8d54db0)
This is now scheduled for 2013-04-25.
This is very high priority for us (for hewiki and all the others of course), but as Roan says it's blocking on a version of Parsoid that we can deploy that will work with non-English wikis - see bug 43332 for details.
I support this, but I will make one observation. The version of Parsoid that's running in production is fairly old (2012-12-12 or thereabouts), so if there's anything in Parsoid that Hebrew depends on that was added after mid-December, it won't be live yet.

We can't upgrade Parsoid right now because the Parsoid team is rewriting the serializer and master is too broken to deploy right now. We'll probably make a deployment attempt within the next two weeks, but until then, we'll keep running this ancient (but apparently stable, for English at least) version of Parsoid.
**Author:** `afeldman`

**Description:**
The FORCE INDEX provided in this query results in a /much/ slower query plan than without.  This is the case with both MySQL 5.1-facebook, and MariaDB 5.5, so it should just be removed.

Query:

SELECT /* IndexPager::buildQueryInfo (contributions page unfiltered) user */  rev_id,rev_page,rev_text_id,rev_timestamp,rev_comment,rev_user_text,rev_user,rev_minor_edit,rev_deleted,rev_len,rev_parent_id,rev_sha1,user_name,page_namespace,page_title,page_is_new,page_latest,page_is_redirect,page_len,ts_tags  FROM `revision` FORCE INDEX (user_timestamp) INNER JOIN `page` ON ((page_id = rev_page)) LEFT JOIN `user` ON ((rev_user != 0) AND (user_id = rev_user)) LEFT JOIN `user_groups` ON ((ug_user = rev_user) AND  ug_group = 'bot') LEFT JOIN `tag_summary` ON ((ts_rev_id=rev_id))  WHERE (rev_user >18370655) AND (ug_group IS NULL) AND ((rev_deleted & 4) = 0) AND (rev_timestamp<'20130301192103')  ORDER BY rev_timestamp DESC LIMIT 51;

Times of the query as above:

production enwiki master - mysql 5.1-facebook:  51 rows in set (7 min 23.03 sec) 
mariadb 5.5.29:  51 rows in set (1.29 sec)

Times with the FORCE INDEX (user_timestamp) removed
production enwiki master - mysql 5.1-facebook:  51 rows in set (0.26 sec)
mariadb 5.5.29:  51 rows in set (0.20 sec)

The EXPLAIN without the FORCE INDEX looks worse on 5.1 without than with, based on number of rows examined, but it avoids a filesort.  It looks better without the FORCE INDEX on mariadb than mysql 5.1 with or without.  In both cases, rev_timestamp is used instead of user_timestamp.

--------------------------
**Version**: 1.21.x
**Severity**: normal
Presumed fixed.
Change 96228 merged by jenkins-bot:
remove specific FORCE INDEX clauses causing trouble

https://gerrit.wikimedia.org/r/96228
Change 96228 had a related patch set uploaded by Aaron Schulz:
remove specific FORCE INDEX clauses causing trouble, bug 45619

https://gerrit.wikimedia.org/r/96228
Change 96228 had a related patch set uploaded by Springle:
remove specific FORCE INDEX clauses causing trouble, bug 45619

https://gerrit.wikimedia.org/r/96228
Not entirely sure why I was CCed on this, but...

Regarding the FORCE INDEX (user_timestamp) in comment 0, that appears to be coming from includes/specials/SpecialContributions.php, ContribsPager::getUserCond() and ContribsPager::getQueryInfo(). git archeology finds that this force index was added way back in 2005, r9796.

Regarding the FORCE INDEX (change_tag_tag_id) in comment 3, that's coming from ChangeTags::modifyDisplayQuery(), added in r49068 with a comment "fix tag filtering by adding a FORCE INDEX to the relevant queries". There's also forcing of that index in API modules that do the same sort of thing added in r58399, which refers to bug 22032, which makes it sound like r49068 was fixing some issue where a bad query was bringing down the site. Since I have no idea of the background on that and the problematic queries don't seem to be mentioned in the change summaries, I'm CCing some of the people involved in those revisions.
Found another example of this with a slightly different query form:

SELECT /* IndexPager::buildQueryInfo (contributions page unfiltered) 14.0.143.195 */ rev_id,rev_page,rev_text_id,rev_timestamp,rev_comment,rev_user_text,rev_user,rev_minor_edit,rev_deleted,rev_len,rev_parent_id,rev_sha1,user_name,page_namespace,page_title,page_is_new,page_latest,page_is_redirect,page_len,ts_tags FROM `revision` INNER JOIN `page` ON ((page_id = rev_page)) LEFT JOIN `user` ON ((rev_user != 0) AND (user_id = rev_user)) LEFT JOIN `tag_summary` ON ((ts_rev_id=rev_id)) INNER JOIN `change_tag` FORCE INDEX (change_tag_tag_id) ON ((ct_rev_id=rev_id)) WHERE rev_user = '3030741' AND ((rev_deleted & 4) = 0) AND ct_tag = 'visualeditor' ORDER BY rev_timestamp DESC LIMIT 51;

On enwiki, forcing the index hits ~900000 rows with a temp table and filesort. Without the force: ~50000 rows, no temp table or filesort.

Both 5.1 and 5.5 EXPLAIN look the same, so removing this FORCE on change_tag_tag_id would also be a win across the board.
Bump. These queries forcing user_timestamp are running for 5+ minutes on slaves for several of the bigger WMF wikis.

Multiple identical copies running simultaneously too, presumably when clients assume slow == failure and blindly retry.

Re comment 2: Example would be good. Best to review EXPLAIN output for one forcing usertext_timestamp. It might be a completely different story.
(In reply to comment #0)
> The EXPLAIN without the FORCE INDEX looks worse on 5.1 without than with,
> based
> on number of rows examined, but it avoids a filesort.  It looks better
> without
> the FORCE INDEX on mariadb than mysql 5.1 with or without.  In both cases,
> rev_timestamp is used instead of user_timestamp.

	function getIndexField() {
		return 'rev_timestamp';
	}



There is also code using usertext_timestamp:

			if ( $uid ) {
				$condition['rev_user'] = $uid;
				$index = 'user_timestamp';
			} else {
				$condition['rev_user_text'] = $this->target;
				$index = 'usertext_timestamp';
			}


CREATE INDEX /*i*/user_timestamp ON /*_*/revision (rev_user,rev_timestamp);
CREATE INDEX /*i*/usertext_timestamp ON /*_*/revision (rev_user_text,rev_timestamp);


I guess we should remove the force index for that one too?
When we unwrap lists, we currently preserve the internal 'generated' property on paragraphs inside those lists, but we really shouldn't. The fact that we don't currently clear this when unwrapping results in the following serious bug:

1. Create a page with the following content
Foo
Bar
* Baz
* Quux
* Whee
Yay
2. Open the page in VE
3. Select across the three list items and click the list button to unlist them
4. VE now shows five paragraphs
5. Click "Review and save" and observe the diff.

Expected diff: the asterisk and space before "Baz", "Quux" and "Whee" are removed.

Actual diff: the second line becomes "BarBazQuuxWhee", followed by three blank lines, then "Yay".

This happens because the converter unwraps paragraphs with the 'internal': { 'generated': 'wrapper' } property, even if these paragraphs now appear in a different context and even if there are multiple such paragraphs adjacent to each other.

--------------------------
**Version**: unspecified
**Severity**: normal
Code now merged.
https://gerrit.wikimedia.org/r/#/c/52046/
1. Create a document "First line.Second line"
2. Select this text and insert a newline between the '.' and the 'S' (currently, using the Enter key).

Expected result: a single <pre> block with a single newline after the full stop, converting to " First line.\n Second line" in wikitext. Note that this is trivially-obvious on MW Vector due to the "border: 1px dashed #2f6fab;".

Actual result: two separated <pre> blocks (with a slug between them), converting to " First line.\n\n Second line" in wikitext.

I presume that we'll want to retain Enter as a break-me-out-of-this-context newline, and use Shift-Enter to allow insertion of the above.

--------------------------
**Version**: unspecified
**Severity**: normal
**orbit** wrote:

Fixed here: https://gerrit.wikimedia.org/r/#/c/50862/
Stuff like ve.dm.MWInternalLinkAnnotation , ve.dm.modelRegistry.registerExtensionSpecificType( /^mw:/ ), etc.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Fixed as part of a larger move in https://gerrit.wikimedia.org/r/71755
Roan, is this now closeable?
Some more MW specific nodes:
https://gerrit.wikimedia.org/r/#/c/51621/
Changes made in screen

Issues of editing when making changes in a section of https://en.wikipedia.org/wiki/William_Francis_Magie - probably Parsoid selser issue. JDF to re-check when new Parsoid deployed.

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

**Attached**: {F10305}
This is now fixed given the Parsoid update, yay.
Created attachment 11825
Diff coming back with only changed area

**Attached**: {F10306}
The method should isolate a selection of siblings from the siblings either side of it by creating close/open tags with either side of it where necessary.

--------------------------
**Version**: unspecified
**Severity**: normal
This code was merged.
https://gerrit.wikimedia.org/r/#/c/50199/
--------------------------
**Version**: unspecified
**Severity**: normal
This is now merged.
Public documentation at http://www.mediawiki.org/wiki/VisualEditor/Change_markers should be deleted or marked as deprecated once this has been merged.
https://gerrit.wikimedia.org/r/#/c/49363/
In order to implement a category editor, we'll need to be able to process transactions on metadata.

--------------------------
**Version**: unspecified
**Severity**: normal
https://gerrit.wikimedia.org/r/#/c/49182/
1. Load a new (i.e. not currently existing) page into VE
2. Type some text
3. Click "Review and save". The corresponding wikitext appears in a flyout
4. Close the flyout using the up arrow
5. Change the text in the editor
6. Click "Review and save" again.

The flyout that appears in #6 will display the same wikitext as in #3, even though you changed the document. The diff flyout handles this correctly (i.e. it caches the old diff until you change something), but the serialization flyout for new page creation never clears its cache.

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

**Description:**
shows the result after a save with 'friend' being duplicated

Text was several lines long
Placed cursor at start of last line
Pressed delete to move the line up to the same line as the second to last
Saved
The last line has not been deleted and it also present on the second to last

Screenshot attached
This
is
the
end
my
friend

- put cursor at start of friend and pressed delete and then added a space

Screenshot shows the result, 'friend' is now in twice

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

**Attached**: {F10875}
This is now fixed given the Parsoid update. Sorry for the delay.
Thanks for this, report Phil; I can confirm the issue.

It is probably due to us running quite an old version of Parsoid on the live service; we need to update it to a newer version (which has been delayed for other before I can determine if we still have action to take here).
**Author:** `phil`

**Description:**
Page after cut and paste of 'a b c' only showing the 'a'

Created a simple file
a
b
c

Copied all the text, placed the cursor after the 'c' and pasted it
The 'a' from the copy was pasted, the 'b' and 'c' were lost

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

**Attached**: {F10869}
This is now fixed given the Parsoid update. Sorry for the delay.
Ah, right. This is, I think, a Parsoid-related bug, which should get fixed when the new version of Parsoid can be deployed; assigning to myself for review when we get that out.
**orbit** wrote:

I think this is a serialization bug. The linear model shows the full data after paste:  
[
Object
, "a", 
Object
, 
Object
, "b", 
Object
, 
Object
, "c", "a", 
Object
, 
Object
, "b", 
Object
, 
Object
, "c", 
Object
]
but it's not correctly saving. Testing here: http://www.mediawiki.org/wiki/VisualEditor:CopyPaste
**phil** wrote:

This was Safari/Mac - I have just tried it on Chrome/Mac and was able to reproduce

Just to confirm the steps
a
b
c

Save this - this is 3 separate lines
Edit
Copy all the text, paste after the 'c'
Phil, what browser were you using? I'm afraid I cannot reproduce on Chrome/Mac or Safari/Mac; Firefox has wider issues (that mean I can't copy-and-paste anything; to follow-up).
Screenshot

When edited in VisualEditor, the following table:

```
{| class="wikitable"
|- 
! Header
|-
| {{Yes}}
|}
```
... shows the following string in place of the {{Yes}} template:

style="background: #90ff90; color: black; vertical-align: middle; text-align: center; " class="table-yes"|Yes
﻿
See screenshot.
Live at http://en.wikipedia.org/wiki/User:Nicolas1981/Sandbox

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

**Attached**: {F10493}
Change 76861 abandoned by Subramanya Sastry:
WIP: first draft of td reparse.

Reason:
Not required anymore. A DOM-based solution is already merged and in production.

https://gerrit.wikimedia.org/r/76861
Minor niggle: The caches are not yet cleared as we don't have the rights to do so. Cached pages will only update to the correct rendering after that has happened.
(In reply to comment #31)
> (In reply to comment #19)
> > Scott, is the glitch with the certification tables at
> > http://en.wikipedia.org/w/index.
> > php?title=Metallica_%28album%29&oldid=566196578&veaction=edit
> > another effect of 50589, this bug, or should I open a new bug report for it?
> 
> That was bug 50589, which is now fixed.

Correction: It was very similar to 50589, but not quite the same.

In other news about this bug, https://gerrit.wikimedia.org/r/#/c/79943/ is now deployed, which covers the vast majority of cases including the ones mentioned here. Closing as fixed.
(In reply to comment #19)
> Scott, is the glitch with the certification tables at
> http://en.wikipedia.org/w/index.
> php?title=Metallica_%28album%29&oldid=566196578&veaction=edit
> another effect of 50589, this bug, or should I open a new bug report for it?

That was bug 50589, which is now fixed.
The DOM handler is now ready for review in https://gerrit.wikimedia.org/r/#/c/79943/.
I'm working on a DOM-based handler for this. Re-assigning the bug to myself.
Parsoid support for this and a related table parsing issue is tracked in bug 50603, and should be ready in the next weeks.
**kwwilliams** wrote:

(In reply to comment #26)
> On the enwiki-20130102-pages-articles-multistream.xml.bz2 dump, there are:
>  13,057,082 articles, of which

That looks like all namespaces, not just articles.

>  11,877 (0.091%) have some use of [[Template:Table_cell_templates]], and
>  1,875 (0.014%) have a non-trivial use (ie, the preceding character is not
> |).

That sounds about right. As a percentage of our most frequently edited articles, I suspect the percentage is much higher, though. The primary use is in award tables, and while the millions of articles about ghost towns, obscure shellfish, and asteroids tend not to discuss awards, while the ones about modern music, television, and films frequently do.
On the enwiki-20130102-pages-articles-multistream.xml.bz2 dump, there are:
 13,057,082 articles, of which
 11,877 (0.091%) have some use of [[Template:Table_cell_templates]], and
 1,875 (0.014%) have a non-trivial use (ie, the preceding character is not |).
Change 76861 had a related patch set uploaded by Cscott:
WIP: first draft of td reparse.

https://gerrit.wikimedia.org/r/76861
**kwwilliams** wrote:

(In reply to comment #23)
> (In reply to comment #22)
> > (In reply to comment #19)
> > > Scott, is the glitch with the certification tables at
> > > http://en.wikipedia.org/w/index.
> > > php?title=Metallica_%28album%29&oldid=566196578&veaction=edit
> > > another effect of 50589, this bug, or should I open a new bug report for it?
> > 
> > No, this is bug 52254 (which Roan already opened based on your report).
> 
> 52254 is relative to the incorrect italicization and bolding in the lead. It
> does not cover the corrupted certification table (near the bottom), which is
> another case of a template creating table markup which is displayed
> incorrectly.

Opened https://bugzilla.wikimedia.org/show_bug.cgi?id=52296 

The more I play with it, the more it feels like a third related bug. It's clearly not 50589 because Parsoid can't parse it correctly, but I don't think it's a duplicate of this one, either.
**kwwilliams** wrote:

(In reply to comment #22)
> (In reply to comment #19)
> > Scott, is the glitch with the certification tables at
> > http://en.wikipedia.org/w/index.
> > php?title=Metallica_%28album%29&oldid=566196578&veaction=edit
> > another effect of 50589, this bug, or should I open a new bug report for it?
> 
> No, this is bug 52254 (which Roan already opened based on your report).

52254 is relative to the incorrect italicization and bolding in the lead. It does not cover the corrupted certification table (near the bottom), which is another case of a template creating table markup which is displayed incorrectly.
(In reply to comment #19)
> Scott, is the glitch with the certification tables at
> http://en.wikipedia.org/w/index.
> php?title=Metallica_%28album%29&oldid=566196578&veaction=edit
> another effect of 50589, this bug, or should I open a new bug report for it?

No, this is bug 52254 (which Roan already opened based on your report).
Change 76758 merged by jenkins-bot:
Add new parserTests for table cell attributes coming from templates.

https://gerrit.wikimedia.org/r/76758
Change 76758 had a related patch set uploaded by Cscott:
Add new parserTests for table cell attributes coming from templates.

https://gerrit.wikimedia.org/r/76758
**kwwilliams** wrote:

Scott, is the glitch with the certification tables at http://en.wikipedia.org/w/index.php?title=Metallica_%28album%29&oldid=566196578&veaction=edit another effect of 50589, this bug, or should I open a new bug report for it?
rewritten in a more-or-less straightforward manner.
Having looked into it a bit, I agree that the current bug is related to bug 50589.  However, bug 50589 *should* work -- the template is still well structured, it is just generating content for more than one table cell.  This bug, on the other hand, has a template which spans structural boundaries in the HTML.  For example:

{|
|align=center {{table_attribs}}
|}

where {{table_attribs}} expands to 'style="color: red"|Foo'.  This wants to generate something like the following HTML:
<table><tr>
<td align="center" style="color: red"> Foo
</td></tr></table>

Note that the <td> and some of its attributes come from the article text, and the rest of the attributes come from the template. I might be able to hack this through Parsoid, but VE will probably never be able to edit the result.  (Imagine how you'd present the table cell editing UI for something like this.) So the bot approach should probably be used to clean up constructs like these, to something like:

{|
{{table_attribs|align=center}}
|}

Now the template is well-structured in the resulting html.

My current approach is to attempt to get these cases parsed by parsoid, resulting in uneditable-but-visually-correct output.  We will still want a bot to rewrite the templates so to make them editable in the articles using them.

As MZMcBridge correctly guessed, I'm currently running a grep over an enwiki dump to figure out exactly how many articles use table cell templates.  It's not done running yet so I don't have exact statistics, but the short answer is, "a lot".  So far nothing that can't be
**kwwilliams** wrote:

(In reply to comment #15)
> (In reply to comment #12)
> > Bots that modify existing articles to bypass bugs in Parsoid should be off
> > the table as a solution.
> 
> [[Hard cases make bad law]]. :-)
> 
> As a general rule, Parsoid should be handle wikitext in the wild. However, we
> need more information about the prevalence of these constructs on Wikimedia
> wikis and the amount of work required to properly handle them before we can
> make any real decisions here. Scott's Gerrit change #76626 seems to be a step
> in the right direction.

I'm more an adherent to the concept that rigorous adherence to fundamental principles always pays off in the long run, and "Parsoid should handle all wikitext currently in existence in English Wikipedia" strikes me as one of those fundamentals.

I'm concerned by the existence of this one and its interplay with 50589. It appears that Parsoid and VE made some assumptions about how templates, wikimarkup, and tables would interact that aren't true.

Take a look at the certification table in http://en.wikipedia.org/w/index.php?title=Metallica_%28album%29&oldid=566196578&veaction=edit for example. There's something going on in http://en.wikipedia.org/wiki/Template:Certification_Table_Top or http://en.wikipedia.org/wiki/Template:Certification_Table_Entry that's causing more weirdness. I don't know if that's this one, 50589, or yet another related bug.
(In reply to comment #12)
> Bots that modify existing articles to bypass bugs in Parsoid should be off
> the table as a solution.

[[Hard cases make bad law]]. :-)

As a general rule, Parsoid should be handle wikitext in the wild. However, we need more information about the prevalence of these constructs on Wikimedia wikis and the amount of work required to properly handle them before we can make any real decisions here. Scott's Gerrit changeset 76626 seems to be a step in the right direction.
Change 76626 merged by jenkins-bot:
Add 2 more dumpGrepper patterns to get a handle on bug 44498.

https://gerrit.wikimedia.org/r/76626
Change 76626 had a related patch set uploaded by Cscott:
Add 2 more dumpGrepper patterns to get a handle on bug 44498.

https://gerrit.wikimedia.org/r/76626
**kwwilliams** wrote:

(In reply to comment #11)
> We are definitely not trying to make life harder for editors.  We are just
> trying to figure out the best solution going forward.

The best solution going forward is to repair Parsoid. While I agree that we can do things with wikitext that no sane person would *want* to, there's no way to prevent us from doing so, and VE cannot fail based on things that work fine in the standard editor.

Bots that modify existing articles to bypass bugs in Parsoid should be off the table as a solution.
We are definitely not trying to make life harder for editors.  We are just trying to figure out the best solution going forward.

Visual editing is a HTML-based operation, and HTML has structural semantics.  Longer-term, it would make for a better and simpler software and editing interface if templates generated entire html elements instead of part of elements (which these templates do).  We are just trying to reconcile wikitext structural information with HTML structural information with a view towards the long-term.

While we definitely welcome participation and support of existing template/bot authors here, we are definitely not planning to offload this job of writing bots or updating pages onto editors.

All that said, resolving this issue might well involve a temporary interim fix and a strategy for a longer-term resolution that moves wikitext and templates towards a more cleaner solution that is more aligned with HTML DOM semantics.
**kwwilliams** wrote:

Why would we change the contents of articles to match something that Parsoid likes instead of repairing Parsoid? 

The specification of Parsoid surely must have included a spec that all templates and wikitext syntax in widespread use in English wikipedia needed to be handled properly. Since Parsoid doesn't meet that requirement, repair Parsoid.
Bumping up the importance, per comment 7.
**kwwilliams** wrote:

This one as well: http://en.wikipedia.org/w/index.php?title=List_of_Big_Time_Rush_episodes&diff=prev&oldid=565906957

This really isn't a "low importance" bug by any stretch of the imagination. It affects most discographies, most television episode lists, and most award lists.
Could aftereffects of this be responsible for the nightmare at https://en.wikipedia.org/w/index.php?title=Bosnia_and_Herzegovina_in_the_Eurovision_Song_Contest&diff=565659865&oldid=565498623 ?
*** Bug 50366 has been marked as a duplicate of this bug. ***
There are many templates in this set.
https://en.wikipedia.org/wiki/Template:Table_cell_templates

And the most commonly used ones are copied to other languages.  See the interwikis for {{Yes}}
https://en.wikipedia.org/wiki/Template:Yes
*** Bug 50772 has been marked as a duplicate of this bug. ***
This will be hard to support, as the nested template produces part of the table cell syntax plus the table cell content. Moving the pipe starting the table cell into the template would avoid this issue as the template would then expand to a self-contained table cell with content.

Are there other templates following this pattern apart from Yes (and probably No)?
This is a Parsoid bug; couldn't find the master with which to mark as dupe (sorry, Gabriel!).
diff about to delete existing text

I've seen this a few times and I think this is the simplest reproduction. 

Start with a page that has a line of text "this text should be preserved but is not"

In VE, position the cursor at the front of the line and move it two spaces down. 

Move the cursor back to the top of the page. 

Type a new line "totally different stuff"

Save.  Note the incorrect diff. The string "this text should be preserved but is not" has been deleted erroneously upon save.  

Repeat the operation but this time use strings that share words, like "this text should be preserved" and "this text is new"

The behavior is the same, the old text is erroneously deleted, but the diff seems to have intertwined the two strings, keeping their common elements.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=User:Cmcmahon(WMF)&oldid=535559576

**Attached**: {F10454}
This is now fixed given the Parsoid update. Sorry for the delay! (Note that there is a distinct error that this has just thrown up, yayfuntimes.)
Created attachment 11741
'text should be preserved' is not

real screen shot from real computer, my apologies

**Attached**: {F10457}
Created attachment 11740
text with string that will be deleted before save

real screen shot from real computer

**Attached**: {F10456}
This looks to be a Parsoid bug (and is highly dependent on the rest of the page's content); will re-visit when Parsoid is updated before progressing.
The content of attachment 11709 has been deleted by
    James Forrester <jforrester@wikimedia.org>
who provided the following reason:

Not intended to be on Bugzilla?

The token used to delete this attachment was generated at 2013-02-07 03:38:14 UTC.
The content of attachment 11710 has been deleted by
    James Forrester <jforrester@wikimedia.org>
without providing any reason.

The token used to delete this attachment was generated at 2013-02-07 03:36:53 UTC.
(In reply to comment #2)
> Created attachment 11709 [details]
> preview of page before save has correct text

(In reply to comment #3)
> Created attachment 11710 [details]
> saved page, existing text deleted erroneously
Ahm.... these are pictures of deer. Just sayin'.

//attachment 2012-12-30 11.02.48.jpg ignored as obsolete//
Created attachment 11710
saved page, existing text deleted erroneously

//attachment 2013-01-13 15.01.28.jpg ignored as obsolete//
Created attachment 11709
preview of page before save has correct text

//attachment 2012-12-30 11.02.48.jpg ignored as obsolete//
Created attachment 11708
better view of intertwined strings

**Attached**: {F10455}
Go to a new page. Enter some content. Press review-and-save. Observe diff. Press the "leave this context" button ("^"). Change the content. Press review-and-save again. Observe diff.

Expectation: The diff shows the changes against the new content.
Reality: The diff shows the changes against the original content (not re-done).

--------------------------
**Version**: unspecified
**Severity**: minor
Code now merged; thanks, Timo! Will go out in next branch.
Related URL: https://gerrit.wikimedia.org/r/62847 (Gerrit Change I9eddebbdf9294ee3d46286bdf1b157e00252d300)
The comments above are wrong. Actual timeline:

# Page load, enter text
     ve.Surface/Model/on/transact
     onSurfaceModelTransact Clear the diff html
     ve.Surface/Model/on/transact
(2x) ve.Surface/Model/on/transact
# Press "Review and save"
# Close dialog
# Enter more text
(3x) ve.Surface/Model/on/transact
# Press "Review and save"
# Close dialog
(In reply to comment #3)
> (In reply to comment #2)
> > Which I assume means ve.dm.Surface for some reason didn't emit any - or
> > mw.ViewPageTarget is binding it wrong, but that looks fine to me.
> > 
> > @Roan, any ideas?
>
> I'm pretty sure ve.dm.Surface emits the events correctly. You can check this
> by
> placing a breakpoint on the line where Surface calls this.emit().
> 
> It's possible there's a bug in EventEmitter with detaching and reattaching
> though.

Hm.. could be. All I know is that the attached callback didn't get fired.
(In reply to comment #2)
> Which I assume means ve.dm.Surface for some reason didn't emit any - or
> mw.ViewPageTarget is binding it wrong, but that looks fine to me.
> 
> @Roan, any ideas?
I'm pretty sure ve.dm.Surface emits the events correctly. You can check this by placing a breakpoint on the line where Surface calls this.emit().

It's possible there's a bug in EventEmitter with detaching and reattaching though.
Confirmed and hunt down.

From what I can see the problem may be in ve.dm.Surface not emitting any 'transact' events.

Adding a log() call in ve.init.mw.ViewPageTarget.prototype.onSurfaceModelTransact, shows me the following.

* When entering the first characters on a new page it is called.
  The callback then properly unbinds itself after the first call.
* Go to "Review and save"
  Now it binds the event again, so that it is notified of the first
  change (if ever) when the dialog is closed.
  This happens in ve.init.mw.ViewPageTarget.prototype.onShowChanges
* Close the dialog
* Altering the document again

> the method is not called

Which I assume means ve.dm.Surface for some reason didn't emit any - or mw.ViewPageTarget is binding it wrong, but that looks fine to me.

@Roan, any ideas?
*** Bug 45021 has been marked as a duplicate of this bug. ***
For the forthcoming Template Inspector to work, we will need a way to "hint" for the Inspector how the parameters of the VE should be used - we're intending for now for this to be a template-hinting extension that allows editors to specify in the wikitext source what the parameters are called and how they should be used, akin to the Template documentation template on Commons.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This is now deployed to all wikis. Closing.

(In reply to comment #5)
> (In reply to comment #4)
> > We should get this deployed everywhere this coming week.
> 
> I'd like see to a working demo of this feature and expanded documentation at
> [[mw:Extension:TemplateData]] before this is deployed elsewhere.

I've made some quick updates, but you're right, it does need proper documentation.
(In reply to comment #4)
> We should get this deployed everywhere this coming week.

I'd like see to a working demo of this feature and expanded documentation at [[mw:Extension:TemplateData]] before this is deployed elsewhere.
We should get this deployed everywhere this coming week.
Live on mw.org and testwiki now.
I will need to review and deploy this soonish.
Initial code in gerrit 49840 which is now merged.

To come - review, deployment and usage.
empty review pane, should show heading markup for non-Latin string

Using a string like "āæǣ" or special characters like "☺☻♥♦"

Highlight the string in VE
Choose "Heading 1"

VE displays the string larger, as expected

Click "Review and save""

Note that review pane is empty, see screen shot. 
Click "Looks good to me" and finish saving. 

The non-Latin string has not been affected and the Heading not been applied. 

Note that normal ASCII latin strings work fine. 
Also note that the regular editor applies the Heading markup to non-latin strings correctly.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://en.wikipedia.org/w/index.php?title=User:Cmcmahon(WMF)&oldid=535414434

**Attached**: {F10377}
The underlying issue (with Parsoid) has been resolved with the new version of Parsoid finally running on the cluster; marking as FIXED.

[I have forked comment 6 into bug 47436.]
**guanhao7** wrote:

I found it is impossible to use Sogou Input or other Input software to type Chinese with this tool.

You may download a Sogou Input(which is the most popular one in china, on the Windows） to test it.

Here is the download link: http://download.ime.sogou.com/sogou_pinyin_65f.exe?st=lTJ11fWyCsrUkj6oWiGI_Q&e=1359462829&fn=sogou_pinyin_65f.exe
This would make a nice automated browser regression test
OK, interesting. This is actually a quite complicated bug, and is not actually correctly-named.

The problem appears to be the '[http://barbarbar bar]' beforehand - if you remove this, the diff magically "works" - BUT it fails to show the '[http://barbarbar bar]' being removed, and indeed puts it after the header too, with another paragraph of 'āæǣ'. The diff is the behaviour that results from the save, even though this isn't a fair representation of the document model (the '[http://barbarbar bar]' is removed from the DM).

RK: this feels like a Parsoid bug (or two?), but might be on our side related to SelSer? - can you confirm before we sling it at them?
Also repro'd on Chrome/Linux
Chrome, OSX, enwiki. I can reproduce this reliably on my User page on enwiki.
Afraid I can't reproduce this (it works fine for me with Firefox, Safari and Chrome from here - I get as-expected diffs, which also then save appropriately) - what wiki / version of the software was this on, and with what browser?
VE gets some error codes and messages from Parsoid, but not a lot. I'm expanding that a little bit in a new patch [0], and it would be cool if VE could handle the errors I've added.

401: Unauthorized: Should be handled as a user-visible error. Usually this means that the API isn't readable by anonymous users, but could be later used for something else. The text of the HTTP response has details about the error, so showing that to the user might be an OK solution.

404: Not found: Usually means that we couldn't find anything for the article you're trying to parse or serialize. This shouldn't usually happen, but when it does, it *probably* means that the interwiki isn't set properly. Maybe hint that the user should compare their localsettings.js file to the example.

500: Server error: This is a catch-all, but we'll send as much information as we can in the text of the HTTP response. Showing the user the text would go a long way towards more useful bug reports (I currently see roughly 4 suggested duplicates that have roughly the same summary....differentiating them might be helpful)

These are all implemented in js/lib/mediawiki.ApiRequest.js in functions that inherit from the native Error object, so you can read it if you don't want to take my word for it.

We could implement other error codes as we see cases that require them, but these are the big three. And of course 200 is the main success code.

We might also be able to use some of the 3xx codes to represent redirects, but I'm not sure it would be totally useful. File a bug against Parsoid if it would be :)

[0] https://gerrit.wikimedia.org/r/45794

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=43147
Marking this as done as the code's been committed; we may want to review in future (e.g. i18n of the error messages), but Gabriel has indicated that that entire area of code will be removed anyway, so marking as closed for now.
(In reply to comment #1)
> Code in Gerrit change #52249

This patch passes through the error messages from Parsoid to the existing error alert in VE. Mark's comment talks about providing suggestions based on the error code. Although maybe this could be done by Parsoid.

This change should at least provide users with more specific errors for filing bugs.
Code in gerrit 52249
See http://inimino.org/~inimino/blog/javascript_cset for some work in this area.

--------------------------
**Version**: unspecified
**Severity**: major
Like this: https://gerrit.wikimedia.org/r/#/c/54480 (well, apart from non-BMP characters...)
The Unicode standard has a fair amount to say on the matter. Ideally we would implement their standard.

http://www.unicode.org/reports/tr29/#Word_Boundaries
As an incremental improvement I've expanded the letters and numbers groups to their Unicode categories: https://gerrit.wikimedia.org/r/#/c/53583/
We still need to think about which punctuation categories to add.
If you're going to do lexicon-based word boundary detection in Chinese, maybe you could use a word list stored in a client-side Bloom Filter. 

I don't know if it's as much of a problem in Japanese; you could probably use (?<=\P{Han})(?=\p{Han}) as a good start (i.e. there is a word break be.
To begin with a patch to add some test structure and fix what we have already: https://gerrit.wikimedia.org/r/#/c/53564
http://xregexp.com/ has unicode character class support. We may be able to pick out the data we need from it instead of using the whole library.
Acutually Chinese & Japanese don't have any word boundaries at all. The only way to detect them is with a dictionary. We'll need a special case for these languages so we don't end up selecting entire sentences.
Bit of clarification:

When the user clicks the link button in the toolbar and they haven't selected any text, we expand the selection in both directions from the cursor position and select the word the cursor is in, make that a link, then show the link inspector. The code that expands the selection to a full word is in ve.dm.SurfaceFragment, and apparently treats non-ASCII characters as word boundaries. The practical bug that this leads to is that if you put the cursor in the middle of "Möckernbrücke" (or "égalité", if you prefer French) and click the link button, only "ckernbr" (or "galit", respectively) will be selected and linkified. Obviously this is a problem for i18n in languages using an extended Latin alphabet like German, French and Polish, but it's a total nightmare for non-Latin languages like Russian, Hebrew and Japanese.
Related to bug 44083

Because there is not yet a paragraph to insert content in, the link inspector won't be able to insert the new link text into a slug, even if bug 44083 is fixed.

The solution is probably to make the automatic paragraph insertion code in ve.ce.Surface.handleInsert more generic and moving it into ve.dm.SurfaceFragment.insertContent, triggered when inserting at a slug location.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=44083
This has now been fixed and deployed.
Noting that this is more severe.
1. Make an article that begins with an alien followed by a paragraph with some text
2. Click on a word in the paragraph
3. Click on the slug
4. Press the link button
5. See that rather than the link inspector knowing to begin inserting a new link inside the slug, it inspects the word you clicked on in the paragraph.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=44084
https://bugzilla.wikimedia.org/show_bug.cgi?id=50141
Actually closing it.
Confirming that this is now fixed, and was done so some time ago - back-dating to approximately when I think it was fixed.
Hm.. I can't reproduce this.


1. Opening a MediaWiki page with the following source in VisualEditor:

<<<MW
<templatedata>{
    "params": {}
}</templatedata>

Foo bar baz.
MW;

2. Selecting word "bar".
3. Clicking in the slug area above the green templatedata alien.
4. Pressing the link button.

Shows a link inspector with an empty input field. Upon entering some text in the link input widget and closing the link editor, the link target page is inserted as plain text (different bug?)
Key commands should be able to vary based on language/locale and platform. E.g. toggling something as Bold could be:

* Ctrl + b (Windows, English)
* Cmd  + b (Mac OS X, English)
* Meta + b (Solaris, English)

* Ctrl + f (Windows, German)
* Cmd  + f (Mac OS X, German)
* Meta + f (Solaris, German)

... etc.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=42919
Now merged, will go out in 2013-02-04 release cycle.

Note that the internationalisation aspect (Ctrl+F rather than Ctrl+B for Bold in German) is WONTFIX as directed by the Language Engineering team, who advised against.
Patched in https://gerrit.wikimedia.org/r/#/c/44347/
"Can have grandchildren" is a misnamed check that should be cleaned up. What it really appears to mean is "is this a non-content-containing branch node", given that it checks that the node can have children, is not content, and is not a content container.

canHaveGrandchildren seems to still be used in some places, it should be renamed and documented adequately.

--------------------------
**Version**: unspecified
**Severity**: normal
https://gerrit.wikimedia.org/r/#/c/53750/
We should use pushState such that pressing the back button after clicking VisualEditor takes you back to read mode.

--------------------------
**Version**: unspecified
**Severity**: minor
(In reply to Lokal_Profil from comment #11)
> (In reply to Andre Klapper from comment #10)
> > Lokal_Profil: Where? Example link? Browser? Reopening not helpful without
> > giving instructions to reproduce... :-)
> 
> Sorry ;)
> 
> Confirmed in both Firefox and Chorme running on Ubuntu
> 
> Tested on both sv.wp[1] and en.wp[2] (logged out on sv.wp to make sure no
> personal settings were affecting it)
> 
> [1] https://sv.wikipedia.org/wiki/Bonsai?uselang=en
> [2] https://en.wikipedia.org/wiki/Bonsai

Moved to bug 63739 as a new regression.
(In reply to Andre Klapper from comment #10)
> Lokal_Profil: Where? Example link? Browser? Reopening not helpful without
> giving instructions to reproduce... :-)

Sorry ;)

Confirmed in both Firefox and Chorme running on Ubuntu

Tested on both sv.wp[1] and en.wp[2] (logged out on sv.wp to make sure no personal settings were affecting it)

[1] https://sv.wikipedia.org/wiki/Bonsai?uselang=en
[2] https://en.wikipedia.org/wiki/Bonsai
Lokal_Profil: Where? Example link? Browser? Reopening not helpful without giving instructions to reproduce... :-)
This seems to be broken again (back button changes URL but doesn't take user back to read state)
Merged and will go out with wmf7 (from tomorrow).
*** Bug 49336 has been marked as a duplicate of this bug. ***
Related URL: https://gerrit.wikimedia.org/r/67172 (Gerrit Change I5c345c1526852a84b04436955845bf1b56d94402)
Related URL: https://gerrit.wikimedia.org/r/67171 (Gerrit Change Ia4b949d9c066a3f7b07217aa3d51de9908734e85)
Setting milestone to 2013-06-27 since it is marked as blocker for "Beta" (2013-07). It may be moved to an earlier milestone as we see fit. But no later than 06-27. Setting it since I use milestone to sort "My bugs".
We currently use ?veaction=edit as trigger for VisualEditor from a permanent url.

This is implemented by checking the query parameter on page load and triggering init (just like a click on "VisualEditor" would do), and then we replace (without refresh) the url to drop this query parameter using the HTML5 History api (replaceState).

I'd recommend we build on this by using pushState when VisualEditor is initialised (we can then remove the current behaviour as there's no longer any reason to remove it from the url).

Note that it is slightly more complicated than just calling replaceState on init. We also need to listen on('popstate') to move back to read mode if the user presses Back to a url within the history that contains HTML5 history state data from VisualEditor.
To further clarify what the issue here is:

* a user visits <https://www.mediawiki.org/wiki/Wikimedia_Engineering/2012-13_Goals>;
* user clicks "edit";
* VisualEditor form loads;
* user tries to escape the form by pressing the "back" button in his/her browser;
* browser's "back" button doesn't work as expected (it should take the user back to the implicit view action where he/she started).
Is this an easy bug?
When the diff result is null (no changes), don't show a confusing blank diff but instead a message like "There are no changes detected in your edit" so that users aren't confused.

--------------------------
**Version**: unspecified
**Severity**: trivial
Merged; re-closing.
Related URL: https://gerrit.wikimedia.org/r/63691 (Gerrit Change I537bcae91f51a3f30ca4736c41f7a5619bbf321d)
Re-opening to provide less hacky fix.
Merged into master and will go out in wmf4.
Related URL: https://gerrit.wikimedia.org/r/63236 (Gerrit Change I8daae124b060ccf54ce5ca7c1e1a6d18b7265ade)
Working on this now.
For whatever reason (may be a bug in the DM, or in the seralizer, or in selser), whitespace preservation didn't work in this edit https://en.wikipedia.org/w/index.php?title=International_Air_Transport_Association_airport_code&diff=530666305&oldid=526301045 . The whitespace changes didn't show in the initial diff I was asked to verify, only in the final change.

--------------------------
**Version**: unspecified
**Severity**: normal
*** Bug 48367 has been marked as a duplicate of this bug. ***
Merged.
(In reply to comment #3)
> Related URL: https://gerrit.wikimedia.org/r/59570 (Gerrit Change
> Ic4c93510518163894201a693ab50331413715967)

This commit fixes the bug. CC Gabriel and Subbu because they'd probably like to test it.
Related URL: https://gerrit.wikimedia.org/r/59570 (Gerrit Change Ic4c93510518163894201a693ab50331413715967)
It looks like this is happening because getDomFromData() somehow messes up the whitespace information. Then when getDomFromData() runs a second time (because you go back, change things, then diff again, or if you save after diffing), it sees inconsistent whitespace information and refuses to serialize it.
Confirm not happening in live - but /does/ happen with heads of VisualEditor and Parsoid (and MediaWiki) in testing. As Roan says, doesn't appear in diff, does appear in the final change.
Now fixed - you get the message: "Error loading data from server: novenamespace: VisualEditor is not enabled in namespace 100. Would you like to retry?"

Arguably the option to retry should be skipped, but marking this as now fixed.

J.
**Coiby.Xu** wrote:

I meet this problem, too
https://gerrit.wikimedia.org/r/#/c/42198/ is mostly done.
The specs for the server-side logging API that Dario hashed out with S and me earlier this morning would totally cover this. I think we can do it. I'll shoot for getting this done in time for the deployment window next Thursday (Jan 10th).
(In reply to comment #2)
> I'm not able to reproduce it. Please confirm if this still occurs to you -
> and
> if o - please provide information about your platform as well. Thanks.

As reporter of this bug I cannot reproduce it now.
I'm not able to reproduce it. Please confirm if this still occurs to you - and if o - please provide information about your platform as well. Thanks.
(In reply to comment #1)
> @James: Are you still able to reproduce it?

No; partially invalid because we no longer show lots of distinct slugged LIs for lists. :-)

> Also, I wonder if it is correct behavior that if you have completely empty by
> multiply-indented list and you press backspace in the deepest li - it delete
> entire list. Check out this video:
> https://dl.dropboxusercontent.com/u/1026938/multiplyindented.mov

This feels a bit wrong, yeah; maybe just decrease by one?
@James: Are you still able to reproduce it?

Also, I wonder if it is correct behavior that if you have completely empty by multiply-indented list and you press backspace in the deepest li - it delete entire list. Check out this video: https://dl.dropboxusercontent.com/u/1026938/multiplyindented.mov
This seems to be fixed already (try to reproduce on English Wikipedia).
I think I know what's the reason of this problem. I will work on it next week.
*** Bug 46506 has been marked as a duplicate of this bug. ***
This is fundamentally an "editing what appears to be a blank space but is actually a slug means this behave in a way I did not anticipate" - assigning to CE, but we really need to talk about this and what we should do longer-term.
This seems to be fixed already (try to reproduce on English Wikipedia).
**orbit** wrote:

We're going to resign (for now at least) from using localStorage for copy and paste. Although I was unable to reproduce this error, we're only using localStorage for copy and paste.
@James: Yes, it is. I will look into it.
Fixed and will go out with wmf8, from Thursday 20 June.
https://gerrit.wikimedia.org/r/68300 (Gerrit Change I35c892581943057acbf9ddd638576e998cc82c1a) | change APPROVED and MERGED [by jenkins-bot]
Related URL: https://gerrit.wikimedia.org/r/68300 (Gerrit Change I35c892581943057acbf9ddd638576e998cc82c1a)
I've just created a test that covers this problem: https://github.com/inez/VE-tests/commit/4c1a444b207b37f90dc5d5ce969b5af00ee893ef (solution still not pushed).
This issue is not browser specific.
This is now fixed (as of the new deletion code).
This (first part; second part is now bug 43155) is fixed in gerrit 39834 which is now merged; will be deployed as part of the 2013-01-16 release cycle.
Cannot reproduce this without a deep stack trace; also, this is from three months ago, and we're unlikely to still have the same issue.
These are all moot since the redesign of slugs over a year ago.
Would having an object inspector on the non-editable non-text things that provides options to "insert text before"/"insert text after" be a solution to the problem?
Created attachment 11767
Mockup of VisualEditor in various modes

Just wanted to note that slugs were an experimental solution to the problem of "how do you allow users to insert content between non-text things?

We have had a lot of ideas, but so far the direction we intend to go is to remove them entirely from the existing "layout" mode and provide an "outline" mode to the editor which includes them. There could also be a "source" mode where we could integrate the markup editing experience directly into VisualEditor.

**Attached**: {F10138}
This is now deployed. Marking as fixed.
(In reply to comment #9)
> Yeah; it would be helpful if gerrit changes which mentioned bugs were either
> always or never proxied by the bot to bugzilla, instead of the half-way house
> of being unknown. :-)

Feel free to file a new ticket with reference to bug 17322. :)
Yeah; it would be helpful if gerrit changes which mentioned bugs were either always or never proxied by the bot to bugzilla, instead of the half-way house of being unknown. :-)

Apologies, all!

J.
(In reply to comment #7)
> Related URL: https://gerrit.wikimedia.org/r/61382 (Gerrit Change
> I56906c123e924b84eb9ee076cd67254f8935911d)

Result of a typo. ^
Related URL: https://gerrit.wikimedia.org/r/61382 (Gerrit Change I56906c123e924b84eb9ee076cd67254f8935911d)
(In reply to comment #5)
> Related URL: https://gerrit.wikimedia.org/r/61250 (Gerrit Change
> I98028df0bcb621e8f13a2f8ab130e86a9010ebeb)
This change enables VisualEditor on test2wiki, and will be deployed on Monday.

I fixed the namespace configuration last week, it's now the same on all wikis: VisualEditor is enabled in the main and user namespaces, as well as the VisualEditor namespace where it exists (testwiki and mediawikiwiki have this namespace for historical reasons).
Related URL: https://gerrit.wikimedia.org/r/61250 (Gerrit Change I98028df0bcb621e8f13a2f8ab130e86a9010ebeb)
http://test.wikipedia.org/wiki/Special:Preferences#mw-prefsection-editing allows to "Enable VisualEditor (only in the main and user namespaces)"
http://test2.wikipedia.org/wiki/Special:Preferences#mw-prefsection-editing does not offer enabling VisualEditor.

Roan: As this is assigned to you, do you plan to work on this and is this high priority? If not, please reset. Thanks.
[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]
https://gerrit.wikimedia.org/r/70344 (Gerrit Change I253b9b7a9b463439e86d7cf7975cd92f9c851e70) | change APPROVED and MERGED [by jenkins-bot]
The fix will go out with tomorrow's Parsoid deployment.
https://gerrit.wikimedia.org/r/70348 (Gerrit Change Ied95c87fda13dbea2b8c46ad1e96fde1c50c1517) | change APPROVED and MERGED [by jenkins-bot]
Related URL: https://gerrit.wikimedia.org/r/70348 (Gerrit Change Ied95c87fda13dbea2b8c46ad1e96fde1c50c1517)
Related URL: https://gerrit.wikimedia.org/r/70344 (Gerrit Change I253b9b7a9b463439e86d7cf7975cd92f9c851e70)
*** Bug 49984 has been marked as a duplicate of this bug. ***
We used to use a special page redirect hack, but now use the API to properly retrieve image information including the path. So the new code needs to implement some similar protocol-relative massaging for image URLs, at least for the domains we know to support both http and https.
Per Roan's comments, moving to Parsoid so they can fix.
(In reply to comment #7)
> This seems to have been unfixed in production.
> 
Specifically, Parsoid is now once again returning http:// URLs for images (except in labs, where it returns https:// URLs). MZ submitted a fix in December to make these URLs protocol-relative, but this seems to have been unfixed somehow.

Perhaps the repository URL is being grabbed from the API? That would explain why it's now a fully qualified URL, and it might explain the difference between labs and production.
This seems to have been unfixed in production.

Strangely, parsoid.wmflabs.org is now giving me https URLs for images.
*** Bug 49283 has been marked as a duplicate of this bug. ***
The page at https://en.wikipedia.org/wiki/User:Trevor_Parscal?veaction=edit displayed insecure content from http://upload.wikimedia.org/wikipedia/commons/thumb/f/ff/California_Bay_Area_county_map.svg/38px-California_Bay_Area_county_map.svg.png.
I am getting this issue, on the test page referenced in the bug and others, again. The URLs do not contain Special:FilePath anymore, so perhaps something was changed about  how images are handled that introduced a regression? Reopening this bug since the issue appears to be essentially the same.
Tagging with deploy-train cycle.
Merged into master and will go out with wmf5.
Related URL: https://gerrit.wikimedia.org/r/63679 (Gerrit Change I709d936d998b130515b62de880c6e7aa7978786b)
I know mine doesn't work, because I put it together in five minutes, but it's definitely proper. Here's the code I used to construct it: http://pastebin.com/ELJ4LdKy
BTW, for whoever's curious, here is what an official URI regular expression would look like (it does't work, needs debugging; it's probably missing a parentheses or something):

/^[A-Za-z][A-Za-z0-9\+\-\.]*:(\/\/(([:A-Z0-9-\._~!\$&'\(\)\*\+,;=]|%[A-Fa-f]{2})@)?(\[(|v[A-Fa-f]+\.[:A-Z0-9-\._~!\$&'\(\)\*\+,;=]+)\]|([0-9]|[1-9][0-9]|2[0-4][0-9]|25[0-5])\.([0-9]|[1-9][0-9]|2[0-4][0-9]|25[0-5])\.([0-9]|[1-9][0-9]|2[0-4][0-9]|25[0-5])\.([0-9]|[1-9][0-9]|2[0-4][0-9]|25[0-5])|([A-Z0-9-\._~!\$&'\(\)\*\+,;=]|%[A-Fa-f]{2}))(:[0-9]*)?(\/(([:@A-Z0-9-\._~!\$&'\(\)\*\+,;=]|%[A-Fa-f]{2}))*)*|\/(([:@A-Z0-9-\._~!\$&'\(\)\*\+,;=]|%[A-Fa-f]{2}))+(\/(([:@A-Z0-9-\._~!\$&'\(\)\*\+,;=]|%[A-Fa-f]{2}))*)*|(([:@A-Z0-9-\._~!\$&'\(\)\*\+,;=]|%[A-Fa-f]{2}))+(\/(([:@A-Z0-9-\._~!\$&'\(\)\*\+,;=]|%[A-Fa-f]{2}))*)*|)\?((([:@A-Z0-9-\._~!\$&'\(\)\*\+,;=]|%[A-Fa-f]{2})|[\/\?])*)?(#(([:@A-Z0-9-\._~!\$&'\(\)\*\+,;=]|%[A-Fa-f]{2})|[\/\?])*)?$/
Change-Id: I4954bfd3750d5c990e91cc0dc8a175225ccbad1e
Yes, but is it truly necessary to validate that much? I mean, for example, take the (invalid) URI "https://www.google.com/search?q=test test". The URI is invalid because it has a space character in the query, but if you were to do something like "location.href = <that uri>", it would work perfectly fine, because the browser automatically percent-encodes the space.

Basically, I'm wondering for what the mw.Uri class is being used for that requires such strict validation.
(In reply to comment #10)
> I wouldn't attempt to make a comprehensive URI parsing library in JavaScript.

> The first reason is because it's unnecessary. With the fix I just uploaded to
> Gerrit, there should not be any more bugs in this function. 

I just pointed out a glaring one above.

(In reply to comment #8)
> What about whitespace in the authority part? (This isn't allowed,
> but those regexes match it just fine.)

I'm sure there are more, waiting to be uncovered.


> Secondly, the
> regular expression would be absurdly complicated. URIs have specific sets of
> characters that can be included only in certain sections. I wrote a regex for
> an official URI once when I was working on the PHP version of this class
> (still
> in Gerrit), and it was so confusing it took days to get it working properly.

Of course, I know this. That's why I'm suggesting using the work of someone who has already spent time pulling his hair out to get this right; or at least just taking those crazy regexes in from some other library.
I wouldn't attempt to make a comprehensive URI parsing library in JavaScript. The first reason is because it's unnecessary. With the fix I just uploaded to Gerrit, there should not be any more bugs in this function. Secondly, the regular expression would be absurdly complicated. URIs have specific sets of characters that can be included only in certain sections. I wrote a regex for an official URI once when I was working on the PHP version of this class (still in Gerrit), and it was so confusing it took days to get it working properly.
(In reply to comment #8)
> (In reply to comment #6)
> > On further investigation and following links from that gist, it looks like
> > the
> > regexes in mw.Uri aren't so half-baked.
> > 
> > They actually come from here:
> > http://blog.stevenlevithan.com/archives/parseuri
> 
> If they weren't half-baked, mw.Uri wouldn't crash on '@' in the URL. 
> 
> These regexes are already awful (177 characters? Seriously?), and are bound
> to
> get worse as we discover more edge-cases. 
> 
> What about password with a '@' in it? (Yeah, this is allowed as far as I
> know,

No, those need to be url escaped afaik. At least in Chrome and in the nodejs modules I used it the password (especially the @ symbol) needs to be url escaped or it won't work.

> While on second though the <a>-abuse I linked isn't a good idea, we really
> need a serious parsing library.

I'm open to suggestions, though it'll need to be flexible and be replaceable in-place to allow smooth transition (same API and and unit tests, different internal implementation).

The module is generic enough to easily allow a different parser.

But there is some ambiguity on the fields to be extracted and their meaning[1], so even a "perfect" library may need modification to work for us and our interpretation of those terms.

[1] http://tantek.com/2011/238/b1/many-ways-slice-url-name-pieces
(In reply to comment #6)
> On further investigation and following links from that gist, it looks like
> the
> regexes in mw.Uri aren't so half-baked.
> 
> They actually come from here:
> http://blog.stevenlevithan.com/archives/parseuri

If they weren't half-baked, mw.Uri wouldn't crash on '@' in the URL. 

These regexes are already awful (177 characters? Seriously?), and are bound to get worse as we discover more edge-cases. 

What about password with a '@' in it? (Yeah, this is allowed as far as I know, and works.) What about whitespace in the authority part? (This isn't allowed, but those regexes match it just fine.)

While on second though the <a>-abuse I linked isn't a good idea, we really need a serious parsing library.
(In reply to comment #6)
> (In reply to comment #3)
> > I googled a little for a reasonable JS URI parsing library that could replace
> > those half-baked regexes, and found this: https://gist.github.com/2428561
> > 
> > It seems genius and is 100% correct. Is it a good idea to use something like
> > this? If it is, I can implement it.
> 
> That's not a URI parsing library, that's an unreliable hack using <a href="">
> parsing. See the comments there.
> 
> On further investigation and following links from that gist, it looks like
> the
> regexes in mw.Uri aren't so half-baked.
> 
> They actually come from here:
> http://blog.stevenlevithan.com/archives/parseuri

Indeed. You'll also notice that the user and password aren't parsed at all in that implementation.

Also, https://gerrit.wikimedia.org/r/44665
(In reply to comment #3)
> I googled a little for a reasonable JS URI parsing library that could replace
> those half-baked regexes, and found this: https://gist.github.com/2428561
> 
> It seems genius and is 100% correct. Is it a good idea to use something like
> this? If it is, I can implement it.

That's not a URI parsing library, that's an unreliable hack using <a href=""> parsing. See the comments there.

On further investigation and following links from that gist, it looks like the regexes in mw.Uri aren't so half-baked.

They actually come from here:
http://blog.stevenlevithan.com/archives/parseuri
Found the problem. Expect a patch in the near future.
It should be noted that those are HTML5-specific properties.
This is fixed in gerrit 39847 which is now merged; will be deployed as part of the 2013-01-16 release cycle.
Now merged.
Rephrased summary.

The problem is that different skins use a different message for the Edit button. Vector uses msg key "vector-view-edit". Monobook (and most other skins) use msg key "edit".

By default the messages are equal but on en.wikipedia.org, as example, classic msg "edit" has been changed to contain "Edit this page".

This lead to the tab replacement causing a weird change from "Edit" to "Edit this page" when in VE mode.
Change-Id: I2e7dd85cd14049101e2d49751d37797d77bc7c9d
**Jason_quinn** wrote:

Postscript:

Blue is for boys. Pink is for girls. Yellow or green are neutral.

This is a cultural convention for gender through the Western world and much of the rest of the World, especially for example in nurseries, and has been for the better part of a century. This is *why* many here associate blue with male. If you are from the Western world and don't have at least some mental association about that, you're an oddity. The suggestion of "red" rather than "pink" to denote female is puzzling. (In fact, the red icon suggested above for female and the old icon's blue color are clearly similar to the red and blue used for instance by Olympic boxers.) It is also puzzling why "yellow" or "green" weren't mentioned as possible general neutral colors.

I'm not saying that this color convention (or any color convention) should be used for the icon. There would be many issues to discuss about it. Some people might object saying it re-enforces gender stereotypes and so on. There may be countries where the conventions are totally different (I'm unaware of any but this same issue came up when color-coding Asian family tree charts in the encyclopedia and nobody has yet complained). All I am saying is that it wasn't clear to me from the above discussion that anybody even was even consciously aware of the convention so it needed to be mentioned explicitly. Getting rid of the icon altogether may be the best course of action anyhow so this might be moot except to better understand the issue.

Regardless, it was a fantastic suggestion that the icon should not have an indefinable skin color. Bravo on that.
Change 157990 merged by jenkins-bot:
Make profile icon gender neutral and remove from login link in Vector

https://gerrit.wikimedia.org/r/157990
Change 146979 abandoned by Robmoen:
Make profile icon gender neutral and remove from login link in Vector

Reason:
Abandoned in favor of new patch in skins directory.
https://gerrit.wikimedia.org/r/#/c/157990/

https://gerrit.wikimedia.org/r/146979
Change 157990 had a related patch set uploaded by Robmoen:
Make profile icon gender neutral and remove from login link in Vector

https://gerrit.wikimedia.org/r/157990
While we wait for screenshots here, I've loaded the icon at its default size of 13px and out of context I would have called it a sunset over a hill. I guess that *is* gender neutral, no idea how clear it is.

See also bug 45056 comment 15.
Change 146979 had a related patch set uploaded by Robmoen:
Make profile icon gender neutral.  Remove from Login link

https://gerrit.wikimedia.org/r/146979
**wmf.amgine3691** wrote:

This idea has already been discussed in this bug (starting around comment 9, 17) and was discussed in other bugs (35341) and has its own bug (45056).
**swalling** wrote:

(In reply to Nemo from comment #57)
> The problem in this bug is very well defined and it has nothing to do with
> your proposed solution. Your proposal is a solution for the supposed problem
> "personal toolbar personalises", which is a) different, b) not agreed upon
> as a problem. It's possible that the two problems will be resolved by a
> single solution in the end, but collapsing them in a single report doesn't
> help anything.

When a problem comes up with a current design (whether it's an icon, a button, or a whole feature), it is extremely useful to go back to basic principles and talk about why something is needed in the first place. Questioning whether a design element is necessary hones in on why it's important. If we understand why it's important, then if we want to keep it, we can be clearer about what it's supposed to be doing. 

TL;DR: all options are on the table. If you don't like it, we can always go discuss this on the more open-ended bug I filed. But berating a designer for having ideas is not progress.
I don't know what "personal toolbar personalises" means, can you explain/clarify?
The problem in this bug is very well defined and it has nothing to do with your proposed solution. Your proposal is a solution for the supposed problem "personal toolbar personalises", which is a) different, b) not agreed upon as a problem. It's possible that the two problems will be resolved by a single solution in the end, but collapsing them in a single report doesn't help anything.
Nemo, bugs shouldn't neccesarily express a solution, the problem here is "icon represents gender" it's easy to assume the fix is "make a better icon" when the problem could just as easily be "don't have an icon" when we presuppose a solution we close ourselves off to many possible correct conclusions for the same issue. 

Pre- and post- login icons are currently the same asset by the way, to answer your question.
What is the pre-login or post-login icon? Jared, please file a separate bug report for separate issues. This bug is not about removing the icon.
Created attachment 15907
post login

see post login sketch

- icon removed
- additional per item padding added
- right margin adjusted to align with search.

**Attached**: {F9746}
I propose we remove the post-login icon for now, and when wikifont is in core we can add the updated icon then. We have personal bar instrumented right now, so we'll be able to see if there is any dropoff from users based on the removed icon.
**swalling** wrote:

(In reply to Jared Zimmerman (WMF) from comment #51)
> Created attachment 15906 [details]
> no icon -> mediawiki.ui controls
> 
> How about for now we just remove the icon altogether, pre-login we should
> use medaiwiki.ui controls, and post login, just remove the existing icon.

I think this is the right way to go for login. 

Not sure about removing the icon for once you're logged in. It does provide value, in that it denotes that the menu items are related to you personally. I think if we try something simpler (the version May did pushed things a bit in terms of personality and verve) then we can easily replace it. Munaf is working on something in conjunction with our designs for a task suggestions alpha.

**Attached**: {F9744}
Created attachment 15906
no icon -> mediawiki.ui controls

How about for now we just remove the icon altogether, pre-login we should use medaiwiki.ui controls, and post login, just remove the existing icon.

**Attached**: {F9744}
*** Bug 67837 has been marked as a duplicate of this bug. ***
Hi RituS! Actually I don't think this bug at this point is the best first task for a new contributor. We have many other bugs to choose from at 

https://www.mediawiki.org/wiki/Annoying_little_bugs

The reason is...

(In reply to comment #39)
> Removing easy keyword; the implementation may be easy, but as we still
> haven't 
> agreed on what to do with this, it's probably not something we'd necessarily
> want to bring a new person into.

I agree. Have we agreed on a plan? If so, a new comment summarizing the work that needs to be done is welcome. With 48 comments and 5 attachments, the chances to work on something that won't be directly merged are high.
Hi RituS, thanks for your interest! Please see https://www.mediawiki.org/wiki/Developer_access and https://www.mediawiki.org/wiki/Gerrit/Tutorial for information and also for where to receive help with the general development setup.
**ritusparks** wrote:

Hey!
I'm a newbie to mediawiki and I would like to work on this bug! Could somebody navigate me through the required procedure?
(In reply to comment #40)
> 
> As you point out, it should likely be anthropomorphic. Blue is used for
> accent in the skin, but every icon and graphic is monochromatic grey
> (http://ur1.ca/fx8u3, search) - as should be this one.

Good point - I must have been thinking of some extension icons I'd seen that were link-coloured.

(In reply to comment #44)
> Created attachment 13548 [details]
> Profile icon

As I said, an icon like that defeats the purpose of having a user icon in the first place, as it is not immediately recognisable as 'user account' related and thus does not adequately function as a graphical label for the personal tools. Indeed, that it is so similar to the echo thanks thing should help explain why it isn't appropriate here.

The one Munaf made or one of the ones thehelpfulone linked would be much more appropriate and effective. May need to fix the colours/weight for the skin, but that is the direction this should be taking. Or rather that it should never have left.

//attachment profile.svg ignored as obsolete//
(In reply to comment #43)
> Created attachment 13547 [details]
> Example use of icon

I want to say that I appreciate all of the work that the design team does. Good design on our projects and in our products is important. A rich, meaningful, and aesthetically pleasing user experience is something that every user who visits our sites or uses our services should have.

That said, sweet Jesus no, we will not be putting that icon anywhere near MediaWiki core or Wikimedia wikis. It conjures up [[blackface]] in the mind and will be viewed by many users to be offensive and completely inappropriate. This icon flatly will not work.

In seeing another squared-headed smiley face in the wrong color, I'm reminded of bug 51927. (Oh, it's already marked as a "see also." Hrm.)

//attachment Screenshot 2013-10-22 16.06.53.png ignored as obsolete//
Profile icon

//attachment profile.svg ignored as obsolete//
Example use of icon

//attachment Screenshot 2013-10-22 16.06.53.png ignored as obsolete//
Realized the asset uploaded was slightly out of date, May is uploading the correct asset and mockup now. 

I feel that the asset she's uploading (a variation on the original she posted) head and shoulders (ha!) better than what we have now. its a small change, I'd prefer to integrate it, since its in-line with the user icon on mobile as well as upcoming multi-media features. Stay tuned for the updated asset in just a bit.
**wmf.amgine3691** wrote:

Hmmph. https://bits.wikimedia.org/static-1.22wmf21/extensions/UniversalLanguageSelector/resources/images/cog-sprite.svg?2013-10-10T16:45:00Z works just fine... <grumbles>
**wmf.amgine3691** wrote:

(In reply to comment #39)
...
> It seems rather like we're stuck on a choice - whether to be intuitive and
> clear or to not offend people. Strange choice, since no matter what you do
> you'll pretty much always wind up offending or disturbing someone if you've a
> broad enough audience.

Nonsense.

As you point out, it should likely be anthropomorphic. Blue is used for accent in the skin, but every icon and graphic is monochromatic grey (http://ur1.ca/fx8u3, search) - as should be this one.

Aesthetically not the best choice for some people, but it's likely the least offending (even to the designers) compromise and we're all just waiting for someone to point this out and force the stakeholders to grow up and accept the compromise.
Removing easy keyword; the implementation may be easy, but as we still haven't agreed on what to do with this, it's probably not something we'd necessarily want to bring a new person into.

There are arguments here that an icon is not needed at all, but based on what Trevor said, even if it isn't needed, it's definitely useful. To remain useful, however, it needs to also remain a recognisable 'user' icon - that rules out anything with too much abstraction that wouldn't necessarily have the same meaning to the user, like a smiley face or animal (even without added issues those might present such as those Siddhartha Ghai points out), and brings us back to the more standard head and shoulders, which arguably tend to look male. Blue, which fits the skin, is apparently also problematic because in some cultures blue is associated with masculinity.

It seems rather like we're stuck on a choice - whether to be intuitive and clear or to not offend people. Strange choice, since no matter what you do you'll pretty much always wind up offending or disturbing someone if you've a broad enough audience.
(In reply to comment #28)
> Another design practice that I'm a fan of is to go with more abstract user
> icons or animal icons e.g. github's
> https://dribbble.s3.amazonaws.com/users/8063/screenshots/873671/
> github_icon_vector_shape_teaser.png

I'd just like to point out that animal icons would not be wise since languages may associate certain animals with certain genders by default. For example, a user with native language hindi might consider a cat icon to be female and a lion to be male. Cat: male: बिल्ला, female: बिल्ली, latter is what is generally default usage. Lion invokes a male idea since hindi, like English, defaults to lion (शेर), not lioness (शेरनी)
Can we get someone to integrate this, we've recently updated the general user icon used in mobile for user talk, article history, and watchlist, so it would be great to get this one in sync sooner rather than later.
Removed May (visual designer) as the assignee, not that she's uploaded the new asset from the Echo icon set. Please assign a developer to submit a patch as needed.
Profile icon

//attachment User_web.svg ignored as obsolete//
Thanks Jared; please leave correct terminology too in the bug summaries for the purposes of discoverability (the area is called "personal tools").
We'll address this icon as part of a a visual alignment exercise we're doing with the echo notifications
(In reply to comment #5)
> (In reply to comment #3)
> > Thanks for pointing this out, Aude.  For ideas on how to rework the default
> > icon to make it more gender-neutral, here's the "gallery of default
> > anonymity":
> > http://www.murketing.com/journal/?p=3098
> 
> Flickr is IMHO the best.

BTW, apparently Flickr disagreed :) , they replaced the default buddy icon with a purple square containing a rainbow camera.
**Thehelpfulonewiki** wrote:

What about https://commons.wikimedia.org/wiki/File:Gnome-stock_person.svg or https://commons.wikimedia.org/wiki/File:Crystal_Clear_app_personal_gray.png (I prefer the former).
Looks like it wasn't linked yet: monobook icon on Commons, "Racially, gender neutral icon". https://commons.wikimedia.org/wiki/File:User-variant.png

(In reply to comment #29)
> I say we keep it, and when we make all the other icons monochrome (going
> along
> with work like Agora and VisualEditor) it should become a silhouette.

I don't understand, are you saying it can't be changed before that for some reason of consistency? Also, does "silhouette" mean that in

(In reply to comment #28)
> abstract
> head + shoulders or an abstract face in b&w.

you recommend the former?
Just adding my 2 cents in here.

The icon was chosen, by me, in 2009. It was the standard generic user icon in the Tango icon library, which we were embracing at the time.

I agree with some of comments here that using stereotypes to make the icon more gender specific is going to be offensive. Should we also assume their nationality based on their location or language and adjust the icon accordingly? Obviously this is going to be a nightmare. Besides, none of this would any value.

The use of the icon was inherited from Monobook. As many people are aware, Vector was more of a riff on Monobook than a new skin. At the time especially, Monobook had become this iconic skin that everyone was so attached to after years of staring at it, that every tiny adjustment we proposed was highly controversial.

Do we still need the icon? I think so. It's actually one of the more reasonable uses of iconography - which we use very selectively in Vector - because it is...

1. Identifiable (must be obvious what it means)
2. Necessary (icons for the sake of icons are bad)
3. Important (icons for obscure tasks bring attention to the wrong things)

I say we keep it, and when we make all the other icons monochrome (going along with work like Agora and VisualEditor) it should become a silhouette.
**sumanah** wrote:

symbolic variant from gnome-icon-theme courtesy Mizmo (Máirín Duffy of Red Hat)

I asked a few other designers who work in open source to comment.  Georgia Bullen wrote:

"Hmmm...

Well there are the options of just stick figure gender-less icons e.g.
http://wikieducator.org/images/1/16/Dummy_user.png and if you avoided
colors, and went with gray or something like that then it wouldn't even
have gender color implications.

Another design practice that I'm a fan of is to go with more abstract user
icons or animal icons e.g. github's
https://dribbble.s3.amazonaws.com/users/8063/screenshots/873671/github_icon_vector_shape_teaser.png

Or this awesome site: https://diy.org/ which uses animal avatars to avoid
issues with COPA for children.

Hope that's helpful!

-georgia"


Máirín Duffy of Red Hat wrote:

"The best gender- and race-neutral icons of people are basically abstract
head + shoulders or an abstract face in b&w. One of the links you posted
in the bug had a few good examples:

http://www.murketing.com/journal/wp-content/uploads/2009/04/garageband.gif

http://www.murketing.com/journal/wp-content/uploads/2009/04/myspacenophoto.jpg

http://www.murketing.com/journal/wp-content/uploads/2009/04/nopic_192.gif

http://www.murketing.com/journal/wp-content/uploads/2009/04/vimeo.jpg

http://www.murketing.com/journal/wp-content/uploads/2009/04/identica.png

http://www.murketing.com/journal/wp-content/uploads/2009/04/npr.gif

FWIW the icon you guys are using now is one of the old gnome-icon-theme
icons. I am attaching a copy of the same icon from the newer
gnome-icon-theme, symbolic variant - it's licensed GPL, I've pasted the
link with license details below:

http://git.gnome.org/browse/gnome-icon-theme/tree/COPYING

You may of course feel free to use it!

~m"

//attachment avatar-default-symbolic.svg ignored as obsolete//
**sumanah** wrote:

(In reply to comment #24)

> Speaking on this issue, I think we should avoid any kind of gender cues in
> the
> icon. The concept of "gender" is intensely personal, mercurial, and
> ephemeral.

I completely get what you're saying here (and nudge you to potentially undo the WONTFIX on Bug 25834 to expand the currently binary gender options MediaWiki preferences offer users).  But is it really possible to avoid *any* gender cues in an icon given that "male" is, to the perception of most users, the default state of any head-and-shoulders icon unless it includes specific "not male" markers?  Defeating the unmarked state is tough.

> This bug actually points to a larger issue that we have within the software
> itself (which is that gender is a binary switch, rather than something that
> accommodates individuals who identify as "genderqueer").

> (And yes, I know that namespace translations for user pages based on gender
> is
> a whole other ball of wax, and I can't hope to think we'll ever solve for
> gender-identification problems that are fundamental to a language itself).

Solve entirely?  No.  *Improve* how we deal with genderqueer people in all languages?  Sure.

People opining on this bug ought to also look at Bug 30442 - give the user a chance to specify the gender when opening the account - and Bug 31816 - Improve the wording of gender selection option.

> As far as the icon itself goes, I would prefer that we also would move
> towards
> an image that is also racially neutral (thus, Munaf's grey icon is probably
> the
> best choice).

Seconding the request for the icon's "skin color" to be neutral. :-)
I don't necessarily think I need to address them; my position is that the icon isn't needed at all and I think it distracts as clutter rather than providing a visual cue.

However, I'm not married to killing it off, and if people decide that we want to keep it, I'm fine with that, but I also want to make sure that we're working inside some rational guidelines.
Brandon, thanks for adding your points about older comments, but I hope you can also address comment 20, comment 23 and bug 45056 comment 6: instead of explaining your position you just restated it in a post-scriptum. Thanks.
(In reply to comment #4)

> How do you make a "female" icon anyway, short of giving it breasts? Long
> hair?
> Tell that to Brandon and Sumana!

Are you suggesting that I could be mistaken for a woman? ;)

Speaking on this issue, I think we should avoid any kind of gender cues in the icon. The concept of "gender" is intensely personal, mercurial, and ephemeral. This bug actually points to a larger issue that we have within the software itself (which is that gender is a binary switch, rather than something that accommodates individuals who identify as "genderqueer").

(And yes, I know that namespace translations for user pages based on gender is a whole other ball of wax, and I can't hope to think we'll ever solve for gender-identification problems that are fundamental to a language itself).

As far as the icon itself goes, I would prefer that we also would move towards an image that is also racially neutral (thus, Munaf's grey icon is probably the best choice).

That said, I still want to get rid of the icon entirely.
**massaf** wrote:


> But why did you change the color of userpage link in that mockup?
> This just distracts from the purpose of the change :/

Unintentional. I habitually plugged in Agora red (#cc0000) instead of our current link red (#ba0000) so there's a weird differential.

> Actually I'm starting to lean towards just killing the icon per bug 45056.

Not sure I'm convinced of that yet. Just one icon does make the user tool list more scannable (ideally they'd be re-arranged or redesigned altogether).
I agree with the three comments above (as said on bug 45056). Finding a better icon doesn't seem that hard, and we're not in a hurry: the current one is not doing any severe harm, it's just imperfect (and in monobook probably even good enough).
Agora doesn't really work with Vector.
I kind of find the icon to be a sort of visual cue. Without it the personal bar is just a collection of unidentified links. While with the icon it's instantly identified as a series of links related to the user.

Stuff like proper padding and lining up of whitespace are invisible when they are present and done right. But when they are not there they give uncomfortable feelings, usability issues, etc... I think the personal icon fits into that category.

Why don't we try Agora-fying the icon?
https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Icon_Set
Two things: One, that is not a male icon. Blue does not make it male. Blue matches the skin, and I really don't understand why there is a fuss about that in particular. Two, killing the icon entirely would make sense with current skins especially since it has no functional significance anyway.

GRAW. Arg. Chickidee?
(In reply to comment #17)
> Personally, I say kill the icon.  It's the only one we have, and it stands
> out because of it.  Maybe we revisit them in the future, but for now I don't
> see a purpose.

We may one day have an avatar up there (similar to Facebook). Definitely something to think about for [[mw:GlobalProfile]]. For now, I think you're probably right that no icon is better than the current icon.
Personally, I say kill the icon.  It's the only one we have, and it stands out because of it.  Maybe we revisit them in the future, but for now I don't see a purpose.
(In reply to comment #14)
> Created attachment 11794 [details]
> testing out a gender-neutral icon
> 
> Not sure I see what you're seeing. It fits fine when you scale and color it
> based on context. 

Okay, it's considerably better when appropriately colored (but still looks like a pawn). But why did you change the color of userpage link in that mockup? This just distracts from the purpose of the change :/

Actually I'm starting to lean towards just killing the icon per bug 45056.

//attachment gender-icon-test.png ignored as obsolete//
(In reply to comment #9)
> Killing this icon was briefly proposed at bug 35341.

Filed separately as bug 45056.
**massaf** wrote:

testing out a gender-neutral icon

Not sure I see what you're seeing. It fits fine when you scale and color it based on context. 

A shade of gray would work if each user portlet item had an icon alongside it, which we're talking about in other bugs.

//attachment gender-icon-test.png ignored as obsolete//
So, I don't want to be a buzzkill and mean, but Munaf, have you actually tried putting that icon into the interface?

Because it looks awful. It doesn't fit the rest of the skin and hardly resembles a human, especially scaled-down. Maybe it would be a little better if made blue-ish, but I'm still skeptical about the new look.
**massaf** wrote:

an attempt at a gender-neutral icon

Here's a first attempt. I agree with Krinkle that it shouldn't draw attention. Link blue (#3366bb) might be appropriate, but for now it's gray. Thoughts?

//attachment GenderNeutralPerson.png ignored as obsolete//
Well, as Sumana notes, the current icon can be perceived as conforming to some gender stereotypes, so it's not "neutral" in its common perception. I've clarified the summary further.
I agree with Krinkle.  I don't see what makes this icon (https://bits.wikimedia.org/static-1.21wmf9/skins/vector/images/user-icon.png) male.  I don't think a blue shirt makes it male.

As he said, Vector uses a lot of blue.  In particular, light blue.  We could change the shirt color to light blue to make it further match the theme, but I don't know that this is really necessary.
Killing this icon was briefly proposed at bug 35341.
(In reply to comment #6)
> I ask our designers to figure out how to make a more gender-neutral icon
> (perhaps dispensing with the requirement that it look like a person).

Species-neutral too, I like it :)
Sorry for double comment.

(In reply to comment #5)
> Flickr is IMHO the best. Should also be {{PD-ineligible}} and in compliance
> with the colour scheme per Krinkle above.

(Same for Yahoo and identi.ca, very similar.)

(In reply to comment #6)
> The current icon is
> https://bits.wikimedia.org/static-1.21wmf9/skins/vector/images/user-icon.png
> .

Ah, right, I forgot that monobook is different! You can see the old good one e.g. in the screenshot at https://creativecommons.org/weblog/entry/13967
I've never considered it particularly manly: the hair always looked to me like a bun (if this is the correct term for the hairstyle), which is indeed particularly rare for men. :-)
Hence the ? in the bug summary.
**sumanah** wrote:

The current icon is https://bits.wikimedia.org/static-1.21wmf9/skins/vector/images/user-icon.png .

(In reply to comment #4)
> I prefer a single, neutral icon to gender specific icons. 
> 
> How do you make a "female" icon anyway, short of giving it breasts? Long
> hair?
> Tell that to Brandon and Sumana!

For people who haven't met us: Brandon is a man with long hair, and I am a woman with short hair.

These kinds of avatars are usually heads, head-and-shoulders, or stick figures of the whole body, so some designers use long hair, earrings, or a skirt as a shorthand for "female."

I ask our designers to figure out how to make a more gender-neutral icon (perhaps dispensing with the requirement that it look like a person).
(In reply to comment #3)
> Thanks for pointing this out, Aude.  For ideas on how to rework the default
> icon to make it more gender-neutral, here's the "gallery of default
> anonymity":
> http://www.murketing.com/journal/?p=3098

Flickr is IMHO the best. Should also be {{PD-ineligible}} and in compliance with the colour scheme per Krinkle above.
I prefer a single, neutral icon to gender specific icons. 

How do you make a "female" icon anyway, short of giving it breasts? Long hair? Tell that to Brandon and Sumana!
**sumanah** wrote:

Thanks for pointing this out, Aude.  For ideas on how to rework the default icon to make it more gender-neutral, here's the "gallery of default anonymity": http://www.murketing.com/journal/?p=3098
Now fixed as part of the alienation re-write.
Merged and will go out in the deploy train tomorrow.
https://gerrit.wikimedia.org/r/#/c/61157/
This is a bug in newFromContentBranchConversion(), and is caused by selectNodes() returning the paragraph rather than a text node, because the selection is between the open/closing paragraph and the alien.
Can't reproduce. Note that it is nowiki in paragraph, not in a header.
And in Chrome.
Still a CE issue (?).
This has been fixed in the ensuing 3 months, probably when aliens was re-written.
(In reply to comment #25)
> I did a quick test on mediawiki.org just now using [[mw:VisualEditor:What A]]
> and [[mw:VisualEditor:What B]]. It seems to mostly work in my browser, though
> it inserted a non-breaking space before the header. I'll file a separate bug
> about this.

Filed as bug 58563.
I did a quick test on mediawiki.org just now using [[mw:VisualEditor:What A]] and [[mw:VisualEditor:What B]]. It seems to mostly work in my browser, though it inserted a non-breaking space before the header. I'll file a separate bug about this. This bug report seems to be resolved/fixed and I'll echo others in suggesting that new bug reports be filed for cases in which copying and pasting misbehaves. Basic support appears to be implemented, however.
(In reply to comment #22)
> @Quim somewhat true, but we should also not forget that if you have a title
> like: "support copy and paste from other VE instances", which basically reads
> as a user story, that you can expect folks to judge the ticket as a user
> story as well.

Yes, I fully agree. This is what I meant in previous post when qualifying this bug report (perhaps too nicely) as far from perfect. We have a title and a one-line comment that doesn't provide any details about the feature expected.

It was filed more than a year ago, when VisualEditor was basically a feature developed and used by one small team. The note to remember is that even in those circumstances reports filed must be minimally descriptive in order to set a clear expectation about the requirement to fix it.

Anyway, back to the actual problem. Many more bug reports have been added to tracking Bug 33105 (thank you!) which is clearly the report that will define the quality of copy&pasting in VisualEditor.
@Quim somewhat true, but we should also not forget that if you have a title like: "support copy and paste from other VE instances", which basically reads as a user story, that you can expect folks to judge the ticket as a user story as well.

We say that this is fixed because the basic technical backbone work for it has been done and that the 'content' part of it is separate tracked in it's parent ticket, but that is a very narrow definition of course when the line between user/developer is as thin as it often is on bugzilla. Such differences are bound to create friction.
This discussion is not helpful. Please read 

https://www.mediawiki.org/wiki/Bug_management/Bugzilla_Etiquette

This report is far from perfect since Comment 0 since all we have to evaluate is

"VisualEditor: Support copy and paste from other VE instances (surfaces)"

Now this support is in place. You are saying that it doesn't work in certain circumstances. Are there file bugs opened for the circumstances you can reproduce? Currently we have

Bug 33105 - VisualEditor: Preserve rich text formatting when pasting from internal or external sources (tracking)

which tracks 6 bug reports. Are the problems you are encountering covered there? I didn't read the whole conversation at the wiki page, but the problems seemed to be related with formatting being lost from copy to paste, which is what Bug 33105 is tracking. 

If not, please create new bugs for the cases that are missing.
**Wikifram** wrote:

(In reply to comment #18)
> (In reply to comment #17)
> > Have you actually looked at and read (and understood) the linked enwiki
> > thread? And you can straight-faced claim that this is "fixed"?
> 
> I am aware that this bug, though fixed, does not encompass the entirety of
> what
> we want to see. There are other bugs, many of which we are trying to fix but
> are being distracted by people who think it's productive to edit-war on
> Bugzilla and sling insults and threats rather than actually engaging.
> 
> If you had bothered to ask, rather than just assume, we could have pointed
> this
> out before you got so very excited. But you seem more content to scream than
> talk, and then act surprised when we choose to spend our time more
> productively.


"Though fixed". Right... 

"Does not encompass the entirety of what we want to see" is newspeak for "actually screws up nearly every edit"?

"People who think it is productive to edit-war on Bugzilla and sling insults and threats rather than actually engaging"; history has shown that complacency isn't productive with you (plural), so another approach is needed. "Actually engaging"? The section about this bug and these problems has been open for days at enwiki, I have done ''all'' the work on it, I am the only one that actually tested this bugfix (and the rest of the deployment as well, clearly). Your "engagement" was a hardly relevant reply focusing on one minor aspect, but ignoring the larger picture; 

"Being distracted"; well, I didn't see any positive results when you weren't being distracted either...

"If you had bothered to ask"? Instead of e.g. reclosing this without even commenting? 

I would be very happy if you spent your working hours productively, but the results are lacking. Of course, if you consider something that is as extremely buggy as this thing "a fix", then I understand your replies; I can't use them though.
**Wikifram** wrote:

(edit conflict)
As for rewriting history, I reopened this here with the comment

"As reported at
[https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Rich_content.3F],
this is clearly not yet fixed. Testing at MediaWiki shows that copying between
VisualEditor pages (both within MediaWiki, and from enwiki to MediaWiki) gives
very poor results. I have made four tests, none of them anything extreme (only
one section header and text, no images, templates, ...), and none of them gave
a satisfactory result."

Can you indicate where you replied to this comment and/or adressed the issues I highlighted in them? Are you seriously claiming that your comment at the Status page was a reply (never mind a sufficient reply) for problem reports like what happened [https://www.mediawiki.org/w/index.php?title=User%3AFram%2FSandbox&diff=837324&oldid=837321 here]? You didn't at least think about retesting this when you thought that this was "resolved"? It still happens, FYI. And when I reopened this, you didn't think that just perhaps I didn't believe that this was resolved onwiki or offwiki? 

I have pointed out countless bugs, probably more than anyone else the last half year: perhaps it is time you start taking them seriously, and consider that I may have a point, instead of blundering on blindly.
(In reply to comment #17)
> Have you actually looked at and read (and understood) the linked enwiki
> thread? And you can straight-faced claim that this is "fixed"?

I am aware that this bug, though fixed, does not encompass the entirety of what we want to see. There are other bugs, many of which we are trying to fix but are being distracted by people who think it's productive to edit-war on Bugzilla and sling insults and threats rather than actually engaging.

If you had bothered to ask, rather than just assume, we could have pointed this out before you got so very excited. But you seem more content to scream than talk, and then act surprised when we choose to spend our time more productively.
**Wikifram** wrote:

Oh, my edit rights at Bugzilla? I'm scared now. What will I do without the possibility to edit Bugzilla? I imagine that if you continue to bury your head in the sand, someone will take away your job, but my imagination and reality sadly don't always match. 

Have you actually looked at and read (and understood) the linked enwiki thread? And you can straight-faced claim that this is "fixed"? This is comparable to "operation successful, patient dead".
Your attempts to re-write history notwithstanding, Fram, this is and remained fixed. If you edit war again, I imagine someone will end up taking your edit rights away. Please stop.
**Wikifram** wrote:

[https://en.wikipedia.org/w/index.php?title=Wikipedia%3AVisualEditor%2FFeedback&diff=585650020&oldid=585645740]

This thing is so not ready that it is laughable to claim otherwise. I would seriously urge you to keep this on open now, read and check all the comments (bug reports), and only then come back. This is more serious than any of you seems to understand. 

THIS FIX IS ABSOLUTELY NOT READY TO BE DEPLOYED. 

Read the fucking linked section, [[en:Wikipedia:VisualEditor/Feedback#Who needs bugs when you get "fixes" like this?]], don't bury your heads in the sand.
**Wikifram** wrote:

(In reply to comment #13)
> Fram,
> 
> I closed this without comment because we'd already discussed this, and it
> didn't seem like a worthwhile expenditure of my time or yours to re-hash the
> issue when we already agreed about things. I'm sad that you think I did it
> out
> of malice. AGF clearly doesn't apply to your attitude. :-( Please be less
> aggressive in future.

No, I'll only get more aggressive, just read my last post at enwiki or my next post here, which will be a link to enwiki. 

"We'd already discussed this"? You mean your replies at [https://www.mediawiki.org/wiki/Talk:VisualEditor/status]? No, I don't see where we actually agreed upon things. You were pinged about the enwiki discussion as well, which contained further examples. 

But I don't said you did it out of malice, there are a number of other possible reasons, including (but probably not limited to) laziness, incompetence, stupidity, or a hopefully well-founded fear of losing your job after the umpteenth VE fiasco.
(In reply to comment #12)
> (In reply to comment #11)
> > Wikifram: Sorry, I won't read through the entire
> > https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Rich_content.
> > 3F -
> > summarize clear testcases in Bugzilla in separate followup tickets to keep
> > things constructive, change your passive-aggressive tone, keep this ticket
> > closed as FIXED (as functionality exists but obviously is extremely
> > error-prone
> > for your testcases), and discuss high-level stuff refering to general testing
> > on the mailing list instead. Thanks.
> 
> My tone isn't passive-agressive, it is simply agressive, as in thoroughly fed
> up with the way the WMF handles things. I love it though that theDJ has
> added a
> ticket that blocks this one, but that you closed it again nevertheless. 
> 
> I am not interested in discussing things on the mailing list, I am discussing
> it at enwiki which has the largest and least biased audience of all public
> discussion places (compared to MediaWiki, which has a rather more slanted and
> smaller audience, Foundation, where there are no public discussion spaces,
> and
> Bugzilla, which is not suited for this). 
> 
> Closing tickets without any explanation, like Product Manager Forrester did,
> is passive-agressive and completely unconstructive though.

Fram,

I closed this without comment because we'd already discussed this, and it didn't seem like a worthwhile expenditure of my time or yours to re-hash the issue when we already agreed about things. I'm sad that you think I did it out of malice. AGF clearly doesn't apply to your attitude. :-( Please be less aggressive in future.
**Wikifram** wrote:

(In reply to comment #11)
> Wikifram: Sorry, I won't read through the entire
> https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Rich_content.
> 3F -
> summarize clear testcases in Bugzilla in separate followup tickets to keep
> things constructive, change your passive-aggressive tone, keep this ticket
> closed as FIXED (as functionality exists but obviously is extremely
> error-prone
> for your testcases), and discuss high-level stuff refering to general testing
> on the mailing list instead. Thanks.

My tone isn't passive-agressive, it is simply agressive, as in thoroughly fed up with the way the WMF handles things. I love it though that theDJ has added a ticket that blocks this one, but that you closed it again nevertheless. 

I am not interested in discussing things on the mailing list, I am discussing it at enwiki which has the largest and least biased audience of all public discussion places (compared to MediaWiki, which has a rather more slanted and smaller audience, Foundation, where there are no public discussion spaces, and Bugzilla, which is not suited for this). 

Closing tickets without any explanation, like Product Manager Forrester did, is passive-agressive and completely unconstructive though. Perhaps you can lecture him on these things instead. My posts have been constructive, trying to improve Wikipedia and VE, but the format and tone hasn't been to your liking. Tough luck. If you wan to know what is wrong with this "feature", either read the enwiki thread or (better still) test it or get your team to test it thoroughly, but don't expect me to repeatedly seek the shabby treatment the WMF people routinely handle out to critics, by submitting new bugs about this.
Wikifram: Sorry, I won't read through the entire https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Rich_content.3F - summarize clear testcases in Bugzilla in separate followup tickets to keep things constructive, change your passive-aggressive tone, keep this ticket closed as FIXED (as functionality exists but obviously is extremely error-prone for your testcases), and discuss high-level stuff refering to general testing on the mailing list instead. Thanks.
**Wikifram** wrote:

But can't we expect new functionality to work sometimes? ''Every'' test I have done produced errors. You could copy and paste before this "fix", it didn't give any layout though. With this fix, you get some layout, and a lot of botched layout.

I really can't believe that any of you believe this "fix" is sufficiently reliable, stable, mature to be implemented in live environments. Sometimes, like here, ''not'' having a feature is a lot better than having an extremely poor attempt at one. I don't expect it to work 100% in all cases, but I do expect it to work 100% in some cases, and 95% in most cases. I don't believe this can truthfully be claimed of this. 

As for "provide exact steps to reproduce": RTFM. I have given a link to the many tests I have done, I have described there what goes wrong. I have only received evasive or plainly incorrect answers from WMF people there. I am not going to repeat all of that here, you can just as easily follow the link I provided and try do to the same. 

No thanks for your (WMF collective) help.
> Why do you reclose a bug as resolved -fixed without any improvement or comment

Because the functionality to copy and paste from other VE instances exists with the given patch having been merged, so this request is FIXED.

This bug report never was about "Implement functionality to copy and paste from other VE instances and make sure that it works in 100% of all cases".
Software always has issues. But the request in this bug report has been fixed.

Hence please create separate followup bug reports on issues that don't work and provide exact steps to reproduce. Comment 7 does not have steps to reproduce.
Thanks for your help!
**Wikifram** wrote:

James Forrester, get lost. 

Why do you reclose a bug as resolved -fixed without any improvement or comment, when people take the time to test this, report their findings, and show where the problems are? 

The least you can do is explain why this is resolved - fixed despite my remarks; the best you can do is test this, correct it, and only then close it as fixed. 

How many times will you make the same mistakes, how often will you close bugs as duplicates when they are not, as fixed when they are not, or present things as finished when they aren't even tested? Please change your approach to this or leave it to people who seem to be more competent or less defensive. You are not doing yourself, WMF, or Wikipedia a favour by your continued behaviour wrt VisualEditor.
**Wikifram** wrote:

As reported at [https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Rich_content.3F], this is clearly not yet fixed. Testing at MediaWiki shows that copying between VisualEditor pages (both within MediaWiki, and from enwiki to MediaWiki) gives very poor results. I have made four tests, none of them anything extreme (only one section header and text, no images, templates, ...), and none of them gave a satisfactory result.
Change 86664 merged by jenkins-bot:
Rich paste

https://gerrit.wikimedia.org/r/86664
Change 86664 had a related patch set uploaded by Esanders:
Rich paste

https://gerrit.wikimedia.org/r/86664
*** Bug 50421 has been marked as a duplicate of this bug. ***
(In reply to comment #2)
> Also, question to the other of this ticket: Do you mean copying content from
> VisualEditor opened in one tab to VisualEditor opened in another tab of the
> same browser (Chrome for instance)?

This is still not working:

1. Open two different articles with VisualEditor.
2. Copy or cut content from one and paste it to the other one.

Format is lost. Links are lost. Not worth even trying in an average wiki page.

This is a relatively frequent action when cleaning, reorganizing archiving content in articles.
(In reply to comment #6)
> It could be actually a problem in Parosid/Serializer.
Yup, this is a Parsoid bug, duped as such.
*** This bug has been marked as a duplicate of bug 33091 ***
It could be actually a problem in Parosid/Serializer.

@Liangent: Could you please provide exact steps to reproduce?
We've changed our plans for how the overall integration will work, so marking this as a DUPE of 38128 now.

*** This bug has been marked as a duplicate of bug 38128 ***
**orbit** wrote:

Yeah, fixed through various re-writes. We're going to leave aliens as ce="false" for standards-based browsers and we'll have to programmatically fix IE if the cursor ends up inside.
Is this still an issue, or has it been fixed through the various re-writes of this area?
Works in current version of the editor (thanks to IME support). However I will make sure to keep executing tests from this page: http://www.mediawiki.org/wiki/VisualEditor/Typing/Indic (at this moment we have problems with automating IME tests).
**orbit** wrote:

It appears both of these are fixed. Probably due to list fixes from Roan and cursor fixes from Inez.
Marking back as fixed as of October. If you have new bugs, please create new reports rather than re-open ones tangentially-related.
This seems to be fixed already in master and on mediawiki.org.
*** Bug 47687 has been marked as a duplicate of this bug. ***
I think that this happens again, but only on Firefox.

Here's another simple test:

https://www.mediawiki.org/wiki/VisualEditor:Pawn

Edit this page in VE and start moving with the arrow keys forward (right). A pawn appears in the beginning and the end of every list item.
**vladjohn2013** wrote:

Hi, this project is still listed at  https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Work_on_RefToolbar 

Should this project be still listed in that page? If not, please remove it. If it still makes sense, then it could be moved to the "Featured projects" section if it has community support and mentors.
The main template editing functionality is now live. Though there are some fixes to make, I'm marking this one as closed.
Change-Id: I9174ed7c9012522246a6defc859276bf36763f5b
VE will support template editing quite soon (famous last words!) which will replace (alongside the TemplateData extension) pretty much all of what the RefToolbar does in terms of telling users how to use the templates and what each parameter means.

We should certainly look at some accessor functionality to make it easy and obvious when in a reference to know what templates to use, but that would be in longer time.

My concern is that we're currently targetting this landing in the middle of the GSoC period - too late for someone working on GSoC to react to it and extend it, and so soon into the period (and so obviously-about-to-happen) to make working on the area that VE will replace it. :-(
**brassratgirl** wrote:

Fair enough. Maybe the project should be "work on citation stuff" broadly -- not sure how to frame that :) There is plenty of work that should overlap between the reftoolbar and the VE, though; like figuring out what citation template parameters need to be used, figuring out how to work with Lua conversions, and so on. I wonder if reftoolbar could be converted into a VE plugin -- the interface is actually pretty good, no need to reinvent the wheel on handling citations.
Phoebe is recommending to Work_on_RefToolbar improvements at
http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Work_on_RefToolbar

However, I wonder whether our focus shouldn't be put in VisualEditor support for the Cite templates, either out of the box or via plugin. Any advice?
*** Bug 46520 has been marked as a duplicate of this bug. ***
Maybe this "Template Parameter Wizard" is of some interest:

http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_103#Template_Parameter_Wizard
Now live in master, going out in tomorrow's branch.
Speculatively putting this in the -27 deploy.
DM support for categories in https://gerrit.wikimedia.org/r/55120
Fixing test broken by 50045 https://gerrit.wikimedia.org/r/#/c/53180/
https://gerrit.wikimedia.org/r/#/c/50045/
Fixed a long time ago (September?). Closing.
Not fixed - that fixes a type error for undefined, not a range error.
Yeah, `contain: content` will perform better than `overflow: hidden`, but has imho a different semantic purpose and meaning. Either way, it's too new to cover us from a security perspective. Either way, this is blocked in migration of indicators to use <https://www.mediawiki.org/wiki/Help:Page_status_indicators>. Last I checked, many major wikis still aren't using it (much) yet.

See T40848#1938655 and T40848#1913661 for the next steps after that.
https://developer.mozilla.org/en-US/docs/Web/CSS/contain describes the CSS Containment Module 3, which is supported in Chrome 52 & up. This modules offers a general way to restrict the rendering of styled content to its parent element's dimensions: `contain: content`
https://developer.mozilla.org/en-US/docs/Web/CSS/contain describes the CSS Containment Module 3, which is described as supported in Chrome 52 & up. This modules offers a general way to restrict the rendering of styled content to its parent element's dimensions: `contain: content`
It would probably be possible to sandbox away the content area (make sure the top skin, left skin and content are in different stacking contexts and the skin ones have positive z-index). There is no way for content in a stacking context to ever overlap content in sibling stacking contexts with higher z-index, even with `position:fixed`.
It would probably be possible to sandbox away the content area (make sure the top skin, left skin and content are in different stacking contexts and the skin ones have positive z-index. There is no way for content in a stacking context to ever overlap content in sibling stacking contexts with higher z-index, even with `position:fixed`.
Negative margins combined with z-index can be used for similar re-dressing attacks. Example:

 <div style="margin-top: -340px; margin-left: 100px; color: red">Hello there</div>
Negative margins combined with z-index can be used for similar attacks. Example:

 <div style="margin-top: -340px; margin-left: 100px; color: red">Hello there</div>
Just to comment that `position:fixed` also affect extensions, such as Flow. I suggest sanitize it completely.
I chatted with Krinkle about this bug yesterday, I think we have a clear roadmap for fixing it. We'll start by pushing method A to our sites, which is the least risk to our sites. It will affect some users who have updated their user pages to "customize" the wiki logo, so those users will notice as soon as we patch the cluster. Due to that, we'll need to push the fix to our sites, and release this as a mediawiki tarball update in quick succession. We'll time it so that we also alert ambassadors and tech-news, so that technical people in the movement all hear about this soon after we push it onto the site.

Once that is in place, we'll work towards change C as a public followup. Wikis will need some time to finish converting indicators, and we can test ways of fixing the margin collapse issue.

Before we can start this, we need to do some more testing with method A. Maybe we can use Tim's visual-diff to see what it would affect. Target of Early Feb might be realistic.
>>! In T40848#1449889, @csteipp wrote:
> Krinkle mocked up the interface if we also had overflow: hidden, and the result visually (imo) looks much less like a security issue and more like vandalism,
> 
>> If we had done overflow-hidden, the page would've looked like this: http://i.imgur.com/TrPeYxG.png
>> Instead of the current: http://i.imgur.com/MFN8cBo.png
> 
> @Krinkle, can you post the style updates that you used to get that result? It looks as Trevor said, setting overflow:hidden isn't quite enough.

It turns out that result was a lucky match between screen height and the exact code used by that piece of vandalism. It used `width: 100%; height: 100%;` which means in an overflow scenario with sufficient page content and a short window, it wouldn't extend far enough to peak out.

Ignoring `position: fixed` for a second (see T123811 for that), `overflow: hidden` is enough and addresses this issue entirely for both Vector, MonoBook and any other skin. The core patch will affect modern skins using the `mediawiki.skinning` base; other skins can adopt the same in their own CSS.

As for `position: fixed`. That can be reliably addressed by giving the content its own rendering context using `transform: translateZ(0);`. See http://jsfiddle.net/Loezmm7y/4/. However that impacts rendering performance. Supported in 90%+ of browsers per http://caniuse.com/#feat=transforms2d (not in IE<=8).

However I suggest we simply forbid `position: fixed` in the Sanitizer. I don't see any valid use case for it. Fixed position is bound to rendering context (= window by default) and can always peek out if allowed. The original issue here was absolute position and relative position.
>>! In T40848#1449889, @csteipp wrote:
> Krinkle mocked up the interface if we also had overflow: hidden, and the result visually (imo) looks much less like a security issue and more like vandalism,
> 
>> If we had done overflow-hidden, the page would've looked like this: http://i.imgur.com/TrPeYxG.png
>> Instead of the current: http://i.imgur.com/MFN8cBo.png
> 
> @Krinkle, can you post the style updates that you used to get that result? It looks as Trevor said, setting overflow:hidden isn't quite enough.

It turns out that result was a lucky match between screen height and the exact code used by that piece of vandalism. It used `width: 100%; height: 100%;` which means in an overflow scenario with sufficient page content and a short window, it wouldn't extend far enough to peak out.

Ignoring `position: fixed` for a second, `overflow: hidden` is enough and addresses this issue entirely for both Vector, MonoBook and any other skin. The core patch will affect modern skins using the `mediawiki.skinning` base; other skins can adopt the same in their own CSS.

As for `position: fixed`. That can be reliably addressed by giving the content its own rendering context using `transform: translateZ(0);`. See http://jsfiddle.net/Loezmm7y/4/. However that impacts rendering performance. Supported in 90%+ of browsers per http://caniuse.com/#feat=transforms2d (not in IE<=8).

However I suggest we simply forbid `position: fixed` in the Sanitizer. I don't see any valid use case for it. Fixed position is bound to rendering context (= window by default) and can always peek out if allowed. The original issue here was absolute position and relative position.
(documenting my email to security@, and Timo's writeup)

Last week Jerry Hoff from WhiteHat Security posted https://twitter.com/jerryhoff/status/617340137689755653?s=03.

> The page the Twitter user in question was viewing is:
> https://en.wikipedia.org/wiki/Thomas_Sowell
> 
> This page uses Template:Hlist in the infobox, which was changed briefly to include Lua Module "Dynkin" (edit made by an experienced user):
> https://en.wikipedia.org/w/index.php?title=Template:Hlist&diff=prev&oldid=669920021
> 
> Which in turn was vandalised to include the red box (edit made by an anonymous user):
> https://en.wikipedia.org/w/index.php?title=Module:Dynkin&diff=prev&oldid=669919700

Because https://gerrit.wikimedia.org/r/#/c/178086/ was deployed last December, on Vector

> So all that happened is a big red box was displayed *behind* the interface menus.

For monobook, much of the interface was obscured. Fixing this issue on monobook seems unlikely.

Krinkle mocked up the interface if we also had overflow: hidden, and the result visually (imo) looks much less like a security issue and more like vandalism,

> If we had done overflow-hidden, the page would've looked like this: http://i.imgur.com/TrPeYxG.png
> Instead of the current: http://i.imgur.com/MFN8cBo.png

@Krinkle, can you post the style updates that you used to get that result? It looks as Trevor said, setting overflow:hidden isn't quite enough.
>>! In T40848#1122583, @Anomie wrote:
> Hiding overflow will also hide content when someone with a very wide screen resolution makes something that won't fit for people with lower resolutions. Horizontal scrollbars suck, yes, but is just cutting it off necessarily better?

This task is about elements placing themselves outside the content area to overlap interface elements. Capturing overflow doesn't mean it has to be inaccessible. `overflow: auto;` (e.g. scroll when overflow) would work just as well. The scrollbar would be on the content area instead of on the window. Unless scrolled to the bottom of the page the user wouldn't notice much difference in behaviour. Except that the excess content would be correctly displayed on a white background instead of against the outer the skin body (which is grey in Vector).

Example: https://codepen.io/Krinkle/debug/eNEwYo.

The only difference is that (on desktop) the sidebar would stay in view. On mobile the sidebar may be out of view depending on the viewport and how far away you scroll (virtual depth is applied). This is making its way to desktop browsers as well.

http://www.quirksmode.org/mobile/viewports.html
http://www.androidpolice.com/2015/01/09/chrome-beta-v40-new-zoom-behavior-makes-fixed-headers-scrollable-less-aggravating/
Hiding overflow will also hide content when someone with a very wide screen resolution makes something that won't fit for people with lower resolutions. Horizontal scrollbars suck, yes, but is just cutting it off necessarily better?
Giving content its own rendering context (e.g. using `translateZ(0)`) would also restrict `position: fixed;`. It's similar to "visual" security provided by iframes. Perhaps `overflow: hidden;` and translate can be used together.

Note that mw-indicators has been introduced in MediaWiki core and projects can now migrate templates such as Coordinates, Featured article etc. to using that instead. Which, to my knowledge, was the last remaining (valid) use case for allowing position: absolute; outside the content area. Which means, once migration period settles, we are free to apply `overflow: hidden;`. We may want to additionally add z-indexes in various places, but we should hide overflow no matter what.
Turns out applying overflow: hidden to .mw-body doesn't solve for fixed positioned content[1].

I looked at various techniques, including using backface-hidden which works in certain cases on certain browsers, but nothing appears to be reliable.

The only safe approach I can see is to combine z-indexing with obscuring content behind UI areas using positioned divs that fully block out the UI area and have opaque backgrounds[3].

[1] https://en.wikipedia.org/wiki/User_talk:Bababa67
[2] http://jsfiddle.net/w119kpwL/
[3] http://jsfiddle.net/Loezmm7y/1/
The Vector skin has been moved into a separate repository and the element is now targeted as `.mw-body-content` instead of `#bodyContent`.

Part of task has been resolved with T76965.
*** Bug 24667 has been marked as a duplicate of this bug. ***
I see you've found the issue with the navigation tabs in monobook. Those rely on the content being on top because they are longer than they have to be.

Note that these are longer on purpose because of relative font-size differences on different browsers. I see you shortened them to arbitrary values 0.2em and 0.3em.

Presumably, after you moved the content behind the tabs and removed the z-index from the tabs, you trimmed those values until they no longer stick out, but not so short that they leave a gap and would no longer touch the content container.

As you can guess by now, those em values would expand to different sizes and most certainly in one of the browsers Monobook supports this will now leave a gap (as if they're shorter), or cause an ugly border to stick it (as if they're longer).
Created attachment 15282
Patch for Monobook

Changed it to use #column-one > *, which seems to work.

**Attached**: {F9561}
(In reply to Chris Steipp from comment #58)
> Which seems to fix the issue, but would break some of the widgets that
> position elements outside of the content area. Do those usually work with
> monobook?

Yes, they do. And since this would break common things like enwiki's "featured article" star, I recommend against doing this.

A better fix would be to apply the z-index to the contents of div#column-one rather than to the whole thing; you could either target them individually by id or by targeting something like "#column-one > *" (do we still care about browsers old enough to not support ">"?).
I wasn't seeing a great way to fix monobook with z-index=0, so I used another fix that Krinkle had also mentioned

#bodyContent {
	position: relative;
	overflow: hidden;
}

Which seems to fix the issue, but would break some of the widgets that position elements outside of the content area. Do those usually work with monobook? I looked at https://en.wikivoyage.org/wiki/Clearwater with Vector and Monobook, and the map widget is gone in monobook.
Thanks Bartosz,

Testing this on my dev system, the monobook patch doesn't seem to be working right. Since div#column-one covers over the top of everything in the content area, it prevents clicking on any forms / links in that area. So it breaks all special pages.

I'm testing it on master as of this afternoon, so might be a recent change?
Created attachment 15223
Patch for Modern

**Attached**: {F9560}
Created attachment 15222
Patch for Monobook

I ended up just guessing better padding values for the tabs to allow them to always have a higher z-index than content.

At first I tried to properly calculate the necessary heights and to not mix pixels and ems, but it required changing the code considerably (mostly to keep IE6 from breaking). The end result was not really prettier than what we have now, and definitely not something appropriate for a security patch.

//attachment 0003-SECURITY-Monobook-Secure-interface-layer-from-page-c.patch ignored as obsolete//
Created attachment 15221
Patch for CologneBlue

**Attached**: {F9559}
Created attachment 15220
Patch for Vector

Patch from attachment 14981 no longer applies, here's a rebased version.
I'm going to work on patches for other skins today (finally; sorry for the delay).

I'm using this very simple test case:
  <div style="background: red; position: fixed; z-index: 999999;
  top: 0; left: 0; bottom: 0; right: 0;">&nbsp;</div>
…and verifying that all of the elements listed by Krinkle in earlier comments (logo, sidebar, personal, tabs, search, sitenotice, page name) are visible and clickable (unless any of them are missing in given skin, of course).

**Attached**: {F9558}
(In reply to Bartosz Dziewoński from comment #51)
> My personal opinion is that we should either WONTFIX this bug

I disagree. The advantage to fixing this bug, even if it's not perfect with respect to the TOC and other in-content "chrome", is that when some vandal tries to take advantage of it then people don't have to know about manually editing the URL to include "?action=edit" to be able to fix it.
For Monobook, we could make the top border of content area be actually generated by <div id="p-cactions"/> or one of its descendants, which should make applying Krinkle's idea reasonably straightforward. (Or, someone could sit down with pen and paper and actually calculate what exactly is the height of the tabs, with all of the em sizings applied, which would let us avoid z-index hacks.)

Modern and CologneBlue should also be straightforward to adjust.

I could do that (when I find the time, probably the soonest could be this weekend), but I'm not entirely sure if the fix is really worth the effort: we would still have important UI bits interspersed with the content (table of contents, section edit links), and the whole exercise is rendered pointless if such easily exploitable elements remain. (Moving them out of content would require a pretty big redesign of all skins, including third-party ones.)

My personal opinion is that we should either WONTFIX this bug (I actually thought that this "bug" was almost common knowledge…) or combine Krinkle's solution with something that would also protect inter-content chrome (possibly the z-index limiting mentioned earlier, if we can't come up with anything less nasty – I'm all out of ideas). But I can prepare the skin patches anyway.
MatmaRex, Brad had noticed specifically that I07223ba4 made fixing Monobook more difficult.
Adding MatmaRex, in case he can help out with the Monobook and Cologne Blue skins
Created attachment 14983
Screenshot of test case (on master, with patch)

**Attached**: {F9557}
Created attachment 14982
Screenshot of test case (on master, before patch)

**Attached**: {F9556}
Created attachment 14981
Patch for Vector skin

//attachment security-vector-zindex.patch ignored as obsolete//
Okay, updated the patch one more time with a check. A few things have changed in the Vector skin since last time.

Test case:

<div style="
 position: absolute;
 top: -180px; left: -10%;
 z-index: 99999;
 width: 120%; height: 400px;
 background: rgba(0, 0, 255, 0.8);
 outline: 1px solid orange;
 font-size: 2em;
 text-align: center;
">
<div style="
 position: absolute;
 top: 0; right: 0; bottom: 0; left: 0;
 overflow: hidden;
 background: rgba(255, 255, 255, 0.8);
 outline: 1px solid blue;
">[[File:Transparent.gif|4000x4000px|link=//example.org|Click]]</div>
<div style="position: absolute; bottom: 0; text-align: center;">Navigation/Search</div>
</div>

<div style="
 position: absolute;
 top: -170px; left: -190px;
 z-index: 99999;
 width: 240px; height: 640px;
 background: rgba(0, 255, 255, 0.8);
 outline: 1px solid red;
 font-size: 2em;
 text-align: center;
">
<div style="position: absolute; bottom: 0; text-align: center;">Logo/Sidebar</div>
<div style="
 position: absolute;
 top: 0; right: 0; bottom: 0; left: 0;
 overflow: hidden;
 background: rgba(255, 255, 255, 0.8);
 outline: 1px solid green;
">
[[File:Transparent.gif|350x350px|link=//example.org|Click]]
</div>
</div>


Current mediawiki/core.git@master:

== Vector skin ==
- Logo:       Not safe
- Sidebar:    Not safe
- Personal:   Not safe
- Tabs:       Not safe
- Search:     Not safe
- Sitenotice: Not safe
- Page name:  Not safe

After my patch:

== Vector skin ==
- Logo:       Safe
- Sidebar:    Safe
- Personal:   Safe
- Tabs:       Safe
- Search:     Safe
- Sitenotice: Safe
- Page name:  Safe
So I'd recommend we move ahead with just the Vector fix.
Monobook can't get fixed, it is currently relying on insecure z-index overrides. It needs to be refactored in general.

I think we can do so in public without exposing or explaining this bug though, but it's more than a bug fix, we basically need to re-make the same visual layout with a different It requires a few changes to the html as well, which always make this more complicated with regards to caching and backwards compatibility while the html cache rolls over but stylesheets are on a separate request that will roll over separately (earlier).
(In reply to Chris Steipp from comment #41)
> Timo, any chance you were able to get Monobook fixed?

Timo: ping?
(In reply to comment #39)
> Created attachment 13731 [details]
> Patch for Vector skin
> 
> As for Monobook, can't take the same approach due to it purposely having the
> navigation behind the content (because of the overflow of the tabs). So we'll
> need to take a different approach there (or, preferably, refactor it to not
> use
> that weird nesting).

Timo, any chance you were able to get Monobook fixed? It would be great to get this fixed on the cluster once fundraising's big push is done in Jan. I think Monobook is the only non-default skin that many admins use.

Also adding Jared so UX is aware of this.

//attachment bug38848.patch.diff ignored as obsolete//
Created attachment 13731
Patch for Vector skin

As for Monobook, can't take the same approach due to it purposely having the navigation behind the content (because of the overflow of the tabs). So we'll need to take a different approach there (or, preferably, refactor it to not use that weird nesting).

//attachment bug38848.patch.diff ignored as obsolete//
Krinkle: Do you plan to rework your patch in comment 36 (as you obsoleted it)?
Comment on attachment 11395
Updated combined patch for 1.21, with Brad's fixes.

Obsoleting this patch set. Also I see you fell into the same clean up trap as I did for Monobook. The z-indexes there for the tabs are needed to 1) display the tabs underneath #content (since they are taller than they should be), and 2) make the selected tab go on top so it overlaps the top border of #content.
It does. It's just been a little lower priority.
Chris, does this still need to happen?
(In reply to comment #19)
> In monobook, the left-hand menu is still covered up. I wasn't able to fix that.

Set position:relative on .portlet?

(In reply to comment #28)
> * Sitenotice: Fail (wikipage remains on top)

Since the Sitenotice is inside the #content area, that's going to be a bit difficult.
Merged and will go out in wmf6.
Related URL: https://gerrit.wikimedia.org/r/65703 (Gerrit Change Ic01e110a5e6094cd275327a2e8cea90c900f1bd1)
Moving all of these out into their own bugs and closing this:

(In reply to James Forrester from comment #18)
> * media thumbnail over-ride: not yet done, low priority

Now bug 62669.

> * alignment (baseline/middle/…): not yet done, low priority

Now bug 62670.

> * need a "set as 'upright'" size value setting (default to 75%)

Now bug 62671.

> * link: not yet done, low priority

Now bug 62672.

> Non-image things:
> * page (for multi-page items, e.g. PDFs): not yet done, low priority

Now bug 62673.

> * noicon (for multimedia items): not yet done, low priority

Now bug 62674.


> * start: not yet done, low priority

Now bug 62675.


> * thumbtime: not yet done, low priority

Now bug 62676.


> * merging with the (future) gallery editing dialog: not yet done

Now bug 62677.


> * CE-surface fixes to make TMH's media items display correctly: not yet done

Now bug 62678.

Closing this one as an unhelpful semi-tracker.
Updated list of not-yet-done items from comment #16:

* which media item is shown (but keeping other options): bug 51033
* media thumbnail over-ride: not yet done, low priority
* alignment (baseline/middle/…): not yet done, low priority
* need a "set as 'upright'" size value setting (default to 75%)
* link: not yet done, low priority

Non-image things:
* page (for multi-page items, e.g. PDFs): not yet done, low priority
* noicon (for multimedia items): not yet done, low priority
* start: not yet done, low priority
* thumbtime: not yet done, low priority

Other things:
* preview of media item: bug 52461
* remove from page button: bug 51764
* merging with the (future) gallery editing dialog: not yet done
* CE-surface fixes to make TMH's media items display correctly: not yet done
Change 105247 merged by jenkins-bot:
Add image type change to media edit dialog

https://gerrit.wikimedia.org/r/105247
A quick review of the settings functionality for the media dialog right now:

* which media item is shown (but keeping other options): bug 51033
* media item type (thumb, frame, frameless): underway in gerrit 105247
** media thumbnail over-ride: not yet done, low priority
* border: not yet done, low priority
* location (left/right/centre/non): bug 51293, done
* alignment (baseline/middle/…): not yet done, low priority
* size: mostly done; needs some fixes
** need a "set at default size" button
** need a "set as 'upright'" value setting (default to 75%)
** logic rule changes when image is frame not thumb (no upscaling of image)
* link: not yet done, low priority
** Possibly needs to know licence to avoid linking in violation of licence, e.g. CC-BY?
* alt text: done
* caption: done

Non-image things:
* page (for multi-page items, e.g. PDFs): not yet done, low priority
* noicon (for multimedia items): not yet done, low priority
* start: not yet done, low priority
* thumbtime: not yet done, low priority

Other things:
* preview of media item: bug 52461
* remove from page button: bug 51764
* merging with the (future) gallery editing dialog: not yet done
* CE-surface fixes to make TMH's media items display correctly: not yet done
Change 105247 had a related patch set uploaded by Jforrester:
[WIP] Add image type change to media edit dialog

https://gerrit.wikimedia.org/r/105247
Change 105098 merged by jenkins-bot:
Adding alternate text to media edit dialog

https://gerrit.wikimedia.org/r/105098
Change 103193 merged by jenkins-bot:
Changing image size in MWMediaEditDialog

https://gerrit.wikimedia.org/r/103193
Change 105098 had a related patch set uploaded by Jforrester:
Adding alternate text to media edit dialog

https://gerrit.wikimedia.org/r/105098
Change 103193 had a related patch set uploaded by Jforrester:
Changing image size in MWMediaEditDialog

https://gerrit.wikimedia.org/r/103193
Change 92767 abandoned by Mooeypoo:
[WIP] Add further image attribute editing to the media dialog

Reason:
Split into separate dependent commits

https://gerrit.wikimedia.org/r/92767
*** Bug 53937 has been marked as a duplicate of this bug. ***
Change 92767 had a related patch set uploaded by Jforrester:
[WIP] Add further image attribute editing to the media dialog

https://gerrit.wikimedia.org/r/92767
We have another request for "alt text" support in the media dialog.  As this is an accessibility concern for the visually impaired in our reader base, it's an important option to offer (the dialog will have to explain this field, and why it's desirable).
Change 74082 had a related patch set uploaded by Jforrester:
Base for media settings size widget.

https://gerrit.wikimedia.org/r/74082
*** Bug 51126 has been marked as a duplicate of this bug. ***
Just adding another urge for alt.text at English Wikipedia. :)
*** Bug 50709 has been marked as a duplicate of this bug. ***
Caption editing is now done and will be live in a few minutes; setting size, alignment, type and border will come later.
Speculatively putting into the next release.
Related URL: https://gerrit.wikimedia.org/r/67082 (Gerrit Change Ic38992e04b5f3932cf18f2dfc217cd733196efb8)
Related URL: https://gerrit.wikimedia.org/r/66993 (Gerrit Change Idc5f4a23a2709264d869a91d00873c4e187bc470)
@Ed Feature tests:

* Engine is ECMAScript5 compliant.

  Avoid testing things like Object.create or Function#bind which can easily
  be polyfills (and asserting the difference between native and polifill can
  be tricky). Assert that strict mode works. 

  supportsStrictMode = ( function () {
      "use strict";
      function x() {
          return this;
      }
      return x() === undefined;
  }() );

  Perhaps you could even take out x() and just return this === undefined.
  Though that appears to work and seems more straight forward, I see all
  patterns out there use a function inside. Let's figure out if its needed
  and only do it if needed.

* Browser supports ContentEditable.

  DOMElements have all supported properties defined in their default state.
  e.g. all input fields have property 'placeholder' (empty string as value
  by default).
  supportsPlaceholder = 'placeholder' in document.createElement( 'input' );

  For content editable we don't need to create an element, we can just
  use document.body as test target since it works body as well. 

  supportsContentEditable = 'contentEditable' in document.body;
Setting milestone per James.
*** Bug 41149 has been marked as a duplicate of this bug. ***
Having discussed this with Timo just now, ua-parser has now moved even further away from being appropriate for client-side use, so here's the new plan:

* We will have some basic up-front tests of browser functionality - contentEditable, localStorage, etc.

If the browser is detected to not have this, we will fail with an error message along the lines of "Sorry, this browser does not support some of the core technologies used in VisualEditor and so it will not load. <Oh well>"

* Then we have two lists - a known-good list (i.e., currently the IE9+/Firefox10+/Chrome16+/Safari5+ list) and a known-bad list (e.g., Android<=2, Opera) If the browser is in the former, VE loads; if in the latter we will fail with an error message along the lines of "Sorry, this browser is known to have serious issues with VisualEditor and so it will not load. <Oh well>"

If we reach this point (seems to have the technologies, not a known-bad or a known-good), we give the user a choice about whether to proceed - "We do not know if this browser works perfectly with VisualEditor; do you wish to proceed? <OK> <Cancel>" - and set the answer in localStorage.
This was deliberately removed by bug 40034.
**ignatzmice.wiki** wrote:

Was going to file a new bug, but this popped up as a possible duplicate. I notice that rather than doing *nothing*, it does create a newline in the edit summary box, which is then transformed into a space on saving. I too use Monobook, not that I image it makes a difference.
Agree with comment #4, this is still an issue, and it's now more problematic due to a higher number of experienced users being used to hit 'Enter' to save.

Has Rob's code (committed almost a year ago) been merged?
**KilliondudeWP** wrote:

This is an issue and has been for at least a few weeks. I'll note that I use Monobook in case that is relevant.
This is now fully correct; closing as fixed.
Change 246185 merged by jenkins-bot:
Media upload: Initialize booklet before setting file on drag drop

[[https://gerrit.wikimedia.org/r/246185]]
Change 246185 had a related patch set uploaded (by Prtksxna):
Media upload: Initialize booklet before setting file on drag drop

[[https://gerrit.wikimedia.org/r/246185]]
Change 244331 merged by jenkins-bot:
Media upload: Initiate upload process on image drop

[[https://gerrit.wikimedia.org/r/244331]]
Change 244331 had a related patch set uploaded (by Esanders):
Media upload: Initiate upload process on image drop

[[https://gerrit.wikimedia.org/r/244331]]
VE's drop handler needs a list of allowed file extensions on the target remote wiki. You can get this via the API – http://commons.wikimedia.org/w/api.php?action=query&meta=siteinfo&siprop=fileextensions – but we'll need T114765 before we can scrape it. It also/instead needs a list of MIME types; not sure if that's possible in MW, sadly.
(In reply to comment #3)
> If using UploadWizard itself is not feasible at this stage, a lightweight
> uploader UI similar to what's available on mobile might be good -- this does
> a cross-origin POST to Commons for the upload, so we don't have to leave the
> page or open an iframe or anything weird like that.

Opening up an iframe isn't too hard for VisualEditor (every dialog is one already), but re-using UploadWizard (and refactoring it so this is possible) seems like a much better solution than writing our own.

There's wider product questions about whether to allow uploading to local, or just to Commons (given that relatively few wikis allow local uploads, and that those are only meant to be used in special circumstances, making it too easy to upload copyvios/etc. and having licence proliferation might be the wrong approach).
I think roughly what we'd want to happen is something like this:

* user drag-and-drops an image file from Explorer/Finder/file manager into the document.
** if possible, show a rectangular placeholder box around the cursor position while dragging
* on drop, save the cursor position so we know where in the document to insert...
* ...and spawn the UploadWizard or similar interface, handing it the file we've received to start the actual upload process, select a license, save a description etc.
* At the end of the UploadWizard, instead of showing you the link to the file we transition straight back to the editor...
* ...and you can then modify the positioning/sizing/caption/etc with the VisualEditor's existing dialogs.


If using UploadWizard itself is not feasible at this stage, a lightweight uploader UI similar to what's available on mobile might be good -- this does a cross-origin POST to Commons for the upload, so we don't have to leave the page or open an iframe or anything weird like that.
Request for similar functionality made at MediaWiki today:

Hi, I see a number of requests for the ability to easily upload local images (from our local HD to Wiki I guess). I'd like to add my vote for this request. How is this progressing? How would it work? Simply browse for an image locally and then go through the captioning, sizing, aligning, positioning, licensing — then upload for it to appear immediately in the desired location with also the hi-res and info immediately in Wikimedia Commons?

Robertwhyteus (talk)‎20:27, 9 July 2013
This is not on schedule for before the next big release; noting as such.
Change 240116 merged by jenkins-bot:
Add image upload tab to media dialog

[[https://gerrit.wikimedia.org/r/240116]]
Change 240116 had a related patch set uploaded (by Esanders):
[WIP] Image uploading

[[https://gerrit.wikimedia.org/r/240116]]
@nirzar, @matmarex, @marktraceur, please clarify if I've missed or misunderstood anything.
Notes from `#wikimedia-multimedia`, with @matmarex and @marktraceur //(logs are edited to keep only relevant messages)//:

{P1870}

***

**tl;dr**
Our first step is to make a tool that can upload a file from enwiki to commons with a default license. The local vs remote and license choices can come later. 
The commons specific subclass of [[https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.Upload.Dialog|mw.Upload.Dialog]] can go to [[https://www.mediawiki.org/wiki/Extension:CommonsMetadata|CommonsMetadata]]. The `mw.CommonsUpload` model will take care of the `{{information}}` template on Commons. 
This new code could live in VE-mediawiki, or in core, after naming it `MediaRepoUpload` instead of `CommonsUpload`.
I had a discussion with @nirzar, on how we can integrate the [[https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.Upload.Dialog|upload dialog in core]] with VisualEditor. @nirzar explained to me the expectations of the user when in VE, and how a simplified workflow would work best. @marktraceur was talking about a bare bones version for the first iteration too, more in my next comment. In simplifying the workflow, we wanted to cut some details currently required to upload, but aren't sure if it is  acceptable from a product or legal point of view—

1. Isolate global and local information to avoid cognitive overload.
2. Pick sane license defaults and don't give the user too much choice
3. Auto-categorize the image to— //from-VE//, or some such, making it easier to find these images on Commons.
4. Hide where the image is going (local wiki vs commons). Inform user later that the image went to commons — //Thanks for uploading to Commons. [[https://commons.wikimedia.org/wiki/Commons:Welcome|Learn More]].//

***

When uploading through VE there would be two entry points—
1. An //Add more// button in the Insert Media (//Media settings//) dialog //[1]//.
2. Dropping a file into VE.

The first option would lead to the first pane of the upload dialog //[2]//. The second option would jump straight to the second pane //[3]//. For VE we'll always skip the last, //Usage// pane and directly insert the image on the page. 

@nirzar wanted the local editing to be more inline in VE, but, it currently opens up a dialog //[4] (this isn't exactly in the purview of making upload work with VE, but deserves mentioning)//. We need to decide whether we want to automatically open up this dialog or let the user initiate the action.
He has also requested User Research for this workflow, but I don't know much about that yet.

***

1. F1359538
2. F1359743
3. F1360116
4. F1360346
//Comments from the pitch meeting last week//
* Show a preview of the image in the dialog? Easier in VE but useful for WE.
* Licensing imposition info and user click-through
** Let them choose? Danger of choice turning into what we have with UW?
* Build a preview whilst you go through the steps – show where the caption will be rendered, anticipate the final result.
* Description and caption. If we’re doing it in an article, do users have that distinction? Hard to provide them as separate things?
** Separation between local information and global information? Do local activities after the ‘publish’ step?
** Show caption as part of preview?
** Just use caption as description?
** Call out //“how it will appear in the article”// vs //“how it will appear to re-users”//?
** Each step may have a different license, need to split them by those lines
* Split licences – possibly CC0 for description/etc. but CC-BY-SA-3.0 [or whatever] for the image and possibly CC-BY-SA-3.0 or CC-BY-SA-4.0 or PD or … for the caption (and may be different)
//Comments from the pitch meeting last week//
* Show a preview of the image in the dialog? Easier in VE but useful for WE.
* Licensing imposition info and user click-through
** Let them choose? Danger of choice turning into what we have with UW?
* Build a preview whilst you go through the steps – show where the caption will be rendered, anticipate the final result.
* Description and caption. If we’re doing it in an article, do users have that distinction? Hard to provide them as separate things?
** Separation between local information and global information? Do local activities after the ‘publish’ step?
** Show caption as part of preview?
** Just use caption as description?
** Call out “how it will appear in the article” vs “how it will appear to re-users”?
** Each step may have a different license, need to split them by those lines
* Split licences – possibly CC0 for description/etc. but CC-BY-SA-3.0 [or whatever] for the image and possibly CC-BY-SA-3.0 or CC-BY-SA-4.0 or PD or … for the caption (and may be different)
//Comments from the product pitch meeting today//

* @Esanders: inline inspectors are there for things that probably shouldn’t be easily dismissed
* Need to think about when information should be required - some things can be postponed
* Can we use a non-linear workflow for this?  Additional information is recorded non-modally
* Doesn’t provide any user education about what’s allowed on Commons and what’s not
** @Jdforrester-WMF: almost all users skip straight past that page in the UploadWizard anyway
*** Bug 64158 has been marked as a duplicate of this bug. ***
This is not on schedule for before the next big release; noting as such.
Merged and will be pushed to production in a few minutes.
We could trivially extend the functionality as it has just been implemented so that each subsequent click beyond the third expands the selection to the next block parent. Might be useful for selecting multiple paragraphs within a table cell, table rows, full tables etc. Or might be annoying. Thoughts?
Related URL: https://gerrit.wikimedia.org/r/70104 (Gerrit Change Ic80d24581535766714d80104222924f7a0d20f1a)
I just encountered this again when editing a table on a wiki. Especially in table cells it is tedious to have to manually select the contents of a table cell.
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVzly25pU4b8yJAIAY5X} [2017-06-26T19:05:33Z] <mobrovac@tin> Finished deploy [restbase/deploy@3975ab2]: Update Parsoid HTML version to 1.5.0 - T39902 (duration: 06m 16s)
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVzlxbBhU4b8yJAIAY5J} [2017-06-26T18:59:17Z] <mobrovac@tin> Started deploy [restbase/deploy@3975ab2]: Update Parsoid HTML version to 1.5.0 - T39902
{nav icon=file, name=Mentioned in SAL (#wikimedia-operations), href=https://tools.wmflabs.org/sal/log/AVzlvvIiU4b8yJAIAY40} [2017-06-26T18:51:55Z] <arlolra> Updated Parsoid to b59045f2 (T39902, T149794)
Change 351537 merged by jenkins-bot:
[mediawiki/services/parsoid@master] Implement rendering of redlinks, etc. as a post-processor

[[https://gerrit.wikimedia.org/r/351537]]
Change 351537 had a related patch set uploaded (by Arlolra; owner: Arlolra):
[mediawiki/services/parsoid@master] WIP: Port VE's LinkCache::styleElement

[[https://gerrit.wikimedia.org/r/351537]]
See https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/HEAD/modules/ve-mw/init/ve.init.mw.LinkCache.js
To highlight one of the blocked tasks: T119266 makes for a pretty bad user experience in the Android app.
Change 303827 abandoned by Arlolra:
[WIP] Add redlinks to a doc

Reason:
Per offsite

[[https://gerrit.wikimedia.org/r/303827]]
@ssastry, I put this on the list for the next services / parsoid sync meeting. Red links are frequently requested, and we now have the tools to implement this efficiently.
>>! In T39902#2537871, @Legoktm wrote:
> Unfortunately, relying on the links API or the current database state isn't enough. We also have to be aware of `Title::isKnown()`, so things like special pages are blue if they exist, foreign files/global user pages (and future shadow namespaces) are looked up remotely.

I see {T141963} already exists.

Also, BTW, the suggested API query already handles Special- and Media-namespace links. That does leave MediaWiki-namespace links and anything using the 'TitleIsAlwaysKnown' hook.
>>! In T39902#2537460, @Pchelolo wrote:
> So at this point #changeprop knows which particular redlink was updated and can give this information to #restbase and #parsoid. So if #parsoid implements this an an html2html endpoint with the semantics of 'add/remove redlink information to this one particular title' - it wouldn't need to call MW API at all.

It should watch out for races.  Two pages are created in close succession.  The creation of Page_1 triggers a job to update that in the DOM to blue/exists.  While that is running, Page_2 is created, triggering another job.  It needs to not clobber the first.
Per @gwicke at E258
>>! In T39902#2537460, @Pchelolo wrote:
>
> So at this point #changeprop knows which particular redlink was updated and can give this information to #restbase and #parsoid. So if #parsoid implements this an an html2html endpoint with the semantics of 'add/remove redlink information to this one particular title' - it wouldn't need to call MW API at all.

The base case is not solved ... you are talking about steady state behavior after a revision has been rendered and stored. But, on page edit, when the page is reparsed, you need to set up red links which requires getting information from the API.

>>! In T39902#2537871, @Legoktm wrote:
> Unfortunately, relying on the links API or the current database state isn't enough. We also have to be aware of `Title::isKnown()`, so things like special pages are blue if they exist, foreign files/global user pages (and future shadow namespaces) are looked up remotely.

This is not a problem per se. Whatever code in Mediawiki provides this functionality can be implemented in the ParsoidBatchAPI extension / API call providing the functionality, unless I am missing something.
Unfortunately, relying on the links API or the current database state isn't enough. We also have to be aware of `Title::isKnown()`, so things like special pages are blue if they exist, foreign files/global user pages (and future shadow namespaces) are looked up remotely.
>>! In T39902#2537353, @GWicke wrote:
>> Rely on Change Propagation to provide Parsoid the information about what redlinks to update
> 
> This is a possible optimization, but if that precise information is not available right away we could perhaps start by indicating "update all red links" only. See {T114413} for more on the html2html end point.

Basically we already have (partially) code in CP to propagate redlinks updates, but it's not enabled. What it would do is on each new page creation/deletion it would go over the links table to see which pages were linking to this one and send rerender requests to each of those pages.

So at this point #changeprop knows which particular redlink was updated and can give this information to #restbase and #parsoid. So if #parsoid implements this an an html2html endpoint with the semantics of 'add/remove redlink information to this one particular title' - it wouldn't need to call MW API at all.

We could even not involve parsoid and do it with a regex in #restbase (I'm joking)
> I am not opposed to this, but, can someone summarize what led to this change?

Red links change rarely, and we do have information & infrastructure to propagate those changes. This means that it is significantly cheaper (esp. for the PHP API) to only process red links on change, rather than on each view.

> Rely on Change Propagation to provide Parsoid the information about what redlinks to update

This is a possible optimization, but if that precise information is not available right away we could perhaps start by indicating "update all red links" only. See {T114413} for more on the html2html end point.
Comment from Arlo's [Gerrit change 303827](https://gerrit.wikimedia.org/r/303827):
> [WIP] Add redlinks to a doc
> * Makes use of the suggestion here: T39902#2209625
> * Since this is still a WIP, provides an internal qs param (_redlinks) to add them to wt2html requests.
>This probably belongs in html2html, as described here: T39902#2240375
> However, it's not clear that there's a consensus on doing that yet.
> See the discussion [in T114413]
Change 303827 had a related patch set uploaded (by Arlolra):
[WIP] Add redlinks to a doc

[[https://gerrit.wikimedia.org/r/303827]]
>>! In T39902#2535493, @Arlolra wrote:
>> @Anomie provided advice how to use the Action API to get redlink information.
> 
> Can you put that here?

See his April 2016 comments, starting at T39902#2209625
> @Anomie provided advice how to use the Action API to get redlink information.

Can you put that here?
@Jdlrobson and I just had a really good conversation about this.  The thing #ArchCom (or someone) needs to provide is guidance for what code that someone (possibly Jon?) can contribute in order to accelerate progress on the redlink issue.  @anomie provided advice how to use the Action API to get redlink information.  @gwicke, is there any guidance you're waiting on the rest of #ArchCom for?  @ssastry, do you agree with @gwicke that Parsoid needs modification to provide redlink information in the HTML?
We are currently working on implementing the update logic in the change propagation service: T133221. This will trigger HTML re-renders for all pages linking to a created / deleted page. As part of the re-render request (see T114413), we will supply

- an update mode ('redlinks', 'brokenlinks' or the like),
- whether this is a deletion or creation, and
- the created / deleted title (so that updates can be targeted).

The number of update requests from this will be fairly small, so optimizations are not critical. However, for this to actually result in red links being inserted / updated, Parsoid will need to mark up red links as part of the normal render process.
@anomie, thanks for the input! And sorry to hear about the flu- hope you are better soon!
>>! In T39902#2208376, @GWicke wrote:
> As far as I am aware, there is currently no API that lets us efficiently retrieve the list of red links in the current version of a given article. https://en.wikipedia.org/w/api.php?action=help&modules=query%2Blinks provides a full list of links, but [does not mark red links specially](https://en.wikipedia.org/w/api.php?action=query&prop=links&titles=User:GWicke/LinkTest).

You could use something like https://en.wikipedia.org/w/api.php?action=query&generator=links&titles=User:GWicke/LinkTest.

> This end point already supports restricting links to a specific namespace using the `plnamespace` parameter. Along the same lines, we could add a `plbrokenlinks` flag parameter, which would restrict the returned list of titles to broken / red links only. 

We might have to disable it (or reduce the functionality) in miser mode though, like we do with various other parameters, to avoid bugs like T97797.

I'll try to remember to look at it next week when I'm over the flu.
Based on the performance information we have from elematch, I think it is clear that updating red link information server-side is doable at very moderate cost. Here is a proposal:

### Implement red link updates in change propagation

The recently deployed change propagation service will follow page creation / deletion events, and will initiate red link updates for all pages linking to the created / deleted pages. (#services)

### Parsoid to mark red links with an attribute by default

Regular parse: Parsoid will request a list of red links from the API, and annotate <a> elements with appropriate attributes in a DOM pass. 

Update: When getting a 'red link update' request from the change propagation service, RESTBase will pass the current HTML and **the update mode ("redlinks")** to Parsoid, the same way it already does right now for template or image updates. Parsoid will then update red links using any technique of its choosing. For example, it could do this using elematch, avoiding the need for expensive DOM parsing. (#parsing-team)

### Issue: API for red links

As far as I am aware, there is currently no API that lets us efficiently retrieve the list of red links in the current version of a given article. https://en.wikipedia.org/w/api.php?action=help&modules=query%2Blinks provides a full list of links, but [does not mark red links specially](https://en.wikipedia.org/w/api.php?action=query&prop=links&titles=User:GWicke/LinkTest). Nor does it support only retrieving red links.

This end point already supports restricting links to a specific namespace using the `plnamespace` parameter. Along the same lines, we could add a `plbrokenlinks` flag parameter, which would restrict the returned list of titles to broken / red links only. 

@Anomie @ssastry @Pchelolo @mobrovac @Arlolra, does this sound sane to you?

(#services or #parsing-team)
Based on the performance information we have from elematch, I think it is clear that updating red link information server-side is doable at very moderate cost. Here is a proposal:

### Implement red link updates in change propagation

The recently deployed change propagation service will follow page creation / deletion events, and will initiate red link updates for all pages linking to the created / deleted pages. (#services)

### Parsoid to mark red links with an attribute by default

Regular parse: Parsoid will request a list of red links from the API, and annotate <a> elements with appropriate attributes in a DOM pass. 

Update: When getting a 'red link update' request from the change propagation service, RESTBase will pass the current HTML and **the update mode ("redlinks")** to Parsoid, the same way it already does right now for template or image updates. Parsoid will then update red links using any technique of its choosing. For example, it could do this using elematch, avoiding the need for expensive DOM parsing. (#parsing-team)

### Issue: API for red links

As far as I am aware, there is currently no API that lets us efficiently retrieve the list of red links in the current version of a given article. https://en.wikipedia.org/w/api.php?action=help&modules=query%2Blinks provides a full list of links, but [does not mark red links specially](https://en.wikipedia.org/w/api.php?action=query&prop=links&titles=User:GWicke/LinkTest). Nor does it support only retrieving red links.

This end point already supports restricting links to a specific namespace using the `plnamespace` parameter. Along the same lines, we could add a `plbrokenlinks` flag parameter, which would restrict the returned list of titles to broken / red links only. @Anomie, does this sound sane to you?

(#services or #parsing-team)
Based on the performance information we have from elematch, I think it is clear that updating red link information server-side is doable at very moderate cost. Here is a proposal:

### Implement red link updates in change propagation

The recently deployed change propagation service will follow page creation / deletion events, and will initiate red link updates for all pages linking to the created / deleted pages. (#services)

### Parsoid to mark red links with an attribute by default

Regular parse: Parsoid will request a list of red links from the API, and annotate <a> elements with appropriate attributes in a DOM pass. 

Update: When getting a 'red link update' request from the change propagation service, RESTBase will pass the current HTML and **the update mode ("redlinks")** to Parsoid, the same way it already does right now for template or image updates. Parsoid will then update red links using any technique of its choosing. For example, it could do this using elematch, avoiding the need for expensive DOM parsing. (#parsing)

### Issue: API for red links

As far as I am aware, there is currently no API that lets us efficiently retrieve the list of red links in the current version of a given article. https://en.wikipedia.org/w/api.php?action=help&modules=query%2Blinks provides a full list of links, but [does not mark red links specially](https://en.wikipedia.org/w/api.php?action=query&prop=links&titles=User:GWicke/LinkTest). Nor does it support only retrieving red links.

This end point already supports restricting links to a specific namespace using the `plnamespace` parameter. Along the same lines, we could add a `plbrokenlinks` flag parameter, which would restrict the returned list of titles to broken / red links only. @Anomie, does this sound sane to you?

(#services or #parsing-team)
Based on the performance information we have from elematch, I think it is clear that updating red link information server-side is doable at very moderate cost. Here is a proposal:

### Implement red link updates in change propagation

The recently deployed change propagation service will follow page creation / deletion events, and will initiate red link updates for all pages linking to the created / deleted pages. (#services)

### Parsoid to mark red links with an attribute by default

Regular parse: Parsoid will request a list of red links from the API, and annotate <a> elements with appropriate attributes in a DOM pass. 

Update: When getting a 'red link update' request from the change propagation service, RESTBase will pass the current HTML and **the update mode ("redlinks")** to Parsoid, the same way it already does right now for template or image updates. Parsoid will then update red links using any technique of its choosing. For example, it could do this using elematch, avoiding the need for expensive DOM parsing. (#services)

### Issue: API for red links

As far as I am aware, there is currently no API that lets us efficiently retrieve the list of red links in the current version of a given article. https://en.wikipedia.org/w/api.php?action=help&modules=query%2Blinks provides a full list of links, but [does not mark red links specially](https://en.wikipedia.org/w/api.php?action=query&prop=links&titles=User:GWicke/LinkTest). Nor does it support only retrieving red links.

This end point already supports restricting links to a specific namespace using the `plnamespace` parameter. Along the same lines, we could add a `plbrokenlinks` flag parameter, which would restrict the returned list of titles to broken / red links only. @Anomie, does this sound sane to you?

(#services or #parsing-team)
A patch for element & attribute matching is now up at https://github.com/wikimedia/elematch/pull/5. Performance results for Obama (1.5mb):

- match / replace all figures: 1.95ms
- match / replace all links: 13.9ms
- **match / replace a *specific* link (`a[href="./Riverdale,_Chicago"]`): 1.9ms**
- match / replace references section (`ol[typeof="mw:Extension/references"]`): 3.7ms

Other options:
- libxml XML DOM round-trip (no matching): 51.1ms
  - plus xpath match: ~15ms
- domino round-trip (no matching): 255.3ms

This means that we can dynamically update red links in large documents using less than ~2ms of cpu time. This is over a magnitude less than libxml in XML mode, the next best option.
A patch for element & attribute matching is now up at https://github.com/wikimedia/elematch/pull/5. Performance results for Obama (1.5mb):

- match / replace all figures: 1.95ms
- match / replace all links: 13.9ms
- **match / replace a *specific* link: 1.9ms**
- match / replace references section (`ol[typeof="mw:Extension/references"]`): 3.7ms

Other options:
- libxml XML DOM round-trip (no matching): 51.1ms
  - plus xpath match: ~15ms
- domino round-trip (no matching): 255.3ms

This means that we can dynamically update red links in large documents using less than ~2ms of cpu time. This is over a magnitude less than libxml in XML mode, the next best option.
To provide a rough idea of the cost of server-side link processing, matching / processing all 1852 links in [[Barack Obama] using https://github.com/wikimedia/elematch takes about 32ms of CPU time. LibXML offers similar performance for a full DOM parse + XPath match, but incurs some extra cost for DOM serialization.

The cost is directly proportional to the number of elements matched. For comparison, matching only <figure> elements in Obama takes only 2ms.

Edit: Updated benchmark results at https://github.com/wikimedia/elematch#performance

Edit 2: Assuming XML spec compatible serialization, it turns out that we should actually be able to implement relatively efficient matches on attribute values as well. There are several gotchas around optional entity encoding, but they look solvable so far. I'll try to explore this approach in [elematch](https://github.com/gwicke/elematch).
To provide a rough idea of the cost of server-side link processing, matching / processing all 1852 links in [[Barack Obama] using https://github.com/wikimedia/elematch takes about 32ms of CPU time. LibXML offers similar performance for a full DOM parse + XPath match, but incurs some extra cost for DOM serialization.

The cost is directly proportional to the number of elements matched. For comparison, matching only <figure> elements in Obama takes only 2ms.

Edit: Updated benchmark results at https://github.com/wikimedia/elematch#performance
To provide a rough idea of the cost of server-side link processing, matching / processing all 1852 links in [[Barack Obama] using https://github.com/wikimedia/elematch takes about 32ms of CPU time. LibXML offers similar performance for a full DOM parse + XPath match, but incurs some extra cost for DOM serialization.

The cost is directly proportional to the number of elements matched. For comparison, matching only <figure> elements in Obama takes only 2ms.
To provide a rough idea of the cost of server-side link processing, matching / processing all 1852 links in [[Barack Obama] using https://github.com/wikimedia/elematch takes about 32ms of CPU time. LibXML offers similar performance for a full DOM parse + XPath match, but incurs some extra cost for DOM serialization.
To provide a rough idea of the cost of server-side link processing, matching / processing all 1852 links in [[Barack Obama] using https://github.com/wikimedia/elematch takes about 32ms of CPU time. LibXML offers similar performance for a pull DOM parse + XPath match, but incurs some extra cost for DOM serialization.
To provide a lower bound on server-side link processing, matching / processing all 1852 links in [[Barack Obama] using https://github.com/wikimedia/elematch takes about 32ms of cpu time. LibXML offers similar performance for a pull DOM parse + XPath match, but incurs some extra cost for DOM serialization.
cscott: the image blocklist is actually very very small, much fewer than 1000 images on there.
cscott: i'm not worried about caching the image as blocked in the archive.  it's the same as any other template dependency; the page "as it looks right now" depends on the current state of the image blocklist.
cscott: because it's small and a corner case, i don't think it should drive redlink discussions/decisions.

redlinks are orders of magnitude more common.  let's not try to make these two cases the same thing.
@ssastry, I have added option 3) as an extension in the task description.

One question we should make up our mind on is whether we would rewrite href attributes to point to edit views, to match what is currently done on the web. Doing so would complicate further processing:

- VisualEditor would need to strip ?action=edit from its link widget. The same will likely be true for other clients, like mining of link graphs.
- Matching could not rely on the plain href, but would need to either match on a mangled href, or use other attributes like a class instead.

If we decide to not mangle href, then web clients would need to do so after the fact, negating the advantage of not needing to run JS.

Another consideration is that link updates in old revisions are currently only efficiently possible using link information from the latest revision. This means that links that were only present in the older revision won't be checked for existence in queries based on the latest revision's links.

In the context of the API-driven front-end effort, it seems likely that we'll serve metadata about a page separately. This metadata would contain red links, language links (from wikidata), categories, table of content hints and more. If we assume that we'll need this anyway for other bits of metadata, then the extra cost of a general page metadata request is becoming less of an issue in this discussion.

So, overall I'm still torn, but am starting to lean more towards 1) than 2) / 3).
@ssastry, I have added option 3) as an extension in the task description.

One question we should make up our mind on is whether we would rewrite href attributes to point to edit views, to match what is currently done on the web. Doing so would complicate further processing:

- VisualEditor would need to strip ?action=edit from its link widget. The same will likely be true for other clients, like mining of link graphs.
- Matching could not rely on the plain href, but would need to either match on a mangled href, or use other attributes like a class instead.

If we decide to not mangle href, then web clients would need to do so after the fact.

Another consideration is that link updates in old revisions are currently only efficiently possible using link information from the latest revision. This means that links that were only present in the older revision won't be checked for existence in queries based on the latest revision's links.

In the context of the API-driven front-end effort, it seems likely that we'll serve metadata about a page separately. This metadata would contain red links, language links (from wikidata), categories, table of content hints and more. If we assume that we'll need this anyway for other bits of metadata, then the extra cost of a general page metadata request is becoming less of an issue in this discussion.

So, overall I'm still torn, but am starting to lean more towards 1) than 2) / 3).
Soln 3: Provide a Parsoid API endpoint that transforms stored HTML with red link info added in. But, this will require some caching / temporary storage  (and associated invalidation) to alleviate performance impact of a secondary api request.
Soln 2 will cause old revisions to render broken.
Soln 1 is the ideal solution.

That said, this question will surface again for "bad images". For "bad images", we do not have the luxury of breaking old revisions. Bad images are probably expected to be blacklisted in all revisions. Plus, client-side solution for that will probably not be acceptable for the no-js case since those images will render in full glory.

It seems like we should pick a solution that works in both scenarios => solution 3?
Soln 3: Provide a Parsoid API endpoint that transforms stored HTML with red link info added in. But, this will require some caching / temporary storage  (and associated invalidation) to alleviate performance impact of a secondary api request.
Soln 2. => old revisions will render broken.
Soln 1 is the ideal solution.

That said, this question will surface again for "bad images". For "bad images", we do not have the luxury of breaking old revisions. Bad images are probably expected to be blacklisted in all revisions. Plus, client-side solution for that will probably not be acceptable for the no-js case since those images will render in full glory.

It seems like we should pick a solution that works in both scenarios => solution 3?
Soln 3: Provide a Parsoid API endpoint that transforms stored HTML with red link info added in. But, this will require some caching / temporary storage  (and associated invalidation) to alleviate performance impact of a secondary api request.
Soln 2. => old revisions will render broken.
Soln 1 is the ideal solution.

That said, this question will surface again for "bad images". For "bad images", we do not have the luxury of breaking old revisions. Bad images are probably expected to be blacklisted in all revisions. Plus, client-side solution for that will probably not be acceptable for the no-js case since those images will render in full glory.

It seems like we should pick a solution that works in both scenarios.
We discussed this again in today's Reading / Services sync-up meeting. We really need to figure out a general solution for this to avoid each client needing to implement their own.

In the discussion, the consensus was that external metadata might also be workable, but inline information would be easier to work with. I have updated the task description with some use cases, requirements & pros / cons of each approach. Please update / add your view, so that we can decide on the way forward soon.
I wouldn't hold that patch up as an example, though, at least in its current form; we had to un-deploy it because of memory issues.
https://gerrit.wikimedia.org/r/#/c/274638/ has a patch implementing red link hiding in the mobile app content service.
>>! In T39902#1694428, @GWicke wrote:
>>>! In T39902#413952, @Jdforrester-WMF wrote:
>> Roan's going to try to work on this, at least as a first run.
> 
> Famous last words ;)

This was complete two weeks later – {T39901}.

> I am wondering if we could implement this at the edge / client after all, as part of a setup like T111588. Idea would be:
> 
> 1) API providing an array of links in the page that don't exist, and
> 2) JS skin code running in a service worker or in nodejs on the edge generating CSS to style red links, or JS code running on the DOM to add classes.

{T64803} is the task to turn the current client-side VE code into a service that provides an additional stylesheet per your recommendation – something like:

  restbase/styleContent/page/Foobar/revision/123456

… which returns a stylesheet like

  a[href=LinkDoesNotExist],
  a[href=AnotherLinkDoesNotExist]
  { color: red; }

… or whatever.
I would prefer to add a class to the DOM. The app can provide the CSS rules to style it or do something else with it (like replace the link with a span).

This task is very old already. Any chance of getting this in soon?
>>! In T39902#413952, @Jdforrester-WMF wrote:
> Roan's going to try to work on this, at least as a first run.

Famous last words ;)

I am wondering if we could implement this at the edge / client after all, as part of a setup like T111588. Idea would be:

1) API providing an array of links in the page that don't exist, and
2) JS skin code running in a service worker or in nodejs on the edge generating CSS to style red links, or JS code running on the DOM to add classes.
Roan's going to try to work on this, at least as a first run.
(In reply to comment #14)
> (In reply to comment #13)
> > As a note, if we did this cross-cluster, that would fix bug 11 (!) which
> > would be a lovely additional feature.
> 
> Sounds doable with separate API requests to each target wiki. Or even HEAD
> requests for external links, so that even non-wiki external links could be
> redlinked ;)

That would just be showing off. :-)
(In reply to comment #13)
> As a note, if we did this cross-cluster, that would fix bug 11 (!) which
> would
> be a lovely additional feature.

Sounds doable with separate API requests to each target wiki. Or even HEAD requests for external links, so that even non-wiki external links could be redlinked ;)
As a note, if we did this cross-cluster, that would fix bug 11 (!) which would be a lovely additional feature.
For stub thresholds, the API could also return an array of linked articles and their respective size. I think it would be fine to put the burden of an additional request onto those few users using stub indicators (they are disable d by default). The actual rendering can be done client-side based on that user's stub thresholds, which can sadly be arbitrary byte sizes.
(In reply to comment #10)
> Presumably an optional parameter to that core API is "stub length
> preference".

That could work, but feels a little messy. Gabriel as guardian of all that is appropriate coding might well have some thoughts. :-)
Presumably an optional parameter to that core API is "stub length preference".
(In reply to comment #8)
> One option might be to merge in information from another API into the <head>
> of the document which parsoid returns, to minimize round trips -- but in that
> case the API should first be added to core.  The simplest possible API would
> supply the name of an article and get back an array of stubbed or red links
> in that article.

Only problem is that this doesn't solve the "colouring stubs differently at a user-set arbitrary byte length" preference; I'd be reasonably OK with us removing that feature anyway, but that should be an actual decision discussed with people rather than just over-looked. :-)
One option might be to merge in information from another API into the <head> of the document which parsoid returns, to minimize round trips -- but in that case the API should first be added to core.  The simplest possible API would supply the name of an article and get back an array of stubbed or red links in that article.
Changing component to general- this would either happen in MediaWiki PHP/DOM post-processing or the client side.
Verified, working fine on the English and Italian Wikipedias.
(In reply to pamdavies7 from comment #25)
> It doesn't seem to be resolved. I found
> https://en.wikipedia.org/wiki/Demented_Are_Go#Studio_albums by hitting
> "Random article" until I found a redlink, tried to edit it in VE, and the
> red link ("Welcome back to Insanity Hall ") looked blue. Am I missing
> something?
> 
> In case it was any of my settings, I tried again using my (declared)
> alternative account which has default settings for everything: went to
> preferences to enable VE, tried editing that article, still a blue link.

The code is not yet deployed to the English Wikipedia. It will be deployed today to MediaWiki.org (hence the date in the "milestone"), and to the English Wikipedia in a week, following the regular schedule.
It doesn't seem to be resolved. I found https://en.wikipedia.org/wiki/Demented_Are_Go#Studio_albums by hitting "Random article" until I found a redlink, tried to edit it in VE, and the red link ("Welcome back to Insanity Hall ") looked blue. Am I missing something?

In case it was any of my settings, I tried again using my (declared) alternative account which has default settings for everything: went to preferences to enable VE, tried editing that article, still a blue link.
Change 118045 merged by jenkins-bot:
Display links to nonexistent pages as red

https://gerrit.wikimedia.org/r/118045
Change 118045 had a related patch set uploaded by Jforrester:
[WIP] Red link support

https://gerrit.wikimedia.org/r/118045
Change 118045 had a related patch set uploaded by Jforrester:
[WIP] Red link support

https://gerrit.wikimedia.org/r/118045
Revert. Lots of "basic" features are enhancements. Bugs are "this should already be working and its lack of presence is a code failure". Noting however that this is high priority.
Changing importance to "Normal". Even though it's not a regression compared to the source editor, common sense says that it should be a basic feature of VE and not an "Enhancement".
*** Bug 56442 has been marked as a duplicate of this bug. ***
**jonathan.haas** wrote:

(In reply to comment #16)
> * Internal links
> ** If the page does not exist, colour it red
> ** If the page does exist but is a disambiguation page, colour it yellow
> ** If the page does exist but is under (arbitrary) stub threshold, colour it
> purple
> ** Elsewise, colour it dark blue

Don't forget about redirection pages. In some Wikipedia's it is probably bad practice to link them. In german Wikipedia, it's okay to link them, but only if the link target makes more sense than the main page title. So in any case it's nice to see that the link target is a redirect. A bonus would be a tooltip which shows the page the redirect redirects to.

(In reply to comment #6)
> This can be implemented with a generated CSS file containing attribute
> selectors matching red link targets like this:
> 
> a[href="./Foo"],
> a[href="./Bar"] { color: red }

This is a really horrible idea. About 5% of the population are color blind, you really don't want to hardcode colors like this in any way. If embedding this information in the page source is technically impossible for whatever reason, then load a list of external pages using JS and add css classes or other attributes on the fly.
(In reply to comment #16)

> * Internal links
> ** If the page does not exist, colour it red
> ** If the page does exist but is a disambiguation page, colour it yellow
> ** If the page does exist but is under (arbitrary) stub threshold, colour it
> purple
> ** Elsewise, colour it dark blue

If the link is a redirect, will the system pick up the properties of the target page or just code it as a stub because it's short? (Target could be a dab page, stub, or normal page).
(In reply to comment #14)
> This is an 80/20 issue - 80% of the value comes from fixing just the coloring
> of internal wikilinks. Coloring of external links isn't critical. (There can
> be
> significant time-delay in getting 404 or similar error codes for page
> non-existence, as well as false negatives when a website is temporarily
> down.)
> And of the internal wikilinks, most of the value is redlinks, some of the
> value
> is disambiguation pages, and little of the value is stubs (which, again, are
> subject to false positives, since article assessments aren't automated).
> 
> In short, the priority ought to be to code internal wikilinks that go to
> non-existent pages (as red), and internal wikilinks that go to disambiguation
> pages (as yellow, I think), and not to worry all that much about anything
> else.

The solution we're considering is a service that, given an array of links, returns a set of CSS selectors that VE applies to the page, to give the appropriate hinting on links.

To be very specific, we are talking about:

* Internal links
** If the page does not exist, colour it red
** If the page does exist but is a disambiguation page, colour it yellow
** If the page does exist but is under (arbitrary) stub threshold, colour it purple
** Elsewise, colour it dark blue

* External links
** If the link is to a wiki that is "internal" (i.e., an interwiki), colour it mid-blue
** Elsewise, colour it mid-blue with an "external link" icon.

It is a mistake to think that doing this but only for internal link state and only for existence/non-existence is 20% of the work for 80% of the gain; it's much more like 90% of the work for 80% of the gain. :-) Building the service itself is definitely the hard part of this.
(In reply to comment #14)
> This is an 80/20 issue - 80% of the value comes from fixing just the coloring
> of internal wikilinks. Coloring of external links isn't critical.


I don't think anyone suggested (or has ever implemented?) coloring of external links. They only change color based on your browser settings, for clicked/unclicked links (essentially).


> And of the internal wikilinks, most of the value is redlinks, some of the
> value
> is disambiguation pages, and little of the value is stubs (which, again, are
> subject to false positives, since article assessments aren't automated).


Stubs are colored based on byte-count, not whether they're tagged-as-a-stub. You can change the byte-count in your [[special:preferences]], under "Appearance->Threshold for stub link formatting (bytes):[dropdownmenu]"


> In short, the priority ought to be to code internal wikilinks that go to
> non-existent pages (as red), and internal wikilinks that go to disambiguation
> pages (as yellow, I think), and not to worry all that much about anything
> else.


Agreed that only redlinks are crucial. 

For disambig links, possibly the new Property system can help?
https://en.wikipedia.org/wiki/Special:PagesWithProp?propname=disambiguation&propname-other=

For anything more complex than that, Anomie's Linkclassifier code might be useful/insightful. 300+ users have it installed. I recommend the "run on demand" version. https://en.wikipedia.org/wiki/User:Anomie/linkclassifier
code at https://en.wikipedia.org/wiki/User:Anomie/linkclassifier.js
This is an 80/20 issue - 80% of the value comes from fixing just the coloring of internal wikilinks. Coloring of external links isn't critical. (There can be significant time-delay in getting 404 or similar error codes for page non-existence, as well as false negatives when a website is temporarily down.) And of the internal wikilinks, most of the value is redlinks, some of the value is disambiguation pages, and little of the value is stubs (which, again, are subject to false positives, since article assessments aren't automated).

In short, the priority ought to be to code internal wikilinks that go to non-existent pages (as red), and internal wikilinks that go to disambiguation pages (as yellow, I think), and not to worry all that much about anything else.
Right now the linking problems detected only after saving the page. So please raise the importance of this bug and fix it on priority.
(In reply to comment #10)
> There has just been another editor on en.wp requesting this functionality. 
> 
> (In reply to comment #9)
> > Would it be possible also to make other kinds of pages to appear in different
> > colours, by changing CSS pages on the local wikis? I know that some wikis
> > have
> > different colours for redirects (green), others make links to disambiguation
> > pages appear highlighted in yellow.
> 
> That is bug 52173. Although there was some discussion about whether that was
> a duplicate of this the consensus seemed to be that it wasn't.

That bug was asking for the same problem to be fixed, but was suggesting a different technical solution (and one which is a WONTFIX from the Parsoid team, as it makes the cached pages get invalidated by other pages getting created/deleted/expanded out of the stub threshold/made into/out of a redirect/made into/out of a disambiguation page). Sorry for the confusion.
*** Bug 52173 has been marked as a duplicate of this bug. ***
There has just been another editor on en.wp requesting this functionality. 

(In reply to comment #9)
> Would it be possible also to make other kinds of pages to appear in different
> colours, by changing CSS pages on the local wikis? I know that some wikis
> have
> different colours for redirects (green), others make links to disambiguation
> pages appear highlighted in yellow.

That is bug 52173. Although there was some discussion about whether that was a duplicate of this the consensus seemed to be that it wasn't.
Would it be possible also to make other kinds of pages to appear in different colours, by changing CSS pages on the local wikis? I know that some wikis have different colours for redirects (green), others make links to disambiguation pages appear highlighted in yellow.
We don't want to encode this information in the DOM to avoid cache updates for the page content. There is really no need to do so since CSS selectors work well these days, and purging / regenerating CSS is much cheaper than updating page content.
Normally, in article view mode, redlinks have CSS class "new" and I'm suggesting doing it in the same way for the sake of consistency.
This can be implemented with a generated CSS file containing attribute selectors matching red link targets like this:

a[href="./Foo"],
a[href="./Bar"] { color: red }

Alternatively a JSON file containing the redlink targets could be fetched and a redlink class set on each of them. CSS seems to be the more elegant solution without a need for JS and DOM changes though.

In the longer term this is something we should implement for core too.
*** Bug 50974 has been marked as a duplicate of this bug. ***
*** Bug 50020 has been marked as a duplicate of this bug. ***
*** Bug 49475 has been marked as a duplicate of this bug. ***
It is actually shown as blue links which are considered to be existing pages. This is confusing.  I understand the parsoid isn't doing existence checks at all, so better use a natural color for all links.
Sorry, not "fixed" but duplicate of bug 33105.

*** This bug has been marked as a duplicate of bug 33105 ***
Just copy content from a page (e.g. https://it.wikipedia.org/wiki/Fire?veaction=edit) and paste in another one (e.g. https://it.wikipedia.org/wiki/Phantom?veaction=edit) :-) all the links, italics, lists etc. are lost.
Francisco: Exact steps to reproduce highly welcome, so developers can take a look.
I have to confirm that this bug still occurs on it.wiki.
(In reply to comment #6)
> Bug 33105 is *not* general c'n'p, it's only c'n'p from external sources.

You're right, sorry, I didn't update the title. Fixed. (Also, another VE instance is definitely an external source.)
Bug 33105 is *not* general c'n'p, it's only c'n'p from external sources.
This was replaced with bug 33105 (general copy-and-paste)

*** This bug has been marked as a duplicate of bug 33105 ***
This bug seems to be occurring again.  Same issue- format loss.

Ref:
https://en.wikipedia.org/w/index.php?title=Wikipedia%3AVisualEditor%2FFeedback&diff=561998028&oldid=561996397
`vagrant up` worked fine when I deleted //everything// and started with an empty repository.
Write a Parsoid backend for VirtualRestService, and replace VisualEditor's and Flow's hacks with that. Incorporate the cookie forwarding hacks from VE as well.

See https://www.mediawiki.org/wiki/Requests_for_comment/PHP_Virtual_REST_Service and https://github.com/wikimedia/mediawiki/tree/master/includes/libs/virtualrest

This would also be a good opportunity to clean up the way the Parsoid URL (and whether it's available) is configured in mediawiki-config

See also: T74988
Change 181011 merged by jenkins-bot:
Use ParsoidVirtualRESTService

[[https://gerrit.wikimedia.org/r/181011]]
Change 181706 merged by jenkins-bot:
Make a VirtualRESTService class for Parsoid

[[https://gerrit.wikimedia.org/r/181706]]
Change 181706 had a related patch set uploaded (by Alex Monk):
Make a VirtualRESTService class for Parsoid

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

#patch-for-review
@krenair: Ahh, great news! @aaron: Thank you!
>>! In T1218#935534, @Krenair wrote:
> I ran into issues with the way I was trying to use VirtualRESTService. My onResponses function was not getting called. Aaron said "seems like there should be a $execReqsByService for the second loop to over so onReponse is called for non-replaced requests too" (referring to code in VirtualRESTServiceClient::runMulti)

We fixed the issue I was running into in https://gerrit.wikimedia.org/r/181121, @Aaron made https://gerrit.wikimedia.org/r/181119 to fix the issue we found last night.
Change 181011 had a related patch set uploaded (by Alex Monk):
Make a VirtualRESTService class for Parsoid, and use it

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

#patch-for-review
I ran into issues with the way I was trying to use VirtualRESTService. My onResponses function was not getting called. Aaron said "seems like there should be a $execReqsByService for the second loop to over so onReponse is called for non-replaced requests too" (referring to code in VirtualRESTServiceClient::runMulti)
It might be nice to model the internal interface somewhat similar to the way the RESTBase interface will look like:

- `GET /v1/local/page/Foo/html/123456` -- HTML for page Foo at revision 123456
- `GET /v1/local/page/Foo/data-mw/123456` -- data-mw for same
- `POST /v1/local/convert/html/to/wikitext` -- convert html to wikitext, body tbd

The `local` bit here could be shorthand for the local domain / wiki. Page titles are percent-encoded, so slashes are no problem.

The cookie authentication business should be doable in the virtualrest backend handler for the parsoid end point, so that users don't need to deal with it. The backend is also the only place that needs to deal with actual host names etc from the config.
It might be nice to model the internal interface somewhat similar to the way the RESTBase interface will look like:

- `GET /v1/local/page/Foo/html/123456` -- HTML for page Foo at revision 123456
- `GET /v1/local/page/Foo/data-mw/123456` -- data-mw for same
- `POST /v1/local/convert/html/to/wikitext` -- convert html to wikitext, body tbd

The `local` bit here could be shorthand for the local domain / wiki. Page titles are percent-encoded, so slashes are no problem.

The cookie authentication business should be doable in the parsoid backend handler, so that users don't need to deal with it. The backend is also the only place that needs to deal with actual host names etc from the config.
It might be nice to model the internal interface somewhat similar to the way the RESTBase interface will look like:

- `GET /v1/local/page/Foo/html/123456` -- HTML for page Foo at revision 123456
- `GET /v1/local/page/Foo/data-mw/123456` -- data-mw for same
- `POST /v1/local/convert/html/to/wikitext` -- convert html to wikitext, body tbd

The `local` bit here could be shorthand for the local domain / wiki. Page titles are percent-encoded, so slashes are no problem.
Currently the MediaWiki markup allows the inclusion of html elements with style attributes. Mixing layout with content causes various problems with reusability, maintainability and is not future proof. Already on the mobile version of MediaWiki problems are being seen with inline styles with how pages render on smaller screens which could be solved via css3 media queries, however these cannot be done in inline styles.

It should be possible for templates to have associated stylesheets so that media queries can be applied where necessary. This is related to T37704.

This RFC was proposed in 2013, discussed at two separate RFC meetings in 2014, and the status is unclear as of 2016-03-29.  More detailed status in the comments of this task

Full writeup:
[[ https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates | Allow styling in templates RfC ]].
>>! In T483#2316983, @MZMcBride wrote:
> I'm hoping to find some time to play around with TemplateStyles this week. I'm curious whether features such as `url()` will be totally banned or only banned for non-Wikimedia domains. If we're going to disallow certain kinds of CSS (i.e., if we're only going to allow a subset of CSS), we'll want to make sure that the documentation and user interface both make this clear early and often to prevent headaches and frustration.

I presume that anything banned inline is banned in TemplateStyles as well, as they are both 'public access' so to speak. What would be cool is to have some directive to import stylesheets from MediaWiki: space, where CSS is unrestricted.
Hi @coren. We're looking at goal options for [[ https://www.mediawiki.org/wiki/Reading/Quarterly_planning/FY2016-2017/Q1#Reading_Infrastructure | Reading Infrastructure in Q1 FY 2016-2017]].

The question arose: is the following something that's still relevant and that you were thinking to pursue?

> Safety/security notes:
> * need to parse/validate CSS rules for safety anyway -- avoid external refs, scary things
>  * probably have to do a 'real' CSS parse rather than blacklisting a few keywords like we do on inline styles
>  * doing this reliably may be the hardest part!

@coren, if it's not on your list (yet still in scope), we were thinking this might be something Reading Infrastructure could work on starting July 2016. If it's already on your list, we would consider a different Reading Infrastructure goal for Q1 FY 2016-2017.

CC @JKatzWMF, @tgr, @anomie
>>! In T483#2294327, @matmarex wrote:
> We do care about IE 8, and even IE 6, as allowing users to view the site with correct styling is a basic core feature of MediaWiki, and therefore we should strive to support grade C browsers here. See https://www.mediawiki.org/wiki/Compatibility#Basic for details.

I'm not sure about this requirement. Right now we are just talking about template styles. Would it be a travesty if these styles didn't apply but an IE6 browser could still use the content? If we were talking about disabling skin styles I would understand but an unstyled infobox is not the end of the world.
> We do care about IE 8, and even IE 6

The read-only JS fix for IE8 would work in earlier IE versions as well.
@matmarex, do you expect a drastic increase in the size of the CSS associated with templates? If anything, being able to migrate some inline styles to rules should reduce CSS size somewhat, and compression would pick up repetitions & avoid a significant impact on download sizes. 

Less styles in the <head> can also unblock rendering of above-fold content more quickly, which matters especially on mobile (see T124966).

In any case, I would expect very frequently used transclusions like cite to still be predominantly styled globally. Changing some linked / global CSS is a lot cheaper than re-rendering all of Wikipedia to update a detail in citation styling.
@matmarex, do you expect a drastic increase in the size of the CSS associated with templates? If anything, being able to migrate some inline styles to rules should reduce CSS size somewhat, and compression would pick up repetitions & avoid a significant impact on download sizes. 

Less styles in the <head> can also unblock rendering of above-fold content more quickly, which matters especially on mobile (see T124966).

In any case, I would expect very frequently used transclusions like cite to still be predominantly styled globally. Changing some linked CSS is a lot cheaper than re-rendering all of Wikipedia to update a detail in citation styling.
@matmarex, do you expect a drastic increase in the size of the CSS associated with templates? If anything, being able to migrate some inline styles to rules should reduce HTML size somewhat, and compression would pick up repetitions & avoid a significant impact on download sizes. 

Less styles in the <head> can also unblock rendering of above-fold content more quickly, which matters especially on mobile (see T124966).

In any case, I would expect very frequently used transclusions like cite to still be predominantly styled globally. Changing some linked CSS is a lot cheaper than re-rendering all of Wikipedia to update a detail in citation styling.
@matmarex, do you expect a drastic increase in the size of the CSS associated with templates? If anything, being able to migrate some inline styles to rules should reduce HTML size somewhat, and compression would pick up repetitions & avoid a significant impact on download sizes. 

Less styles in the <head> can also unblock rendering of above-fold content more quickly, which matters especially on mobile (see T124966).

In any case, I would expect very frequently used transclusions like cite to still be predominantly styled globally. Changing some linked CSS is a lot cheaper than re-rendering all of Wikipedia to update a detail in citation styles.
@gwicke Are you suggesting that we duplicate the template stylesheet for every template invocation? That's crazy, and it would be literally the opposite of what this feature is being developed for.
We do care about IE 8, and even IE 6, as allowing users to view the site with correct styling is a basic core feature of MediaWiki, and therefore we should strive to support grade C browsers here. See https://www.mediawiki.org/wiki/Compatibility#Basic for details.
> Just as side-note: Why would you base64 text? That might result in more data over the wire –after gzipping– like with SVGs laid out here.

Good point! The following seems to work just as well:

```lang=html
<div id="mw12345">
  <link rel="stylesheet"
    href="data:text/css,#mw12345 { color: red }">
  This text is styled red.
</div>
```

The main limitation with data URLs is [limited support in IE8](http://caniuse.com/#search=data). Only IE9+ supports stylesheets in data URLs. If we care about IE8, then we could create some JS for a read-only fix-up. VisualEditor does not support IE8, so there is no need to support the more complex editing scenarios.
>>! In T483#2293454, @GWicke wrote:
>             href="data:text/css;base64,I213MTIzNDUgeyBjb2xvcjogcmVkIH0=">
Just as side-note: Why would you base64 text? That might result in more data over the wire –after gzipping– like with [[ https://css-tricks.com/probably-dont-base64-svg/ | SVGs laid out here ]].
>>! In T483#2289858, @TheDJ wrote:
> I was thinking a bit about variance, maintainability etc. And in the mobile-friendly content meeting we were also discussing: How do we document this so that editors know what they should do ?
> 
> Lets say we have a block like:
> ```lang=css
> @media print and (min-width: 480px)
> ```
> 
> How do we make sure that not every single template has a different cutoff width and thus triggers a reflow? In every single language ?
> 
> This made me realize: We need to make this a less sheet and MediaWiki/Wikimedia should have a centralized less sheet with predefined variables, functions/mixins etc. We could properly document those variables and functions and use them in our examples. We could put complicated CSS magic in descriptively named functions/variables, so that people don't have to understand all the CSS details, they can just be "in this situation i need to use this function".
> 
> This would make templatestyles a lot more maintainable and consistent, still give lot's of flexibility to editors and also allow us to make changes from the MediaWiki/Wikimedia side.

:thumbsup: This seems very reasonable to me. From user experience _and_ developer perspective it makes sense to choose the media query breakpoints wisely and provide them in a central stylesheet. Less and future CSS offers this capability!
> It's not immediately clear to me what the fundamental difference is between that and the current scheme (a <style> tag in the header)?

The <style> tag in the header requires a page-global aggregation pass to collect styles, which would need to be implemented in the PHP parser, Parsoid, VisualEditor, and any other application composing wiki content (such as apps).

The inline stylesheet on the other hand keeps each template expansion self-contained, and avoids the complexity of global passes. It is both easier to implement, and easier to consume.
> It's not immediately clear to me what the fundamental difference is between that and the current scheme (a <style> tag in the header)?

The <style> tag in the header requires a page-global aggregation pass to collect styles, which would need to be implemented in the PHP parser, Parsoid, VisualEditor, and any other application composing wiki content (such as apps).

The inline stylesheet on the other hand keeps each template expansion self-contained, and avoids the complexity of global passes.
> It's not immediately clear to me what the fundamental difference is between that and the current scheme (a <style> tag in the header)?

The <style> tag in the header requires a page-global aggregation pass to collect styles, which would need to be implemented in the PHP parser, Parsoid, VisualEditor, and any other application composing wiki content (such as apps).

The inline stylesheet on the other hand keeps each template self-contained, and avoids the complexity of global passes.
>>! In T483#2293454, @GWicke wrote:
> All modern browsers support <link rel="stylesheet"> in the body

It's not immediately clear to me what the fundamental difference is between that and the current scheme (a <style> tag in the header)?
>>! In T483#2289895, @GWicke wrote:
> Adding the parsing team, as this would introduce page-global state, and also needs to work in Parsoid and VE.

I've been pondering on that issue for a bit; clearly there needs to be an API endpoint for parsoid to hit - but I'm not certain what data would be most useful to return; would the final "merged" stylesheet be apropriate?
Adding the parsing team, as this would introduce page-global state, and also needs to work in Parsoid and VE.
Adding the parsing team, as this would introduce page-global state, and also needs to be implemented in Parsoid and VE.
I was thinking a bit about variance, maintainability etc. And in the mobile-friendly content meeting we were also discussing: How do we document this so that editors know what they should do ?

Lets say we have a block like:
```lang=css
@media print and (min-width: 480px)
```

How do we make sure that not every single template has a different cutoff width and thus triggers a reflow? In every single language ?

This made me realize: We need to make this a less sheet and MediaWiki/Wikimedia should have a centralized less sheet with predefined variables, functions/mixins etc. We could properly document those variables and functions and use them in our examples. We could put complicated CSS magic in descriptively named functions/variables, so that people don't have to understand all the CSS details, they can just be "in this situation i need to use this function".

This would make templatestyles a lot more maintainable and consistent, still give lot's of flexibility to editors and also allow us to make changes from the MediaWiki/Wikimedia side.
I was thinking a bit about variance, maintainability etc. And in the mobile-friendly content meeting we were also discussing: How do we document this so that editors know what they should do ?

Lets say we have a block like:
```css
@media print and (min-width: 480px)
```

How do we make sure that not every single template has a different cutoff width and thus triggers a reflow? In every single language ?

This made me realize: We need to make this a less sheet and MediaWiki/Wikimedia should have a centralized less sheet with predefined variables, functions/mixins etc. We could properly document those variables and functions and use them in our examples. We could put complicated CSS magic in descriptively named functions/variables, so that people don't have to understand all the CSS details, they can just be "in this situation i need to use this function".

This would make templatestyles a lot more maintainable and consistent, still give lot's of flexibility to editors and also allow us to make changes from the MediaWiki/Wikimedia side.
I was thinking a bit about variance, maintainability etc. And in the mobile-friendly content meeting we were also discussing: How do we document this so that editors know what they should do ?

Lets say we have a block like:
```
@media print and (min-width: 480px)
```

How do we make sure that not every single template has a different cutoff width and thus triggers a reflow? In every single language ?

This made me realize: We need to make this a less sheet and MediaWiki/Wikimedia should have a centralized less sheet with predefined variables, functions/mixins etc. We could properly document those variables and functions and use them in our examples. We could put complicated CSS magic in descriptively named functions/variables, so that people don't have to understand all the CSS details, they can just be "in this situation i need to use this function".

This would make templatestyles a lot more maintainable and consistent, still give lot's of flexibility to editors and also allow us to make changes from the MediaWiki/Wikimedia side.
>>! In T483#2232623, @brion wrote:
> If volunteers are +2'ing config updates and deploying them, I'm impressed. :)

Regardless, it is probably worthwhile to ask what the communities around templates think before we figure it out - at least on the bigger projects.  Ima do this this week.
If volunteers are +2'ing config updates and deploying them, I'm impressed. :)
>>! In T483#2232450, @brion wrote:
> on communities to deal with the question, and on wmf releng to handle updating the setting.

I don't know if you've been watching #wikimedia-site-requests lately but the credit for handling that process really should go to the volunteers involved.
It seems like an unnecessary burden on users to figure out why it didn't work and ask their communities for permission to change, on communities to deal with the question, and on wmf releng to handle updating the setting.

What downside is there to just having it always on everywhere?
>>! In T483#2232314, @brion wrote:
> Note that people do like to use templates outside the template NS, for user or project pages for instance. Not sure if we want to support that explicitly/implicitly/not at all, etc. :)

It's supported via $wgTemplateStylesNamespaces; whether that is left to just Template: or not when that gets deployed to prod seems to me to be a decision best left to the individual communities.
Note that people do like to use templates outside the template NS, for user or project pages for instance. Not sure if we want to support that explicitly/implicitly/not at all, etc. :)
With the latest rounds of merges, the TemplateStyles extension appears to be in a reasonable state and implements the major substantive part of this RfC as discussed in Jerusalem.

An interesting side effect of the current implementation is that a `<templatestyles>` tag appearing on a page //not// appearing in the list of allowed namespaces will not - as designed - affect pages transcluding it but it **does** style //itself// regardless of namespace.

I'm not sure that shouldn't simply be documented as a feature.  :-)
Change 283772 merged by jenkins-bot:
Add unit tests for CSSParse and CSSRender

[[https://gerrit.wikimedia.org/r/283772]]
>>! In T483#2223326, @Edokter wrote:
> I think scoping to `#mw-content-text` should be enough. Any tempate appearing outside actual content is usually protected anyway.

I would tend to agree; let's not overcomplicate the first go at this and aim for an implementation that is simple to implement //and// describe: template styles allow styling of contents.

I think there's a good case to be made that styling UI elements is outside the scope of this extension; it's a marginal use at best and should probably be left to some other mechanism (especially since fiddling with the UI is very skin-specific and depends a great deal on the actual interface in use).
I think scoping to `#mw-content-text` should be enough. Any tempate appearing outside actual content is usually protected anyway.
Would it be safer to introduce this feature as only available on admin-protected templates?  Then we could relax that requirement gradually once the issues are better understood and have been prevented..?
>>! In T483#2218236, @Edokter wrote:
> Actually, plenty of templates can appear outside 'content' space, such as edit notices. Those should be able to be styled. The risk of clashing CSS classes is pretty low anyway.

In addition to the desirability of avoiding clashes, there is also the issue that part of the objective of placing styling in templates is to allow non-administrator the ability to edit styles - which means that we need to protect most UI elements from accidental (or malicious) alteration.

It might be worthwhile to consider alternatives by which UI elements can be styled in controlled contexts, but I think this is a good project for a future version.  :-)
>>! In T483#2215393, @Entlinkt wrote:
> It should probably be avoided that templates can leak styles into that area.

Actually, plenty of templates can appear outside 'content' space, such as edit notices. Those should be able to be styled. The risk of clashing CSS classes is pretty low anyway.
>>! In T483#2211010, @TheDJ wrote:
> We have `#mw-content-text` that contains all generated output for wikitext pages, but more importantly the classes `mw-content-ltr` and `mw-content-rtl`.

Please note that in diff views, `#mw-content-text` also contains the `table.diff` element with the actual diff, revert links etc. It should probably be avoided that templates can leak styles into that area.

I don't know of any selector that precisely catches user-generated content. Currently, `#mw-content-text` is just an approximation.
Change 283772 had a related patch set uploaded (by coren):
Add unit tests for CSSParse and CSSRender

[[https://gerrit.wikimedia.org/r/283772]]
>>! In T483#2211010, @TheDJ wrote:
> Right, found a quite important point... We are now scoping using:
> `mw-body-content` it seems. But that is a skin specific class, amongst others not used by the mobile minerva skin.
> 
> We have `#mw-content-text` that contains all generated output for wikitext pages, but more importantly the classes `mw-content-ltr` and `mw-content-rtl`.

Aha.  Good catch.  Fixing.
Right, found a quite important point... We are now scoping using:
`mw-body-content` it seems. But that is a skin specific class, amongst others not used by the mobile minerva skin.

We have `#mw-content-text` that contains all generated output for wikitext pages, but more importantly the classes `mw-content-ltr` and `mw-content-rtl`.
>>! In T483#2210556, @Legoktm wrote:
>>>! In T483#2209954, @TheDJ wrote:
>> Tried [[ http://ts.wmflabs.org/w/index.php?title=Template%3AWide_image&type=revision&diff=124&oldid=121 | using wikimarkup inside the style block ]], but that doesn't seem to work (and scary if it would..)
> 
> What if you used `{{#tag:templatestyles}}` so the wikitext is processed? I'm not sure how the extension is storing the actual styles though.

It's stored as a serialized parse tree of the rules; the processing would happen exactly once on save, then parsed as CSS and stored in a fixed format.
>>! In T483#2209954, @TheDJ wrote:
> Tried [[ http://ts.wmflabs.org/w/index.php?title=Template%3AWide_image&type=revision&diff=124&oldid=121 | using wikimarkup inside the style block ]], but that doesn't seem to work (and scary if it would..)

What if you used `{{#tag:templatestyles}}` so the wikitext is processed? I'm not sure how the extension is storing the actual styles though.
>>! In T483#2209954, @TheDJ wrote:
> Tried [[ http://ts.wmflabs.org/w/index.php?title=Template%3AWide_image&type=revision&diff=124&oldid=121 | using wikimarkup inside the style block ]], but that doesn't seem to work (and scary if it would..)

That wouldn't have worked even if the tag was parsed: the stylesheet is parsed on save and stored as a page property for use by transcluding pages, so it cannot differ from one transclusion to another.
Some first practical experiences:
1: i quickly found a situation, where in lieu of inline styles, i'll have to use a unique (per parserrun) class or ID. we have no good options for this right now. For now, i'll keep using inline styles for those situations. (width specific to the image being transcluded)
2: the style block should probably be inserted AFTER the <meta name="ResourceLoaderDynamicStyles" content=""/>
3: These style blocks will have to be exposed in the api, so that something like LivePreview can update them.
4: The style block will need an identifying attribute, so that something like livepreview can replace it.
5: Every conditional styling option of a template will require it's own class (always included). For instance, even if I don't use the border option of  http://ts.wmflabs.org/w/index.php/Template:Wide_image, I will always have to include the .noborder styling class. This might be more bytes and more unused styling classes for uses of certain templates. Not really sure what to do about that... Tried [[ http://ts.wmflabs.org/w/index.php?title=Template%3AWide_image&type=revision&diff=124&oldid=121 | using wikimarkup inside the style block ]], but that doesn't seem to work (and scary if it would..)
Done.  I added ParserFunctions and Scribunto, and reimported Template:Wide image recursively to make sure it worked.
>>! In T483#2209633, @TheDJ wrote:
> Coren, can you add parserfunctions extension to your experimental wiki ?
> i'd like to test a few actual en.wiki templates, and almost all of those need parserfunctions and/or scribunto

Yeah, those and a couple others really - will do so shortly.
Coren, can you add parserfunctions extension to your experimental wiki ?
i'd like to test a few actual en.wiki templates, and almost all of those need parserfunctions and/or scribunto
>>! In T483#2207021, @coren wrote:
> The current WIP can be played with [[ http://ts.wmflabs.org/w/index.php/Main_Page | on an experimental wiki ]].  The main page is an example of a transclusion of a style template.

[[http://ts.wmflabs.org/w/index.php?title=Template:Boilerplate&action=edit|Direct link to the styled template]]
The current WIP can be played with [[ http://ts.wmflabs.org/w/index.php/Main_Page | on an experimental wiki ]].  The main page is an example of a transclusion of a style template.
Change 282155 merged by jenkins-bot:
TemplateStyles extension prototype

[[https://gerrit.wikimedia.org/r/282155]]
Change 282155 had a related patch set uploaded (by coren):
[WIP] TemplateStyles extension prototype

[[https://gerrit.wikimedia.org/r/282155]]
Current plan summary based on the etherpad notes (in case they get lost):
* use mechanism similar to TemplateData
 * extension tag to encapsulate a CSS chunk directly in the template's wikitext
 * note supporting media queries is super important for mobile & narrow-window views!
 * use save hook to validate & store the style data
* have parser pull up the style data of all used templates when rendering out a page
 * build them into a <style> tag (this keeps style & html versions consistent within parsercache, and is simpler than trying to load lots of deps via ResourceLoader)

That much should be pretty easy to prototype.

Encapsulation notes:
* one idea is to do the template styles only on properly balanced templates
 * encourage people to 'do the right thing' with templates ;)
* this allows wrapping the template in a (custom?) html element which can be added to the prefix of any CSS rules in the template
 * should prevent leakage of defined rules outside the template
 * which should also prevent conflicts in styles and class/id names between templates
 * but requires parsing the CSS well enough to be able to reliably prefix all selectors

Safety/security notes:
* need to parse/validate CSS rules for safety anyway -- avoid external refs, scary things
 * probably have to do a 'real' CSS parse rather than blacklisting a few keywords like we do on inline styles
 * doing this reliably may be the hardest part!

Editor helper tools:
 * jon is interested in a helper tool to look for suspicious inline styles and warn users on edit that their page or template is likely to render badly on mobile/narrow window
 * if we're parsing & storing metadata on the css styles, we can build a tool to look for common/duplicated styles and suggest moving truly common ones to MediaWiki:Common.css

Open questions:
* what about style libraries to be shared between templates? (maybe not a high prio; truly common styles can go in existing MediaWiki:Common.css)
After some architecture discussion with @Brion and @jdlrobson, we came up with a fairly good plan for which I'm going to do a first prototypical implementation.

The summary: styles are to be added inline to the template (with a mechanism comparable to that of templatedata and/or outright coopting that mechanism), combined at page rendering time, and placed inline with the page.  We avoid redundancy by eschewing true scoped styles, opting to make them global instead.

//Faux//-scoping is provided for balanced templates by making certain they are encapsulated and given a class that is then used as a selector for the template's declared classes; this would ideally rely on T114445 to avoid duplicating effort.
Notes from @Jdlrobson @coren & @brion at Wikimedia Hackathon 2016: https://etherpad.wikimedia.org/p/WikiHack16_TemplateStyles

@coren is interested in doing some prototyping work.
>>! In T483#1884696, @Jdlrobson wrote:
> Any update on this?

This was moved into the "Approved, but not resourced" column in T483#1073658 (@daniel, 2015-02-27).  The answer to "what happens next?" when an RFC reaches that state is admittedly unclear; #ArchCom doesn't have the ability to assign developers to things, and should be very stingy about volunteering their own time.  There are some old action items documented @brion and @tstarling from the RFC meeting on 2014-10-15, but that doesn't seem relevant today.

Given that the  [[ https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates | Allow styling in templates RfC ]] writeup on mw.org states that the author is "Jon Robson who no longer has time to move this forward" and the state marked there is "stalled", it's tempting to treat the RFC as abandoned, were it not for the frequent mentions this task gets, and @Jdlrobson adding this as a blocker to resolving @ori's bug report T130846.

Looking at the history on the  [[ https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates | Allow styling in templates RfC ]] page, it would seem that this needs a new driver who is probably not @brion.  For tasks in the #ArchCom-RFC, we have been provisionally using (misusing?) the assignment field as where we assign the shepherd.  I think it potentially makes sense for @brion to remain the shepherd, but someone else needs to be the driver for this.

Any volunteers to drive this?
Any update on this?
From https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-10-15-21.02.html

* ACTION: tim interested in helping with the css parsing, may port some tools from node if nothing good already in php (brion, 21:46:56)
* ACTION: accepted styling in templates, work & final details to be done by brion & tim (brion, 21:50:58)
Found logs that say APPROVED here: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-10-15-21.02.html
Also related: {T37704}.
Related: {T52644}.
> Brion interested in this
> will update the RfC w/ implementation plans and schedule it for next weekish

https://www.mediawiki.org/wiki/Architecture_committee/2014-10-08#RFCs_to_triage
On Day 1 we will need a process to request a new project, because plain users will not be able to create projects themselves.

In fact, we need such progress already now in this Labs instance. We can define the process as we document it, and fine tune it as we see fit, real request after real request.

I have started a draft at https://www.mediawiki.org/wiki/Phabricator/Help. @aklapper & co, feel free fine tuning it while satisfying the current requests for Labs.
//importing issue status//
**qgil** wrote on `2014-08-04 16:42:20 (UTC)`

I'm resolving this task because we have a process in place:

https://www.mediawiki.org/wiki/Phabricator/Help#Requesting_a_new_project

We will mature the process as we define T68, and with the experience acquired.
**aklapper** wrote on `2014-07-28 19:32:47 (UTC)`

Heja, let's please move the naming scheme discussion to T68 where we have more target audience (PMs). I will comment on concerns and thoughts brought up here in T68.
**Florian** wrote on `2014-07-28 12:02:33 (UTC)`

@Rush: So you would suggest to use always lowercase project namens? But the extension/project itself can still be named "as it is" with CamelCase and/or whitespaces?
**qgil** wrote on `2014-07-25 13:55:28 (UTC)`

@Rush, see {T495}. It's a project creation request with a strict CamelCase name. You said this is a problem. I asked why and provided my reasons to avoid project names with lower case only and dashes. What is the conclusion?
**qgil** wrote on `2014-07-17 11:38:14 (UTC)`

I had what I needed, I only couldn't see it.

Anyway, I have simplified the instructions to request a new project. It all boils down to create a task specifying the name and description of the project, and a reasoning for special access permissions if the defaults don't work for you. 

There is a note for teams expecting to create several projects. Those will need to start with a project for the team.

https://www.mediawiki.org/wiki/Phabricator/Help#Requesting_a_new_project

I will start testing this process with {T458}.
**Rush** wrote on `2014-07-16 19:01:19 (UTC)`

@qgil, I"m not sure what you are looking at?

your a phab admin (meant in both senses)
your in security group
phabricator-request-project is all users for all fields
http://fab.wmflabs.org/T458 is all users for all fields

what perm screen are you looking for?
**qgil** wrote on `2014-07-16 18:57:07 (UTC)`

@Rush I still can't access the admin options to check the possible permissions...
**Rush** wrote on `2014-07-16 15:26:16 (UTC)`

@qgil you are now security!
**qgil** wrote on `2014-07-16 12:05:52 (UTC)`

>>! In T457#7, @Rush wrote:
> * I'm not sure how we limit comment ability unless it's the broader view/edit permissions?

This might be because I had to recall the types of permission by heart. Can I get momentarily admin access to check those permissions, document accordingly, and then give back (again) the admin rights, please?
**MissGayle** wrote on `2014-07-15 17:42:18 (UTC)`

What're the naming conventions?

project name following the naming conventions (link)
- Talent & Culture Office
description including the purpose of the project -- you will be able to edit it after the project has been created
- Tracking HR projects and key deliverables in a transparent manner
access policies -- the defaults are public view and equal access for all registered users
- public 
who can view the project and tasks (list options, default Public)
- public 
who can join the project (list options, default ?)
- anyone in HR (Gayle, Anna Stillwell, Joady Lohr, Anna Lantz, Emanuela Neagu, Heather McAndrew, Emily Blanchard, Jenn Suzuki, Elena Hernandez) 
who can edit tasks (list options)
- anyone in HR (Gayle, Anna Stillwell, Joady Lohr, Anna Lantz, Emanuela Neagu, Heather McAndrew, Emily Blanchard, Jenn Suzuki, Elena Hernandez) 
who can add comments (list options)
- anyone
(are there more sensible options?)
Currently the process (except for security) https://www.mediawiki.org/wiki/Backporting_fixes implies usage of flags.
@MarkAHershberger, @Mglaser: Task 76168 got backported to 1.24. Not sure if you want the #MediaWiki-Tarball-Backports project to be added to that task. https://www.mediawiki.org/wiki/Backporting_fixes#Backports_to_stable.2Fsupported_release does not cover this "retroactively" - whatever works for you and isn't overhead.
>>! In T101#11104, @Aklapper wrote:
> Project names: "WMF-Server-Backports" and "MediaWiki-Tarball-Backports"
> 
> as usual confused whether the action to create and set up these two projects should now be separate tasks...

@greg, @MarkAHershberger, @mglaser: I have created #WMF-Server-Backports and #MediaWiki-Tarball-Backports and added you accordingly. Was unsure which [[ https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Type%20project | type/kind of project ]] these are so I sticked with the default (briefcase/blue) for the time being.
We do not migrate any flag data from Bugzilla so this does not block T259.

Project names: "WMF-Server-Backports" and "MediaWiki-Tarball-Backports"

Closing the "figure out a process" part as resolved, as usual confused whether the action to create and set up these two projects should now be separate tasks...
Are there any more details that must be decided here? We really need to close this task, or at least have it in a state where it is not blocking T259 anymore.

In other words, the period for input to the migration script needs to end. We can always file tasks based on the results of {T552}.
>>! In T101#9607, @Aklapper wrote:
> **Project naming:**
> 
> "WMF-Backports" and "MediaWiki-Backports" doesn't feel explanatory enough to me. Sounds too similar to other subprojects which have a defined codebase area. "WMF-Server-Backports" and "MediaWiki-Tarball-Backports" will work for me. Let's go for that?

I'll probably make a short version for WMF-Server-Backports (aka "WMF-Backport"), but sure :)   (just like I made "#releng" for "#Release-Engineering")


> **Bugzilla Backport Flags migration aspect only:**
> 
> Tickets with any of our two Bugzilla flags (Backport_WMF and Backport_to_Stable) set will not have the flag information migrated to Phabricator. I don't see any historical need to know whether something was backported at some undefined point in the past (and that information is available in comments anyway if somebody is curious).
> 
> Regarding currently open tickets with Backport requests that have not been decided on, there are less than 10 of them hence the effort is not worth it to write migration code covering that.
> I have cleaned up WMF backport requests yesterday and I've sent an email today to the Tarball Release Team to please take a look at the queue of undecided tarball backport requests. 
> Furthermore Bugzilla will be available as read-only for some time after the migration so we could still look up which Bugzilla tickets had this flag if we wanted.

Probably fine. We can get backport information from git but it'll obviously not have the bug info (if there was a bug).
**Project naming:**

"WMF-Backports" and "MediaWiki-Backports" doesn't feel explanatory enough to me. Sounds too similar to other subprojects which have a defined codebase area. "WMF-Server-Backports" and "MediaWiki-Tarball-Backports" will work for me. Let's go for that?

**Bugzilla Backport Flags migration aspect only:**

Tickets with any of our two Bugzilla flags (Backport_WMF and Backport_to_Stable) set will not have the flag information migrated to Phabricator. I don't see any historical need to know whether something was backported at some undefined point in the past (and that information is available in comments anyway if somebody is curious).

Regarding currently open tickets with Backport requests that have not been decided on, there are less than 10 of them hence the effort is not worth it to write migration code covering that.
I have cleaned up WMF backport requests yesterday and I've sent an email today to the Tarball Release Team to please take a look at the queue of undecided tarball backport requests. 
Furthermore Bugzilla will be available as read-only for some time after the migration so we could still look up which Bugzilla tickets had this flag if we wanted.
No strong opinion either, and no willingness to bikeshed at all. Just trying to apply a principle of starting simple, knowing that we can write more complex names if the simple are confusing.
> WMF-Backports?

No strong opinion - just not sure if that's clear enough, keeping in mind that we will also have projects like "Wikimedia-Site_requests" after importing from Bugzilla, see T43

> MediaWiki-Backports?

...and that would be in a Product-Component row with stuff like "MediaWiki-Categories", "MediaWiki-Page_editing" and so on, but the different color and tag (like a keyword) might be sufficient.
Could we simplify the name? WMF-Backports?
What about backports to MediaWiki releases? MediaWiki-Backports?
Alright, let's keep it simple for the start: Create a "Backport_to_WMF_servers" project in Phabricator and ask interested people (@greg, SWAT) to become members of that project (so they are subscribed to the project) or even "watch" that project (more or less the same).

Anybody can propose a backport for the fix of a task by adding "Backport_to_WMF_servers" to the Projects list for a task (similar to setting that flag in Bugzilla which also wasn't very discoverable, so not much worse). 
We'll fall back to adding comments (and closing tasks) for clarification when a commit has been backported. 
It's not better or worse than Bugzilla currently, where there's also some ambiguity whether to keep a ticket open or resolved when a fix has been merged into git master vs. all the wmf branches: It boils down to defining social workflows.

Documentation in https://www.mediawiki.org/wiki/Backporting_fixes will need updates.

We can still iterate on a more sophisticated solution after having migrated Bugzilla content.
We need to define the process to be applied here and now.

>>! In T101#21, @flimport wrote:
> **greg** wrote on `2014-08-28 22:27:10 (UTC)`
>> **Question2**: I //do not// see a way in Herald to define a rule "Projects | name includes the string | WMF_server_deployment" though, so somebody tell me I'm wrong that this would require subscribing to each project created every week? Uhm.
> 
> I couldn't find anything useful. I assume some script somewhere will be creating this projects (not Phab itself), so maybe the logic of who should be subscribed could stay in that script for now?

Such script doesn't exists today...

>> **Fallback:** If my questions above indeed do make things complicated, we could also start simple and stupid with a generic "Backport_to_WMF_servers" project, and could switch to a more sophisticated process later on when Phabricator provides more functionality (cf. release notes) needed.
> 
> I'm fine with that.

So this might be it for now.
**Mglaser** wrote on `2014-08-28 22:33:43 (UTC)`

Sounds like a good start. I assume the project "MediaWiki_tarball_release" will be generic and always points to the next maintenance release. It is then within the scope of the release team to decide whether to backport this to legacy and lts releases as well, right?
**greg** wrote on `2014-08-28 22:27:10 (UTC)`

>>! In T167#36, @aklapper wrote:
> So it sounds like James and Greg want separate "WMF server deployment 2014-05-29 (1.24wmf7)"-style projects for each weekly deployment.

something, even just 1.XXwmfYY would be fine with me (dates may change due to holidays etc, so predicting them is hard, and we may change our deploy cycle/cadence in the future, too)
 
> **Question1**: If above was possible (release notes) and we automatically set such a project: If a task with that "deployment of the week"-project set is reopened (e.g. not entirely fixed) and that project entry isn't removed from the task, wouldn't the next person looking at the task interpret it as a backport request, if I understand the proposed logic correctly?

If a task is reopened then who ever is triaging those should move the project to the latest 1.XXwmfYY project. That should be clear enough.
(This is where I want Launchpad's per project status... but I digress)

> **Question2**: I //do not// see a way in Herald to define a rule "Projects | name includes the string | WMF_server_deployment" though, so somebody tell me I'm wrong that this would require subscribing to each project created every week? Uhm.

I couldn't find anything useful. I assume some script somewhere will be creating this projects (not Phab itself), so maybe the logic of who should be subscribed could stay in that script for now?

> **Fallback:** If my questions above indeed do make things complicated, we could also start simple and stupid with a generic "Backport_to_WMF_servers" project, and could switch to a more sophisticated process later on when Phabricator provides more functionality (cf. release notes) needed.

I'm fine with that.
**aklapper** wrote on `2014-08-27 19:23:17 (UTC)`

And to summarize what this task is about in one sentences: "define a process to mark tasks which have merged commits in git master and those commits should be backported into 1.24wmf123 and deployed on the Wikimedia servers, and automatically notify those folks doing backports and deployments by adding such a "backport" project to such a task"
**aklapper** wrote on `2014-08-27 19:20:32 (UTC)`

@greg, @jdforrester: Any comments? I'm leaning towards "keep it simple and stupid" at the beginning, due to the open questions in my previous comment which sound cumbersome and error-prone.
**Mglaser** wrote on `2014-07-17 09:29:33 (UTC)`

+1 to @greg wrt security releases. 

Another question is whether we need to be able to differentiate between backport to current stable and backport to legacy/lts. In particular, this would be useful during pre-release / RC phases, where we want to get some of the master changes still into the tarball. Using a separate flag might be a bit over-organized, though.
**greg** wrote on `2014-07-16 16:58:31 (UTC)`

>>! In T167#32, @aklapper wrote:
>>>! In T167#28, @Nemo_bis wrote:
>> Discussion above is focused on 1 out of 3 backport processes. Were MediaWiki release managers asked to comment?
> 
> The "backport to deployed version on WMF servers" process isn't that different to the "backport to stable branch for next tarball release" process and feels sufficiently covered to me.

+1 to "backport to WMF servers" and "backport to stable releases" are basically the same; I see zero substantial difference. So that's 2 of 3 use cases.

The last use case, security releases, will be handled differently than the other 2 use cases, and it basically won't change in the world of Phab. We'll still have a Security private project, and we'll still make security releases from those bugs, er, tasks. We don't have a "Backport to Security Release" flag because all security bugs are private and in the same queue together already, a flag would be redundant.
**aklapper** wrote on `2014-07-16 14:57:33 (UTC)`

>>! In T167#28, @Nemo_bis wrote:
> Discussion above is focused on 1 out of 3 backport processes. Were MediaWiki release managers asked to comment?

The "backport to deployed version on WMF servers" process isn't that different to the "backport to stable branch for next tarball release" process and feels sufficiently covered to me.

As written in T166, subprojects in https://secure.phabricator.com/T3670 will probably the way to go here too.
**Nemo_bis** wrote on `2014-06-12 06:40:48 (UTC)`

Discussion above is focused on 1 out of 3 backport processes. Were MediaWiki release managers asked to comment? https://www.mediawiki.org/wiki/Backporting_fixes#Backports_to_stable.2Fsupported_release
(Added Markus; I don't find hexmode.)
**jdforrester** wrote on `2014-05-30 15:56:48 (UTC)`

>>! In T167#23, @greg wrote:
>>>! In T167#21, @jdforrester wrote:
>> We'd discussed creating a project for each deployment – so "WMF server deployment 2014-05-29 (1.24wmf7)" //etc.//. This would potentially leave us with a lot of projects, but it would map well to the workflow of "are there any outstanding code commits for deployment?" which is common.
> 
> I think that might be overkill initially, honestly. But I can be convinced otherwise.

If we don't do it for WMF-wide we'll need to do it for VisualEditor at least to preserve the existing milestones which are used to tracking bugs, regressions, patches and so on… The feedback we've had from community members is that the clarity of deployment target on every bug (for Phabricator, read: task) and patch is that it's been very helpful and clear for them in understand what has changed and when.

Also, I'd presume (hope!) that it would allow us to no longer create [[ https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf7/Changelog | mw:MediaWiki 1.24/wmf7/Changelog ]] and its ilk, but instead have it neatly and usefully listed on the project "WMF server deployment 2014-05-29 (1.24wmf7)".
**jdforrester** wrote on `2014-05-30 15:55:32 (UTC)`

>>! In T167#26, @aklapper wrote:
>> We'd discussed creating a project for each deployment – so reproducible etc.. This would potentially leave us with a lot of projects, but it would map well to the workflow of "are there any outstanding code commits for deployment?" which is common.
> 
> I've also copied this comment to T166 as it relates not only to **backporting**. If we managed to //automatically// add a "WMF server deployment 2014-05-29 (1.24wmf7)" project to tasks whose status is set to resolved based on a timeframe, that would be lovely and would drop the need for a separate "Backport to WMF servers" project, as one could query for open tickets where that project was //manually// added.

Yeah; I was thinking that it would also answer the "what things are being proposed for backport to MW 1.23?" with a "MediaWiki 1.23" project.
**aklapper** wrote on `2014-05-30 15:37:56 (UTC)`

> We'd discussed creating a project for each deployment – so reproducible etc.. This would potentially leave us with a lot of projects, but it would map well to the workflow of "are there any outstanding code commits for deployment?" which is common.

I've also copied this comment to T166 as it relates not only to **backporting**. If we managed to //automatically// add a "WMF server deployment 2014-05-29 (1.24wmf7)" project to tasks whose status is set to resolved based on a timeframe, that would be lovely and would drop the need for a separate "Backport to WMF servers" project, as one could query for open tickets where that project was //manually// added.
**greg** wrote on `2014-05-29 22:17:33 (UTC)`

>>! In T167#24, @jdforrester wrote:
> Also, I'd presume (hope!) that it would allow us to no longer create [[ https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf7/Changelog | mw:MediaWiki 1.24/wmf7/Changelog ]] and its ilk, but instead have it neatly and usefully listed on the project "WMF server deployment 2014-05-29 (1.24wmf7)".

I'm convinced.
**greg** wrote on `2014-05-29 21:52:29 (UTC)`

>>! In T167#21, @jdforrester wrote:
> We'd discussed creating a project for each deployment – so "WMF server deployment 2014-05-29 (1.24wmf7)" //etc.//. This would potentially leave us with a lot of projects, but it would map well to the workflow of "are there any outstanding code commits for deployment?" which is common.

I think that might be overkill initially, honestly. But I can be convinced otherwise.



>>! In T167#19, @aklapper wrote:
> Greg: Any opinions here?
> 
> Currently I favor creating a generic "Backport to WMF servers" project and making you subscribe to that project's notifications by you setting up a rule in Maniphest's Herald.

I like this. Also a "Backport to MediaWiki Releases" project that the Release Team subscribe to.
**jdforrester** wrote on `2014-05-29 15:36:02 (UTC)`

>>! In T167#19, @aklapper wrote:
> Greg: Any opinions here?
> 
> Currently I favor creating a generic "Backport to WMF servers" project and making you subscribe to that project's notifications by you setting up a rule in Maniphest's Herald.

We'd discussed creating a project for each deployment – so "WMF server deployment 2014-05-29 (1.24wmf7)" //etc.//. This would potentially leave us with a lot of projects, but it would map well to the workflow of "are there any outstanding code commits for deployment?" which is common.
**aklapper** wrote on `2014-05-26 13:44:20 (UTC)`

Greg: Any opinions here?

Currently I favor creating a generic "Backport to WMF servers" project and making you subscribe to that project's notifications by you setting up a rule in Maniphest's Herald.

(Note to myself: Updating the docs on https://www.mediawiki.org/wiki/Backporting_fixes is covered by T350)
**qgil** wrote on `2014-04-23 13:51:20 (UTC)`

"query that project regularly" = [[ https://secure.phabricator.com/book/phabricator/article/herald/ | Herald ]]

We still need to play with that tool and see what can it offer.
**aklapper** wrote on `2014-04-23 06:37:15 (UTC)`

+1 for using a project and making people responsible for backports receive automatic notifications about it, or query that project regularly (social thing to solve, not technical).
**qgil** wrote on `2014-04-22 18:02:51 (UTC)`

It looks like Phabricator provides enough elements for us to define this process.
**qgil** wrote on `2014-04-19 16:11:19 (UTC)`

Create a "Backport WMF" project and add the related tasks to that project? This could be used in combination with release projects and what not, see T166.
Related task upstream: [[ https://secure.phabricator.com/T390#21 | Implement project types ]].

I don't understand how we're going to mark release milestones: each release a blocked task, kept open for each sub-point release until the RELX_Y branch in question is frozen?
(Due to http://fab.wmflabs.org/T164 we can't have two levels of dependency so I suppose we'll instead give up on granularity.)

A handful of MediaWiki extensions are maintained by teams who use sprints, so the sprints could then be mapped to the RELX_Y branch in which they first appear and to the corresponding task; in this case (in theory) we'd gain, for no cost, that WMF work would be visible to tarball users.
I consider this task decided/resolved/closed.
Works for us.  I like the rainbow.
Thumb ups from me, this fits my team's workflow.
Are there any more details that must be decided here? We really need to close this task, or at least have it in a state where it is not blocking T259 anymore.

In other words, the period for input to the migration script needs to end. We can always file tasks based on the results of {T552}.
>>! In T100#9608, @Aklapper wrote:
> Trying to keep it simple for the start: Combine one color with one icon.

Deal.

> * Projects have a {icon briefcase} Briefcase icon (and blue color).
> * Releases have a {icon truck} Release icon (and orange color).
> * Sprints have a {icon calendar} Deadline icon (and some other color - indigo? shrug).
> * For completeness: Cross-project 'keywords' (Bugzilla terminology) have a {icon tag} Tag icon (and red color I think).

Yes to most points, but look what I've done instead: {M4}

Let's finish the discussion about icons and colors in the mockup.
Happy for the VisualEditor TMs to be magically transformed into projects to which each Bugzilla item is transferred as appropriate, but yes, we really need to keep that data if at all possible.
**Target Milestone data migration:**

Sorry, this fell through the cracks and this is not entirely 'ready to go' yet but close.

I'm currently checking the use of Target Milestones in Bugzilla products, and which TMs are in the past so I can disable setting these TMs in Bugzilla (cleaning up but need to talk to several teams), and which TMs are rubbish (see e.g. https://bugzilla.wikimedia.org/show_bug.cgi?id=71807 ).

Projects in Bugzilla using Target Milestones:
* Huggle (3 TMs, 3 of them active)
* MediaWiki (15 TMs, 6 of them active)
* MediaWiki extensions (8 TMs, 5 of them active)
* MediaWiki skins (1 TMs, 1 of them active but TM set on 0 tickets)
* VisualEditor (89 TMs, 89 of them active but asked James if past ones could be made inactive)
* Wikimedia (1 active TM called 'Mysterious future' which I want to delete, see https://bugzilla.wikimedia.org/show_bug.cgi?id=71807)
* Wikipedia App (2 TMs, 0 active)

**Question:** Not sure if that makes things more complicated or not in the migation logic hence question might not make sense: I'm wondering whether we could/should ignore past TMs (TMs that are 'not active' / cannot be set anymore on Bugzilla tasks) and not necessarily migrate them into //archived// projects in Phabricator. On the other hand we'd lose data, e.g. which VisualEditor bug was fixed at which time, hence probably going for archived makes more sense.

In any case, Bugzilla TMs should become deadline or release projects. See my previous comment.
Different/separate tags for project (e.g. '{icon briefcase} VisualEditor') which covers all tasks in a project, vs. release (e.g. '{icon truck} VisualEditor 1.0.1') and vs. deadline (e.g. '{icon calendar} VisualEditor 2014-12-24').

Trying to keep it simple for the start: Combine one color with one icon.

* Projects have a {icon briefcase} Briefcase icon (and blue color).
* Releases have a {icon truck} Release icon (and orange color).
* Sprints have a {icon calendar} Deadline icon (and some other color - indigo? shrug).
* For completeness: Cross-project 'keywords' (Bugzilla terminology) have a {icon tag} Tag icon (and red color I think).
I just created a project for the [[ https://phabricator.wikimedia.org/T18 | Engineering Community October 2014 ]] sprint. A sprint is not a release, so I used another icon: {icon calendar}

Sprints could have a color on their own, or they could have the same as releases, not to end up with a full-fledged rainbow.
I got a bit lost with the discussion above and what we will start doing right now. Different tags for project and release, or single tags "project + release"?

Above you have covered stable MediaWiki releases 1.xx and also WMF weekly releases 1.xx-wmfZZ. Could we also add months as in yyyy-mm for those teams organizing monthly sprints? This is the case of at least Engineering Communty, but I imagine we are not the only ones.

PS: enthusiastic thumbs up for {icon truck}!
I got a bit lost with the discussion above and what we will start doing right now. Different tags for project and release, or single tags "project + release"?

Above you have covered stable MediaWiki releases 1.xx and also WMF weekly releases 1.xx-wmfZZ. Could we also add months as in yyyy-mm for those teams organizing monthly sprints? This is the case of at least Engineering Communty, but I imagine we are not the only ones.

PS: enthustastic thumbs up for {icon truck}!
I got a bit lost with the discussion above and what we will start doing right now. Different tags for project and release, or single tags "project + release"?

Above you have covered stable MediaWiki releases 1.xx and also WMF weekly releases 1.xx-wmfZZ. Could we also add months as in yyyy-mm for those teams organizing monthly sprints? This is the case of at least Engineering Communty, but I might imagine we are not the only ones.

PS: enthustastic thumbs up for {icon truck}!
**aklapper** wrote on `2014-08-10 19:58:22 (UTC)`

For the time being (as implementing subprojects might take too long for us in upstream), the basic idea is to use projects (tags) in Phab, differentiating types via icons and colors. For releases ("target milestones" in Bugzilla), imagine a truck tag for example, or check out the preliminary screenshot. 

Not entirely set in stone yet and just to show the basic idea. All kudos goes to Chase.
Sigh, as I get an "Upload Failure" both with Chrome and Firefox here, external link to screenshot: [[ http://home.arcor.de/ak-47/tmp/Phab-Project-Tags-T46.png ]]
**SG** wrote on `2014-07-10 20:27:36 (UTC)`

That does seem like it would fit our needs. It's slightly less clunky than our proposed solution.
**aklapper** wrote on `2014-07-06 20:35:34 (UTC)`

Upstream decided to try subprojects in https://secure.phabricator.com/T3670 (makes our T240 a WONTFIX), which "will make an attack on sprints/milestones/versions." This might make our life easier?
**jdforrester** wrote on `2014-06-09 18:16:52 (UTC)`

>>! In T166#40, @aklapper wrote:
>  * Planning to fix a task in a past version (backporting to servers; only applies for //WMF server deployment 1.xx-wmfZZ (yyyy-mm-dd)//)

Actually, we also do this for releases – tagging bugs as things that need to get fixed in 1.23.1 for example.  However, I don't think it makes a major difference.

> So.... does this novel make any sense?

Yes! It looks good. I'd suggest having a "Backport to MediaWiki releases" project for the MW release maintainers as well, but yes, it works for us.
**mmodell** wrote on `2014-06-09 17:51:24 (UTC)`

Documenting when a big fix got released should be simple because you can link a git commit to a task as well as linking differential revisions. It would be trivial to traverse the git log from the newest commit to find the next release tag that occurs between the relevant commit and HEAD. That version tag can be exposed In the task ui as the first release containing the fix.
**qgil** wrote on `2014-05-30 21:40:04 (UTC)`

In this case, renaming projects is not an option.

Wouldn't the workboard of <sprint/deployment> be enough?
**jdforrester** wrote on `2014-05-30 21:35:40 (UTC)`

>>! In T166#37, @qgil wrote:
> Maybe this sounds silly, but what about
> 
> # Work on the tasks at project "WMF server deployment 2014-05-29 (1.24wmf7)".
> # By the end of 2014-05-29, some tasks will be resolved and forgotten, others will remain open.
> # Rename the project to "WMF server deployment 2014-06-05 (1.24wmf8)".
> # Add the new tasks you want to complete in addition to the ones you still have open.
> 
> If you don't like the idea of simply renaming projects for whatever obscure archiving reason, then "Edit batch" selecting ll open tasks of a project can make wonders. Not automatic but still pretty simple.

Where would the static links to "tasks fixed in <sprint/deployment>" and "code landed in <sprint/deployment>" live? That's one of the key needs from my POV.
**qgil** wrote on `2014-05-30 19:19:49 (UTC)`

Maybe this sounds silly, but what about

# Work on the tasks at project "WMF server deployment 2014-05-29 (1.24wmf7)".
# By the end of 2014-05-29, some tasks will be resolved and forgotten, others will remain open.
# Rename the project to "WMF server deployment 2014-06-05 (1.24wmf8)".
# Add the new tasks you want to complete in addition to the ones you still have open.

If you don't like the idea of simply renaming projects for whatever obscure archiving reason, then "Edit batch" selecting ll open tasks of a project can make wonders. Not automatic but still pretty simple.
**jdforrester** wrote on `2014-05-30 15:53:56 (UTC)`

>>! In T166#33, @aklapper wrote:
> Copying @jdforrester's comment from T167:
> 
>> We'd discussed creating a project for each deployment – so "WMF server deployment 2014-05-29 (1.24wmf7)" etc.. This would potentially leave us with a lot of projects, but it would map well to the workflow of "are there any outstanding code commits for deployment?" which is common.
> 
> If we did that, we might want to be able to //close projects if they are in the past// (disable adding a project to a task). Now I need to find out if that's possible already, and if not I'll upstream.
> 
> The problem I see is that we'd want to add such a "Deployment Target Milestone" project to tasks automatically in the long run: Closing a task in a certain timeframe in a certain project should automatically add this project to the task. Which will be a complex feature request.

That'd be a nice-to-have, but we don't have it on Bugzilla and I manage it manually instead. The important thing would be an automtic "add change to project", which presumably we could do as part of the script that currently posts the list on MediaWiki.org?
**aklapper** wrote on `2014-05-30 15:39:17 (UTC)`

Answering my own question thanks to upstream IRC:

> we might want to be able to close projects if they are in the past (disable adding a project to a task).

<mikkn>  If you go to Projects then click on the project in question, then edit, you will have an "Archive Project" button there
**aklapper** wrote on `2014-05-30 15:16:16 (UTC)`

Copying @jdforrester's comment from T167:

> We'd discussed creating a project for each deployment – so "WMF server deployment 2014-05-29 (1.24wmf7)" etc.. This would potentially leave us with a lot of projects, but it would map well to the workflow of "are there any outstanding code commits for deployment?" which is common.

If we did that, we might want to be able to //close projects if they are in the past// (disable adding a project to a task). Now I need to find out if that's possible already, and if not I'll upstream.

The problem I see is that we'd want to add such a "Deployment Target Milestone" project to tasks automatically in the long run: Closing a task in a certain timeframe in a certain project should automatically add this project to the task. Which will be a complex feature request.
**qgil** wrote on `2014-05-15 14:07:55 (UTC)`

At the teampractices mailing list there is a discussion about [[ http://lists.wikimedia.org/pipermail/teampractices/2014-May/000411.html | how to organize sprints ]]. While [[ https://secure.phabricator.com/T390#21 | the upstream solution ]] arrives, it would be good to know how Phabricator users do this nowadays.

As far as I can see, the process seems to be something like this:

# A //Project X// exists containing several tasks. Optionally, a team is created for it.
# A new //Project X Sprint 1// project is created. The tasks from //Project X// to be included in the sprint are tagged accordingly. The only relation between these projects is their naming convention. For Phabricator these are independent projects. Herald rules can be created to assign to //Project X// any task created for //Project X*// automatically.
# At the end of the sprint, //Project X Sprint 1// is archived and //Project X Sprint 2// is created. The remaining tasks of Sprint 1 can be moved to the next sprint with a single batch edit.

There are some manual steps that in the future should be automatized, but other than that the process seems to be simple enough? Creating projects is simple, you only need to add a title and, if you wish, you can copy & paste a stock description. Membership of these subprojects is not relevant. If you want to set some special permissions for the developer team you can simply set those permissions to the //Project X// team.
**mattflaschen** wrote on `2014-04-29 04:30:12 (UTC)`

>  (Due to http://fab.wmflabs.org/T164 we can't have two levels of dependency so I suppose we'll instead give up on granularity.)

Do you mean that you can't visualize two levels in a chart?  You can have arbitrary dependencies, as far as I can tell.  Two-level example: T248 depends on T249, which depends on T250.
**qgil** wrote on `2014-04-28 13:14:48 (UTC)`

Moving here this comment from @awjrichards at {T44}

* The concept of bucketing 'tasks' into an 'iteration'
** This also includes the ability to look at past iterations (and what was contained in them)
** As well as the ability to look at future iterations (and what will be contained in them)
* The concept of bucketing 'iterations' into a broader 'release'
**qgil** wrote on `2014-04-24 14:05:29 (UTC)`

There is a plan to [[ https://secure.phabricator.com/T390#21 | implement project types ]] that would include 

  ( ) Tag
    Tags are lightweight projects that don't have members or wiki pages.
    
  ( ) Sprint
    Sprint projects organize work into a series of iterations. Iterations
    are created automatically and incomplete tasks roll from one iteration to
    the next.

In the meantime, I think we could work with specific projects and queries. According to some comments in that task, this is how some orgs are doing it.
**aklapper** wrote on `2014-04-24 09:15:47 (UTC)`

Projects + queries (like "open tickets in all these projects: '1.23.0 release' && 'MediaWiki'").
**qgil** wrote on `2014-04-22 18:03:22 (UTC)`

It looks like Phabricator provides enough elements for us to define this process.
**qgil** wrote on `2014-04-19 16:05:43 (UTC)`

Why not creating project "1.23.0 release", and add the relevant tasks there? Release managers would even get a workboard to mark mark the status of each task from that release point of view.
> Project behavior in Maniphest is similar to keywords behavior in Bugzilla

Right, but then... what about keywords? Are they supposed to be enabled separately or are we using projects literally as keywords?

By the way, since we may have finally a common system for keywords/tags across different tools, this might be relevant: https://www.mediawiki.org/wiki/Project:New_contributors/One_ontology

**UPDATED**: 

Projects are keywords, keywords are projects, components might be projects if we want... We need to come up with a default organization of projects, knowing that user will come and create the projects they miss (unless we stop them by restricting permissions), just like wiki editors create categories.

**RULES FOR MIGRATING PROJECT NAMES**


  buginfo["product"] = buginfo["product"].replace('-', '_')
  buginfo["product"] = buginfo["product"].replace(' ', '_')
  buginfo["component"] = buginfo["component"].replace('/', '_and_')
  buginfo["component"] = buginfo["component"].replace('-', '_')
  buginfo["component"] = buginfo["component"].replace(' ', '_')

  component_separator = '-' 
  project = "%s%s%s" % (buginfo["product"],
                       component_separator,
                       buginfo["component"])


Examples:

| Bugzilla product | Bugzilla component | Phabricator project |
| MediaWiki | Change tagging | MediaWiki-Change_tagging |
| MediaWiki‑Vagrant | labs-vagrant | MediaWiki_Vagrant-labs_vagrant |
| Wikimedia | Git/Gerrit | Wikimedia-Git_and_Gerrit |
| Wiki Loves Monuments | Unused images | Wiki_Loves_Monuments-Unused_images |
>>! In T43#15328, @Qgil wrote:
> It's not a bug, it makes sense that URLs of projects follow the names of the projects, and if you edit one, the other follows.

Lack of redirects after renaming a project is almost certainly a bug, as I laid out in T910.

>>! In T43#15314, @Qgil wrote:
> Please, could you revert your changes and open a new tasks to discuss specifically the substitution of dashes and underscores by spaces?

I filed T911 to track this issue.
True, the URLs. I have reverted your renaming of "Bugzilla-Preview" to make sure that this URL that we have sent to everybody in the past 48h works:

https://phabricator.wikimedia.org/tag/bugzilla-preview/

If you change the dash for a space, then you get

https://phabricator.wikimedia.org/tag/bugzilla_preview/

It's not a bug, it makes sense that URLs of projects follow the names of the projects, and if you edit one, the other follows. You can also link to the project number (https://phabricator.wikimedia.org/project/view/40/) but we opted to promote the self-explanatory URL.
>>! In T43#15315, @chasemp wrote:
> Changing this broke links currently shared to the migration effort.  I have locked this project to prevent this from happening again as people are trying to follow up on emails sent with details about the coming changes.  It would be more appropriate to start a discussion on whether another name is preferable rather than taking action that has unintended consequences.

Uhh, that sounds like a Phabricator bug. I filed T910 to track this issue.
>>! In T43#15276, @MZMcBride wrote:
> I changed "Bugzilla-Migration" to "Bugzilla migration" because MediaWiki/Wikimedia development typically uses sentence case and standard word demarcation.
> 
> If Phabricator can't handle spaces, a very basic component of English and other languages, in project display names, then Phabricator will need to be fixed. But as a label, "Bugzilla-Migration" and similar awkwardly hyphenated and capitalized project names are pretty bad and should be avoided, in my opinion.

Changing this broke links currently shared to the migration effort.  I have locked this project to prevent this from happening again as people are trying to follow up on emails sent with details about the coming changes.  It would be more appropriate to start a discussion on whether another name is preferable rather than taking action that has unintended consequences.
>>! In T43#15276, @MZMcBride wrote:
> I changed "Bugzilla-Migration" to "Bugzilla migration" because MediaWiki/Wikimedia development typically uses sentence case and standard word demarcation.
> 
> If Phabricator can't handle spaces, a very basic component of English and other languages, in project display names, then Phabricator will need to be fixed. But as a label, "Bugzilla-Migration" and similar awkwardly hyphenated and capitalized project names are pretty bad and should be avoided, in my opinion.

Changing this broke links currently shared to the migration effort.  I have locked this project to prevent this fromhappening again as people are trying to follow up on emails with details about the coming changes.  It would be more appropriate to start a discussion on whether another name is preferable rather than taking action that has unintended consequences.
@MZMcBride, we invested a fair amount of time, energy and patience in order to decide [[ https://www.mediawiki.org/wiki/Phabricator/Requesting_a_new_project#Guidelines | the current guidelines ]]. You can challenge the guidelines with better arguments, and if the guidelines change then we can change the names of project accordingly. Please, could you revert your changes and open a new tasks to discuss specifically the substitution of dashes and underscores by spaces?
I changed "Bugzilla-Migration" to "Bugzilla migration" because MediaWiki/Wikimedia development typically uses sentence case and standard word demarcation.

If Phabricator can't handle spaces, a very basic component of English and other languages, in project display names, then Phabricator will need to be fixed. But as a label, "Bugzilla-Migration" and similar awkwardly hyphenated and capitalized project names are pretty bad and should be avoided, in my opinion.
We aim at having a clear and consistent migration script logic. MediaWiki has 43 components; Wikimedia 34; MediaWiki_extensions a few more; we can rename stuff after importing, but please not in the migration script logic.

Redundancy: Depends. Seeing component names such as "Uploading" you're supposed to have different teams working on uploading related stuff on different architecture levels (Core upload handling code, low-level media storage, Multimedia team's UploadWizard etc.).
Some time ago I proposed to get rid of "MediaWiki" and "Wikimedia" since most of the times they are redundant, but I can see how that might be easier to do manually than with a magical instruction in the scrip.

I find the combination of -_-_ disturbing. Possible scenarios:

# Leave it as it is now and wait until our eyes get used to them.
# Leave it as it is now and convert everything to dashes manually where makes sense.
# Convert everything to dashes with the script, editing manually if this option is confusing in a project name.

My preferred is 3, although 2 would be fine, an even 1 if I'm the only one being picky about this.  :)
| Bugzilla product | Bugzilla component | Phabricator project |
| MediaWiki | Change tagging | MediaWiki-Change_tagging |
| MediaWiki‑Vagrant | labs-vagrant | MediaWiki_Vagrant-labs_vagrant |
| Wikimedia | Git/Gerrit | Wikimedia-Git_and_Gerrit |
| Wiki Loves Monuments | Unused images | Wiki_Loves_Monuments-Unused_images |
Could you give some examples of the result of this pattern? I think I get it, but maybe I'm wrong.
Yeah, done.

Pasting the name replacement rules here, for the records:

  buginfo["product"] = buginfo["product"].replace('-', '_')
  buginfo["product"] = buginfo["product"].replace(' ', '_')
  buginfo["component"] = buginfo["component"].replace('/', '_and_')
  buginfo["component"] = buginfo["component"].replace('-', '_')
  buginfo["component"] = buginfo["component"].replace(' ', '_')

  component_separator = '-' 
  project = "%s%s%s" % (buginfo["product"],
                       component_separator,
                       buginfo["component"])
Naming guidelines as discussed here are have been drafted at https://www.mediawiki.org/wiki/Phabricator/Help#Requesting_a_new_project 

[[ https://phabricator.wikimedia.org/project/query/o8VA7EyUUHZT/#R | Active projects ]] in this instance have been renamed accordingly.

Is there anything else left in this task?
**Rush** wrote on `2014-09-08 15:48:20 (UTC)`

at this point we can leave existing?  Mainly these restrictions are for imported content atm, I'm sure the ongoing etymology will provide plenty of conversation and change opportunities :)
**qgil** wrote on `2014-09-07 20:45:35 (UTC)`

Is there anything else to be decided before closing this task?

>>! In T68#68, @aklapper wrote:
> Once issues created by **spaces** for URLs and referencing have been handled/fixed in upstream, we can still pretty up project names in our instance if we want.

Is it worth renaming now the projects that will be migrated to follow all the same guideline?

* Project
* Great-Project

I can do it in the next hours. Or we can wait and do it after the migration if you prefer.
**aklapper** wrote on `2014-08-10 19:25:38 (UTC)`

Once issues created by **spaces** for URLs and referencing have been handled/fixed in upstream, we can still pretty up project names in our instance if we want. 

Currently we cannot entirely judge how often referencing is needed and used e.g. in Differential (pre-push code review tool) etc. Upstream does avoid spaces in project names, so I'd like to follow upstream here, even if things don't look pretty for use at first.
**qgil** wrote on `2014-08-05 20:14:10 (UTC)`

Indeed! Regardless of the outcome, it is very good to see that this discussion is helping making Phabricator more robust with project names. Thank you @Rush.
**Florian** wrote on `2014-08-05 19:03:19 (UTC)`

@Rush That seems to solve one problem and looks very good :) Thanks!
**Rush** wrote on `2014-08-05 00:11:53 (UTC)`

for fun:

http://fab.wmflabs.org/tag/mediawiki/
http://fab.wmflabs.org/tag/MEDIAWIKI/
http://fab.wmflabs.org/tag/MeDiAwIkI/
**Rush** wrote on `2014-08-05 00:10:34 (UTC)`

Case sensitivity in urls is now handled by normalizing to lower case:

https://github.com/phacility/phabricator/commit/1e375c97c594e029d8e796c3fa937a7522e3b42f

applied to fab for testing :)
**qgil** wrote on `2014-08-04 20:49:25 (UTC)`

>>! In T68#60, @aklapper wrote:
> So whenever people wanted to link to "Project Name" as in "#project name", we'd recommend to write "#Project_Name" and replace spaces by underscores. Question is how many users (non-heavy Phabricator users) we can make aware of it

How many non-heavy Phabricator users are going to know that they can type "#project" in the first place? How often do you see this Markup feature in use? It sounds like a minor case even without spaces. Being project with spaces a minority, the relevance of the problem becomes smaller. And the worse that can happen is that a user can't type properly a reference of a project; not a big problem either.

> plus I really don't know how much referencing is used in e.g. Differential and what other stuff we might break by using spaces in project names.

Do we have specific examples? Phabricator supports spaces in project names. If this causes a problem we can file a bug upstream.
**Rush** wrote on `2014-08-04 20:03:35 (UTC)`

thanks andre for that update :)  



Pretty much my thought, get wider input on spaces if we are (in my eyes at least) overriding technical consistency for readability, and push along the case sensitivity mixup if that is a need for us.  FWIW, evan seemed to indicate the case strictness wasn’t too hard of a fix
**aklapper** wrote on `2014-08-04 20:00:06 (UTC)`

So whenever people wanted to link to "Project Name" as in "#project name", we'd recommend to write "#Project_Name" and replace spaces by underscores. Question is how many users (non-heavy Phabricator users) we can make aware of it, plus I really don't know how much referencing is used in e.g. Differential and what other stuff we might break by using spaces in project names.

On the latter, //input from folks who have been using Phabricator extensively would help//. Chase and I don't feel entirely comfortable deciding for everybody here - it's clear that developers and engineering is the primary customer of Phab, but we'd also have HR and Legal and others here in the long run.

As we'd like to not only use lower-case for project names, we want to get https://secure.phabricator.com/T5728 fixed first. Because if things don't work properly, people //will// work around them. I've asked in the upstream tickets for pointers.

The general tradeoff we're discussing here is readability for humans vs. technical consistency (the value and use of referencing in Markup).
**qgil** wrote on `2014-07-30 21:00:36 (UTC)`

Than you for the summary! Everything sounds sensible, except the bit about underscores in project names that I still (almost apologize for) disagree(ing) with.  :)

>>! In T68#58, @aklapper wrote:
> * Spaces //do not work// in the context of Remarkup in Phabricator. Hence we should avoid spaces in tag/project names. Make spaces become underscores.

Phabricator converts automatically spaces in project names into underscores in their corresponding hastags in Remarkup. For what is worth, it even ignores the case style (while names with dashes/underscores seem to be case sensitive, one annoyance more to consider): 

  #Wikimedia_Phabricator_Day_1, #Developer_Hub, #Human_Resources, #Trusted_User_Tool
  #wikimedia_phabricator_day_1, #developer_hub, #human_resources, #trusted_user_tool
  #WikImediA_pHabRicator_DaY_1, #deVELoper_HUB, #HUMAN_resources, #trustEd_User_tOoL
renders as
 #Wikimedia_Phabricator_Day_1, #Developer_Hub, #Human_Resources, #Trusted_User_Tool
 #wikimedia_phabricator_day_1, #developer_hub, #human_resources, #trusted_user_tool
 #WikImediA_pHabRicator_DaY_1, #deVELoper_HUB, #HUMAN_resources, #trustEd_User_tOoL 

Therefore, substituting spaces with underscores in project names doesn't add anything apart from the inconvenient case sensitivity and the lack of tokenization.

Also note that the labels above look visually good and feel human, natural. Put the underscores between words, and it will look like computer generated text with a slightly broken UI (like a string without localization). Project names are visible everywhere in Phabricator. If they look nice, our Phabricator will look nicer.

> (Underscores however are not tokenized (yet), same problem for dashes in https://secure.phabricator.com/T5727.) I don't see this as a big issue for type-ahead in the Project field. If some consider it, it is fixable.

Tokenization works fine with spaces in projects names.
**aklapper** wrote on `2014-07-30 18:11:30 (UTC)`

We have two aspects and we've mixed them up so far. My fault.
1) Migrating data from Bugzilla to Phabricator, in a consistent way, via a script. That's T423.
2) Fixing some of Bugzilla's product and component taxonomy. For example, "MediaWiki extensions" should have never been a product in Bugzilla as it's not "one codebase/shared ownership". Instead, its components should have been products in Bugzilla. A few years too late.

In today's Phab meeting there was pretty much agreement on:
* Fix Bugzilla's broken taxonomy //after// migrating, instead of trying to cover and fix lots of cornercases in the migration script itself. (Not sure if we can (mass-)rename via API. If not, I'll spend a long night on coffee.)
* Convert forward slashes like in "General/Unknown" to underscores or just drop the part after the slash, because slashes would break project URLs. There are 15 components affected in Bugzilla.
* Spaces //do not work// in the context of Remarkup in Phabricator. Hence we should avoid spaces in tag/project names. Make spaces become underscores. (Underscores however are not tokenized (yet), same problem for dashes in https://secure.phabricator.com/T5727.) I don't see this as a big issue for type-ahead in the Project field. If some consider it, it is fixable.
* The "Product Component" pair in Bugzilla should become "Product:Component", with a colon as separator. (And I just renamed two components in Bugzilla to not include colons.)
* As Bugzilla's keywords and "Product Component" pairs will be in the same namespace in Phabricator, a Bugzilla keyword becomes a tag, "Product Component" becomes a project. These would be two different types and Mukunda said this should not be too hard to fix if I got it right at the end.
**jdforrester** wrote on `2014-07-28 23:59:55 (UTC)`

@qgil's suggestions all make sense to me.

Spaces in project names is a fact of life, but we should discourage it unless it's needed; in general, the first space being a subproject is a neat enough design idea.

My only concern is where we have clashes in name (//e.g.// we used to have Vector the skin and Vector the extension), but I think we can manage our way around those as needed.
**qgil** wrote on `2014-07-28 21:53:35 (UTC)`

I summarized my opinion about this topic at T457#19. In short:

> * Using original project names in Phabricator makes them easier to type and find.
> * Project names are used as simple tags, except in the case of explicit subprojects of an existing project à la "Product - Component". No "MediaWiki-Extensions-Etc".
> * Since projects are proper nouns, by default they use the regular Title Case. Other uses of case are allowed only when the original project name uses them (e.g. GoogleLogin, VisualEditor, MySQL, FOSDEM)

If the VisualEditor team wants to have a "VisualEditor Data Model" project, that's fine, but I don't see the usefulness of adding "MediaWiki Extension" to the project name. Especially when with the same principle we will add the same string to hundreds of extension projects, ruining type-ahead for any users typing "MediaWiki" and/or "extension"

As the description of this task says, in Phabricator projects are keywords, keywords are projects. Search and type-ahead are essential in Phabricator (and in MediaWiki itself, btw). The tree structure that Bugzilla and Git/Gerrit enforce doesn't need to be replicated here. What's the use? Project naming should focus on proper tagging instead of trying to emulate a tree structure.
**Rush** wrote on `2014-07-28 20:47:30 (UTC)`

@aklapper @qgil

I took this to mean that we qgil does not want either categorization or hierarchy in the googlelogin case

> What is important about "GoogleLogin" is that users can find it or reference it easily. Therefore the best is to use the name as is.

@qgil can you maybe clarify so we aren't shadow boxing here?
**qgil** wrote on `2014-07-23 14:54:41 (UTC)`

A note aside: there is an RfC about Bugzilla taxonomy: https://www.mediawiki.org/wiki/Requests_for_comment/Bugzilla_taxonomy

We should check which concerns still are relevant in the context of Phabricator, even if here we don't have trees, product-component pairs, and restrictions to file reports only under one product-component.
**aklapper** wrote on `2014-07-02 16:20:51 (UTC)`

Refering to differentiating between types of projects (e.g. keywords and components in Bugzilla language), it looks like upstream is going towards project tags. That means that https://secure.phabricator.com/T390 (Implement Project Types) might not gonna happen, but https://secure.phabricator.com/D9709 and https://secure.phabricator.com/T2628 (Add project tags to Pholio, Ponder, Differential, and other applications) instead.

As one example, upstream Phabricator shows a different (kind of transparent) background on umbrella projects now, see e.g. https://secure.phabricator.com/T1205
**Nemo_bis** wrote on `2014-06-15 10:36:47 (UTC)`

> (Phab doesn't list project names first which start with the entered substring).

Doesn't?
**aklapper** wrote on `2014-06-12 18:11:33 (UTC)`

>>! In T68#42, @qgil wrote:
> Let's avoid repetitive mentions to "Wikimedia" and "MediaWiki". Think again about the side effects this creates in type-ahead when a user starts typing "Wiki..." when actually the request is the very licit WikiLove.

Good point, as type-ahead proposals for the Project field always have the alphabetical order of project names it would clutter a lot (Phab doesn't list project names first which //start// with the entered substring).
"skin" and "extension" implicitly refer to MediaWiki nowadays; crossing fingers it'll stay like this.
**qgil** wrote on `2014-06-11 22:17:57 (UTC)`

I wouldn't patch anything before receiving consistent feedback from real users. I still believe type-ahead will just work as a method, and we might just fix nmes of projects based on what people is not finding easily.

Let's avoid repetitive mentions to "Wikimedia" and "MediaWiki". Think again about the side effects this creates in type-ahead when a user starts typing "Wiki..." when actually the request is the very licit WikiLove.

I would keep keywords as projects. It is easier to get rid of those projects we won't user than to fix missing keywords after the migration.
**jdforrester** wrote on `2014-06-11 18:23:28 (UTC)`

>>! In T68#40, @aklapper wrote:
> * Please help: What are further potential categories (skins, extensions, tool labs, mobile apps) you can imagine?

I think the main one will be cross-cutting pieces of work, which currently are represented as you say as either:
* a tracking bug, often in a in poor location
** //e.g.// "All repositories should pass jshint test (tracking)" https://bugzilla.wikimedia.org/show_bug.cgi?id=60619 which is in the component for Wikimedia's CI infrastructure rather than being a cross-tracked "code quality" compontent
* a keyword, often poorly understood, abused or ignored
** //e.g.// "shell" https://bugzilla.wikimedia.org/buglist.cgi?keywords=shell&list_id=321010&resolution=--- which really just means "deployment rights needed" and so duplicates the "Site requests" component a chunk.

I would suggest that:

* All tracking bugs should be merged into existing projects / components or tasks within a larger cross-cutting project
* All keywords should become projects (with overlap with the above), or just be killed.

Examples:

* //Code quality// is clearly something we'd want as a cross-cutting project (taking on the tracking bugs around CI/etc.); some keywords (//e.g.// hiphop) would want to be a task underneath this project.
* //Language support// would replace the i18n and utf8 keywords

> * Keywords like "community-consensus-needed" - will that become a column in the //Wikimedia Site Requests// project?

Sounds good to me.
**jdforrester** wrote on `2014-05-11 09:31:45 (UTC)`

> Sounds good to me. Ultimately, whoever works on the migration script will request the discrete mapping from Bugzilla products-components to Phabricator projects, with the exact names (or name schema) for each combination. Maybe this is a task on its own?

Yeah, that makes sense; or maybe a "present the final mapping of fields/values/etc. for comment before running the import"?
**qgil** wrote on `2014-05-11 09:20:26 (UTC)`

Sounds good to me. Ultimately, whoever works on the migration script will request the discrete mapping from Bugzilla products-components to Phabricator projects, with the exact names (or name schema) for each combination. Maybe this is a task on its own?
**jdforrester** wrote on `2014-05-11 08:01:31 (UTC)`

> I don't think we should make project hierarchy a blocker of Day 1, though.

Agreed.

I'd suggest instead some careful implicit hierarchy in naming of like things, and where there are duplicates clear them up with a disambiguating term, but otherwise leave things to be named naturally.

For example:
* "MediaWiki" for MediaWiki core
* "Vector" for the MediaWiki skin (not "MediaWiki" > "Skin and page rendering" (!))
* "Vector (extension)" for the MediaWiki extension (not "MediaWiki extensions" > "Vector")
* "Continuous integration" for continuous integration issues (not "Wikimedia" > "Continuous integration")
* "Wikimedia site configuration" for configuration of Wikimedia's hosted sites (not "Wikimedia" > "Site configuration")
* "VisualEditor" for VisualEditor core
* "VisualEditor MediaWiki integration" for VisualEditor's MediaWiki integration (not "VisualEditor" > "MediaWiki")

Thoughts?
**qgil** wrote on `2014-05-10 23:40:05 (UTC)`

> I'd strongly recommend having project hierarchies implemented before giving in to the flatness.

Status of project hierarchies feature upstream:

* ~~[[ https://secure.phabricator.com/T333 | Allow projects to have subprojects ]]~~ (Closed, Wontfix)
* [[ https://secure.phabricator.com/T390 | Implement Project Types ]] (Open since August 2011, Normal)

Looks good and they will eventually implement different types of project hierarchy. I don't think we should make project hierarchy a blocker of Day 1, though.
**parent5446** wrote on `2014-05-10 14:46:10 (UTC)`

As much as naming rules will "work" for this, I'd strongly recommend having project hierarchies implemented before giving in to the flatness.
**qgil** wrote on `2014-05-10 09:17:11 (UTC)`

Since Day 1 is defined by the Bugzilla migration, I think we should focus on the projects that would be automatically generated out of that migration. Once we see the situation after 65k tasks have been migrated, we can decide whether this is good enough for Day 1, or we want to fine tune projects before opening the gates for everybody.

A simple proposal for this first iteration:

* Every "[[ https://bugzilla.wikimedia.org/describecomponents.cgi | Product - Component ]]" combination is a project.
* Every [[ https://bugzilla.wikimedia.org/describekeywords.cgi | keyword ]] is a project.

Project names can be edited without causing any disruption, therefore the members of the "MediaWiki extensions - TorBlock" project can just rename it to "TorBlock".

Good enough for a first decision?
**qgil** wrote on `2014-05-10 09:05:14 (UTC)`

I created [[ http://fab.wmflabs.org/herald/rule/3/ | a Herald rule ]] to add an identified parent project automatically every time a child project is added. Testing this here for the first time right now.

PS: it works.  :)
**aklapper** wrote on `2014-05-03 16:56:06 (UTC)`

Another aspect to think about which I run into this afternoon when giving porting my Bugzilla Greasemonkey triagescripts to Phabricator a shot: //Deployed/planned-to-get-deployed vs. 3rd party extensions//, as a random WMF triager has more interest in making sure that bug reports on extensions which are more relevant to WMF (=deployed on WMF servers) get handled sufficiently. Differentiation isn't currently done in Bugzilla either. I do differentiate though in my (client-side) Greasemonkey script for Bugzilla, by dully comparing component name strings against a hardcoded list (not cool, I know).

As a task can have more than on project in Phabricator, something less cumbersome could be having a general "MediaWiki extension" product and an additional "Deployed on WMF servers" project, but only //if// this could be automatically set via a "if task in Project A, also automatically add Project B" rule, and if this differentiation isn't considered visual overkill making the "Projects" field too noisy. Don't know yet either.
**qgil** wrote on `2014-04-18 17:26:18 (UTC)`

I don't think it is messy at all. It is just different of the (inflexible and problematic) hierarchy of products and components in Bugzilla.

We have well defined items out there: products usually tied to code repositories (VisualEditor, Flow, PyWikiBot...), Wikimedia projects (en.wiki, Commons...), Bugzilla keywords (i18n, design, shell...), and we have the current Bugzilla taxonomy, of course.

We could start with this, and see what happens. Tasks filed without a project specified might show lazy users... and might show also gaps in our current taxonomy. And, as said, users will create also projects, which is another way to provide feedback.

If we agree on the basic idea, we can start thinking on the specific case of the Bugzilla migration.
**qgil** wrote on `2014-04-18 17:10:08 (UTC)`

◀ Merged tasks: T54.
**aklapper** wrote on `2014-04-18 08:39:30 (UTC)`

Git repositories, useful Bugzilla keywords (assuming we use keywords instead of dependencies to express the relation of a task to a certain area), and Bugzilla components when one repository is big/complex enough that it needs subareas for developers to find stuff that they work on. Sounds a bit messy, I know...
**qgil** wrote on `2014-04-17 21:45:05 (UTC)`

In practice this means that we would create the initial list of projects based on... Bugzilla components? Git repositories?
**qgil** wrote on `2014-04-17 19:01:35 (UTC)`

Also relevant: T54#9
**aklapper** wrote on `2014-04-10 21:15:27 (UTC)`

AFAIK there's no separate keyword concept in Phabricator, so if we don't want code changes, keywords would become projects (as tasks can have more than one project). In a kind of way that's even more consistent, as current Bugzilla keywords like "accessibility", "i18n" or "easy" could be considered projects across projects too, and Phabricator's Advanced Query allows AND and OR queries for the Projects field. 

I expect a few people to complain about missing free-form tagging (in Bugzilla: globally visible "Status Whiteboard" and private "Tags" field) though. Translating this functionality to Phabricator terminology, I'd probably call it "private projects" if a user could define her/his own projects only visible to her/him in the project field, e.g. via a prefix being the username in Phabricator so they'd be easy to find via the autocomplete (type "aklapper", find "aklapper-moreinfo" and others and have these items only be available and visible to the user "aklapper" in the projects field).
Damn, I didn't plan to propose an implementation, but I guess I just did.
Which features would Trello users really miss? If you are not sure whether feature X is supported, under development, roadmapped... just ask. Let's create new subtasks for features considered blockers.
@spage 

I think porting trello checklists into this type of checklist is acceptable for a migration, but it is definitely something that people will miss ( actual interactive checklists)
>>! In T21#305, @connorshea wrote on `2014-04-22 01:43:08 (UTC)`
> 
> As far as I can tell, there's no checklist functionality in Phabricator. There are numbered lists, but that isn't particularly convenient in comparison to the checklist functionality of Trello.

If you make the items subtasks, then Phabricator tracks them in **Blocked by**.

If you want an internal checklist, [[ https://secure.phabricator.com/book/phabricator/article/remarkup/ | Phabricator's "Remarkup"]] turns `[]` and `[x]` at the start of a line into a checklist:
[x] buy eggs
[] scramble eggs

The task's "card" in the Phabricator workboard doesn't show an indicator there's a checklist or a "2/6" completion count next to it, and the single task view doesn't show a "33%" progress bar under the checklist. The latter I think is simply client-side JavaScript. I don't find any of these indicators particularly useful, but T1141 covers them.
>>! In T21#305, @connorshea wrote on `2014-04-22 01:43:08 (UTC)`
> 
> As far as I can tell, there's no checklist functionality in Phabricator. There are numbered lists, but that isn't particularly convenient in comparison to the checklist functionality of Trello.

If you make the items subtasks, then Phabricator tracks them in **Blocked by**.

If you want an internal checklist, [[ https://secure.phabricator.com/book/phabricator/article/remarkup/ | Phabricator's "Remarkup"]] turns `[]` and `[x]` at the start of a line into a checklist:
[x] buy eggs
[] scramble eggs

The task's "card" in the Phabricator workboard doesn't show an indicator there's a checklist or a "2/6" completion count next to it, and the single task view doesn't show a "33%" progress bar under the checklist. The latter I think is simply client-side JavaScript. I don't find any of these indicators particularly useful.
//importing issue status//
**qgil** wrote on `2014-04-30 23:49:39 (UTC)`

The current list of subtasks seems to be accurate. No blockers have been identified. Some missing features would make our life easier and nicer, but the integration with bug reporting and code review would pay off.

If there are relevant Trello features not listed here, please add them as subtasks.

Resolving this task. Your attention is welcome especially in the subtasks above, {T238}, and {T61}.
**qgil** wrote on `2014-04-28 06:15:27 (UTC)`

After reading all the current a previous feedback related to the RfQ, including [[ https://blog.wikimedia.org/2014/04/15/agile-and-trello-the-planning-cycle/ | Tomasz's recent blog post ]], I cannot find any blocker due to Trello features missing in Phabricator. Trello does perform better in its territory, but I couldn't find anything that would outweigh the benefits of moving to one single open source tool hosted in Wikimedia servers and integrated with bug reporting and software development. The missing features reported could be contributed locally and/or upstream, if we would really need them.

Do you agree with this? If you see any Trello related blocker, please highlight it.
**mattflaschen** wrote on `2014-04-24 21:18:33 (UTC)`

> Is this provided by the mobile app or the web? In Phabricator you can check your notifications in mobile, but you have to click the "flame" button (or your mailbox) to find out. Which minimum improvement would you welcome in this direction?

"Push notifications" means there is no need to check.  I don't use Trello notifications (though I know other people do).  However, the general idea of push notifications is that the notification is sent directly to your phone, and it typically buzzes or beeps, similar to if you received a text (of course, this depends on your phone configuration).  Then, you check a notification list on your phone.  So there is no need to keep opening the app or mobile web site until you get notified.

> The ability to develop a product roadmap (as opposed to just a task list/project management tool) using a board.

This might be doable by just having a separate workboard for the roadmap.

> Easy customization. The labels/task columns/themes/ etc. are so easy to change at a whim.

Phabricator does let you change the task columns freely (and per-workboard), albeit a different UI from Trello.
**kevinator** wrote on `2014-04-22 15:31:49 (UTC)`

I logged a bug (er task) because I believe task titles should not get truncated in the Workboard View.  Trello wraps titles and makes its cards taller to accommodate for long titles.  
http://fab.wmflabs.org/T195
**connorshea** wrote on `2014-04-22 01:43:08 (UTC)`

As far as I can tell, there's no checklist functionality in Phabricator. There are numbered lists, but that isn't particularly convenient in comparison to the checklist functionality of Trello.
**swalling** wrote on `2014-04-11 00:42:53 (UTC)`

Here's a list off the top of my head:

- Great **mobile** support. Trello gives me push notifications for a board/card I am following. The mobile website + email for Phabricator is a workable but not perfect replacement. 
- The **ability to develop a product roadmap** (as opposed to just a task list/project management tool) using a board. Ultimately this is a "nice to have" feature and we can easily switch to using another tool like MediaWiki. 
- **Easy customization**. The labels/task columns/themes/ etc. are so easy to change at a whim. It really support ongoing refinement of a team's project management toolkit, in an agile fashion. 
- **Team independence and control** over task management styles. Each team also has a high degree of independence, since settings can be different across boards. Once we all move to Phabricator there is more interdependence between project management styles across teams. 
- **Markdown** Phrabricator has some weird mix of Markdown and MediaWiki-like syntax which we will all have to learn. Trello just formats with Markdown. 
- **A pretty interface** Trello has a nice clean friendly UI. Enhancements like turning image attachments in to covers for tasks, setting stickers, emoji, and more are all features that make a task management system more fun and easy. We //really need// to continue to support memes and other fun interface elements of Phabricator to achieve parity here. Turning on serious business mode is not fun!

To expand, here's a list of **things I //won't// miss** about Trello:

- No dependencies. You can only manually list dependencies in Trello.
- Not easy for community members to use. You have to login to a third party site to use it, and it clearly is not a Wikimedia-run tool, which scares community/volunteer participants away. 
- Paying for Business Class license. This costs a (small) fee for the WMF.
**swalling** wrote on `2014-04-11 00:12:19 (UTC)`

@kevinator have you seen the board view of Phabricator task lists? We have customizable boards like that now, such as [[ http://fab.wmflabs.org/project/board/1/ | VisualEditor test board ]]. You can find it via "Workboards" on any project.
**kevinator** wrote on `2014-04-11 00:02:31 (UTC)`

found this on quora:
http://www.quora.com/Phabricator/If-you-had-to-choose-between-Phabricator-or-Pivotal-Tracker-what-would-you-choose-and-why

Here's what I love about trello:

Where cards appear on the screen has meaning (column denotes stage, top is importance).
It's easy to move things around.
**milimetric** wrote on `2014-04-09 00:01:51 (UTC)`

  - Real-time collaborative updating (it's an amazing way to task an issue without copying the breakdown work back and forth between tools)
Paste the following table (or any table from a non-Mediawiki source) into VE. While in edit mode, it will look fairly normal, with borders and a grey background for header cells (due to VE's own style rules). But after the page is saved, it will appear in read mode without any borders or background.

| Animal | Ferocity | Cuddliness
| ------- | ---------- | -------------
| Bunny | 0 | 9
| Cat | 4 | 10
| Tiger | 10 | ? 
 
{F25893} 

This is because pasted tables do not get `class="wikitable"` which provides the normal table styling.
Change 265812 merged by jenkins-bot:
Follow-up I9714cf3: Add tests for wikitable paste

[[https://gerrit.wikimedia.org/r/265812]]
Change 265812 had a related patch set uploaded (by Esanders):
Follow-up I9714cf3: Add tests for wikitable paste

[[https://gerrit.wikimedia.org/r/265812]]
Change 265785 merged by jenkins-bot:
MWTableNode: Apply wikitable class to pasted tables

[[https://gerrit.wikimedia.org/r/265785]]
Change 265785 had a related patch set uploaded (by Esanders):
MWTableNode: Apply wikitable class to pasted tables

[[https://gerrit.wikimedia.org/r/265785]]
I just got bit by this while helping some folks copy over existing information from a Word document. 

Perhaps a solution would be to allow tables to have a modal like Media and Templates where one could click to bring up a window to make configuration changes to the table? One option could be to apply styles - directly by class name or perhaps language indicating "with borders" or some such. Less ambiguity in the language is better for editors unfamiliar with language such as "class=wikitable" but also understandably more difficult to implement consistently.

Or, conversely (and I can't believe I'm taking inspiration from Microsoft Word) upon paste there is a modal to ask editors 'match default style' or "keep existing style"?

Tables created in VE-MW do get class="wikitable" applied by default, correct?
Question: Are we //stripping// any table classes these days?
Question: Are we stripping any table classes?
So it sounds like `.wikitable` is, in fact, just one style out of many. So I think task will remain limited to what it says in the title: automatically give pasted tables `class="wikitable"` in VisualEditor-Mediawiki.
>>! In T85577#1379805, @Neil_P._Quinn_WMF wrote:
> In fact, I'd go further and ask why Vector doesn't style all tables like this by default? In the rare cases when people actually want the default style, //that// could be applied using a class. 

fwiw... The use of `.wikitable` is relegated almost exclusively to discussions and help pages on Wikisource at best -- where the last thing we want is a table that renders //nothing// like the ones found in works we're transcribing.

Go ahead and make it the default for VE but please provide a way to override/usurp that or it will just wind up as another never-used dialog in our case.
>>! In T85577#1398663, @Izno wrote:
>>>! In T85577#1379898, @Jdforrester-WMF wrote:
>> It's important to note that we only want this to be the case in VE-MW, not VE-core. :-)
> 
> Last I checked .wikitable ships in core. Am I crazy, or is there some other reason why not?

You're not crazy, it's just that the naming is confusing :). "VE-core" (VisualEditor core) is a rich text editor independent of MediaWiki. "VE-MW" (VisualEditor MediaWiki) is what everyone knows as **the** VisualEditor, the extension to MediaWiki. We want this behavior in VE-MW, but not VE core.


>>>! In T85577#1380307, @Neil_P._Quinn_WMF wrote:
>>>In fact, I'd go further and ask why Vector doesn't style all tables like this by default? 
>> 
>> To answer my own question, it's probably that this would break tables used as a poor man's layout tool by Mediawiki editors
> 
> These very rarely, if ever, occur in mainspace on en.wp. Probably rare on the other wikis. Why doesn't someone do the research of getting a dump of mainspace of x or y or z MW wikis and look for tables without the class assigned?

We wish :) https://en.wikipedia.org/wiki/San_Francisco has 39 `table` elements without the `wikitable` class. This includes the infobox, some nested infobox bits which have their own tables, all the navboxes, all the maintenance templates, assorted templates which generate infobox-like or thumbnail-like structures, and some other bits and pieces.
>>! In T85577#1379898, @Jdforrester-WMF wrote:
> It's important to note that we only want this to be the case in VE-MW, not VE-core. :-)

Last I checked .wikitable ships in core. Am I crazy, or is there some other reason why not?

>>! In T85577#1380307, @Neil_P._Quinn_WMF wrote:
>>In fact, I'd go further and ask why Vector doesn't style all tables like this by default? 
> 
> To answer my own question, it's probably that this would break tables used as a poor man's layout tool by Mediawiki editors

These very rarely, if ever, occur in mainspace on en.wp. Probably rare on the other wikis. Why doesn't someone do the research of getting a dump of mainspace of x or y or z MW wikis and look for tables without the class assigned?
I've asked at https://en.wikipedia.org/wiki/Help_talk:Table#Where_is_class.3Dwikitable_not_used.3F
>In fact, I'd go further and ask why Vector doesn't style all tables like this by default? 

To answer my own question, it's probably that this would break tables used as a poor man's layout tool by Mediawiki editors
It's important to note that we only want this to be the case in VE-MW, not VE-core. :-)
I agree with @Quiddity. From the user's perspective, `wikitable` styling //is// how Mediawiki tables look. We should definitely apply `class="wikitable"` automatically. 

In fact, I'd go further and ask why Vector doesn't style all tables like this by default? In the rare cases when people actually want the default style, //that// could be applied using a class.
>>! In T85577#1105146, @Catrope wrote:
> This is "correct" behavior: tables in MW read mode do not have borders unless `class="wikitable"` is explicitly set. Perhaps pasted tables should automatically get `class="wikitable"`, like newly created tables do?

I believe that would be good. All tables I've ever seen in articles use this (or more complex) styling, and it's used almost everywhere in https://www.mediawiki.org/wiki/Help:Tables
This is "correct" behavior: tables in MW read mode do not have borders unless `class="wikitable"` is explicitly set. Perhaps pasted tables should automatically get `class="wikitable"`, like newly created tables do?
Seen as both anon and while logged in: 

Edit any page at http://en.wikipedia.beta.wmflabs.org

Use insert menu to insert almost anything: I had the same experience with Formula, Table, and Media. 

Save the page after inserting the element. 

After save, click the wikitext edit link, whether logged in or anonymous.  Nothing happens. 

I see no javascript errors when clicking the wikitext edit, but I do see a warning on saving the page in VE, but I'm not sure it's relevant: 

 load.php:61
"Invalid _currentGuiderID.  Returning early" load.php:153
console.trace(): load.php:154
mw.log</log.warn() load.php:154
transition/<()
Checked in betalbs - Edit source works after VE Save.
Change 181679 merged by jenkins-bot:
Don't break "Edit source" link after VE has closed

[[https://gerrit.wikimedia.org/r/181679]]
I just saw the patch, thanks!
Sounds like this is something I already spotted and uploaded a patch for.
Change 181679 had a related patch set uploaded (by Alex Monk):
Don't break "Edit source" link after VE has closed

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

#patch-for-review
Seen in Firefox and Chrome: 

Edit any page in VE, e.g. http://en.wikipedia.beta.wmflabs.org/wiki/Media_Interface_VisualEditor_Test?veaction=edit

Click Insert/Template

The input text field briefly shows a cursor and a blue bar indicating that the element has focus, but then the focus disappears. User should be able to type directly into text field without needing to click the text field element first, but no longer can. 

This is the failure at https://integration.wikimedia.org/ci/view/BrowserTests/view/-All/job/browsertests-VisualEditor-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/423/testReport/(root)/VisualEditor%20Transclusion/Add_parameter_to_template/
On Firefox 35 Mac, I am editing Wikipedia with the Visual Editor.

By habit, I type "{{cit". This brings a dialog for choosing a template with one field for typing the name. But the "cit" went nowhere. And typing the name does nothing. I have to click in the field first. It would be nice to have the focus in the field. Thus, when we type, by habit, "{{cit", the characters "cit" would go in the field for the template name.

Thank you.
Fixed/checked in beta.
Change 186505 merged by jenkins-bot:
Focus the add template input in the template dialog

[[https://gerrit.wikimedia.org/r/186505]]
Change 186505 had a related patch set uploaded (by Mooeypoo):
Focus the add template input in the template dialog

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

#patch-for-review
Duplicate to https://phabricator.wikimedia.org/T86040
Still happening for me - Mac - betalabs FF, Chrome and Windows7 IE.
This no longer happens
As a logged in user with access to VE in MobileFrontend, bring up a random page and click the pencil icon to edit with VE e.g. http://en.m.wikipedia.beta.wmflabs.org/wiki/0.6922277312143298#/random. 

Note that in the upper left, the back-arrow icon "escape" button appears before the other controls. 

Click the back-arrow escape icon as the page loads, before the page is finished loading. Nothing happens. 

This is the failure at https://integration.wikimedia.org/ci/view/BrowserTests/view/-All/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox-sauce/455/testReport/(root)/VisualEditor%20Mobile/Going_back_from_save_screen_in_VisualEditor/
Verified the fix in en.wiki
Verified the fix in Betalabs and test2
https://gerrit.wikimedia.org/r/#/c/181698/ also needs to get deployed.
I stand corrected, this is now fixed in master. The error above is in wmf13, so we seem to have missed another patch that should be cherry-picked.
`Uncaught TypeError: boolean is not a function in Overlay.extend.hide`

 It's trying to call `this._hasChanged()` , while `this._hasChanged` is a boolean property (set to true). Appears to be related to https://gerrit.wikimedia.org/r/#/c/182113/ , which was cherry-picked to wmf13 but doesn't seem to have solved everything.
```Uncaught TypeError: boolean is not a function in Overlay.extend.hide```. It's trying to call ```this._hasChanged()``` , while ```this._hasChanged``` is a boolean property (set to true). Appears to be related to https://gerrit.wikimedia.org/r/#/c/182113/ , which was cherry-picked to wmf13 but doesn't seem to have solved everything.
When trying to assemble the December's issue of VE multilingual newsletter,
I got this message after [[ https://meta.wikimedia.org/w/index.php?title=VisualEditor%2FNewsletter%2FSandbox&diff=10833033&oldid=10815060  |  this edit ]] (I guess LUA can't actually handle so many languages. If I'm right, this needs to change - 20-something languages aren't "many" at all.)

More info:

Backtrace:
[C]: in function "isRTL"
mw.language.lua:99: in function "isRTL"
mw.language.lua:132: in function "getDir"
Module:Assemble_multilingual_message:46: in function "chunk"
mw.lua:490: ?
Change 343590 merged by jenkins-bot:
[mediawiki/extensions/Scribunto@master] Make the maximum language cache size configurable

[[https://gerrit.wikimedia.org/r/343590]]
Alright @Elitre, I wrote the patch for option 2. https://gerrit.wikimedia.org/r/#/c/343590/
Change 343590 had a related patch set uploaded (by Tim Starling):
[mediawiki/extensions/Scribunto] Make the maximum language cache size configurable

[[https://gerrit.wikimedia.org/r/343590]]
Thanks Tim. What needs to be done here? Do we need to involve someone in particular in this conversation? (I'd really love to be able to deliver the next visual editor newsletter into more than 20 languages.)
IIRC my concern was that there was no eviction from the cache in LocalisationCache::$data, which continues to be the case. If recaching is required, memory usage is about 1.5MB per language, measured locally today. So a limit of 20 implies 30MB, which seems reasonable compared to the Lua memory limit of 50MB.

However, in the WMF production setup, l10n recaching is done in advance, so there's no way recaching would be done in response to a Lua request. It only needs to load the preloaded messages plus the data actually requested (isRTL). Using eval.php on a production server, I measured 145KB per language, which is not so concerning.

So I think the options are:
# Fix LocalisationCache so that it doesn't use unlimited amounts of memory when recaching on demand. Implementation ideas can be found in LocalisationCacheBulkLoad.
# Make MAX_LANG_CACHE_SIZE configurable and set it to say 200 on WMF, leave it at 20 by default. We would probably need to add ScribuntoEngineBase::getOptions() so that Scribunto_LuaLanguageLibrary::register() can get access to the configuration options, which are stored in a protected variable.
# Increase the default MAX_LANG_CACHE_SIZE very modestly, say to 30. This seems like a bad choice since in a month or two someone will reopen the same bug, having found a really important use case for loading 31 languages.

Somewhat off topic, but speaking of lightweight Language object construction, I think having $wgLangObjCacheSize = 10 by default is actually bit rot, I don't think there's any reason for that anymore. Language objects used to hold message arrays, presumably that is the reason for it being so low.
Would it be feasible to raise the cap to, say, 30 languages (although that's a limit the VE newsletter has already crushed at least once) and see how it goes?
This seems to go back to the issue that constructing language objects was slow and memory consuming. The most likely culprit was the preloading a big set of language data and some messages every time a language object was constructed. But I was under the impression that this has been improved enough a long time ago, so maybe the restriction in Lua is not necessary anymore. Or if it turns out there are still issues, Language object construction should be made light-weight.
Yes.
@johan, I gather this is a problem you may also have at some point.
This limit is also why Commons template:Dir (https://commons.wikimedia.org/wiki/Template:Dir ), which is the most transcluded template on Commons (with 32,721,515 pages transcluding it) is not using Lua's "isRTL" function.
Thank you, Anomie! The VE newsletter is quite popular, so I'd really like to get rid of the restriction somehow if possible (/bragging).
>>! In T85461#947512, @Elitre wrote:
> Has this never occurred for Tech News?

No, we've never had so many translations in Tech News.
I note the restriction was added by Tim (see [[https://gerrit.wikimedia.org/r/#/c/36496/|Gerrit change 36496]], which was the original source of [[https://gerrit.wikimedia.org/r/#/c/42050/|Gerrit change 42050]] that was actually merged), so adding him as a CC here.
Thanks, Guillaume. Splitting the page doesn't seem very feasible though - one would have to split recipients' lists as well, and maintaining them... doesn't really look sustainable. Has this never occurred for Tech News?
See also https://www.mediawiki.org/wiki/Extension_talk:Scribunto/Lua_reference_manual#Lua_error:_too_many_language_codes_requested.
The first time I open a link inspector using "[[", Ctrl-K, or the toolbar button, it takes about 5 seconds on my laptop. The subsequent times I do it in the same editing session it opens immediately.
Awesome, thanks.
What happened is that inspector dialogs no longer use isolation, so my
guess was probably correct.
I'm not sure what happened, but I cannot reproduce it on Firefox in the version that is currently deployed in Wikipedia. The link inspector appears immediately.
What do you know, it's indeed faster on Chrome - about 1.5 seconds.
I also vaguely recall this having been reported already, but can't find it. I only found T72467, which was actually an entirely separate issue.
This also happens for me when using Opera 12 (which is somewhat slow compared to more modern browsers). The inspector dialogs are still using isolation (rendered inside an `<iframe>`) and I can reproduce using isolated dialogs in the demo, so that's probably the reason. We're apparently working on killing isolation, though.
(This may be a dupe. I remember reporting it a few weeks ago, but I cannot find it now.)
https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015#Schedule
Monday 26, 10:30am

@Tfinc is the owner of the Mobile theme at the #MWDS15. He is also in charge of organizing the Mobile plenary session, or find someone to organize it.

meeting notes: http://etherpad.wikimedia.org/p/MWDS2015_multi-device_world
>>! In T85151#1068841, @MZMcBride wrote:
> Is there a reason this task is still open?

Let's find out.
Is there a reason this task is still open?
Please update the description with the achievements of this session. Thank you in advance.
Etherpad for today: https://etherpad.wikimedia.org/p/MultiDeviceWorld
Currently you have 45 minutes for this plenary session, and right after you have another 45' slot in the main room for a non-plenary session to be defined. If you want to pre-schedule this second session, we need urgently a task describing it. Or perhaps you want to extend this topic, having a short break after the first 45' leading to a discussion among those staying in the room?
Good discussion today about the plenary and focusing it on the challenges of preparing for a multi device world and what technological blockers/opportunities we have. We've done a quick pass on what we'd like to highlight:

* Desktop <-> Mobile convergence
** Highlight success/challenges of building for both
* Building mobile-relevant applications
** Wikirgrok, infoboxes, etc
* WikiData
** How recent mobile app work can enable new desktop workflows
* Editing/Micro Contributions (Gabriel/JonR)
* What's slowing us down?
** API availability

Which may change as the week goes on. Over the next days we'll prepare a short plenary on this, room for discussion, and the the relevant breakout sessions.

notes: http://etherpad.wikimedia.org/p/DevSummitMain
Personally I want people to come out of the session with the mind to explore the limitations of our existing software when it comes to editing and challenges these issues.

From Mobile Web perspective, summarising what @Kaldari and I have said I can see the tdlr as
* People have less time and need new ways to contribute especially on mobile
* We are exploring new was such as Wikigrok and infoboxes (we could refer to mobile uploads and how that showed a thirst to edit but wasn't the right fit)
* Editing does not have to be editing a big chunk of text e.g. wikitext/VisualEditor full edit page
* Take away: How can we do more of this? How can we break down our current editing model using things like wikidata and Parsoid? Let's spend the summit exploring that.
Here's a quick outline for a presentation on WikiGrok:

Motivation:
* Give readers an easy way to make contributions on mobile
* Help build Wikidata for the semantic future
* Experiment with game-like contribution methods

History:
* Magnus's Wikidata Game
* Consulted Magnus at Wikimania 2014 and built prototypes
* First working versions October 2014 (A and B versions)
* Rewrote backend to be scalable
* Removed dependency on Magnus's Wikidata query API
* Test for logged in users (December 2014)
* Test for anonymous readers (January 2014)
* WikiGrok Roulette (January 2014)

Future:
* Pick an interface version
* Push data to WikiGrok
* Add new campaigns
* Use to verify existing data or data from other databases
* New Wikidata query engine for asking better questions
* Desktop version?
* More gamification?
Thoughts so far:
The goal of the native Mobile Apps is to bring the contents of Wikipedia as close as possible to the user's fingertips.  This means:
1) Integrating more tightly with the OS on the user's device (notifications, widgets, location-based things, etc). This would require things like server-side APIs/infrastructure for push notifications.
2) Presenting content in ways that the user "expects" to see, based on other patterns and behaviors in the mobile OS.  In this vein, Wikipedia content has to become more "parceled" into factoids for consumption on mobile. (Thus, an ever-growing dependency on Wikidata)
We've started to tackle some of #2, with our implementation of Lead Images, as well as the Gallery feature (not to mention Wikidata descriptions throughout the app).  
We could begin by demoing our work on lead images, and the associated successes and challenges that came out of it.  We'll show a few articles where the lead image looks excellent and really transforms the first-glance experience of the article. We'll also show some articles where the lead image is "suboptimal", which would lead to a discussion about face detection for proper alignment of the image, a possible microcontribution for the proper cropping/alignment of the image (or indeed which image to use as the lead image), etc.
**Apps! Try all the things!  **

Native apps provide a unique opportunity to showcase Wikipedia media and data, in boundary pushing, even beautiful ways.   

With "lead image styling" we've mixed article title, main image and Wikidata descriptions seamlessly at the top of the article.  

With search results, saved pages, recent and nearby items we've incorporated Wikidata descriptions.  

With native article image galleries, users get instant access to a liquid smooth image browsing interface.  

With nearby we've leveraged location awareness and native performance to guide readers to article geodata coordinates.  

APIs for search, nearby and article data were enhanced to return Wikidata descriptions so we didn't have to make separate requests. Other API clients can now do this as well.      



**Challenges & Opportunities.  ** 

One challenge we encountered with lead image styling was intelligent cropping for constrained lead image presentation. It can be difficult, given widely varying image dimensions, to determine what the "focal area" of an image is so we don't crop through it. Happily, apps can performantly determine certain image focal areas, so we don't crop a notable person's face noticeably in half.   

However, there are edge cases. But we see these challenges as opportunities. If apps could hit a "commons data" endpoint for images, they could report back apps-detected image focal areas, and apps interfaces for users to curate focal area data would be trivial to implement as well. Then any consumer of commons images could easily perform intelligent cropping.
@deskana, we'll have a plenary and several other sessions about SOA at the summit. See T85154 and T86028.

I'm not sure yet whether there will be a dedicated evangelization session, but there should be an evangelizing effect in any case.
>>! In T85151#961318, @Maryana wrote:
> It sounds like these "mobile skeptics" you're alluding to assume that WMF has already formulated some big mobile master plan (and perhaps cynically believe it involves ditching desktop development altogether...?), but the reality is that our mobile teams and projects are still very new/emergent, we're still in the exploratory phase with a lot of our work, and there are still many ideas floating around for the directions mobile could go in the future.

I'm not sure where you get new/emergent from. MobileFrontend is not new. And there was a completely separate mobile site before it and a completely separate mobile site before that, so we're talking about many years of experience here.

A lot of mobile development has come about as the result of either stripping everything away and slowly and painfully re-implementing it (category links at the bottom of the page is a small example of this) or the result of trying to inject features into mobile first as a means of bypassing what would likely be outright rejection, for better or worse, on desktop (Special:UserProfile and the last edit strapline at the top of the page are two examples of this).

So, scare quotes or not, yeah, there needs to be a discussion about what mobile development has looked like and what it should look like going forward. The cold hard truth is that writing an encyclopedia (or a dictionary or a whatever) on the desktop site continues to be a pretty agonizing process. It's basically currently impossible to do serious editing on a mobile device and may remain so indefinitely, again for better or worse. The best we can probably hope for is optimizing micro-contributions, as kaldari says, and reunifying the desktop and mobile experiences, work on which has thankfully finally started.
We should definitely have at least one presentation about microcontributions via Wikidata. This would probably show off WikiGrok and possibly the experimental infobox and description editing. I would really like to have Jon's ForiegnApi code (https://gerrit.wikimedia.org/r/#/c/182134/) implemented as a core mediawiki module before then so that people can hack with it in the break-out sessions (on both desktop and mobile). Other possible things to demo include the experimental lead section styling in alpha and the mobile Media Viewer.
>>! In T85151#961235, @RobLa-WMF wrote:
> I think we need to have a large group alignment conversation about our engineering strategy around mobile, and what the organization as a whole should be doing.  I repeatedly hear skepticism about the fall of desktop and rise of mobile as a reason to drop what we're doing and have everything be about mobile.  It's not so much skepticism about the fact that it's happening (though there is a little misplaced skepticism there), but cynicism about what that fact is being used to justify.
> 
> The temptation on this session would be to "go with what we know", which is lots of presentations and demos.  These will be utterly unconvincing and unengaging to mobile strategy skeptics.  I think it likely needs to be a conversation rather than a presentation in order to win over skeptics, but exactly what this looks like is a bit unclear to me.

It sounds like these "mobile skeptics" you're alluding to assume that WMF has already formulated some big mobile master plan (and perhaps cynically believe it involves ditching desktop development altogether...?), but the reality is that our mobile teams and projects are still very new/emergent, we're still in the exploratory phase with a lot of our work, and there are still many ideas floating around for the directions mobile could go in the future. So I think a "group alignment conversation" is a bit premature. It might be better just to provide a space to talk openly about all these possible future directions (mobile as a service! mobile as the one skin to rule them all! mobile as the shiny new unicorn!, etc.), without necessarily forcing any sort of consensus on the process or making it seem like any of these things are going to happen tomorrow ;)
I think we need to have a large group alignment conversation about our engineering strategy around mobile, and what the organization as a whole should be doing.  I repeatedly hear skepticism about the fall of desktop and rise of mobile as a reason to drop what we're doing and have everything be about mobile.  It's not so much skepticism about the fact that it's happening (though there is a little misplaced skepticism there), but cynicism about what that fact is being used to justify.

The temptation on this session would be to "go with what we know", which is lots of presentations and demos.  These will be utterly unconvincing and unengaging to mobile strategy skeptics.  I think it likely needs to be a conversation rather than a presentation in order to win over skeptics, but exactly what this looks like is a bit unclear to me.
What are we aiming to achieve in this Mobile plenary session? You will have all the Summit attendees in one room, right after the opening. Which are the key messages you want to push? What do you want from them?

>>! In T85151#959834, @Jdlrobson wrote:
> explore other ways to edit that are not via the traditional wikitext model.
> (...)
> I think essentially the role of mobile is to break down the complicated wikitext markup language that we have built over the last 10 years and encourage our projects to dogfood Wikidata more and make wikitext easy for newbies to understand again.

I wonder how this 'role of mobile' you are describing fits with the role of VisualEditor and the Editing plans altogether. CCing JamesF.
Early thoughts:
"Think outside the wikitext"(play on think outside the box) In addition to demoing the obvious Wikigrok, in the plenary I would like to propose demoing the Wikidata infobox editing/lead photos in alpha [1]. Although we currently have no plans to productise this and this is an experimentation project, I think it would be a useful thought exercise to imagine a world where we start breaking down wikitext and reducing our dependency on {{template markup}} and explore other ways to edit that are not via the traditional wikitext model.

I'm not sure what the reaction to this will be. For instance if infoboxes were generated from Wikidata and not within the markup how would our existing community react to that? But I'd hope it might polarise the crowd and lead to some interesting conversations going out of it.

I think essentially the role of mobile is to break down the complicated wikitext markup language that we have built over the last 10 years and encourage our projects to dogfood Wikidata more and make wikitext easy for newbies to understnd again. Microedits are proving successful in mobile and we need to find better ways to support that. @GWicke and I have talked about how Parsoid can help do things such as insert citations in place of 'citation needed' text and I'm hoping we can have a session around Parsoid/Mobile in one of the later sessions to continue this theme.

[1] http://en.m.wikipedia.beta.wmflabs.org/wiki/Albert_Einstein?wikidataid=Q937&mobileaction=alpha
Picking this back up now that were all back. 

Tech leads: @kaldari @Dbrant @Mhurd @jdlrobson

We have a 45min plenary that were going to be creating here. I'd like to have your list of topics by Thur of this week to review and be able to run the by Damon on Friday. Each topic should take up 10-20 if your presenting with someone else or 10-15 if your on your own. Out of these we'll need to think about the potential breakout sessions we brainstormed last month [1] and get them on the MediaWiki Developers Summit Schedule [2] 

No need to create slides at this point (or at all if your demoing), keep them at high level bullet points so that we can validate with Damon and move forward. 

If there are others that want to jump in on the planning of this then please let me know.

[1] - http://etherpad.wikimedia.org/p/Mobile-WMDS
[2] - https://docs.google.com/spreadsheets/d/15pMDR_h84KUTQK7IR95etVJyJBYC5nVxoG9k_9danV0
Picking this back up now that were all back. 

Tech leads: @kaldari @Dbrant @Mhurd @jdlrobson

We have a 45min plenary that were going to be creating here. I'd like to have your list of topics by Thur or this week to review and be able to run the by Damon on Friday. Each topic should take up 10-20 if your presenting with someone else or 10-15 if your on your own. Out of these we'll need to think about the potential breakout sessions we brainstormed last month [1] and get them on the MediaWiki Developers Summit Schedule [2] 

No need to create slides at this point (or at all if your demoing), keep them at high level bullet points so that we can validate with Damon and move forward. 

If there are others that want to jump in on the planning of this then please let me know.

[1] - http://etherpad.wikimedia.org/p/Mobile-WMDS
[2] - https://docs.google.com/spreadsheets/d/15pMDR_h84KUTQK7IR95etVJyJBYC5nVxoG9k_9danV0
Current feeling is to have the tech leads from mobile web @kaldari and apps @dbrant @mhurd present on at least 1 and at most 2 products/features that they've shipped over the last 6 months to highlight what's possible on mobile and what is difficult and/or impossible to do. It would be interesting to have @maryana and @deskana weigh in on those too. I'm going to be eager to paint the narrative of opportunity and highlight where we can do better. Especially along API's, services, etc.

We spent some time earlier this week brainstorming some potential sessions to get us started

http://etherpad.wikimedia.org/p/Mobile-WMDS
{F22740}

This is caused by MobileFrontend setting box-sizing: border-box on every element.
Belay that. now that T86366 is fixed, this is fixed too in master. Thanks!
Yes. We're waiting for the stalled patch in Mobile to be merged.
Is this still a problem?
I'm waiting for a reply here: https://phabricator.wikimedia.org/T86366#1136772
So I tried VE on mobile using the latest MobileFrontend master with "Experimental" (alpha) enabled. It looks to me like it's still getting clipped because of that `height: @icon-size` on `.oo-ui-processDialog-location`?
Change 180775 abandoned by Jdlrobson:
Remove border-box rule from reset.less

Reason:
https://gerrit.wikimedia.org/r/183987 is merged now so removing this from the review backlog. We can always restore it later depending on the outcome of that patch. Thanks for your patience.

[[https://gerrit.wikimedia.org/r/180775]]
Change 183987 merged by jenkins-bot:
Turn off universal box-sizing in alpha

[[https://gerrit.wikimedia.org/r/183987]]
Change 183987 had a related patch set uploaded (by Jdlrobson):
Turn off universal box-sizing in alpha

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

#patch-for-review
I think my fix is the only sensible way to fix the bug. I'm happy with the patch in its current state, but ideally I'd like someone from mobile to give it a test.
@Jdlrobson, @Esanders: What's the status on this? If Ed's change isn't going to be merged, we should at least fix this specific bug.
Change 180775 had a related patch set uploaded (by Esanders):
Remove border-box rule from reset.less

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

#patch-for-review
Every element? So... Fix MobileFrontend?
The output of the embedded `user.tokens` module changes on every request. I'm not entirely sure whether this was on purpose.

Traced it back to https://github.com/wikimedia/mediawiki/commit/b1e4006b44
{b1e4006b44}

This is a bit of a problem since we minify this module, and by default all minifications are cached at a key that is the hash of the unminified contents. We should implement a way to bypass the minification cache.

As such, we're creating a new cache key and populating it on every page view for every logged in user. And that key is never used again.

Example from localhost:

```
<script>...mw.loader.implement("user.tokens",function($,jQuery){mw.user.tokens.set({"editToken":"5da7f8da8cc2c12b40e63510d3b83f3754937d96+\\","patrolToken":"bc1e366f8f7806ed27d067667cdeebe554937d96+\\","watchToken":"c52e9fcc036b315fe8ba3e0135cb928d54937d96+\\"});},{},{},{});
/* cache key: alphawiki:resourceloader:filter:minify-js:7:aed9432283c8152b3eaff1761844e771 */
```
With the cache issues resolved, this is no longer a performance problem.

The constant regeneration isn't actually a problem since they are not actually all stored. MediaWiki uses encoding and encryption to restrict internal tokens with a timestamp salt.

> 6fa4893928 — resourceloader: Don't cache minification of user.tokens
> https://gerrit.wikimedia.org/r/210845
Here's a graph showing a successful drop in RL-minification cache lookups after deploying [I6016e4b01e44](https://gerrit.wikimedia.org/r/#/q/I6016e4b01e44,n,z).

Labels added to match relevant events from the [Server Admin Log](https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&oldid=161613).
{F173780}

Source: https://graphite.wikimedia.org/render?from=-4weeks&until=now&width=900&target=MediaWiki.rl-minify-js-cache-misses.count
>>! In T84960#1284121, @Anomie wrote:
>>>! In T84960#1284083, @Krinkle wrote:
>> I understand that. My point is that it seems useless to embed tokens in the html that client-side JavaScript (from core, extensions or gadgets) cannot reliably use because by design it will always expire after a few minutes.
> 
> Except that's not true. I see nothing in MediaWiki core or WMF-deployed extensions that uses the $maxage parameter for User::matchEditToken() except the ApiCheckTokens module. Maybe Restbase is doing it, but nothing currently in PHP is considering tokens expired any sooner than the end of the session.

I'm guessing VE is submitting to restbase, and restbase is using ApiCheckTokens to check the token. I've lost track of who did that integration (Roan? Gwicke?), but I'm guessing that call needs to fix the maxtokenage param?
>>! In T84960#1284083, @Krinkle wrote:
> I understand that. My point is that it seems useless to embed tokens in the html that client-side JavaScript (from core, extensions or gadgets) cannot reliably use because by design it will always expire after a few minutes.

Except that's not true. I see nothing in MediaWiki core or WMF-deployed extensions that uses the $maxage parameter for User::matchEditToken() except the ApiCheckTokens module. Maybe Restbase is doing it, but nothing currently in PHP is considering tokens expired any sooner than the end of the session.
>>! In T84960#950866, @Anomie wrote:
> The point isn't to make the tokens last **longer** than the session. [...] You won't get a 5-minute token and be able to extend it indefinitely by re-requesting it, or get a 5-minute token but then requesting it again after 4 minutes gives you the same token that will expire in only 1 minute, or [..]

I understand that. My point is that it seems useless to embed tokens in the html that client-side JavaScript (from core, extensions or gadgets) cannot reliably use because by design it will always expire after a few minutes. Similarly it seems useless that VisualEditor and other uses of tokens almost always have to make two or three round trips just to make a write action. Right now its three. 1) Failed write action for token expired, 2) get new token, 3) Re-try write again. Now only does it make two more http requests then desired, it also submits a potentially large amount of data multiple times.

Two facts:

* In the past we made the decision to embed the user.tokens module in the page because we saw performance problems with the client-side having to request a token for write actions by JavaScript (for e.g. watch star click, or VE edit save).
* In the past we made the observation that saving content with VisualEditor is a performance bottle neck, that we worked hard to cut down. Due to this token expiration problem, we basically nulled that effort by now having to submit everything twice.

As such, I would recommend strongly that we figure out a feasible way to allow MediaWiki frontend to perform write actions with the API without needing to fetch a separate token over HTTP. From this perspective, this change was a significant regression as both of these two expectations are no longer met by the system.
I have no idea what distinction you're making between "client-side" tokens and other tokens. All tokens are sent from the server to the client via a channel that CSRF attackers shouldn't have access to, and then sent from the client back to the server to detect CSRF.

The point isn't to make the tokens last **longer** than the session. That won't happen anyway, if the session is lost then all the tokens go away too just as they have always done. The point is to make it possible for tokens to expire **before** the session does to reduce the window of vulnerability if an attacker somehow manages to compromise a single token, with a predictable lifetime after generation for each token. You won't get a 5-minute token and be able to extend it indefinitely by re-requesting it, or get a 5-minute token but then requesting it again after 4 minutes gives you the same token that will expire in only 1 minute, or get a 5-minute token but then it expires early because some other code requests another instance of the same token, and you won't be able to flood the session with hundreds of tokens waiting to expire. The constantly-changing nature of the tokens also protects against attacks such as BREACH which depend on multiple requests to reveal individual bits or bytes of a constant token.


Now, if the caching situation really can't be worked around by requesting the tokens from the API as needed, we might be able to make User::getEditTokenAtTimestamp() public and use that to generate a token with a constant distant-past timestamp for your JS. Uses of the token that don't specify a maximum age will accept such a token as long as the session is valid, while uses that do will still treat them as expired. But I'd wait for Chris to look that plan over before spending a lot of time on it.
>>! In T84960#936308, @Anomie wrote:
> Why is this bug marked as private? I'm not seeing anything obviously sensitive here.

I filed it under security because the varying tokens, while sensible in general, wasn't necessarily applied on purpose for API requests from the web interface. There also seems potential abuse against the minification cache. Or at the very least a performance/scale hazard for sites without LRU in their cache system. MediaWiki's the default DB cache, for instance, would get blown up by this (my localhost install did).

>>! In T84960#936308, @Anomie wrote:
> Or the tokens could just be fetched from the API when they're needed instead of being served with every request.

That would require fair amount of token fetching from the client-side for AJAX actions originating from core modules (e.g. watch), as well as gadgets and extensions.

I'd like to better understand why tokens are time-limited. I assume it has to do with reducing impact of compromise. However does that apply to client-side tokens? The client is able to fetch tokens whenever using its session cookie (which doesn't mutate on every request). Sessions do expire, however. And having tokens last longer than the session seems odd. Perhaps we can associate them with a session and only give clients new tokens once per session? If I recall correctly, that was the previous behaviour as well for CSRF tokens used in HTML (e.g. for EditPage). Or was there a problem with that?
Why is this bug marked as private? I'm not seeing anything obviously sensitive here.

> I'm not entirely sure whether this was on purpose.

The fact that tokens change based on the time they're generated is necessary behavior of the time-limiting: the timestamp must be included (in "plain" text) in the token so it can be checked, and it must be included in the hash so it can't be faked.

> We should implement a way to bypass the minification cache.

Or the tokens could just be fetched from the API when they're needed instead of being served with every request.
Lots of things to do here, but broadly they break down into six categories:

[ ] Functionality – mostly done
[ ] Performance – main focus area left
[ ] User experience – the current integration is a bit lacking, but otherwise this is not far off
[ ] Language support – still a lot of work for IME support here
[ ] Browser support – mostly done
[ ] Major bugs – not many of these left (he says…)
In betalabs: 

1. On a page in VE open Find/Replace - not typing anything in it, just open - a cursor will be in the Find field.
1. Open an existing template on the page for editing.  
2. Place a cursor in the first field of the transclusion box and click Tab to navigate to the next field.

The cursor will be placed into Replace field; clicking Tab one more time brings the cursor back into Transclusion box. 

The same issue is with Citation.
Or maybe listen for events to make sure things focus in the order I wanted, or something
So we could work out the current highest tabindex in the page and then add it to all our tabindexes in the template dialog. Which is horrible.

Or I wonder if we should really just have the info button next to the parameter name and the remove button immediately following the value field, or something. Then the actual order of the elements might be logical and we could remove the tabindexes.
The find and replace dialog also sets tabindexes... Guess the transclusion dialog is setting the same indexes.
In our quest to convert the whole cluster to trusty and HHVM, we've got to the imagescalers.

From what I can see from puppet/the current image scalers is that we have the following packages custom-built at the moment:

  - ffmpeg2theora (disabled libav multithreading)
  - librsvg (external resources loading protection)
  - libvips31 (backport)
  - libvpx1 (backport)

We also need to evaluate the performance of HHVM under the peculiar imagescalers load, which is probably going to be non-optimal.

Finally, testing should be very accurate to assess any rendering differences on trusty vs precise.
Just for cross-reference, a regression was found with rsvg - svgs > 10 MB (there's about 9000 such files) don't render. We'd need to upgrade to a later version of rsvg to fix, see T111815
Change 227967 merged by Giuseppe Lavagetto:
imagescalers: convert the last two servers to HAT

[[https://gerrit.wikimedia.org/r/227967]]
Change 227967 had a related patch set uploaded (by Giuseppe Lavagetto):
imagescalers: convert the last two servers to HAT

[[https://gerrit.wikimedia.org/r/227967]]
Change 227676 merged by jenkins-bot:
Add Content-Length header to thumb.php redirects

[[https://gerrit.wikimedia.org/r/227676]]
Change 227733 merged by jenkins-bot:
Add Content-Length header to thumb.php redirects

[[https://gerrit.wikimedia.org/r/227733]]
Change 227732 merged by jenkins-bot:
Add Content-Length header to thumb.php redirects

[[https://gerrit.wikimedia.org/r/227732]]
Change 227733 had a related patch set uploaded (by BryanDavis):
Add Content-Length header to thumb.php redirects

[[https://gerrit.wikimedia.org/r/227733]]
Change 227732 had a related patch set uploaded (by BryanDavis):
Add Content-Length header to thumb.php redirects

[[https://gerrit.wikimedia.org/r/227732]]
Change 227676 had a related patch set uploaded (by Giuseppe Lavagetto):
Add Content-Length header to thumb.php redirects

[[https://gerrit.wikimedia.org/r/227676]]
Change 227160 merged by Ori.livneh:
Re-introduce ProxyPass rule for thumb_handler.php, with corrected docroots

[[https://gerrit.wikimedia.org/r/227160]]
Change 227160 had a related patch set uploaded (by Ori.livneh):
Re-introduce ProxyPass rule for thumb_handler.php, with corrected docroots

[[https://gerrit.wikimedia.org/r/227160]]
Change 226738 merged by Ori.livneh:
Follow-up for Ie17cb06: add thumb_handler.php ProxyPass rule to all vhosts

[[https://gerrit.wikimedia.org/r/226738]]
Change 226738 had a related patch set uploaded (by Ori.livneh):
Follow-up for Ie17cb06: add thumb_handler.php ProxyPass rule to all vhosts

[[https://gerrit.wikimedia.org/r/226738]]
Change 226658 merged by Ori.livneh:
Add ProxyPass rule for thumb_handler.php

[[https://gerrit.wikimedia.org/r/226658]]
Change 226658 had a related patch set uploaded (by Ori.livneh):
Add ProxyPass rule for thumb_handler.php

[[https://gerrit.wikimedia.org/r/226658]]
>>! In T84842#1473663, @Krenair wrote:
> ```2015-07-23 00:06:38 mw1153 commonswiki exception ERROR: [d68c4bb1] /w/thumb_handler.php/2/2e/Mirage_III_A_01_Mus%0Aee_du_Bourget_P1020118.JPG/424px-%0AMirage_III_A_01_Musee_du_Bourget_P1020118.JPG   MWException from line 171 of /srv/mediawiki/php-1.26wmf15/includes/objectcache/ObjectCache.php: CACHE_ACCEL requested but no suitable object cache is present. You may want to install APC. {"exception":"[object] (MWException(code: 0): CACHE_ACCEL requested but no suitable object cache is present. You may want to install APC. at /srv/mediawiki/php-1.26wmf15/includes/objectcache/ObjectCache.php:171)"}```
> Seen from mw115[2-8]

See {T106743}
>>! In T84842#1473663, @Krenair wrote:
> ```2015-07-23 00:06:38 mw1153 commonswiki exception ERROR: [d68c4bb1] /w/thumb_handler.php/2/2e/Mirage_III_A_01_Mus%0Aee_du_Bourget_P1020118.JPG/424px-%0AMirage_III_A_01_Musee_du_Bourget_P1020118.JPG   MWException from line 171 of /srv/mediawiki/php-1.26wmf15/includes/objectcache/ObjectCache.php: CACHE_ACCEL requested but no suitable object cache is present. You may want to install APC. {"exception":"[object] (MWException(code: 0): CACHE_ACCEL requested but no suitable object cache is present. You may want to install APC. at /srv/mediawiki/php-1.26wmf15/includes/objectcache/ObjectCache.php:171)"}```
> Seen from mw115[2-8]

Ummm, why/how do we have HHVM boxes without APC enabled?
```2015-07-23 00:06:38 mw1153 commonswiki exception ERROR: [d68c4bb1] /w/thumb_handler.php/2/2e/Mirage_III_A_01_Mus%0Aee_du_Bourget_P1020118.JPG/424px-%0AMirage_III_A_01_Musee_du_Bourget_P1020118.JPG   MWException from line 171 of /srv/mediawiki/php-1.26wmf15/includes/objectcache/ObjectCache.php: CACHE_ACCEL requested but no suitable object cache is present. You may want to install APC. {"exception":"[object] (MWException(code: 0): CACHE_ACCEL requested but no suitable object cache is present. You may want to install APC. at /srv/mediawiki/php-1.26wmf15/includes/objectcache/ObjectCache.php:171)"}```
Seen from mw115[2-8]
New imagescalers fun found today: 

an high level of 5xx were going on today, so I intercepted a few urls that were returning a 503 - for example, I requested

https://upload.wikimedia.org/wikipedia/commons/thumb/0/01/Casquette-IMG_0922.jpg/600px-Casquette-IMG_0922.jpg

from my browser and got a 503:

```
...
If you report this error to the Wikimedia System Administrators, please include the details below.
Request: GET http://upload.wikimedia.org/wikipedia/commons/thumb/0/01/Casquette-IMG_0922.jpg/600px-Casquette-IMG_0922.jpg, from 10.64.32.81 via cp1048 cp1048 ([10.64.32.100]:3128), Varnish XID 3696382267
Forwarded for: 79.58.168.196, 10.64.32.81, 10.64.32.81
Error: 503, Service Unavailable at Wed, 22 Jul 2015 16:21:18 GMT
```

while if I do a plain curl I get the correct behaviour, a 302:

```
curl -I https://upload.wikimedia.org/wikipedia/commons/thumb/0/01/Casquette-IMG_0922.jpg/600px-Casquette-IMG_0922.jpg
HTTP/1.1 302 Found
Server: nginx/1.9.3
Date: Wed, 22 Jul 2015 16:30:29 GMT
Content-Type: text/html
Content-Length: 0
Connection: keep-alive
X-Content-Type-Options: nosniff
Expires: Thu, 23 Jul 2015 04:22:53 GMT
Vary: X-Forwarded-Proto
Location: https://upload.wikimedia.org/wikipedia/commons/thumb/9/99/Casquette_d%27administrateur_colonial_-IMG_0922.jpg/600px-Casquette_d%27administrateur_colonial_-IMG_0922.jpg
Cache-Control: no-cache
```

So I tought this could have to do with compression. But subsequent requests were successful from the browser as well, so no idea what is going on here - maybe one imagescaler doing something wrong?
>>! In T84842#1466863, @Joe wrote:
> FTR, I am going to depool all remaining Zend imagescaler today to test any outstanding problems with those. If none arise, I'm going to upgrade the last three tomorrow.

Great. Sounds like a good plan. Thanks for pushing forward.
FTR, I am going to depool all remaining Zend imagescaler today to test any outstanding problems with those. If none arise, I'm going to upgrade the last three tomorrow.
Change 225285 merged by Giuseppe Lavagetto:
imagescalers: re-image mw115[6-8] to trusty, HHVM

[[https://gerrit.wikimedia.org/r/225285]]
Change 225285 had a related patch set uploaded (by Giuseppe Lavagetto):
imagescalers: re-image mw115[6-8] to trusty, HHVM

[[https://gerrit.wikimedia.org/r/225285]]
Change 224594 merged by Giuseppe Lavagetto:
imagescalers: reimage mw1154, mw1155 to HAT

[[https://gerrit.wikimedia.org/r/224594]]
Change 224594 had a related patch set uploaded (by Giuseppe Lavagetto):
imagescalers: reimage mw1154, mw1155 to HAT

[[https://gerrit.wikimedia.org/r/224594]]
Change 223331 merged by Giuseppe Lavagetto:
imagescalers: reimage mw1153 with HAT

[[https://gerrit.wikimedia.org/r/223331]]
Change 223331 had a related patch set uploaded (by Giuseppe Lavagetto):
imagescalers: reimage mw1153 with HAT

[[https://gerrit.wikimedia.org/r/223331]]
(codfw imagescalers are all HHVM+Trusty already, so we're just left with mw1153-1160)
For the past several weeks, this task was blocked on the fact that the HHVM renderer (mw1152) would cause 5xx spikes whenever it was pooled. The issue appears to have been a corruption in the cached byte-code for `/w/404.php` which caused Varnish to be unable to parse 404 responses generated by HHVM on mw1152. These responses were transformed by varnish into 503s. Touching the file fixed it.

The remaining task is to re-image the other scalers.
Bah, edit conflicts.
Since the latest test I did after ori found we needed that file was unsuccessful, and I have zero time to work on this at the moment, I'll release this ticket so that somebody else can grab it.

As matanya clearly stated "We've been waiting forever for this".
Change 213228 merged by Ori.livneh:
mediawiki: Touch /etc/wikimedia-image-scaler on image scalers

[[https://gerrit.wikimedia.org/r/213228]]
Change 213228 had a related patch set uploaded (by Ori.livneh):
mediawiki: Touch /etc/wikimedia-image-scaler on image scalers

[[https://gerrit.wikimedia.org/r/213228]]
>>! In T84842#1306421, @greg wrote:
> What ya'll think now? :)

We should probably not schedule this until we resolve the issue Giuseppe spotted in T84842#1265055.
```
greg moved this task to This week: May 4-8 on the Roadmap workboard.
greg moved this task to This week: May 11-15 on the Roadmap workboard.
greg moved this task to May 18-22 on the Roadmap workboard.

```

What ya'll think now? :)
OK, let's schedule to a specific week once we have confidence on the ETA.
>>! In T84842#1175265, @Eloquence wrote:
> @Joe, do we need to push this to next week?

At minimum. Giuseppe ran into segfaults with Tim's output buffer patch and that's blocking the rollout of a new package, which the scalers need.
@Joe, do we need to push this to next week?
Change 196173 merged by Giuseppe Lavagetto:
mediawiki: install fonts metric-compatible with Calibri and Cambria

[[https://gerrit.wikimedia.org/r/196173]]
This was scheduled for March, is this happening next week or should we bump it to April?
The HHVM upstream bug tracked in {T91468} should block this rollout. See analysis in T89918#1052318 for full gory details, but the TL;DR is that HHVM's async i/o and fcgi bridge interact in such a way that a slow consumer and a fast producer can OOM the HHVM process resulting in a 503 from Apache.
>>! In T84842#1112319, @Joe wrote:
> @brion problem confirmed, but this would be relevant for the videoscalers, right?

ah good if video scalers are a separate config then please regard my comment as belonging to them and ignore it here :D
ok, then it was probably a false positive. I'm a bit in the dark about what is timing out here then, will need to investigate further
What happens with those requests is that the web server queries the image scalers internally to have them scale an image which isn't public yet.

What I don't know yet, and am trying to figure out in that bug, is if any error happens at the image scalers' level, or if it's a timeout happening higher in the chain (in varnish, for example). My main theory is that the image scaler is taking too long to generate the requested thumbnail and *something* times out in the chain, causing a nasty 503 instead of the cleaner error that should happen if the curl request to the image scalers hit the timeout setting.
Special:UploadStash has a known 503 issue happening at the moment: T90599
I re-pooled the HHVM imagescaler and got confirmation that SVG files rendered correctly.

However, I was still seeing a significant amount of 503s, but nothing stood out in any log apart from a few occurrencies of errors in Special:UploadStash, like e.g.
```
http://commons.wikimedia.org/wiki/Special:UploadStash/thumb/13091utfih7k.ab6yzc.1488278.jpg/71px-13091utfih7k.ab6yzc.1488278.jpg
```

but this is just a shot in the dark, as those are probably handled by the general appserver pool. I will have to ask someone with expertise on UploadWizard to confirm how the thumb request is performed in this case.
Change 196186 merged by jenkins-bot:
imagescaling: remove legacy option for HHVM imagescalers

[[https://gerrit.wikimedia.org/r/196186]]
Change 196186 had a related patch set uploaded (by Giuseppe Lavagetto):
imagescaling: remove legacy option for HHVM imagescalers

[[https://gerrit.wikimedia.org/r/196186]]
If the new rsvg version doesn't need a specific option turned on to avoid external resources, then it's just a matter of having a slightly different mediawiki configuration for the hhvm image scaler.

Set wgSVGConverter to 'rsvg-broken' for it instead of the default 'rsvg-secure'.

Relevant code is in:
mediawiki-config/wmf-config/CommonSettings.php
mediawiki-config/wmf-config/InitialiseSettings.php
@Gilles I imagined that - given our svg code now supports the security model in the more modern rsvg versions I guessed it would work automagically. It is not the case, I am still looking at the code to be sure of what's wrong here.
--no-external-files is an option that was coming from our custom patches to librsvg
I had to depool the server, as quite a lot of unexpected errors were spawning.

E.G. when rescaling http://commons.wikimedia.org/w/thumb_handler.php/c/ca/Alarilla_Guadalajara_-_Mapa_municipal.svg/39px-Alarilla_Guadalajara_-_Mapa_municipal.svg.png I got the following error

```
<!DOCTYPE html>
<html><head>
<meta charset="UTF-8" />
<title>Error generating thumbnail</title>
</head>
<body>
<h1>Error generating thumbnail</h1>
<p>
Error creating thumbnail: Unknown option --no-external-files<br />

</p>
<!-- /w/thumb_handler.php/c/ca/Alarilla_Guadalajara_-_Mapa_municipal.svg/39px-Alarilla_Guadalajara_-_Mapa_municipal.svg.png -->
<!-- mw1152 -->

</body>
</html>
```

Probably the imagescaling code needs to be corrected? I'll look at rsvg options later today
@brion problem confirmed, but this would be relevant for the videoscalers, right?
The imagescaler is now into rotation.
Change 196173 had a related patch set uploaded (by Giuseppe Lavagetto):
mediawiki: install fonts metric-compatible with Calibri and Cambria

[[https://gerrit.wikimedia.org/r/196173]]
May you add some additional fonts, e.g. [[https://wiki.debian.org/SubstitutingCalibriAndCambriaFonts|Caladea and Carlito]] for easier SVG rendering?

See also https://commons.wikimedia.org/wiki/File:MediaWiki_SVG_fonts.svg
Announcement made https://commons.wikimedia.org/wiki/Commons:Village_pump#Upgrade_of_image_rendering_servers ( permalink: https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=152736923#Upgrade_of_image_rendering_servers )
@Joe here's a test case for the webm->ogv ffmpeg2theora conversion:

```
wget https://upload.wikimedia.org/wikipedia/commons/c/c8/Sneak_Preview_-_Wikipedia_VisualEditor.webm

ffmpeg2theora \
  --width 640 --height 360 -V 512 -a 1 -H 44100 -c 2 --no-upscaling --keyint 128 --buf-delay 256 \
  -o Sneak_Preview_-_Wikipedia_VisualEditor.360p.ogv \
  Sneak_Preview_-_Wikipedia_VisualEditor.webm
```

Lots of errors about audio format during conversion, then the resulting .ogv is unplayable.
@Bawolff none of the new links you posted presented any issue. I think we can move on and put at least one machine in rotation by thursday 10 AM UTC; are you able to make the announcement on Commons:VP about it?

@brion: if you have a good example I'll test it.
Another thing to test: .ogg / .ogv transcoding output (from .webm or opus source). I've had some troubles with ffmpeg2theora on Trusty (though the note above about multithreading disabled might have resolved that?)
Some other GIF files since that's where we ran into problems (These are from the most popular list, most will be really small cases that don't stress the server, so I expect they will render fine):

* https://upload.wikimedia.org/wikipedia/commons/thumb/2/26/Mug_and_Torus_morph.gif/120px-Mug_and_Torus_morph.gif
* https://upload.wikimedia.org/wikipedia/commons/thumb/8/86/Qxz-ad137.gif/320px-Qxz-ad137.gif
* https://upload.wikimedia.org/wikipedia/commons/thumb/1/19/Second_world_war_europe_animation_small.gif/215px-Second_world_war_europe_animation_small.gif
* https://upload.wikimedia.org/wikipedia/commons/thumb/8/81/ADN_animation.gif/100px-ADN_animation.gif
* https://upload.wikimedia.org/wikipedia/commons/thumb/9/9b/Lang-fr.gif/220px-Lang-fr.gif
Animated gifs have always been memory intensive. File:Cigarette_sales_per_Capita_in_the_United_States%2C_1970_-_2012.gif was already on the edge of what was running out of memory in the old config. I guess the newer image magick uses a bit more memory to push it over the edge.

If a memory limit is set by ulimit (or via a command line option to image magick), image magick will try to trade memory usage for time, which could be a solution to this issue.

For VP9: The default libvpx on trusty should be new enough, but the default libav is too old. Needs at least libav10

-----

Some other things that might possibly be fixed on trusty (Not sure, either way not a regression):

* https://upload.wikimedia.org/wikipedia/commons/thumb/1/18/Zentralbibliothek_Solothurn_S_I_498_Kosciuszko_Inventarium_02.tif/lossy-page1-800px-Zentralbibliothek_Solothurn_S_I_498_Kosciuszko_Inventarium_02.tif.jpg is purple currently. Rumour is that this may be fixed on newer image magick, but I haven't tested.
* 16 bit tiff files don't render on vips. I've heard this is fixed on newer vips, but I'm not sure at what point. example https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Amelia_earhart_received_by_president_coolidge.tif/lossy-page1-464px-Amelia_earhart_received_by_president_coolidge.tif.jpg (This issue is possible to work around on MW side if the upgrade doesn't fix it)
So I'd have to debug the animated gif problem, and after that I guess we can throw the new imagescaler in the ring as soon as this is resolved.
I found no other regressions, and - good news! - https://upload.wikimedia.org/wikipedia/commons/thumb/3/3b/WorldAviation.198409.BackCover.pdf/page1-342px-WorldAviation.198409.BackCover.pdf.jpg gets rendered by the new imagescaler. So does https://upload.wikimedia.org/wikipedia/commons/thumb/7/70/John_Stuart_Mill%2C_Considerations_on_Representative_Government_%281st_ed%2C_1861%29.pdf/page1-382px-John_Stuart_Mill%2C_Considerations_on_Representative_Government_%281st_ed%2C_1861%29.pdf.jpg
the animated gif test throws an error on the HHVM imagescaler:

  <!DOCTYPE html>
  <html><head>
  <meta charset="UTF-8" />
  <title>Error generating thumbnail</title>
  </head>
  <body>
  <h1>Error generating thumbnail</h1>
  <p>
  Error creating thumbnail: /srv/mediawiki/php-1.25wmf19/includes/limit.sh: line 101: 30955 Killed                  /usr/bin/timeout $MW_WALL_CLOCK_LIMIT /bin/bash -c &quot;$1&quot; 3&gt;&amp;-<br />
  <br />
  Error code: 137
  </p>
  <!-- /w/thumb_handler.php/5/5d/Cigarette_sales_per_Capita_in_the_United_States%2C_1970_-_2012.gif/850px-Cigarette_sales_per_Capita_in_the_United_States%2C_1970_-_2012.gif -->
  <!-- mw1152 -->

  </body>
  </html>

I am still unsure of the reason, I'll investigate this further.
Ok, first bad news: 

the VP9 encoding still doesn't work, but it may just need some additional codecs to be installed. At least this is not a regression :)
@Bawolff first of all, thanks for the list of urls to test, this is a great starting point.
Then, I apologize for lagging behind on this, but I have been busy with other priorities after the dev summit, but since this is blocking other tasks, I'll try to get back to this as soon as possible.

I'll plan a migration schedule next week, so that we can also make an announcement.
Ping on this?
The first HAT imagescaler is reimaged, and basic testing shows it's working fine.

I would need suggestions on how/what to test before taking it into rotation.
ffmpeg2theora already includes the patch to disable libav threads in trusty, so we don't have any additional need to repackage things for trusty imagescalers.
Librsvg 2.40.2-1+wm1 is on apt.wikimedia.org and includes the patch at https://git.gnome.org/browse/librsvg/commit/?id=5ba4343bccc7e1765f38f87490b3d6a3a500fde1

I'll look at ffmpeg2theora, then I'll repurpose mw1152 as the test HAT imagescaler
The patch that @PleaseStand referenced cleanly applies on the librsvg package in trusty, so I'll rebuild it using it alone. I don't think we need a repository, the source package upload should be enough.
Thanks for the feedback.

@Bawolff I guess ffmpeg2theora was there because the package lists are shared with the videoscalers.
There's also a second patch to librsvg ([[https://gerrit.wikimedia.org/r/#/c/173639/|80dd6ad665610979]]), which fixes a parsing bug in the library. I think even trusty's version of librsvg is too old to already have the patch, which was only applied upstream last month.
>ffmpeg2theora (disabled libav multithreading)

(Unless I missed something) That's only used in the encoding process (on the video scalars), not during thumbnailing. So I don't think that's needed on image scalars. Additionally, I'm not entirely sure why we have multithreading disabled, but we do use 2 threads (since f1675415) when encoding webm videos with libav (on the video scalars), so the disabling of multithreading for theora videos might not be needed anymore. But I don't know the history behind that, so I may be wrong.
This might be slightly off-topic, but... Video support on commons would be significantly improved with support of VP9 codec (T55863). In order for MediaWiki (as it currently stands) to make the static placeholder thumbnails for VP9 videos, it would need libav10 backported to the image scalars. So if it is possible to backport the newer version of libav while rebuilding the image scalars, that would be really cool.
the newer librsvg supports a different security mechanism that should only load resources in the same directory. Given it seems to me that we're already processing SVG images in a dedicated temporary directory, this should be good enough without patching, but I'd like Tim to comment on this
So, libvps31 and libvpx1 are both at newer versions on trusty and don't need backporting
On a page such as http://en.wikipedia.beta.wmflabs.org/wiki/Media_Interface_VisualEditor_Test?veaction=edit

Click Insert/Media

Note that the default text in the search box is the title of the page. 

Click inside the search box.

Default text should disappear but does not. RETURN also does not remove the default text.

Compare to the Link interface which looks similar but behaves correctly.
Also seen in Chrome as of 23 January
On closer examination, I believe that the default text in the media search box is briefly selected, but the selection disappears. Again, compare to Link which does the same thing correctly.

Seen in Firefox.
CSS via load.php sometimes takes as long as 10  seconds to be returned on my local instance.
If I run
> redis-cli
> monitor

I will notice that the log will considerably slow on lines which look like this:
"GET" "wiki:resourceloader:filter:minify-css:7:ef038bf45ab521177624638cbeb85f3d"

Anyone know why this might be happening?
This hasn't been an issue for a while afaik.

Related issues that contributed to this:
* {T112035}
* {T107377}
* and more..
Removing the #resourceloader tag. I don't see an easy fix for this, and it does not make sense to optimize ResourceLoader for VirtualBox Shared Folders or NFS.
Change 201616 merged by jenkins-bot:
Allow use of cachefilesd to speed up file system operations

[[https://gerrit.wikimedia.org/r/201616]]
Change 201616 restored by BryanDavis:
Use cachefilesd to speed up file system operations

[[https://gerrit.wikimedia.org/r/201616]]
Change 201616 abandoned by Ori.livneh:
Use cachefilesd to speed up file system operations

[[https://gerrit.wikimedia.org/r/201616]]
Change 194217 abandoned by BryanDavis:
Enable stat cache for HHVM fcgi container

Reason:
Makes things worse rather than better unfortunately.

[[https://gerrit.wikimedia.org/r/194217]]
Relevant:
* {7a46e84d69a3c912ba9e3c19c0943dba13026ae3}
* {4ebdd607f5de4fbdf2cfba732452c4df239847c8}
* {061904a913db144b1d81835b37896cec6a7e5e6d}
* {3897868db104b88f70569a22613829031fa64f5c}
Relevant:
* {7a46e84d69a3c912ba9e3c19c0943dba13026ae3}
* {4ebdd607f5de4fbdf2cfba732452c4df239847c8}
* {061904a913db144b1d81835b37896cec6a7e5e6d}
* {3897868db104b88f70569a22613829031fa64f5c}
Change 201616 had a related patch set uploaded (by BryanDavis):
Use cachefilesd to speed up file system operations

[[https://gerrit.wikimedia.org/r/201616]]
>>! In T78733#972401, @Jdlrobson wrote:
> It seems to become an issue as soon as I install multiple wikis

Do we have independent verification of this? It would be significant if true.
>>! In T78733#1130869, @Yurik wrote:
> i wonder if enabling "zend" role (switch back to PHP engine) would have solved it.

I would also like to see if anyone has disabled NFS and seen an ongoing performance improvement.  I realize NFS was supposed to //improve// performance, but IIRC it was originally put in before HHVM, and both VirtualBox and our setup have changed since then.
i wonder if enabling "zend" role (switch back to PHP engine) would have solved it.
I did some debugging with legoktm and less seemed to be the issue. We'd need someone who knows #ResourceLoader inside out. Maybe @Catrope to get to the bottom of this.

I've actually stopped using Vagrant now. It was becoming impractical but the URL I was using was:

http://localhost:8080/w/load.php?debug=false&lang=en&modules=mediawiki.sectionAnchor%7Cmediawiki.ui.button%2Cicon%7Cmobile.pagelist.styles%7Cskins.minerva.beta.images%2Cstyles%7Cskins.minerva.chrome.styles%7Cskins.minerva.content.styles%7Cskins.minerva.drawers.styles%7Cskins.minerva.icons.images%2Cstyles%7Cskins.minerva.tablet.styles&only=styles&skin=minerva&target=mobile&*

I had Flow, MobileFrontend, Apisandbox, Echo, Cite, ConfirmEdit, EventLogging, MultimediaViewer, PageImages roles installed.
@Jdlrobson can you provide the URL of the request that's taking so long? I fear we're all working off the same symptom here (slowness) but not necessarily the same root cause (general NFS performance vs. less compilation, etc.). We need to single in on a particular request that can be consistently profiled. Providing your currently enabled roles would help as well (`vagrant roles list -e`).
Any way forward with this? Any idea of timeline to fix this? Anything I, a frontend engineer can do to help move this along?
Disabling tests made no difference for me @Legoktm
This hook is only run in test mode anyhow so that didn't surprise me.
I think the issue is here is purely lots of RL modules and thus files and thus lookup times.
I'm going to be forced to move off Vagrant next week if this continues, this is very impacting my ability to get things done.
I'm using NFS with a Debian Jessie host, with 3000 MB allocated in .settings.yaml, out of 8 GB on my host.

Performance got a lot worse for me recently.  Talking about it with @bd808, I think the cause of it suddenly getting worse may have been enabling VisualEditor (many JS files could interact badly with any MediaWiki-Vagrant and/or RL stat problems).

I'm also currently using the memcached role (currently with 300 MB, but that's one thing I'm experimenting with).  Before, I was using Redis, but Flow is not as well tested with that.  Just recently before switching to memcached, I got some errors that may or may not have been related to caching.

Finally, I had wgResourceLoaderStorageEnabled set to true (but may experiment with turning that off) and I have:

    $wgCacheEpoch = '20141008025959';
If MF is installed, T91659 could be related.
Enabling HHVM's stat cache is a bust. The implementation in HHVM awesomely uses `inotify` to have the kernel notify it of changes to files on disk. Sadly `inotify` doesn't work on NFS mounts, so HHVM never gets clued in that files are changing.
Magnitudes faster with that patch 12 seconds -> 4 seconds. Still room for improvement though. cc @rmoen @jhernandez who have been having similar issues.
We looked at this for a bit today and may be narrowing in on some parts of the problem. ResouceLoader is doing a lot of file mtime operations. The patch I've posted is one attempt at applying a bandaid to the bleeding patient. I want to dig deeper though and see if there are other settings we can change to make RL happier.
Change 194217 had a related patch set uploaded (by BryanDavis):
Enable stat cache for HHVM fcgi container

[[https://gerrit.wikimedia.org/r/194217]]
yup. My vagrant is a complete mess right now. :-/ Was hoping to get some time during the dev summit to debug but didn't get the chance.
@jdlrobson, have you experienced this same issue since bumping up your VM's memory?
This is resurfacing. It seems to become an issue as soon as I install multiple wikis (I just had a fresh install and installed both wikidata and commons roles)
Still hitting this issue with a new install.
Changed less to 0.4.0.
and then sshing into my vagrant instance and ran `composer update`
Switched back to 0.5.0 and ran `composer update` and the problem seems to have gone. Strange. Will keep investigating and updating this bug report if/when it comes back.
>>! In T78733#937057, @matmarex wrote:
> It upgraded the lessphp library from 0.4.0 to 0.5.0, so I guess they had a performance regression.

Actually https://gerrit.wikimedia.org/r/#/c/174448/ is what upgraded the library, bringing it via composer should have been the same version since Krinkle created a new tag from master.
It upgraded the lessphp library from 0.4.0 to 0.5.0, so I guess they had a performance regression.
@legoktm any idea why this has had just a negative effect on performance for me?
This is the commit where it all went wrong for me
https://gerrit.wikimedia.org/r/#/c/175485/
I can't view T84960 :(
Okay now I'm getting somewhere. If I checkout commit Id0221e9f68786758e10b2f222f5e9170898e320d it only takes 1 second. Going to keep investigating till I find the core change that introduced my woes...
Depending on how recently you mean. The result of some `compileFile` calls used to be cached separately some time ago, now it isn't (only the final CSS is).

Perhaps you have some modules there that are being invalidated (incorrectly) too often?
The cache misses may be due to T84960.
Okay so I debugged this and the source of slowdown seems to be $result = $compiler->compileFile( $fileName ); in compileLessFile

Did something change to do with less recently?

To replicate install MobileFrontend vagrant role and load:
http://localhost:8080/w/load.php?debug=false&lang=en&modules=mediawiki.ui.button%7Cmobile.pagelist.styles%7Cskins.minerva.alpha.styles%7Cskins.minerva.chrome.styles%7Cskins.minerva.content.styles%7Cskins.minerva.content.styles.beta%7Cskins.minerva.drawers.styles%7Cskins.minerva.icons.styles%7Cskins.minerva.tablet.styles%7Cskins.minerva.tablet.styles.beta&only=styles&skin=minerva&target=mobile&forceprofile=1

On my machine this is taking over 16s to load. Can anyone else confirm similar slowdown?
I'm rarely changing the css. I'm seeing lots of rl-minify-css-cache-misses in the redis trace though. Is it possible my caching isn't setup correctly? Will take look at profiling

Reloading and stopping/starting not helping.

@dduval yeh updating LocalSettings.php to support development for MobileFrontend and installing certain pages seems like a good idea.
Also, since it sounds like you're dependent on a fair amount of custom wiki configuration and content/templates for your development, you might want to consider packaging it as a local or published Vagrant role. (Watch @bd808's part of the recent [[ https://www.mediawiki.org/wiki/File:What%27s_new_with_MediaWiki-Vagrant.webm | tech talk ]] for examples; I'm also available to pair on it.)
From what I remember when we were troubleshooting this yesterday, HHVM was tacking the CPU during those same moments which makes me think it's not any sort of IO wait on redis that's hanging things up. I second the profiling and maybe restarting HHVM (or `vagrant reload`) for good measure.
Are you constantly changing your CSS? All the info you've posted looks like RL is either minifying the CSS each time (cache misses), or contacting redis in vagrant is slow.

Have you tried profiling to see what exactly is slow?
This is making it near impossible for me to work now :-(
I really don't want to vagrant destroy as setting up a new wiki instance will take up most of my day.
ve.ce.Surface is a 130k beast (>4000 lines) - more than twice as long as Converter and Transaction, the next largest files. Working on it will kill your mouse wheel and sanity.

We should try and break it up by functionality, e.g.

* Key strokes
* Copy/paste
* Drag/drop
Change 248911 merged by jenkins-bot:
Introduce key down handlers to separate logic from ce surface

[[https://gerrit.wikimedia.org/r/248911]]
https://gerrit.wikimedia.org/r/#/c/248911/
I tried to edit an infobox with the VisualEditor in the German Wikipedia. I changed the website address there.
But when I closed the "infobox editor" all links in the infobox (except of the link I changed) got redlinks.

I think this is only a display error, but anyway I didn't saved the changes I made.
James, did you confirm this?
This feels like a duplicate.
This problem with VisualEditor's performance was reported at MediaWiki.org by User:Leaderboard, who was editing on the English Wikibooks.  The problem is intermittent or at least variable in severity.  It may depend on the size of the page.  It appears to happen at MediaWiki (testing in the sandbox) as well, after about a page's worth of text has been added.  Here's the problem in his own words:

> First , it is too slow to display text which I am typing. It shows it in a slow and slideshow speed. Looks like it's quite slow. And , on Task Manager , it shows that it is using one and only 1 full(utilizes 100% CPU for that) thread for this. It stays at full utilization when I'm typing and becomes very slow. I'm using Internet Explorer 11.
>
> When testing using Performance Dashboard , it stays at 5-15% during idle and while typing , it spikes to 50-55% of total CPU usage.
>
> %%% Running on a Dell Inspiron 6400 with Intel Core2Duo T7200 @ 2Ghz and 4GB DDR2 with Windows 8.1 tested."
In Polish, headlines are written with 1st-letter uppercase only. That's why there are "Polskie diakrytyzowane" and "Inne diakrytyzowane" in [[https://translatewiki.net/wiki/MediaWiki:Visualeditor-specialcharinspector-characterlist-insert/pl|Translatewiki:MediaWiki:Visualeditor-specialcharinspector-characterlist-insert/pl]]. VE displays it wrong (as if English Case Style was Default). {F20866}
Change 179957 merged by jenkins-bot:
SpecialCharacterInspector: Don't auto-capitalise the headings

[[https://gerrit.wikimedia.org/r/179957]]
Change 179957 had a related patch set uploaded (by Jforrester):
SpecialCharacterInspector: Don't auto-capitalise the headings

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

#patch-for-review
See screenshot:

{F20244}
Change 179198 merged by jenkins-bot:
MediaWiki theme: Copy .theme-oo-ui-outline{Controls,Option}Widget from Apex

[[https://gerrit.wikimedia.org/r/179198]]
Change 179198 had a related patch set uploaded (by Bartosz Dziewoński):
Copy .theme-oo-ui-{outlineControlsWidget, outlineOptionWidget} from Apex to MediaWiki

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

#patch-for-review
Environment- test2, beta, Production
Browser- Chrome 39

1> Insert a comment.Click on "Insert" button to close the dialog.
2> While the comment is still highlighted, select any option from the Heading format list.For ex- select Block quote
3> Click to undo(keeping the comment highlighted).Notice the icon and the comment pop-up get detached. Also, JS error "Uncaught TypeError: Cannot read property 'getSurface' of null" shows up in console.

See screenshot.
Screenshot 
{F20838}
1. Click on https://www.mediawiki.org/w/index.php?title=VisualEditor/status&veaction=edit
2. Wait for editor to load
3. Use find-and-replace
4. Try to type "now support "
5. Observe system die in flames after 'n' was typed, not letting you type 'o' yet, let alone the rest.
6. Cry.

250ms is our normal threshold. Let's do that.
This is now better, but not great in very extreme cases.
Change 180635 merged by jenkins-bot:
Use viewport clipping when lots of search results found

[[https://gerrit.wikimedia.org/r/180635]]
Change 180195 merged by jenkins-bot:
Limit number of find and replace results to render

[[https://gerrit.wikimedia.org/r/180195]]
Change 180635 had a related patch set uploaded (by Esanders):
Use viewport clipping when lots of search results found

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

#patch-for-review
getVisibleRange is only ever going to be an estimate due to floats and position absolute, and you'll probably add +/- 50% for good measure. Throwing in a computed style calls ( .css('position') ) is going to make it several times slower.
Yeah I was thinking of binary search too, but I don't know how reliable it'll be because the DOM sequence is similar to but not the same as the rendered visual sequence (due to floated things; good call on absolute positioning but I don't think you'll see absolutely positioned editable text very often).

getVisibleRange() sounds interesting, and that may well be binary search-able if you stick to known-safe things (like .css( 'position' ) === 'static' maybe?)
So I considered the render on screen things, and as you point out you'd have occasional problems with floated things or worse, position absolute things. As you point it your approach doesn't help you work out where to start rendering and calculating if something is on screen is basically as expensive as rendering it (getClientRects being the bottleneck). As viable solution might be to do a binary search. Even on a document of 100k characters that would only be 16 checks.

That shouldn't be too difficult to implement, the only problem being we'd have to re-evaluate on window resize and scroll (although debounced), but being a binary search it should be efficient enough. In might even make sense to push that functionality up to the surface view, so you can just ask it to getVisibleRange.
Change 180195 had a related patch set uploaded (by Esanders):
Limit number of find and replace results to render

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

#patch-for-review
I wonder how much not rendering off-screen would save. You'd save on a bunch of DOM modification, but you'd still have to find every result and compute a rect for it to find out whether it's off-screen. I don't know how much time is spent in the DM search vs the highlight rendering, let's find out.

We could also refactor the DM code so it returns one result at a time instead of all at once, then stop once we hit the first off-screen result. This isn't quite perfect (there might be results in floated image captions that appear significantly above/below the text immediately before/after in the DM/DOM), and it would break the "Kth of N results" thing, so maybe we could try a hybrid approach where we only do full rendering (i.e. the current approach, maybe without off-screen highlights) if there are <=50 results, and above that we aggressively try to stop searching and rendering as soon as we can, while still allowing the user to force the next result to be found and highlighted by pressing next. Or we could base the approach on finding and rendering at most 10 results before and 10 after the currently highlighted one.

(Another problem that I don't quite have a solution for: if the user is scrolled most of the way down the page, how do you know where results start being visible without just trying them all in sequence)
That makes it less likely to explode, but doesn't fix the problem, which is that rendering 16000 highlights is too much. There should either be a cap, or some smartness about not rendering off screen.
In VisualEditor, it is not always possible to save a paragraph that ends with <ref>(cite source)</ref>。 Upon saving the page, the full stop disappears.  See [[ https://www.mediawiki.org/w/index.php?title=VisualEditor/Feedback&offset=20141206172053#Symbol_after_citation_disappear_after_edit_50625 | the original report ]].

I successfully added one [[ https://www.mediawiki.org/w/index.php?title=User:Whatamidoing_(WMF)/Sandbox&diff=1309016&oldid=1228107 | in my sandbox at MediaWiki ]], but (a) I pasted the Chinese full stop into the text, rather than entering it normally, and (b) when I pasted it after the ref, it gave me a black sun before the full stop.  Also, I'm running Safari on a Mac, so it may be browser or OS dependent.
I've re-tested and this seems to now work.
[[ https://www.mediawiki.org/w/index.php?title=VisualEditor/Feedback&offset=20141204053320#Japanese_in_lists_51392 | Original report from MediaWiki.org: ]] from a logged-out editor, on 4 December 2014:

"I just tried to add list items in Japanese. Katakana seemed ok in lists but kanji and maybe hiragana too seemed to delete automatically when pressing enter to go to the next list item."

I believe that this is different from T74619 in which katakana can't be typed at all.
As far as I can tell, this issue and other Japanese text entry issues are all now fixed. Sorry it took so long to confirm!
Confirmed in production. Somehow all works in betalbs and test2. 

This issue is most likely the same bug as T74619.
See screenshot:

{F20270}
Can't reproduce.
See screenshots:

{F20264}{F20266}
This was fixed in the great MediaWiki theme re-write for wmf13.
One of the screenshots got converted to TIFF locally, it seems.
It doesn't seem very different from Apex to me. Also what's up with the attachments on this task?
See screenshot:

{F20251}

(A problem in Apex too, but feels worse in MW.)
Verified the fix in Betalabs and test2
Checked in betalabs - see the attached screenshot.{F28262}
>>! In T78039#966523, @Krenair wrote:
> I checked the resolution to this bug on deployment-prep and found that to close the category popup you actually have to click outside the button which opened it. But I would expect that clicking the button again (while the popup is still open) would close it.

Open a ticket?
I checked the resolution to this bug on deployment-prep and found that to close the category popup you actually have to click outside the button which opened it. But I would expect that clicking the button again (while the popup is still open) would close it.
@Ricordisamoa, since you subscribed the same minute that @Jdforrester-WMF resolved this (and removed your subscription in the process), I'm assuming it was just Phabricator's lack of conflict detection. See T78236
@Jdforrester-WMF Why shouldn't I be subscribed?
Change 183486 merged by jenkins-bot:
Fix styling of MWCategoryWidget to match MW theme

[[https://gerrit.wikimedia.org/r/183486]]
The rounded corners are just left over the from Apex skin where they looked less out of place. Fixed in patch above.
Change 183486 had a related patch set uploaded (by Esanders):
Fix styling of MWCategoryWidget to match MW theme

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

#patch-for-review
(The category selector really should be implemented using the kind of multiselect widget used here by Phabricator for lists of projects or people subscribed to the task, etc. (Phab calls them "tokenizers", which if you ask me is a pretty silly name.) Some of MediaWiki's forms also use something similar, e.g. on <https://wikitech.wikimedia.org/wiki/Special:NovaSecurityGroup> (alas, you need to be logged in to view that page, apparently).)
Whatever you call it, (nearly) everything else in VE is using the standard form style first used in MediaWiki UI, while this is using something different and therefore looks weird and silly.
>>! In T78039#942748, @Jay8g wrote:
> Why aren't we just using a standard mw-ui form for this?

Nothing in VisualEditor or the new OOjs UI front-end has anything to do with MediaWiki UI, which was built as an //ad hoc// provision for systems not yet using OOjs UI.
I agree, lets use the standard form field for this.
Why aren't we just using a standard mw-ui form for this?
//Migrated from: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/64 //

== Narrative ==

As a user, I want localinfo and discussion pages forVisual Editor Beta Features, so I can read them and respond in my language.



== Acceptance Criteria ==

Enable local links for info and discussion pages forthe VisualEditor Beta Features.



== Related Bugs ==

== Related Stories ==

See more VE BF feature requirements here:

 [[https://www.mediawiki.org/wiki/Beta_Features#Tasks | https://www.mediawiki.org/wiki/Beta_Features#Tasks]]
This would be hugely appreciated.
Thanks!
Herald rule H10 created.
>>! In T76954#849205, @Aklapper wrote:
> Summarizing to check I get this right before executing:
> 
> So whenever a task's projects include any of
> * VisualEditor-ContentEditable
> * VisualEditor-ContentLanguage
> * VisualEditor-CopyPaste
> * VisualEditor-DataModel
> * VisualEditor-EditingTools
> * VisualEditor-Initialisation
> * VisualEditor-InterfaceLanguage
> * VisualEditor-MediaWiki
> * VisualEditor-MediaWiki-Links
> * VisualEditor-MediaWiki-Media
> * VisualEditor-MediaWiki-Mobile
> * VisualEditor-MediaWiki-References
> * VisualEditor-MediaWiki-Templates
> * VisualEditor-Performance
> * VisualEditor-Tables
> automatically add project "VisualEditor"?

Yes.

> Note there are two options: Take this actions //every time// or //only the first time// this rule matches. I guess you want everytime.

I think that would make sense, yes.

> Also note that whenever you create a new VE-* project the rule needs to be adjusted. It's not possible to define some placeholders like * for parts of project names like "begins with the string".

Yeah, I guessed as much.
>>! In T76954#848827, @Qgil wrote:
> If the Phabricator team would be included in the Herald policy, I could help you. @aklapper, your choice.  :)

I think that makes sense, still would like to discuss with the team first due to security implications.
Summarizing to check I get this right before executing:

So whenever a task's projects include any of
* VisualEditor-ContentEditable
* VisualEditor-ContentLanguage
* VisualEditor-CopyPaste
* VisualEditor-DataModel
* VisualEditor-EditingTools
* VisualEditor-Initialisation
* VisualEditor-InterfaceLanguage
* VisualEditor-MediaWiki
* VisualEditor-MediaWiki-Links
* VisualEditor-MediaWiki-Media
* VisualEditor-MediaWiki-Mobile
* VisualEditor-MediaWiki-References
* VisualEditor-MediaWiki-Templates
* VisualEditor-Performance
* VisualEditor-Tables
automatically add project "VisualEditor"?

Note there are two options: Take this actions //every time// or //only the first time// this rule matches. I guess you want everytime.
Also note that whenever you create a new VE-* project the rule needs to be adjusted. It's not possible to define some placeholders like * for parts of project names like "begins with the string".
If the Phabricator team would be included in the Herald policy, I could help you. @aklapper, your choice.  :)
When editing the infobox in https://fr.wikipedia.org/w/index.php?title=S%C3%A9bastien_Texier&veaction=edit , the heading is misaligned (overlapping with button), see screenshot.

{F19186}
The main place people encounter this is where all three labels are very long; this "fix" doesn't actually help them.
Well, no, it doesn't change anything except for the case where the label would be clipped.

| | Normal label | Long label
| | -- | -- |
| Before | {F174792,size=full} | {F174794,size=full}
| -- |
| After | {F174798,size=full} | {F174796,size=full}
| -- |
Well, no, it doesn't change anything except for the case where the label would be clipped.

| | Normal label | Long label
| | -- | -- |
| Before | {F174792,size=full} | {F174794,size=full}
| -- |
| After | {F174796,size=full} | {F174798,size=full}
| -- |
Well, no, it doesn't change anything except for the case where the label would be clipped.

Before:
{F174787}
After:
{F174790}
>>! In T76947#1339343, @matmarex wrote:
> Worth a #user-notice, I think? I believe this improves our UI in several languages significantly. :)

And makes it look worse in others. We'll need to test it post-release to see what further tweaks we need to make VE-side.
Worth a #user-notice, I think? I believe this improves our UI in several languages significantly. :)
Change 160812 merged by jenkins-bot:
ProcessDialog: Don't center the title label if there's not enough space

[[https://gerrit.wikimedia.org/r/160812]]
Change 160812 had a related patch set uploaded (by Bartosz Dziewoński):
ProcessDialog: Don't center the title label if there's not enough space

[[https://gerrit.wikimedia.org/r/160812]]
>>! In T76947#1187412, @Whatamidoing-WMF wrote:
> A few images to add to this problem (images show Russian): 

"tempfile.ru" is not very reassuring about the lifetime of these links, so let's copy here.

>   - save: http://img1.tempfile.ru/14007/217cf59a63/72ca3ef85264e46dc8940df5.png
{F109767}
>   - review: http://img5.tempfile.ru/14007/21e2c7cd06/db0830133840b484326c1ae5.png
{F109769}
>   - in templates: http://img1.tempfile.ru/14007/2141f10bfd/81132103a7b84539c4196b6c.png
{F109771}
>   - when add already used ref: http://tempfile.ru/view/14007/21b40770ca/cd799edc8198704e4665e283.png
{F109774}
A few images to add to this problem (images show Russian): 

  - save: http://img1.tempfile.ru/14007/217cf59a63/72ca3ef85264e46dc8940df5.png
  - review: http://img5.tempfile.ru/14007/21e2c7cd06/db0830133840b484326c1ae5.png
  - in templates: http://img1.tempfile.ru/14007/2141f10bfd/81132103a7b84539c4196b6c.png
  - when add already used ref: http://tempfile.ru/view/14007/21b40770ca/cd799edc8198704e4665e283.png
FYI this was brought up again by a user [[ https://phabricator.wikimedia.org/F103020 | testing Citoid ]].
https://www.mediawiki.org/wiki/VisualEditor/Feedback#terrible_title_in_the_form_of_saving_the_page_52517

save:
{F38963}

review: 
{F38964}

in templates: 
{F38965}

when add already used ref:
{F38966}
https://www.mediawiki.org/wiki/VisualEditor/Feedback#terrible_title_in_the_form_of_saving_the_page_52517
This just became worse with the new design, IMHO.
Same at the German Wikipedia (check the Saving dialog). The French workaround to this one was changing the equivalent of "Save your changes" to "Contribution"...
Thanks, Bartosz. The current behavior is clearly undesirable (useless or partially overlapping dialog titles); we may need to do both (shorten some button labels and optimize placement). I defer to @Jdforrester-WMF on the final approach.
The solution would be not to absolutely center the title if it can't fit.

| Before | After |
| ---------|------------ |
| {F19192,size=full} | {F19190,size=full} |
This is the same issue as T70571, where this has been declined (the suggested solution is to make the button labels shorter). The abandoned patch https://gerrit.wikimedia.org/r/160812 would probably still work.
{F19186}
A number of VisualEditor dialogs do not cover full screen when 'full' size.

I can't reproduce this in OOUI demo.

To reproduce:

1. Open a page in VisualEditor
2. Insert → Template (or Insert → Media, or (hamburger) → Options, or others)
3. Resize browser window until it is narrower than the dialog

{F19019}
Checked in beta(Chrome, Safari) - VE dialogs fill up the reduced browser window.
Change 185094 merged by jenkins-bot:
ToolbarDialogWindowManager: Don't pollute parent's .static.sizes

[[https://gerrit.wikimedia.org/r/185094]]
Change 185094 had a related patch set uploaded (by Bartosz Dziewoński):
ToolbarDialogWindowManager: Don't pollute parent's .static.sizes

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

#patch-for-review
Caused by 5eb7294a748231dca841d49896ccfdd630baef7c (https://gerrit.wikimedia.org/r/#/c/174491/).
[x] Deprecate
[x] Replace all code instances in Wikimedia core & deployed extensions
  [x] `iconTitle` https://codesearch.wmflabs.org/search/?q=iconTitle&i=nope&files=&repos=
    [x] Kartographer
    [x] BlueSpiceVisualEditorConnector
    [x] CollaborationKit
    [x] CX
    [x] LanguageTool
    [x] PerformanceInspector
    [x] WikibaseQualityConstraints
  [x] `setIconTitle` https://codesearch.wmflabs.org/search/?q=setIconTitle&i=nope&files=&repos=
    [x] MW core APISandBox
  [x] `indicatorTitle` https://codesearch.wmflabs.org/search/?q=indicatorTitle&i=nope&files=&repos=
  [x] `setIndicatorTitle` https://codesearch.wmflabs.org/search/?q=setIndicatorTitle&i=nope&files=&repos=
    [x] VE
[x] Remove – https://gerrit.wikimedia.org/r/#/c/oojs/ui/+/495949/
Change 400467 **merged** by jenkins-bot:
[mediawiki/extensions/CentralNotice@master] Use findItemFromData instead getItemFromData

[[https://gerrit.wikimedia.org/r/400467]]
Change 404513 **merged** by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (d5428e9b3)

[[https://gerrit.wikimedia.org/r/404513]]
Change 404513 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (d5428e9b3)

[[https://gerrit.wikimedia.org/r/404513]]
Change 398224 **merged** by jenkins-bot:
[mediawiki/extensions/Echo@master] Use findItem(s)FromData instead getItem(s)FromData

[[https://gerrit.wikimedia.org/r/398224]]
Change 398221 **merged** by jenkins-bot:
[mediawiki/core@master] Use findItemFromData instead getItemFromData

[[https://gerrit.wikimedia.org/r/398221]]
Change 398223 **merged** by jenkins-bot:
[mediawiki/extensions/AdvancedSearch@master] Use findItem(s)FromData instead getItem(s)FromData

[[https://gerrit.wikimedia.org/r/398223]]
Change 398217 **merged** by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Use findItem(s)FromData instead getItem(s)FromData

[[https://gerrit.wikimedia.org/r/398217]]
Change 400469 **merged** by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Use findItemFromData instead getItemFromData

[[https://gerrit.wikimedia.org/r/400469]]
Change 400468 **merged** by jenkins-bot:
[mediawiki/extensions/TemplateData@master] Use findItemFromData instead getItemFromData

[[https://gerrit.wikimedia.org/r/400468]]
Change 400466 **merged** by jenkins-bot:
[mediawiki/extensions/Flow@master] Use findItemFromData instead getItemFromData

[[https://gerrit.wikimedia.org/r/400466]]
Change 400470 **merged** by jenkins-bot:
[VisualEditor/VisualEditor@master] Use findItemFromData instead getItemFromData

[[https://gerrit.wikimedia.org/r/400470]]
Change 398006 **merged** by jenkins-bot:
[oojs/ui@master] [DEPRECATING CHANGE] MultiSelectWidget: Rename getters

[[https://gerrit.wikimedia.org/r/398006]]
Change 398005 **merged** by jenkins-bot:
[oojs/ui@master] [DEPRECATING CHANGE] SelectWidget: Rename getSelectedItem to findSelectedItem

[[https://gerrit.wikimedia.org/r/398005]]
Change 400470 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[VisualEditor/VisualEditor@master] Use findItemFromData instead getItemFromData

[[https://gerrit.wikimedia.org/r/400470]]
Change 400469 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[mediawiki/extensions/VisualEditor@master] Use findItemFromData instead getItemFromData

[[https://gerrit.wikimedia.org/r/400469]]
Change 400468 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[mediawiki/extensions/TemplateData@master] Use findItemFromData instead getItemFromData

[[https://gerrit.wikimedia.org/r/400468]]
Change 400467 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[mediawiki/extensions/CentralNotice@master] Use findItemFromData instead getItemFromData

[[https://gerrit.wikimedia.org/r/400467]]
Change 400466 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[mediawiki/extensions/Flow@master] Use findItemFromData instead getItemFromData

[[https://gerrit.wikimedia.org/r/400466]]
Change 398209 **merged** by jenkins-bot:
[oojs/ui@master] Use findItem(s)FromData instead of getItem(s)FromData

[[https://gerrit.wikimedia.org/r/398209]]
Change 398004 **merged** by jenkins-bot:
[oojs/ui@master] [DEPRECATING CHANGE] GroupElement: Rename getItem(s)FromData to findItem(s)FromData

[[https://gerrit.wikimedia.org/r/398004]]
Change 398224 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[mediawiki/extensions/Echo@master] Use findItem(s)FromData instead getItem(s)FromData

[[https://gerrit.wikimedia.org/r/398224]]
Change 398223 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[mediawiki/extensions/AdvancedSearch@master] Use findItem(s)FromData instead getItem(s)FromData

[[https://gerrit.wikimedia.org/r/398223]]
Change 398221 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[mediawiki/core@master] Use findItemFromData instead getItemFromData

[[https://gerrit.wikimedia.org/r/398221]]
Change 398217 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[mediawiki/extensions/ContentTranslation@master] Use findItem(s)FromData instead getItem(s)FromData

[[https://gerrit.wikimedia.org/r/398217]]
Change 398209 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] Use findItem(s)FromData instead of getItem(s)FromData

[[https://gerrit.wikimedia.org/r/398209]]
Change 398006 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] [DEPRECATING CHANGE] MultiSelectWidget: Rename getters

[[https://gerrit.wikimedia.org/r/398006]]
Change 398005 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] [DEPRECATING CHANGE] SelectWidget: Rename getSelectedItem to findSelectedItem

[[https://gerrit.wikimedia.org/r/398005]]
Change 398004 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] [DEPRECATING CHANGE] GroupElement: Rename getItemFromData to findItemFromData

[[https://gerrit.wikimedia.org/r/398004]]
> OO.ui.SelectWidget.prototype.getSelectedItem ➞ OO.ui.SelectWidget.prototype.findSelectedItem

We should also change this for `MultiSelectWidget` (not just `SelectWidget`) and thus `getSelectedItemsData`.
>>! In T76630#3833381, @Volker_E wrote:
> @Prtksxna Yes, please. Also `getSelectedItemsData` ➞ `findSelectedItemsData`.

Yes, thanks, just writing a comment about that.
>>! In T76630#3833381, @Volker_E wrote:
> @Prtksxna Yes, please. Also `getSelectedItemsData` ➞ `findSelectedItemsData`.

Yes, that one is already filed in the description.
@Prtksxna Yes, please. Also `getSelectedItemsData` ➞ `findSelectedItemsData`.
> OO.ui.GroupElement.prototype.getItemFromData ➞ OO.ui.GroupElement.prototype.findItemFromData

Just confirming, we should also change the plural, OO.ui.GroupElement.prototype.getItem**s**FromData ➞ OO.ui.GroupElement.prototype**.find**Item**s**FromData
@Prtksxna Would you please care about the two last open items here, as well? Want to get this in for v0.25.0.
Change 376173 **merged** by jenkins-bot:
[oojs/ui@master] [BREAKING CHANGE] SelectWidget: Remove getFirstSelectableItem

[[https://gerrit.wikimedia.org/r/376173]]
Change 376185 **merged** by jenkins-bot:
[oojs/ui@master] [BREAKING CHANGE] SelectWidget: Remove getRelativeSelectableItem

[[https://gerrit.wikimedia.org/r/376185]]
Change 375936 **merged** by jenkins-bot:
[oojs/ui@master] [BREAKING CHANGE] Remove BookletLayout#getClosestPage

[[https://gerrit.wikimedia.org/r/375936]]
Change 376503 **merged** by jenkins-bot:
[oojs/ui@master] [BREAKING CHANGE] SelectWidget: Remove getHighlightedItem

[[https://gerrit.wikimedia.org/r/376503]]
Change 376186 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: Use findRelativeSelectableItem instead of getRelativeSelectableitem

[[https://gerrit.wikimedia.org/r/376186]]
Change 376176 merged by jenkins-bot:
[mediawiki/core@master] apisandbox.js: Use findFirstSelectableitem instead of getFirstSelectableItem

[[https://gerrit.wikimedia.org/r/376176]]
Change 376174 merged by jenkins-bot:
[mediawiki/extensions/TemplateData@master] Use findFirstSelectableitem instead of getFirstSelectableItem

[[https://gerrit.wikimedia.org/r/376174]]
Change 376175 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Use findFirstSelectableitem instead of getFirstSelectableItem

[[https://gerrit.wikimedia.org/r/376175]]
Change 376177 merged by jenkins-bot:
[VisualEditor/VisualEditor@master] Use findFirstSelectableitem instead of getFirstSelectableItem

[[https://gerrit.wikimedia.org/r/376177]]
Change 376184 merged by jenkins-bot:
[oojs/ui@master] Use findRelativeSelectableItem instead of getRelativeSelectableItem

[[https://gerrit.wikimedia.org/r/376184]]
Change 376183 merged by jenkins-bot:
[oojs/ui@master] [DEPRECATING CHANGE] SelectWidget: Rename getRelativeSelectableItem to findRelativeSelectableItem

[[https://gerrit.wikimedia.org/r/376183]]
Change 376172 merged by Prtksxna:
[oojs/ui@master] Use findFirstSelectableItem instead of getFirstSelectableItem

[[https://gerrit.wikimedia.org/r/376172]]
Change 376502 merged by jenkins-bot:
[oojs/ui@master] Use findHighlightedItem instead of getHighlightedItem

[[https://gerrit.wikimedia.org/r/376502]]
Change 376501 merged by jenkins-bot:
[oojs/ui@master] [DEPRECATING CHANGE] SelectWidget: Rename getHighlightedItem to findHighlightedItem

[[https://gerrit.wikimedia.org/r/376501]]
Change 376171 merged by jenkins-bot:
[oojs/ui@master] [DEPRECATING CHANGE] SelectWidget: Rename getFirstSelectableItem to findFirstSelectableItem

[[https://gerrit.wikimedia.org/r/376171]]
Change 376503 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] [BREAKING CHANGE] SelectWidget: Remove getHighlightedItem

[[https://gerrit.wikimedia.org/r/376503]]
Change 376502 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] Use findHighlightedItem instead of getHighlightedItem

[[https://gerrit.wikimedia.org/r/376502]]
Change 376501 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] [DEPRECATING CHANGE] SelectWidget: Rename getHighlightedItem to findHighlightedItem

[[https://gerrit.wikimedia.org/r/376501]]
Change 376182 abandoned by Prtksxna:
[BREAKING CHANGE] SelectWidget: Rename getHighlightedItem to findHighlightedItem

Reason:
> As these are public methods, we should deprecate them even if they're unused in git. They might be used on wiki, or by third parties.

Yeah makes sense. Abandoning this because its easier for me :/

[[https://gerrit.wikimedia.org/r/376182]]
Change 376186 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[mediawiki/core@master] RCFilters: Use findRelativeSelectableItem instead of getRelativeSelectableitem

[[https://gerrit.wikimedia.org/r/376186]]
Change 376185 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] [BREAKING CHANGE] SelectWidget: Remove getRelativeSelectableItem

[[https://gerrit.wikimedia.org/r/376185]]
Change 376184 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] Use findRelativeSelectableItem instead of getRelativeSelectableItem

[[https://gerrit.wikimedia.org/r/376184]]
Change 376183 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] [DEPRECATING CHANGE] SelectWidget: Rename getRelativeSelectableItem to findRelativeSelectableItem

[[https://gerrit.wikimedia.org/r/376183]]
> OO.ui.SelectWidget.prototype.getHighlightedItem ➞ OO.ui.SelectWidget.prototype.**find**HighlightedItem

There is a `getHighlightedItem` being used in #mediawiki-recent-changes but it isn't related to this change and doesn't use `OO.ui.SelectWidget`. Could someone please confirm my observation?
> OO.ui.SelectWidget.prototype.getHighlightedItem ➞ OO.ui.SelectWidget.prototype.**find**HighlightedItem

There is a `getHighlightedItem` being used in #mediawiki-recent-changes but it isn't related to this change and doesn't use `OO.ui.SelectWidget`.
Change 376182 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] SelectWidget: Rename getHighlightedItem to findHighlightedItem

[[https://gerrit.wikimedia.org/r/376182]]
Change 376177 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[VisualEditor/VisualEditor@master] Use findFirstSelectableitem instead of getFirstSelectableItem

[[https://gerrit.wikimedia.org/r/376177]]
Change 376176 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[mediawiki/core@master] apisandbox.js: Use findFirstSelectableitem instead of getFirstSelectableItem

[[https://gerrit.wikimedia.org/r/376176]]
Change 376175 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[mediawiki/extensions/VisualEditor@master] Use findFirstSelectableitem instead of getFirstSelectableItem

[[https://gerrit.wikimedia.org/r/376175]]
Change 376174 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[mediawiki/extensions/TemplateData@master] Use findFirstSelectableitem instead of getFirstSelectableItem

[[https://gerrit.wikimedia.org/r/376174]]
Change 376173 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] [BREAKING CHANGE] SelectWidget: Remove getFirstSelectableItem

[[https://gerrit.wikimedia.org/r/376173]]
Change 376172 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] Use findFirstSelectableItem instead of getFirstSelectableItem

[[https://gerrit.wikimedia.org/r/376172]]
Change 376171 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] [DEPRECATING CHANGE] SelectWidget: Rename getFirstSelectableItem to findFirstSelectableItem

[[https://gerrit.wikimedia.org/r/376171]]
Change 375937 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] MWTemplateDialog: BookletLayout: Use findClosestPage instead of getClosestPage

[[https://gerrit.wikimedia.org/r/375937]]
Change 375935 merged by jenkins-bot:
[oojs/ui@master] [DEPRECATING CHANGE] BookletLayout: Rename getClosestPage to findClosestPage

[[https://gerrit.wikimedia.org/r/375935]]
Change 375938 merged by jenkins-bot:
[oojs/ui@master] SelectFileWidget: Rename getTargetItem to findTargetItem

[[https://gerrit.wikimedia.org/r/375938]]
Change 375940 merged by jenkins-bot:
[oojs/ui@master] Toolgroup: Rename getTargetTool to findTargetTool

[[https://gerrit.wikimedia.org/r/375940]]
Change 375940 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] Toolgroup: Rename getTargetTool to findTargetTool

[[https://gerrit.wikimedia.org/r/375940]]
Change 375938 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] SelectFileWidget: Rename getTargetItem to findTargetItem

[[https://gerrit.wikimedia.org/r/375938]]
Change 375937 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[mediawiki/extensions/VisualEditor@master] MWTemplateDialog: BookletLayout: Use findClosestPage instead of getClosestPage

[[https://gerrit.wikimedia.org/r/375937]]
Change 375936 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] [BREAKING CHANGE] Remove BookletLayout#getClosestPage

[[https://gerrit.wikimedia.org/r/375936]]
Change 375935 had a related patch set uploaded (by Prtksxna; owner: Prtksxna):
[oojs/ui@master] [DEPRECATING CHANGE] BookletLayout: Rename getClosestPage to findClosestPage

[[https://gerrit.wikimedia.org/r/375935]]
I don't see anything stalled here.
I don't really see the value in changing this, sorry. (But won't oppose if someone does it, I guess.)
Ping. What's happening with this?
The idea was simply that there were three classes of getters.

1. Get a single thing that is always there - like input.getValue()
2. Get a single thing that may or may not be there - like booklet.getOutline()
3. Get one of the 0+ items inside something - like select.getItemFromData()

I was feeling like there were too many cases where class 2 and 3 getters were being chained, which causes problems since they may or may return null. Since the method names don't hint at whether they are safe to chain - and in the case of class 1 they are perfectly safe to chain, code that is dangerous is very easy to mistake for code that is safe.

I don't have a solution for class 2 yet. I'm very interested in ideas.

The solution I came up with for class 3 is to use find instead of get. I think this hints at the method being unsafe to chain, makes the code clearer that you are asking for one of 0+ items, and is a very simple change in the code.
Change 177799 merged by jenkins-bot:
[BREAKING CHANGE] Rename BookletLayout#getPageName → #getCurrentPageName

[[https://gerrit.wikimedia.org/r/177799]]
But why?! :)
Consistency with what Trevor wants OOUI to look like. :-)
Hm.. consistency with what? At first glance I'd guess that a "get" method returns a reference or value that is computed or gathered on-demand. It typically takes either no argument or a unique identifier for a single item. A "find" method on the other hand seems different, maybe something that might takes a search query and return varying results (0 or more). ack-grep found 0 matches for `prototype.find` in oojs/ui, and 2 matches in lib/ve/*.
The BookletLayout#getPageName → #getCurrentPageName one was an obvious improvement and is entirely painless, but I would like to hear the rationale for get→find replacements before I spend tons of time replacing tons of usages across the repos.
Change 177799 had a related patch set uploaded (by Bartosz Dziewoński):
[BREAKING CHANGE] Rename BookletLayout#getPageName → #getCurrentPageName

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

#patch-for-review
@EBernhardson said that they are currently run with wikitext (without Parsoid).  It would be good to run them with Parsoid (since that's our main backend) in addition to or instead of wikitext.

--------------------------
**Trello card**: [[ https://trello.com/c/YpgazY2B/701-k3-run-flow-unit-tests-with-parsoid-3 | YpgazY2B ]]
I think @Ebernhardson changed most/all of these to use a fixture (mock output for given input) if Parsoid is not available.  We'd still like the real thing, but that should help.
@hashar: How far of do you think those proposed ideas are?
Would it make sense to contact an existing Parsoid, until we can properly clone & run it in isolation?
We're not in a huge rush, but it would be nice to have our tests run with Parsoid.


Possible implementation suggestion, copied from [Trello](https://trello.com/c/YpgazY2B/701-k3-run-flow-unit-tests-with-parsoid-3):

http://www.mediawiki.org/wiki/Parsoid/API says "A production version of Parsoid on the Wikimedia cluster can be accessed at http://parsoid-lb.eqiad.wikimedia.org/", so I guess that one would be good to use.

I'm no Jenkins expert, but I think we should add a build step "Execute shell" with the following command on https://integration.wikimedia.org/ci/view/Extensions/job/mwext-Flow-testextension/configure - this would override the default Parsoid settings:

```
# Load context (namely: MW_INSTALL_PATH)
. "/srv/deployment/integration/slave-scripts/bin/mw-set-env.sh"

# Configure Parsoid
echo -e \
 "<?php\n\$wgFlowParsoidURL = 'http://parsoid-lb.eqiad.wikimedia.org/';\n"\
 "\$wgFlowParsoidPrefix = 'enwiki';\n"\
 "\$wgFlowParsoidTimeout = 100;\n" >> "$MW_INSTALL_PATH/LocalSettings.php"
```
So i know that doing this "correct" is of big benefit, but could we have most of the benefits now just by setting Flow config to point to already existing parsoid in labs? Without having to install or boot a parsoid instance the changes required become trivial, as long as the jenkins runners have network access to the labs machines.
Copying @hashar's comment on Trello:

Sorry for the rather long delay. To run tests with Parsoid as a backend, we would need a job that:

  - spawn a Parsoid daemon like we do for some Parsoid integration tests
  - setup MediaWiki behind a web server which we do for qunit tests

The mwext-Flow-testextension job execute the PHPUnit test suite which combines unit tests for the Flow function as well as integration tests against mediawiki/core.

It is totally doable to spawn a Parsoid daemon and run whatever tests you want. That being said, I would prefer to avoid rushing a solution that would match just the Flow extension in favor of a system that would work for other use cases (such as VisualEditor).

During the summer, I worked on a set of utilities that would let us clone core + vendor + extensions and run them all together with the appropriate patches/branches checked out. That will yield a state of code to be tested and is subject of an RFC: https://www.mediawiki.org/wiki/RFC/Extensions_continuous_integration

Once we have that stack of code available, everything is loaded via include() and we will run: the PHPUnit test suite the qunit page

That will supersede all the testextension and extension-qunit jobs in favor of a two jobs that are used by all repositories.

We can come up with a third job that would have a bit more backend configured such as ElasticSearch or Parsoid. But that will take a bit more time since I want the other two jobs to be setup first.

As I understand, running Flow tests with Parsoid is more of a nice to have feature than a breaker and I guess it can wait a bit. In short: yes, but a bit later and on a wider scale :-)

I am subscribed to this Trello card so we can keep the discussion here 8-)
See {T54365} for the same idea, but for content blocks.
Somehow(?) load/display document-level data (e.g. internal lists, meta lists) for the whole document but only the content for a part of the document.

Will probably need {T49344} for the document splitting.
We already support fetching specific HTML sections by ID in the REST API (see https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_page_html_title), but until consistent <section> wrapping with a sensible granularity & perhaps a predictable section ID for the lead section are implemented in Parsoid (T114072), this is not as useful in practice as it could be.

Behind the scenes, the section-by-id retrieval is currently based on byte offset mappings provided by Parsoid and stored in Cassandra. Given the performance we see in [web-html-stream](https://github.com/wikimedia/web-html-stream) (the library @cscott mentioned), we could however get rid of the explicit section offsets stored in cassandra, and do the matching / extraction dynamically instead.

Apart from the server side section retrieval API, clients will need to discover the page outline & section ids. The reading team has already been doing some section loading in apps & mobile web. This is not yet fully general, but is moving in that direction. Metadata about sections is exposed in [the page summary end point](https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_page_summary_title). Another source of metadata is the [lead section end point](https://en.wikipedia.org/api/rest_v1/#!/Mobile/get_page_mobile_sections_lead_title_revision) used by apps, which additionally includes the lead section content itself. Eventually, I hope that we will have standard <section>s in Parsoid output, and can refer to those in these summary end points for easy section retrieval.
We've had a somewhat-related discussion in Parsoid-land about being able to fetch only subsets of the DOM tree from restbase.  The idea there was that restbase would do the actual subtree extraction from the full document, using the fancy fast regexp-based stuff that @gwicke wrote.  But you'd also want to extract and fetch data-mw and data-parsoid for the same subtree.  We've talked about tree-structuring the data-mw and data-parsoid JSON blobs to make that possible (using a variant of @gwicke's HTML regexp technique), but I'm not sure we've actually implemented that yet.
The VisualEditor image resize icon must appear on the inner side of the page (inner in relation to the page). For RTL now it appears on the outer edge, which makes it not really usable. The direction of the arrow heads must be flipped, too.
This is valid HTML:
```
<blockquote>
<p>
Foo
</p>
<p>
Bar
</p>
</blockquote>
```
But when such structure is edited in VE, the inner paragraphs get alienated.
//*sighs*//

>>! In T154231, @dchan wrote:
> At present, BlockquoteNode behaves like a ContentBranchNode ; it should not.
> 
> Right now, ve.ce.BlockquoteNode extends ve.ce.ContentBranchNode, but ve.dm.BlockquoteNode extends ve.dm.BranchNode . I would say BranchNode is the correct parent, because HTML blockquote elements can contain flow content such as paragraph elements (see https://html.spec.whatwg.org/multipage/semantics.html#the-blockquote-element ).
> 
> If however there's some special weird reason to treat BlockquoteNode as a ContentBranchNode, then I'll implement that instead and document the special weird reason.

>>! In T154231#2913587, @Jdforrester-WMF wrote:
> ISTR there is — or at least, was — a solid reason for doing this. But I don't recall at all what it was.

>>! In T154231#4000786, @matmarex wrote:
> It seems the reason was that we treat it as a top-level block element, like paragraphs or heading.
> 
>>>! @Esanders in https://gerrit.wikimedia.org/r/#/c/329448/
>> This is probably correct but it means we have to come up with a new tool for inserting block quote, as it is currently treated as a CBN conversion in the format dropdown. I think we did it that way because most blockquotes are only one paragraph.
>> 
>> Alternatively, we could go the other way and make it fully ContentBranchNode, at least for the time being.
> 
> It was actually changed to be fully ContentBranchNode in 94dbb244dd.
>>! In T76426#801853, @Whatamidoing-WMF wrote:
> What is a CBN?

Content branch node.
What is a CBN?
As a new editor I want to see more information about pages so that I can choose the correct 1 to link to.

Problem: The existing search interface doesn't look like a list of articles on Wikipedia. 
Based on usability testing, this is rated a 3 - Major usability problem: important to fix, so should be given high priority.
https://www.mediawiki.org/wiki/VisualEditor/Usability#Creating_a_link

View click-through prototype here http://invis.io/NP2TOI4GU

{F34278}

Title area of dialogue shows Link icon, "Link to page" and "External link". Clicking External link will take user to T76398

The search field will be filled with the text the user has selected to link.

The search items show:
Image thumbnail, article title, wikidata description
Article icon if no lead image
Indicate Redirect to [[article]] with redirect icon
Indicate disambiguation page with its icon
Empty page icon if redlink
Based on usability testing, this is rated a 3 - Major usability problem: important to fix, so should be given high priority.
Summary: Users don't realize that the link's search results are actual pages on Wikipedia.
2 out of 5 tested were able to link to a page with a title different from link text. 
https://www.mediawiki.org/wiki/VisualEditor/Usability#Creating_a_link
I have a WIP patch for a page selector widget at https://gerrit.wikimedia.org/r/#/c/195240/ - in case it helps.
Content Translation also need this component to enhance our link adaptation features, also for providing a better source article selector.

Is this currently planned as  a reusable component so that other projects can use it? Is there any rough timeline for implementation?
For the option to create a red link, we may consider a language more related to the user action. So instead of "Page does not exist yet", we can label that option as "Link as a missing page" or something along those lines.
For this wikitext: 
```
<p>'''[[File:Wiki.png|thumb]]'''</p>
```
Parsoid produces HTMLDOM that has bold tag inside anchor tag inside figure tag - which is not consistent with https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec
```
<!DOCTYPE html>
<html prefix="dc: http://purl.org/dc/terms/ mw: http://mediawiki.org/rdf/"><head prefix="mwr: http://en.wikipedia.org/wiki/Special:Redirect/"><meta property="mw:articleNamespace" content="0"/><meta property="mw:parsoidVersion" content="0"/><link rel="dc:isVersionOf" href="//en.wikipedia.org/wiki/Main%20Page"/><title></title><base href="//en.wikipedia.org/wiki/"/><link rel="stylesheet" href="//en.wikipedia.org/w/load.php?modules=mediawiki.legacy.commonPrint,shared|mediawiki.skinning.elements|mediawiki.skinning.content|mediawiki.skinning.interface|skins.vector.styles|site|mediawiki.skinning.content.parsoid&amp;only=styles&amp;debug=true&amp;skin=vector"/></head><body data-parsoid='{"dsr":[0,37,0,0]}' lang="en" class="mw-content-ltr sitedir-ltr ltr mw-body mw-body-content mediawiki" dir="ltr"><p data-parsoid='{"stx":"html","autoInsertedEnd":true,"dsr":[0,6,3,0]}'><b data-parsoid='{"autoInsertedEnd":true,"dsr":[3,6,3,0]}'></b></p><figure class="mw-default-size" typeof="mw:Image/Thumb" data-parsoid='{"optList":[{"ck":"thumbnail","ak":"thumb"}],"dsr":[6,29,2,2]}'><a href="./File:Wiki.png" data-parsoid='{"a":{"href":"./File:Wiki.png"},"sa":{},"dsr":[8,27,null,null]}'><b data-parsoid='{"tsr":null,"autoInsertedEnd":true,"autoInsertedStart":true}'><img resource="./File:Wiki.png" src="//upload.wikimedia.org/wikipedia/en/b/bc/Wiki.png" height="155" width="135" data-parsoid='{"a":{"resource":"./File:Wiki.png","height":"155","width":"135"},"sa":{"resource":"File:Wiki.png"}}'/></b></a></figure><p data-parsoid='{"autoInsertedStart":true,"stx":"html","dsr":[32,36,0,null]}'></p>
</body></html>
```
It breaks rendering for such wikitext in VisualEditor.
This should now be fixed in latest master. New code will be deployed to production on Monday. Please verify and reopen if not fixed.
This is a variation of T70395  where the paragraph tags are present as HTML tags in the wikitext rather than being added by the paragraph wrapper.

```a

'''[[File:Wiki.png|thumb]]'''

b```

renders properly. So, the fixes for T70395 need to be expanded to deal with HTML <p> tags as well.
@ResheilA: Hi! Whatever page called "CA" you refer to, it's unrelated to this software development task about creating a MediaWiki extension called "Newsletter". Please either use https://www.mediawiki.org/wiki/Project:Support_desk for general software problems, or the village pump of your Wikimedia site instead. Thanks.
>>! In T76199#2325761, @ResheilA wrote:
> Hello !
> Its long I have been active in this group. Can someone help me up ? I have
> a page called CA. Uttam Agrawal. And its been deleted by the community. I
> worked hard on it and all my coded stuff are gone. Help me up !! I need it
> urgent.

Was your page on a wiki? If yes, I think you should contact the people who maintain the wiki in which your page was in.
Hello !
Its long I have been active in this group. Can someone help me up ? I have
a page called CA. Uttam Agrawal. And its been deleted by the community. I
worked hard on it and all my coded stuff are gone. Help me up !! I need it
urgent.



Resheil Agarwal,
Founder,
Webportal.in
If you try to say that there is no way to fix the issues I bring up in this particular software development, yes I am aware of that. I try to give feedback not just for the moment, but also for future developments.

> please correct me if I'm not understanding your recommendations
You are not understanding my recommendations.

And I finish reacting here, I have made my points clear. Other people seem to understand them, and being ridiculed is not something I would like to continue.
@Romaine, the problem I see is that you leave us no reasonable options following your line of argument. According to your standards, what specific requirements should we handle in this project to guarantee this continuity? A full-time position hired by the Wikimedia Foundation with budget assured for the years to come? And if we don't reach your standards, should we stop this project altogether? This is literally what I understand reading your comments, please correct me if I'm not understanding your recommendations.

As said several times, there is a process to evaluate extensions willing to be deployed in Wikimedia servers (T110170). That process is open for community enquiries and feedback. I will be the first one not pushing for this extension if its development and maintenance plan has open blockers or other flaws. The people that can seriously stop this initiative are the ones that will have to eventually maintain it if the three current contributors involved suddenly disappear from planet Earth. It's free software, all the code and documentation is available, and this is the ultimate guarantee that if there is a serious problem, it can be solved by someone with the skills. This is how the actual economy of open source software works, at Wikimedia and mostly every project maintaining a large codebase.

> If important factors for end-users are missing in software, the software is incomplete.

Please, file tasks for any feature you are missing.
@Romaine, the problem I see is that you leave us no reasonable options following your line of argument. According to your standards, what specific requirements should we handle in this project to guarantee this continuity? A full-time position hired by the Wikimedia Foundation with budget assured for the years to come? And if we don't reach your standards, should we stop this project altogether? This is literally what I understand reading your comments, please correct me if I'm not understanding your recommendations.

As said several times, there is a process to evaluate extensions willing to be deployed in Wikimedia servers (T110170). That process is open for community enquiries and feedback. I will be the first one not pushing for this extension if its development and maintenance plan has open blockers or other flaws. The people that can seriously stop this initiative are the ones that will have to eventually maintain it if the three current contributors involved suddenly disappear from planet Earth. It's free software, all the code and documentation is available, and this is the ultimate guarantee that if there is a serious problem, it can be solved by someone with the skills. This is how the actual economy of open source software works, at Wikimedia and mostly every project maintaining a large codebase.
@Romaine, the problem I see is that you leave us no reasonable options following your line of argument. According to your standards, what specific requirements should we handle in this project to guarantee this continuity? A full-time position hired by the Wikimedia Foundation with budget assured for the years to come? And if we don't reach your standards, should we stop this project altogether? This is literally what I understand reading your comments, please correct me if I'm not understanding your recommendations.

As said several times, there is a process to evaluate extensions willing to be deployed in Wikimedia servers (T110170). That process is open for community enquiries and feedback. I will be the first one not pushing for this extension if its development and maintenance plan has open blockers or other flaws. The people that can seriously stop this initiative are the ones that will have to eventually maintain it if the three current contributors involved suddenly disappear from planet Earth. It's free software, all the code and documentation is available, and this is the ultimately guarantee that if there is a serious problem, it can be solved by someone with the skills. This is how the actual economy of open source software works, at Wikimedia and mostly every project maintaining a large codebase.
I think we keep too much talking around the core of the problem.

> disappears one day, users of this extension would be able to go back to the current way keeping whatever subscribers they have.
You are with this confirming the problem I indicated.
Unless a software development is intended to be temporary, one of the most important parts for end users is continuity. As I said in my initial post about the problems in the process, this is an example of such problem. The continuity as important aspect would have come up if there was a genuine involvement of the stakeholders/end users.

I was concerned about the process, but I am now really surprised. If important factors for end-users are missing in software, the software is incomplete. If I tell this to my community, they find this crazy. Not to mention the waste of resources.
I think we keep too much talking around the core of the problem.

> disappears one day, users of this extension would be able to go back to the current way keeping whatever subscribers they have.
You are with this conforming the problem I indicated.
Unless a software development is intended to be temporary, one of the most important parts for end users is continuity. As I said in my initial post about the problems in the process, this is an example of such problem. The continuity as important aspect would have come up if there was a genuine involvement of the stakeholders/end users.

I was concerned about the process, but I am now really surprised. If important factors for end-users are missing in software, the software is incomplete. If I tell this to my community, they find this crazy. Not to mention the waste of resources.
@Romaine, what @bawolff said.

{T110170} has a long and complex review process ahead, designed to test the appropriateness and robustness of this piece of software and their maintainers. 

Even if one day this extension is implemented in Wikimedia, newsletter owners will not be forced to use it. If you want to keep your current way of managing your newsletter, just keep it. And in the way it is designed, even if the extension blows up and disappears one day,  users of this extension would be able to go back to the current way keeping whatever subscribers they have.

So really, I don't see which harm we are causing by trying to develop and contribute the right thing.
> In this particular case, I believe yes, because several Foundation-led efforts---the Research Newsletter and Tech/News---will come to rely on it. A cynical answer but a correct one.

This is really an important part of developing software. If newsletters, like mine, are going to use an extension, it is important that continuity is arranged.
And again, general, I see too little commitment in the Wikimedia Foundation to secure the continuity.

> if Wikimedia would have deployed only software written by people guaranteed to stay around in the long term
Sorry, but this is not the essence. It is not about individual people. It can be various people. The essence is that WMF gives a guarantee.

> I still think this feature is needed and will be welcome by many authors of current and future newsletters.
I think not, the number one overall complaint from the community what I see (beyond the irritations of changes and worse styles of implementations) is that the community gets bored that again and again and again software is failing and no longer repaired, while the community makes active use of it. Sure there will be lots of people who have not the previous experience of failing software due lack of maintenance, and like the extension, but that is overall only a short term situation of continuity is not guaranteed.
> But will the Foundation commit to maintaining this extension in the long term?

WMF and volunteer developers do critical maintenance on all extensions deployed to Wikimedia. Whether or not there will be long term resources dedicated to improving the extension depends on a lot of factors which are anyone's guess, but if it is deployed, it will at least be kept in working order.
> But will the Foundation commit to maintaining this extension in the long term?

This is a discussion for {T110170}. See you there.  :)

PS: I'm well aware of of the problem of software maintenance. Then again, if Wikimedia would have deployed only software written by people guaranteed to stay around in the long term, we would have never got MediaWiki and friends. I still think this feature is needed and will be welcome by many authors of current and future newsletters.
@Qgil Unlike communications interns, tech interns create products that the community has to rely on in the long term. But will the Foundation commit to maintaining this extension in the long term?

In general, no (you say "that's not the point"). In this particular case, I believe yes, because several Foundation-led efforts---the Research Newsletter and Tech/News---will come to rely on it. A cynical answer but a correct one.
This Google Summer of Code project has been completed successfully. Thank you @tinaj1234 for your contributions, and thank you @01tonythomas for your technical mentoring. This team has worked very well so far!

For details, read {T109288}.

The work continues at {T110170}. As always, your feedback and contributions are welcome. This is not an internship project anymore; patches are very welcome.  :)
Ohh
For what is worth, {T108205} is still open, to be closed this week.
@01tonythomas - okay, thanks, that's helpful. I don't know if giving someone credit for code he didn't write is "perfect" - it could confuse people (at least, it confused me). Those credits, like the "author" field in mediawiki.org infoboxes, are not just there to give respect; they also give helpful information, like whom to contact if you're thinking of submitting a patch. What about adding a "History" section to the mediawiki.org page, to be able to credit Siebrand while clarifying the current situation?
>>! In T76199#1568209, @Yaron_Koren wrote:
> @01tonythomas - when you say "built from scratch", does that mean that the old extension code was simply wiped out? Looking at the mediawiki.org page, it doesn't look that way - Siebrand is still listed as the author of the extension.

Yeah - the first commit by @Tinaj1234 wiped out everything ( https://github.com/wikimedia/mediawiki-extensions-Newsletter/commit/f0e8491e0c1abda0117b67f05db42fbc708568ca ) if you ignore $wgExtensionCredits entries in Newsletter.php :).  Since @siebrand made an inital commit of the extension in https://github.com/wikimedia/mediawiki-extensions-Newsletter/commit/8cf079a2c2cb71670728eef36c9e42ccbff077be back in 2013 - I think @Tinaj1234 wants to give him credit for his work - which is perfect.
@01tonythomas - when you say "built from scratch", does that mean that the old extension code was simply wiped out? Looking at the mediawiki.org page, it doesn't look that way - Siebrand is still listed as the author of the extension.
In the Internet most newsletters have a private list of subscribers. If you want to discuss this topic further, please create a new task.

Google Summer of Code has strict deadlines. Projects have to deliver functional code in less than four months. We cannot spend half of that time waiting for feedback without writing any code.

On resources, Tina is a volunteer receiving a stipend from Google, Tony is volunteering as primary mentor, and I'm dedicating about 1-2 hours/week as secondary mentor. Other people has been involved in this project in a smaller capacity, most of them by personal initiative and as volunteers.

I have re-read your comments above, and I still don't see which specific problems can we address. You say

> * MediaWiki is not designed for global navigation, nor navigation across wikis.

I'm not sure what that means, but in any case this extension is not read for interwiki use today. This was left out of scope for the GSoC project and needs to be revisited now.

> * the MediaWiki software is very primitive - it is for example not possible to create a simple button in what someone can (un)subscribe or one of the many other limitations that prevent it to be easy.

This extension allows users to subscribe and unsubscribe from newsletters using checkboxes.

Again, you are encouraged to file tasks for specific problems.
> I'm sorry you received such notifications in your busiest time, but I hope you understand that we cannot wait for the best spot in everybody's agendas. In terms of communication and feedback, I think we have covered the minimum and more.
That was not my point. It reacted on this:
> worked upon for 4-5 months and was open to anyone interested
But only 2 months time was actually given to react.

As said before, I am especially disappointed in the problem definition and how the plan in post 1 is described. I gave feedback on that. I have described problems in the process, but I do not get the impression that it is taken seriously.

@Tinaj1234 & @01tonythomas My apologies to you both if my messages are unpleasant. The problems I notice are outside your involvement in this project (so far I understand). I am personally concerned about how the resources (like you) are used in software development. So please do not take this as criticism on your work, so far I can see you have done in the given circumstances a great job.
> User expectations, user privacy.
Those are choices. Here it is chosen to give users privacy. I think it is thought too easy about this.

> It is a usual practice in the Internet that only admins of a newsletter can see who is subscribed to it. For what is worth, by default Wikimedia mailing lists don't disclose the identity of their subscribers either, and only their admins can access to this data.
It is a usual practice thanks to Twitter and other social media that it is publicly known who is watching what. The comparison with mailing lists is not accurate enough imo.
>>! In T76199#1564774, @Romaine wrote:
> 
>> Usernames and emails of subscribes should be kept private. The number of users subscribed to a newsletter would be public (and eventually used to promote popular newsletters).
> 
> I do not see a reason for this.

User expectations, user privacy. It is a usual practice in the Internet that only admins of a newsletter can see who is subscribed to it. For what is worth, by default Wikimedia mailing lists don't disclose the identity of their subscribers either, and only their admins can access to this data.
>>! In T76199#1564774, @Romaine wrote:
> 
>> Usernames and emails of subscribes should be kept private. The number of users subscribed to a newsletter would be public (and eventually used to promote popular newsletters).
> 
> I do not see a reason for this.

User expectations, user privacy. It is a usual practice that only admins of a newsletter can see who is subscribed to it. For what is worth, by default Wikimedia mailing lists don't disclose the identity of their subscribers either, and only their admins can access to this data.
>>! In T76199#1566016, @ResMar wrote:
> I think that Romaine is implicitly criticizing a problem that's plagued the movement for a long time: outside contractors are brought in, write a feature, and then leave. No offense to you, Tinaj, but I //highly// doubt that say three years from now you will be maintaining this codebase, or even contactable.

Just for the record, there are several developers who had GSOC projects and stuck around for 3 or more years. I have no idea if Tinaj will be one of them, and s/he certainly has no obligations past the end of his/her project but its entirely possible that s/he could be.

> 
> In your absence no one attached to the movement will be familiar with the code, causing it to trip up other extensions, suffer legacy rot, and eventually become completely unusable. This turnover problem is one half of the legacy dependence problem of the Wikimedias (a total lack of intercommunal standards across Wikimedias is the other half).
> 
> In this case the extension backs into a "platform for the future", Echo, that's in continual development. Hopefully that will keep this extension alive.

I'm not sure its fair to have this discussion here. These sound more like generic issues surrounding the GSOC/OPW program and doesn't have much to do with this particular project.

Keep in mind, creating a feature for use by the Wikimedia movement over the long term is not necessarily the goal of the GSOC/OPW program.
>>! In T76199#1566284, @Yaron_Koren wrote:
> Can someone briefly explain the goal of this project? From the title and description, it sounds like a project to create a new extension. But instead, this project seems to have modified an existing extension, [[ https://www.mediawiki.org/wiki/Extension:Newsletter | "Newsletter"]]. Is that the case? If so, did the task change at some point? And what is the goal that was achieved?

The goal of the project was to build a 'Newsletter' extension which must allow: 


  # Newsletter Authors to easily create and manage Newsletters with scope limited to his rights
  # A usual wiki user to subscribe/unsubscribe to available newsletters in his Wiki ( inter-wiki is post GSoC scope ) 
  # Receive notifications via web/email using Echo whenever a Newsletter creates a new issuse. 

The project took place basically from the description of this task, and was built from scratch ( https://github.com/wikimedia/mediawiki-extensions-Newsletter/commits/master )  - now live at http://newsletter-test.wmflabs.org/wiki/Main_Page - You can find the instructions on how to use the same over there. @Tinaj1234 will work on it further to cross the arch/sec and performance review to take it to production which is of course, not in the scope of GSoC 2015.
Can someone briefly explain the goal of this project? From the title and description, it sounds like a project to create a new extension. But instead, this project seems to have modified an existing extension, [[ https://www.mediawiki.org/wiki/Extension:Newsletter | "Newsletter"]]. Is that the case? If so, did the task change at some point? And what is the goal that was achieved?
Thanks ResMar!
What ResMar is describing is indeed a part of the issue I see. I am concerned about both the process of the development of this software as the general situation of software development. I am concerned about a long term stability.
I think that Romaine is implicitly criticizing a problem that's plagued the movement for a long time: outside contractors are brought in, write a feature, and then leave. No offense to you, Tinaj, but I //highly// doubt that say three years from now you will be maintaining this codebase, or even contactable.

In your absence no one attached to the movement will be familiar with the code, causing it to trip up other extensions, suffer legacy rot, and eventually become completely unusable. This turnover problem is one half of the legacy dependence problem of the Wikimedias (a total lack of intercommunal standards across Wikimedias is the other half).

In this case the extension backs into a "platform for the future", Echo, that's in continual development. Hopefully that will keep this extension alive.
(Please remember that this bug is about developing a newsletter extension for *MediaWiki*, not *Wikimedia*.)
> 4-5 months
We received a message only 2 months ago: 9 June 2015. Just before the most busiest time of the year.

> I don't think the plan [...] is insufficient at all.
Reading the plan, as described in the first post in this Task, it is insufficient to judge.

> The answer is a 'yes'.
I doubt that. I think the difference in answering is likely caused by interpreting the questions differently than how they were intended.

I am not necessary negative about the idea, but the plan described in post 1 is insufficient. And the involvement from stakeholders was also insufficient. (Yes, insufficient with the current level of participation.)
Based on the provided information I get too much the idea that this extension is //developed for// instead of //developed with//. Of course you then say that you have asked newsletter to give feedback, but that makes it still insufficient. The biggest pain in the ass for the Wikimedia community is that they are too little considered to be stakeholder, and are to little involved from the first plan until the end during the whole process.

> I don't quite get what you meant here.
I described two large issues we experience working on wikis too often. The problem description on Meta can be completely derived from these two large issues. This makes "fixing" the described problem a form of treating symptoms, instead of the core problems.

It gives me this feeling: https://xkcd.com/927/

> But we have brought up a beautiful extension which works fine( with tables and buttons and what not ) and is believed to benefit many, do have a look.
This sounds like a car salesman. I do not think it is a good idea if a developer him/herself is saying that it is beautiful, fine working, benefit many, etc. That is up to the stake holders and end users to judge.
Reading this plan, no publisher is able to give feedback as the actual contents are missing. The actual things that matter to publishers is not described in the plan. The plan described is too vague.

It is like describing a new car: it has doors, a steering wheel, seets, a roof, lights and more. This is completely insufficient.

Also some other issues:
* Where there any publishers and readers involved in the plan?
* Has there been any priority check for which software developments are really needed and make a big difference for the movement?
* Where there any publishers and readers involved during the development process?

Reading more pages I get the impression that these three questions are to be answered with "no".

Seeing what problem description is [[ https://meta.wikimedia.org/wiki/Grants:IdeaLab/Newsletter_extension_for_MediaWiki | given ]], I can only think it is too simplistic and not reaching to the core of the problem: 
* MediaWiki is not designed for global navigation, nor navigation across wikis.
* the MediaWiki software is very primitive - it is for example not possible to create a simple button in what someone can (un)subscribe or one of the many other limitations that prevent it to be easy.

Instead of improving this limited and too often too difficult situation, effort is taken to fight only a symptom of the core problems.

I am afraid that this extension appears to be a waste of energy and resources.
I believe @Qgil was referring to the case of http://newsletter-test.wmflabs.org/wiki/Special:Newsletters where a user need not know who is subscribed to the newsletter instead we tell him/her the popularity of the newsletter through the subscriber count.
> Usernames and emails of subscribes should be kept private. The number of users subscribed to a newsletter would be public (and eventually used to promote popular newsletters).

I do not see a reason for this.
Hi, I have associated two blocked-by tasks with this project. 

**For the student:** 
1. Please go through the checklist in the end-term evaluation and fill out the fields which require any links. The checkboxes are for the mentor(s) only. Adding information on the past projects page is your task. 
2. Ensure that you have completed //all// the items listed in the end-term evaluation task. If there's a strong reason about why a particular item was not completed, please comment on the task and we shall look into it. 
3. Wrap-up report is //mandatory// and so is a demo-able link to the project (either in production or in a demo server). 
4. If you want your project to be featured in the blogpost on the Google OSPO blog, kindly comment back with a short, catchy description of the project along with a screenshot.
Great. @Tinaj1234, please write up a short description of the project when you get time for the blog. Also add one, most relevant screenshot which I can include in the post. Thanks!
>>! In T76199#1528553, @Dzahn wrote:
> It would be great if you could import the repo to Gerrit instead of working off of github.

Ah. We were committing to Gerrit from the start of the project. We have it over here http://git.wikimedia.org/tree/mediawiki%2Fextensions%2FNewsletter
It would be great if you could import the repo to Gerrit instead of working off of github.
In our case, "merged" is what exists in the Newsletter extension repo, fully functional in Labs. "Deployed in Wikimedia" is a goal for us, but definitely out of scope of GSoC.
>>! In T76199#1514646, @NiharikaKohli wrote:
> A few questions (for both mentors and student):
> - Are you confident in completing the project on time?
Of course. Almost all the blockers are resolved as of now, and looking at the open tasks at https://phabricator.wikimedia.org/T76199 - its more of the design elements still there. The strictly planned MVP which came as a result of discussions from Lyon and weekly meetings made sure that we have the minimum features ready even before mid-term. This made it easy for @Tinaj1234, as most of the post-mid term works were design stuff. Most features lacked documentation, but @Tinaj1234 was impressive with getting it done. 
 
> - By when do you think you can merge the code, if at all?
Almost all of the patchsets that showed up in Gerrit was reviewed and merged to the github repo in < 2 days - and if you are talking about deployment to production, it might take a bit long to go through the security, arch and performance review through beta to prod - and I expect these to happen in the coming month. Deployment to production was not a part of the GSoC project, anyway. 
> - Are there any major blockers or important missing features?
I dont think there is anything critical as of now. 

Great work till date. You can see the code produced over here : https://github.com/wikimedia/mediawiki-extensions-Newsletter, and test it live at newsletter-test.wmflabs.org
>>! In T76199#1514646, @NiharikaKohli wrote:
> 
> A few questions (for both mentors and student):
> - Are you confident in completing the project on time?
Yes, ofcourse.
> - By when do you think you can merge the code, if at all?
Most of the completed features are merged already. Everything will be merged before 17th August.
> - Are there any major blockers or important missing features?
No, all important features are almost done. Remaining high priority tasks will be completed in the coming week.
Hello!

End of GSoC is fast approaching. 17 August is "Suggested pencils down" deadline and 21 August is "Firm pencils down" deadline. It is expected that you don't dive into new features which might take longer than two weeks to complete and instead work on polishing up your project, testing thoroughly and getting your code merged into the main branch. I hope this project is almost complete so you can merge it and make it available to everyone as quickly as possible. :)

A few questions (for both mentors and student):
- Are you confident in completing the project on time?
- By when do you think you can merge the code, if at all?
- Are there any major blockers or important missing features?

We are looking for projects which are (nearly) complete to feature on our post on Wikimedia and Google OSPO's blogs (for example: http://google-opensource.blogspot.in/2015/02/google-summer-of-code-wrap-up-processing.html). If you're interested in getting yours up there, hurry up and get this finished!

The hard deadline on getting code merged is September. {T101393} for details. 

We'll be asking the students to demo their projects towards the end of the program as well. 

Good luck!
>>! In T76199#1428602, @ResMar wrote:
> I do wonder if a short tagline could not be added to the Echo notification (something along the lines of "In this issue: see what really goes in the Phabricator")
Yes, it would be more informative for the readers if the notification can contain more details indicating what the new issue is about. Thank you! I'll add a blocker task for this.
I tested it a bit. Looking good so far! I do wonder if a short tagline could not be added to the Echo notification (something along the lines of "In this issue: see what really goes in the Phabricator"), but other than that it's already a dream come true.
I tested it a bit. Looking good so far! I do wonder if a short tagline could not be added to the Echo notification, but other than that it's already a dream come true.
The criteria to define a blocker should be: 

  Bugfix or feature required to handle newsletters hosted in Meta. 

Let's leave the multi-wiki scenario for the next milestone (hopefully to be still address during this GSoC round, will depend on the blockers for the single wiki scenario).
The criteria to define a blocker should be: 

 Bugfix or feature required to handle newsletters hosted in Meta. 

Let's leave the multi-wiki scenario for the next milestone (hopefully to be still address during this GSoC round, will depend on the blockers for the single wiki scenario).
Since the MVP is completed we are in position to discuss on our next milestone!

You can see a number of blockers listed in #MediaWiki-extensions-Newsletter workboard. But we think there is a possibility for more blockers and if anyone finds one feel free to create a task and add it to the workboard. The blockers to be closed by end of July will be decided on the next week's meeting ( 9th June 10:30 AM UTC ) and it would be convenient to have all the blockers out by then.

Test MVP here: http://newsletter-test.wmflabs.org/ ( Check description on Main Page to find which page to go to )

@quiddity, @Bawolff, @legoktm Awaiting reviews and comments especially from you guys :)
Just a note to say that mentoring this project until completion is one of my individual goals for {T101100}.

| Goal |	Measurement of success | Dependency | ETA | Status
| ----- | ----- | ----- | ----- | ----- |
| Mentor {T76199} successfully | New extension deployed in Labs and ready to start Wikimedia's review process | @Tinaj1234 @01tonythomas | #ECT-September-2015 | In progress |
@MGChecker, Thanks for pointing it out. Fixed it.
If I open Special:Preferences in your devwiki, I get


```
[25a347c3] /wiki/Special:Preferences MWException from line 182 of /srv/vagrant/mediawiki/includes/Hooks.php: Invalid callback NewsletterHooks::onGetPreferences in hooks for GetPreferences

Backtrace:

#0 /srv/vagrant/mediawiki/includes/Preferences.php(99): Hooks::run(string, array)
#1 /srv/vagrant/mediawiki/includes/Preferences.php(1260): Preferences::getPreferences(User, RequestContext)
#2 /srv/vagrant/mediawiki/includes/specials/SpecialPreferences.php(60): Preferences::getFormObject(User, RequestContext)
#3 /srv/vagrant/mediawiki/includes/specialpage/SpecialPage.php(384): SpecialPreferences->execute(NULL)
#4 /srv/vagrant/mediawiki/includes/specialpage/SpecialPageFactory.php(581): SpecialPage->run(NULL)
#5 /srv/vagrant/mediawiki/includes/MediaWiki.php(285): SpecialPageFactory::executePath(Title, RequestContext)
#6 /srv/vagrant/mediawiki/includes/MediaWiki.php(634): MediaWiki->performRequest()
#7 /srv/vagrant/mediawiki/includes/MediaWiki.php(431): MediaWiki->main()
#8 /srv/vagrant/mediawiki/index.php(41): MediaWiki->run()
#9 /var/www/w/index.php(5): include(string)
#10 {main}

```

I think this schould be fixed.
Currently, we are implementing T99784 with two of them merged already, T101505 and T100125. When it comes to communication, if you look at the description you'll see that we have weekly meetings every Thursday and also like Quim said there was a task open for Stakeholder Outreach. You might get a better idea of what is going on if you look at the [[ https://phabricator.wikimedia.org/T100997 | weekly reports task ]] and [[ https://phabricator.wikimedia.org/tag/mediawiki-extensions-newsletter/ | corresponding tasks ]] created for each feature maybe.
Thanks for the clarifications.

Is this task's description supposed to be an accurate reflection of the current development and implementation plan? I was responding directly to screenshots such as M12 that are included in this task's description. In addition to a mock-up, there are also comments such as "Adding Newsletter tab to Special:Preferences" in the timeline... this seems pretty confusing to me.

I can appreciate wanting to break down a large task into smaller tasks, but fracturing discussion among dozens of tasks has very real communications costs. There should be a centralized place to discuss this proposal and review its current implementation plan. I thought that place was this task, but perhaps I'm mistaken?
Please see that we are not going to affect Special:Preferences - and - what we have would be a Special:Newsletter which would list down the available newsletters for the wiki, and the user can click on each - read its shorty bio and see some stats - and click on Subscribe button to subscribe. Populating the overpopulated Special:Preference more is definitely a bad idea. 

The extension is designed in such a way that existing Newsletters can be easily added to the extension to increase manageability. The Newsletter admins would be given something like http://newsletter-test.wmflabs.org/wiki/Special:NewsletterCreate ( log-in required ) which would allow addition of existing Newsletters - which are wiki pages. Maybe in the later steps, we would have a feature to readily create a newsletter with pre-defined templates right from the Special:NewsletterCreate
On-wiki newsletters are an interesting idea, though I wonder if we're not just painfully duplicating the features of a mailing list.

Parts of this proposal feel like natural complements to the existing work that's already been done in MassMessage. For example, ContentHandler-backed MassMessage subscription lists should be trivially query-able to retrieve and expose numbers of subscribers.

Adding on-wiki notification (Echo) support to MassMessage might be nice and would begin to expose a need for some kind of extension to manage a user's contact preference, perhaps. However, I'm not sure many users want to get that granular. Are users really interested in the flexibility of receiving the Military history newsletter via e-mail, but the Signpost via talk page message (which would trigger an e-mail for most users anyway...)? Are per-newsletter delivery preferences something we actually want or need?

As always, I'm wary of yet another preferences tab, especially sitting next to an existing "Notifications" tab.

I'm not yet convinced of the need for a separate MediaWiki extension here. Publishing content is what the core wiki software should be good at already. I don't see the great value in a specialized layer for creating newsletters specifically.
Works for me too! See you guys tomorrow at 15:00 IST
[[ http://www.timeanddate.com/worldclock/meetingdetails.html?year=2015&month=6&day=5&hour=9&min=30&sec=0&p1=311&p2=771 | This time ]] works for me, yes.
@Qgil, @Tinaj1234 : How about we having a meeting, tomorrow ( 5 June 2015 ) at 3-4 pm IST ?
How about we having a meeting, tomorrow ( 5 June 2015 ) at 3-4 pm IST ?
>>! In T76199#1315875, @Qgil wrote:
> 
> @Tinaj1234, I think this is a good idea. Could you create a task for this?

T100604 created for further discussions.
>>! In T76199#1314246, @Tbayer wrote:
> Is it planned to do some kind of stakeholder outreach to the people who will be using this new software, in particular publishers of existing newsletters?

@Tinaj1234, I think this is a good idea. Could you create a task for this? There @tbayer and @quiddity will tell us the best to reach to the publishers of newsletters.  ;)  (MassMessage against... a list of Newsletters somewhere? Please discuss in the new task, so we keep this one relatively quiet.)
>>! In T76199#1314246, @Tbayer wrote:
> Is it planned to do some kind of stakeholder outreach to the people who will be using this new software, in particular publishers of existing newsletters? (I understand "community bonding" refers to something different.) It would seem prudent to get their feedback on the planned features, to make sure they will actually get used.

Oops! Sorry for the confusion, but this project is scheduled to be done as part of the Google Summer of Code 2015 program, and @Tinaj1234 is the student assigned with 'us' mentoring. 'Community Bonding' is the phase 1 of the project workflow when the candidate gets to know the community and the project. We are preparing the bare minimum product for a start before the mid term ( https://developers.google.com/open-source/soc/ ) and you we welcome existing stakeholders like you to start creating 'sub tasks' to this phab task so that we make sure its delivered before hitting production.
Very exciting to see work progressing in this area! (Speaking as someone who has been regularly sending out newsletters since 2010, and author of one of the pages that Nick linked.)

Is it planned to do some kind of stakeholder outreach to the people who will be using this new software, in particular publishers of existing newsletters? (I understand "community bonding" refers to something different.) It would seem prudent to get their feedback on the planned features, to make sure they will actually get used.
Just FYI, here's my bookmark folder for "Newsletters", which has many useful parts, many outdated pages, and much potential for distraction. ;-)

* https://meta.wikimedia.org/wiki/Newsletters
* https://meta.wikimedia.org/wiki/Internal_news_media
* https://en.wikipedia.org/wiki/Wikipedia:News
* https://de.wikipedia.org/wiki/Wikipedia:Nachrichten
* https://www.mediawiki.org/wiki/Communication
* https://www.mediawiki.org/wiki/Extension_talk:Newsletter and https://www.mediawiki.org/wiki/Extension:Newsletter
* https://www.mediawiki.org/wiki/Movement_broadcasting
Discussions #2  ( 19/05/2015 ) paste: 
https://phabricator.wikimedia.org/P653
@Qgil: Since we wont be able to do much of code work, since a student is assigned for the same, I think we are looking for something in the 'Meeting' category where we can list out what we are planning to do with the NewsLetter. We should be looking at: 


  # How the SpecialPage(s) should look like, what all functions should be made public
  # Who should be given the right to create/edit NewsLetters 
  # More design inputs for the NewsLetter SpecialPage 
  # Showcase our current idea of creating/storing a NewsLetter - and get more inputs about its feasibility
  # Possibility of handling subscription from the Special:Preferences 

I think we will have to prepare few mockups ( I can take care of that ) !
It is time to promote #Wikimedia-Hackathon-2015 activities in the [[ https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2015/Program | program ]] (training sessions and meetings) and [[ https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2015#Activities_confirmed | main wiki page ]] (hacking projects and other ongoing activities). [[ https://phabricator.wikimedia.org/T97121 | Follow the instructions ]], please. If you have questions, about this message, ask [[ https://phabricator.wikimedia.org/T97121  | here ]].
Log of IRC meeting on #wikimedia-newsletter - P627.
Created web proxy for the Labs instance and can now be accessed using: http://newsletter-test.wmflabs.org/ !
I associated this task to #Wikimedia-Hackathon-2015 when I was trying to get development hours for it from anywhere possible.  :)  Are we going to have any specific activity there, though? If so, please create a specific task for this activity.

In general, we need to keep this task as silent as possible, blocking it by the main tasks of this project (that will have their own subtasks).
@01tonythomas, @Qgil - Thanks a lot for the opportunity. Created subtask, T97413 to start off with the community bonding period. Looking forward to working with everyone involved !
>>! In T76199#1241220, @Qgil wrote:
> Alright, let's start with the [[ https://www.mediawiki.org/wiki/Outreach_programs/Life_of_a_successful_project#Community_bonding_period | community bonding period ]]. Please create a subtask as described in T94166, and let's discuss there the tasks related with this phase (i.e. starting our routine of weekly meetings). 
> 
> @01tonythomas, thank you for your efforts providing microtasks and support to all candidates. Let's leave no excuse to Tina to deliver this extension.  ;) 
@qgil True! Cant wait to start this one :) Congrats @Tinaj1234!
Thanks to everyone who came forward with their proposals!
Congratulations @Tinaj1234 and welcome to #Google-Summer-of-Code-2015 with {T93583}! I'm looking forward to working with you on a first release of the Newsletter extension.

Alright, let's start with the [[ https://www.mediawiki.org/wiki/Outreach_programs/Life_of_a_successful_project#Community_bonding_period | community bonding period ]]. Please create a subtask as described in T94166, and let's discuss there the tasks related with this phase (i.e. starting our routine of weekly meetings). 

@01tonythomas, thank you for your efforts providing microtasks and support to all candidates. Let's leave no excuse to Tina to deliver this extension.  ;) 

Anybody interested in seeing this extension deployed one day in Wikimedia, please step in and get involved.
goodreads.com is my current ideal model - just look at this delicious malleability!   (I know developers are very wary of adding preferences (because extra complexity, and testing, and maintenance) but users tend to love them, especially the broad diversity of powerusers in highly-complex projects. ;-)
{F109890}
Please see the updated comment !
ohh yeaah :)
There was an extra "]" at the end of the link:
https://github.com/wikimedia/mediawiki-extensions-BounceHandler/blob/master/includes/ProcessUnRecognizedBounces.php
Github link is non existent.
This task to add an echo notification came directly to the BounceHandler project - T94436 - and would be a relevant micro-task to the project as you need to be doing that to notify the subscribers.
Hints: 
* You have the failing recipient ( to be notified ) user object in here [ https://github.com/wikimedia/mediawiki-extensions-BounceHandler/blob/master/includes/BounceHandlerActions.php#L93 ]
* Follow http://www.mediawiki.org/wiki/Echo_(Notifications)/Developer_guide to see how you can integrate Echo notifications to an extension!
* You can see how Extension:Thanks hook into 'Echo' notifications in line 33 - 37 here ( https://etherpad.wikimedia.org/p/newsletterExtension )
This task to add an echo notification came directly to the BounceHandler project - T94436 - and would be a relevant micro-task to the project as you need to be doing that to notify the subscribers.
Hints: 
* You have the failing recipient ( to be notified ) email id passed as $email in processUnRecognizedBounces( ) [https://github.com/wikimedia/mediawiki-extensions-BounceHandler/blob/master/includes/ProcessUnRecognizedBounces.php]
* Follow http://www.mediawiki.org/wiki/Echo_(Notifications)/Developer_guide to see how you can integrate Echo notifications to an extension!
* You can see how Extension:Thanks hook into 'Echo' notifications in line 33 - 37 here ( https://etherpad.wikimedia.org/p/newsletterExtension )
This task to add an echo notification came directly to the BounceHandler project - T94436 - and would be a relevant micro-task to the project as you need to be doing that to notify the subscribers.
Hints: 
* You have the failing recipient ( to be notified ) email id passed as $email in processUnRecognizedBounces( ) [https://github.com/wikimedia/mediawiki-extensions-BounceHandler/blob/master/includes/ProcessUnRecognizedBounces.php]
* You can see how Extension:Thanks hook into 'Echo' notifications in line 33 - 37 here ( https://etherpad.wikimedia.org/p/newsletterExtension )
More microtasks, if you're still looking for it: T55564 ! and you can find few over here too : T67673#1074667

Basically, search in here for more : https://phabricator.wikimedia.org/maniphest/query/Wi.yo3mXEjwF/
More microtasks, if you're still looking for it: T55564 ! and you can find few over here too : T67673#1074667
More microtasks for grabs :  T59414 
( Will add more soon )!
>>! In T76199#1145330, @koustuvcse wrote:
> okay... I will look into it.. but what is the GMT of the irc?

err. Its just normal humans ( is it? :P ) and bots hanging around in a public chat-place. So,  normal GMT = IRC GMT :). Please click on the date-time link in https://phabricator.wikimedia.org/T76199#1138098 to get exact conversions and maybe, Google a little :)
okay... I will look into it.. but what is the GMT of the irc?
>>! In T76199#1145323, @koustuvcse wrote:
> I am new to the irc ecosystem. can you please guide me through it? please

You can find loads of (Mediawiki+IRC) relevant links over here : https://www.mediawiki.org/wiki/MediaWiki_on_IRC
I am new to the irc ecosystem. can you please guide me through it? please
Hello! The IRC meeting tomorrow has been shifted to #wikimedia-ect channel. Looking forward to seeing you there. :)
We're holding an IRC meeting on [March 25, at 1700 UTC](http://www.timeanddate.com/worldclock/fixedtime.html?msg=MediaWiki+GSoC%2FOutreachy+IRC+party&iso=20150325T17&p1=%3A&ah=1) for prospective GSoC and Outreachy participants with Wikimedia, on #wikimedia-office channel. Do join us!
@resheila A project being selected for GSoC or not is decided by the quality of proposals received. If we get a good proposal for the same, we'll keep this project for the upcoming GSoC round, else not.
Yes, it is. https://www.mediawiki.org/wiki/Google_Summer_of_Code_2015#MediaWiki_extensions
Is this project for sure there in Gsoc?
If someone is still in search of microtasks : T72784 

If you think you're enough cool with the codebase and extensions, please follow the link in Quims comment above, and start preparing your proposal.
Hi @ResheilA thank you for your interest in this project idea. See https://www.mediawiki.org/wiki/Google_Summer_of_Code_2015#Add_your_proposal
Hey,
This project seems interesting, I would like to work on it. And I can make it more efficient and look good. Can any one tell me how to add it for summer of code?
Hi @koustuvcse, thank you for your interest in contributing to Wikimedia. Please read the conversation and try to solve one of the microtasks suggested in the task description. If you have questions, just ask.
this project is cool.. i am from gsoc and i want to work for this project.. the requirements for this project matches my skill set...
@Ricordisamoa, could be... although the current Newsletters proposal already relies on leveraging existing features. If I understand you correctly, your proposal is based on apparently significant modifications to Flow and the implementation of 'tags', a new type of content in Flow. This might be more work than offering plain wiki pages for newletters, Flow for their discussion pages, Echo for notifications and relatively straightforward special pages for managing subscriptions, and the catalog of newsletters. 

I mean, wiki pages are good for publishing articles, and newsletters are articles. Flow is good for discussion, and "instantly-locked threads with certain tags through which users would subscribe" sounds more of a stretch. Besides, wiki pages are a solid and stable basis, with VisualEditor and full-fledged wikitext, while Flow is probably too young to be used as a platform. For a GSoC 2015 project, I think the current proposal is sensible.
@Ricordisamoa, could be... although the current Newsletters proposal already relies on leveraging existing features. If I understand you correctly, your proposal is based on apparently significant modifications to Flow and the implementation of 'tags'. This might be more work than offering plain wiki pages for newletters, Flow for their discussion pages, Echo for notifications and relatively straightforward special pages for managing subscriptions and the catalog of newsletters. 

I mean, wiki pages are good for publishing articles, and newsletters are articles. Flow is good for discussion, and "instantly-locked threads with certain tags through which users would subscribe" sounds more of a stretch. Besides, wiki pages are a solid and stable basis, with VisualEditor and full-fledged wikitext, while Flow is probably too young to be used as a platform. For a GSoC 2015 project, I think the current proposal is sensible.
I find this a bit redundant to Flow, where newsletters could be cross-wiki instantly-locked threads with certain <spam>[[ //www.mediawiki.org/wiki/User:Ricordisamoa/Flow | tags ]]</spam> through which users would subscribe, leveraging the existing integration with watchlist & Echo.
Just my 2 cents.
Looks like you've finished most of the microtasks listed in the description. You can leave the echo notif as of now ( as people say : 10:32 PM <legoktm> Echo isn't really easy to work with :/ ) :D. To help you gain expertise more with the code base, consider these easy tasks: T4335, T92728,
>>! In T76199#1109430, @01tonythomas wrote:
> * Design : 
> https://phabricator.wikimedia.org/T62725 
> https://phabricator.wikimedia.org/T62725
-- since it belongs to UI standardization, you can always see how it's one over here ( https://phabricator.wikimedia.org/project/sprint/board/24/query/Z6mtlWoK9aIj/) - or check this one - https://gerrit.wikimedia.org/r/#/c/192282/
>>! In T76199#1109612, @Tinaj1234 wrote:
> Yes, that's pretty much all about me. Thanks, @Qgil !
> 
> Starting with the microtasks. Is there something like claiming the tasks? Do I have to comment under the bug ? Or just start right away with the bug ? 

I think you can just start working on the same, and submit the patch with the correct Bug: <id> in the commit message. www.mediawiki.org/wiki/Gerrit/Tutorial would help you prepare the patch to gerrit
Yes, that's pretty much all about me. Thanks, @Qgil !

Starting with the microtasks. Is there something like claiming the tasks? Do I have to comment under the bug ? Or just start right away with the bug ?
See https://www.mediawiki.org/wiki/User:Tinaj1234/MassMessage . She applied but at the end the project was for wctaiwan (who finished the project and has continued contributing until today). With this I mean that @Tinaj1234 is in a good starting point, with good experience and clear perseverance. 

Anyway, let's go back to Extension:Newsletter. Sorry for the interlude.
See https://www.mediawiki.org/wiki/User:Tinaj1234/MassMessage . She applied but at the end the project was for wctaiwan (who finished the project and has continued contributing until today). With this I mean that @Tinaj1234 is in a good starting point, with good experience and clear perseverance. 

Anyway, let's go back to Extenmsion:Newsletter. Sorry for the interlude.
See https://www.mediawiki.org/wiki/User:Tinaj1234/MassMessage
I was wondering if @Tinaj1234 was a previous GSoC/OPW intern with us. I didn't find an entry on GSoC Past projects pages though.
Hi @Tinaj1234, thank you for your interest in this project. Wow, looking at tasks and commits related to your profile one can clearly see that you are not new here. Very interesting.
@01tonythomas, add it to the task description. :)
That looks great. Adding few microtasks. I think most of the work would go similar to the Echo/MassMessage extensions + some SpcialPage works, so hacking on them would get you familiar with the same: 
https://phabricator.wikimedia.org/T56533 - from echo - this would help you understand the procedure of adding a new notification. 
* Design : 
https://phabricator.wikimedia.org/T62725 
https://phabricator.wikimedia.org/T62725
* Special Pages hacks: 
https://phabricator.wikimedia.org/maniphest/query/VXEJAQ_oaxCM/#R

Good luck :)
I'm very much interested in working on this project. I believe I'm equipped with most of the skills required for the projects. Looking forward to the microtasks !
Awesome @01tonythomas! :) 

You and @qgil can hack on it together in the Lyon Hackathon to iron out the details (unless either/both of you have made commitments otherwise :).
>>! In T76199#1104168, @Qgil wrote:
> @01tonythomas, the structure of a newsletter is basically an index of issues, yes, but the design could glorify a bit each issue: the most recent one could be featured at the top and the other ones could be in a list, more compact, but still making room to i.e. a thumbnail if the newsletter contains an image.
Yeah. the design can come later through the project though. It would be great if we can complete the desired functions in the 2 month period, and polish the design later. 
> ... Anyway, these are details. I'd rather focus now in finding a main mentor and filling the template in the description.  :)
Something this cool should not be stalled due to a mentor not turning up, and I am positive to play the mentor role, expecting @legoktm, @parent5446, @Qgil and other devs support ( just like we completed bouncehandler :) )
@01tonythomas, the structure of a newsletter is basically an index of issues, yes, but the design could glorify a bit each issue: the most recent one could be featured at the top and the other ones could be in a list, more compact, but still making room to i.e. a thumbnail if the newsletter contains an image.

... Anyway, these are details. I'd rather focus now in finding a main mentor and filling the template in the description.  :)
Dissecting it for fun :  
>>! In T76199, @Qgil wrote:
> Publisher: 
>A process defining the conditions in which a newsletter can be created, featured, demoted, closed (actions that might imply database changes). Just a basic framework to promote best practices and prevent abuse.
So that would mean a Special:NewsLetter page, that would be something similar to the LiquidThreads template ( https://www.mediawiki.org/wiki/Extension_talk:LiquidThreads ), and the publisher can "Create a new Newsletter" over there, give the subject, and body of his newsletter.
Below that, the user can see the NewsLetters ( subjects ) he has created followed by the ones he is currently subscribed to. 
When the publisher clicks on one of the Newsletter he had created, we should have editing options coming up below the suject with JS, I think. The options over there should be simialr to "New page", "View pages", "Trash  Newsletter", "Stop publishing" etc.

@qgil: above looks similar to something you expected ?
Yes, let's try GSoC/Outreachy first.

I have edited the description adding the template for GSoC / Outreachy. Your help filling skills and microtasks is welcome.

Then we need a technical mentor. As a co-mentor, I can contribute the product and community perspective, but we need a developer as main mentor.
@Pine, it'd take one technical mentor devoting a little of his time for three months to a student. :)
What would it take to bump up the priority of this project? This is a high impact project for community communications and wikiprojects, and it's a pity to let this sit here waiting for resources. I'm not sure how many other projects could be considered higher priorities from the consumer and community standpoints.
@ImPacific, Hello! This project is still under discussion. Although I believe the required skills would be PHP, JavaScript, HTML, CSS.
Hi all,
I find this newsletter extension interesting. I would like to take it up as GSOC project and would like to know what skills would be required to accomplish the required tasks. If required skills are mentioned it would be easier to know whether I meet the minimum skill requirement or not.
Thanks.
My only motivation for the centralization is the need to offer a catalog with all the newsletters available in a wiki farm, and the possibility to subscribe/unsubscribe and receive notifications without having to visit or be an active editor of any wiki. If we solve these use cases, then I agree that each wiki community should be able to manage their own newsletters. Anyway, the first prototype will be most likely a single Labs instance, so this is not the most urgent aspect we need to solve.

About notifications, I think we should focus first on strict notifications, a short message telling you that a new issue can be found at URL. Email notifications are a must (directly or via Echo, I don't know) because this is the simplest process that new users and many others will prefer. Web notifications as a logged in Wikimedia user are also good, but make sense only when email is resolved. 

I'm not convinced at all with "deliveries", as in the full content of an issue pasted in Talk pages etc. If you are on web, then it is better to go to the canonical source and eventually read / join the discussion in its canonical place. Email deliveries make sense, though, as many people will prefer to read the content at the moment, even if they are offline.
I'm interested in how this will interact with existing notification systems like MassMessage, Echo, and TranslationNotifications. 

MassMessage has a not-yet-super-advertised feature which makes signing up for deliveries significantly easier: <https://test.wikipedia.org/wiki/Yay_mm-ch!>. Creating a central listing of these pages and allowing creation of MediaWiki messages to add descriptions would come close to what is being proposed in M12 I think.
@Se4598: If we're accommodating something like the Signpost, then I'd imagine that we'd definitely have to support local distributions. I think the MassMessage approach is a good one, i.e., having centralized but also allowing locally managed mass messaging.
I don't like the idea of centralizing newsletter definition. I'm also for centralizing specific newsletters but let communities handle their own (custom to the wiki) newsletters themself, like it's possible to use MassMessage on any wiki, managed by local admins/senders, but also send messages from Meta to all wikis.
to clarify: My main point here is not the central place, but who will have which rights and how that integrates with local community wishes.

Also a extension probably worth a look at the features is [[https://www.mediawiki.org/wiki/Extension:TranslationNotifications|Extension:TranslationNotifications]], where you can choose where to recieve the notifications (email, local or a remote wiki).
Good questions, @Parent5446! I have started drafting a more precise plan in the task description, addressing your points and other elemental factors. Feel free to fine tune the plan with questions and edits.
This definitely seems like a cool idea, and somewhat of an extension of Extension:MassMessage. The only thing to think about is what the interface for authors and administrators would be. Specifically:

  - How do admins define what newsletters are available to users?
  - Where do authors put drafts, and can other people edit them?
  - How do authors publish a draft? How do admins define who can publish?
  - Can authors set a draft to auto-publish at a specific time?

Assuming we attempt to not disturb current workflows, then we'd probably opt for having newsletters on normal wikipages, and rely on page protection (if necessary) to prevent unauthorized editing. Admins would change an interface message containing all the newsletters and the wikipage they are published on. And finally, we have a special page to pull it all together that allows authors to specify when an edition is published.
https://meta.wikimedia.org/wiki/Grants:IdeaLab/Newsletter_extension_for_MediaWiki

All fronts covered!
Call for a GSoC / Outreachy co-mentor or a hackathon buddy sent to wikitech-l: https://lists.wikimedia.org/pipermail/wikitech-l/2015-February/081022.html
I have marked {T30085} if only to think about this scenario:

# Anonymous user finds an interesting Wikimedia newsletter.
# Anonymous only needs to submit an email address to subscribe and receive notifications.
# Eventually, anonymous can complete their Wikimedia username registration.

This is a model that in my opinion works well in many contemporary newsletters from interesting services: the first time they only require an email address (which is a sensible requirement), and once you are in the hook, slowly slowly you feel like more encouraged to be more involved, create your user profile etc.
I have marked {T30085} if only to think about this scenario:

# Anonymous user finds an interesting Wikimedia newsletter.
# Anonymous only needs to introduce an email address to subscribe and receive notifications.
# Eventually, anonymous can complete their Wikimedia username registration.

This is a model that in my opinion works well in many contemporary newsletters from interesting services: the first time they only require an email address (which is a sensible requirement), and once you are in the hook, slowly slowly you feel like more encouraged to be more involved, create your user profile etc.
I'm willing to co-mentor this project, which I consider very much needed in Wikimedia and MediaWiki in general. But I need a technical mentor.

If we miss this GSoC/Outreachy round, another possibility is to propose an activity for the Wikimedia Hackathon in Lyon, although in that case I will also need a technical mentor of sorts.

Sigh.
Wikimedia will [[ https://phabricator.wikimedia.org/T921 | apply to Google Summer of Code and Outreachy ]] on Tuesday, February 17. If you want this task to become a featured project idea, please follow [[ https://phabricator.wikimedia.org/project/view/1042/ | these instructions ]].
I guess any pixel helps.  :)
Alright, but it already has&had a project in BZ/Phab so wondering whether to associate that here. :)
https://www.mediawiki.org/wiki/Extension:Newsletter is not a real project, just one of my attempts (with @siebrand) to kick this feature in a productive direction.
I assume this is about resource allocation? Or does this also refer to technically enhancing functionality in https://www.mediawiki.org/wiki/Extension:Newsletter (so that project should be associated to this task)?
**Name:** Spelling-Dictionary

**Type of Project:** Project, #spelldict

**Policy:** Visible To Public 

**Description:** Spelling dictionaries for the major languages of the world (English, Italian, French) help make Wikipedia articles in these languages more readable and professional and provide an opportunity for participation in improving spelling. Many languages, however, don’t have spelling dictionaries.

This project aims at developing a collaborative dictionary which shall also have an additional feature of checking spellings of the words. This is to be achieved with the collaborative efforts of the mediawiki community using crowd-sourcing, as a MediaWiki extension integrated with VisualEditor, and possibly using Wikidata as a backend. We need to create something that's useful as VE module.

The essence of the project shall aim to develop an admin panel where the administrator/moderator will be able to manage the submissions: verify the suggested spellings of the words, accept them, reject them, filter and build new versions of the spelling dictionary upon them. A simple start to the project could be by starting with a simple list of words.

The detailed time line can be read [[ http://www.mediawiki.org/wiki/User:Ankitashukla/Proposal | here ]]
Please also add yourself to the project members to receive updates. See https://www.mediawiki.org/wiki/Phabricator/Help#Receiving_updates_and_notifications for more information.
#spelldict created. If for some reason you want to rename it, please check https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Renaming_projects

Enjoy!
I'm OK with this name.
>>! In T76160#792226, @Qgil wrote:
> @amire80, @kartikmistry, are you ok with this name of project? CCing @Jdforrester-WMF as well, since this is a project related to VisualEditor.

Ping? I want to create this project today, if possible.
@amire80, @kartikmistry, are you ok with this name of project? CCing @Jdforrester-WMF as well, since this is a project related to VisualEditor.
The job: [[ https://integration.wikimedia.org/ci/view/BrowserTests/view/VisualEditor/job/browsertests-VisualEditor-language-screenshot-windows_8.1-firefox/ | browsertests-VisualEditor-language-screenshot-windows_8.1-firefox ]]
That job has been deleted by https://gerrit.wikimedia.org/r/#/c/183480/ which replaced it with a mac os version.
Most of the jobs is green, but a few failed.

https://integration.wikimedia.org/ci/view/BrowserTests/view/VisualEditor/job/browsertests-VisualEditor-language-screenshot-windows_8.1-firefox/
The job is green now.

https://integration.wikimedia.org/ci/view/BrowserTests/view/VisualEditor/job/browsertests-VisualEditor-language-screenshot-windows_8.1-firefox/LANGUAGE_SCREENSHOT_CODE=ar,label=contintLabsSlave%20&&%20UbuntuTrusty/7/consoleFull
The only [[ https://integration.wikimedia.org/ci/view/BrowserTests/view/VisualEditor/job/browsertests-VisualEditor-language-screenshot-windows_8.1-firefox/LANGUAGE_SCREENSHOT_CODE=ar,label=contintLabsSlave%20&&%20UbuntuTrusty/4/console | failing scenario ]] at the moment is caused by T76134.
Change 176235 merged by jenkins-bot:
[BrowserTest] Fixed a couple of page elements

[[https://gerrit.wikimedia.org/r/176235]]
Change 176235 had a related patch set uploaded (by Zfilipin):
[BrowserTest] Fixed a couple of page elements

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

#patch-for-review
Open VE-> Heading - under sub-heading 4, visualeditor-formatdropdown-format-blockquote will be displayed from <span class="oo-ui-tool-title-text">&lt;visualeditor-formatdropdown-format-blockquote&gt;</span>(see the attached screenshot).
{F16461}
This functionality was released in wmf10 so shouldn't show up in wmf9 wikis; on MediaWiki.org and test2.wikipedia.org it appears fine for me (and also on Beta Labs). Deployment issue?
There's a range of different loading indicators in Wikimedia Foundation products. 
Let's unify them.

=== Standard progress indicators
==== Progress bar (application, elevated above view)
- **VisualEditor** -   [[ https://doc.wikimedia.org/oojs-ui/master/demos/?page=widgets&theme=wikimediaui&direction=ltr&platform=desktop#Progress-bar | ProgressBarWidget (OOUI widget)]] as elevated application loading indicator
{F33930009 width=50%}

==== Progress indicator (in page)
- **Three (bouncing) dots** for in-view loading content, for example RCFilters
  [[ https://codepen.io/Volker_E/pen/yqNXMe | CodePen with dots indicator example at 16px ]]. Depending on context product designers can also choose to go for 12px dot sizes. 


---

=== //Outdated, non-standard// progress indicators in Foundation products

**Content translation** - loading article (content). 
{F3067365}

**Notifications** - loading notifications (content) 
{F3067366}

**Structured Discussion** - loading more topics (content) 
|{F27614503}|{F3067367} 

loading contents on infinite scroll
{F3068028}

**MobileFrontend** - loading "nearby" articles (content) 
|{F27614726}|{F3067368}

---
**Related notes:**
- User:Splarka has done some analysis [[ https://www.mediawiki.org/wiki/User:Splarka/Throbber | here ]] to see how loaders work in different colored backgrounds. 
- Relevant [[ https://phabricator.wikimedia.org/T95137 | task about loading indicators should accelerate as it nears completion ]]
- {T78062}
I changed from indeterminate to just a discussion of loading indicators so we can look at loading indicators as a whole. Documented here on MW: https://www.mediawiki.org/wiki/Wikimedia_User_Interface/Use_cases/Loading_Indicators
Over on T61699 I've got a hi-dpi update to jquery.spinner in MW core that doesn't change its design -- should I go ahead and try to land that as-is for now or wait on this design to replace it?
@prtksxna yes, here's my first cut http://nirzar.github.io/prototypes/ui/primary-button-loading.html
@nirzar, didn't you at some point make prototypes of this indicator along with buttons? Is this same/related? Could you please add a link to that task?
sure, @Pginer-WMF has designs for an in-page indeterminate loading indicator, I'd like for us to consistently use this when we have in-page indeterminate loaders. On the app this could be… loading search results, long articles, large images, nearby lists, etc.
>>! In T75972#848540, @Jaredzimmerman-WMF wrote:
> @Deskana, There are other other in-page loaders that you see occasionally, are these all inherited from mobile web?

From the engineering perspective, we don't inherit anything about our UI from mobile web or desktop. It's nontrivial to inherit UI elements from mobile web for a variety of technological reasons. It's possible that they were designed the same way and therefore look very similar, however. You'd have to ask your designers about that. :-)

> As far as inconsistency with Material Design or iOS guidelines, I feel we've already settled on a look and feel that is wikimedia, rather than being platform specific. I know that we've made subtle platform adjustments, but overall we've diverged pretty far from each platform's design in order to have something that is unique to the application. 

Yes and no. We use material design icons in the Android app almost everywhere for things like search, table of contents, hamburger menu, etc. We also use an Android-spec progress bar for page load indication. For pretty routine operations like this, it means if someone's used another app on their phone then they reasonably know what to expect from ours. As mentioned, I would be reluctant to break that pattern.

In other places, we don't pay much attention to their guidelines (e.g. progressive action buttons in the editing workflow are not in line with Android). For editing I think that makes sense, because the editing workflow is so unique to our application.

But anyway, this is a pretty high level discussion. To figure out our next steps, could you say specifically what you're proposing we do in the iOS app and the Android app? Thanks!
@Deskana, There are other other in-page loaders that you see occasionally, are these all inherited from mobile web? As far as inconsistency with Material Design or iOS guidelines, I feel we've already settled on a look and feel that is wikimedia, rather than being platform specific. I know that we've made subtle platform adjustments, but overall we've diverged pretty far from each platform's design in order to have something that is unique to the application.
This doesn't make much sense as a task for mobile apps. For system controls like loading indicators, it's much important to use the platform's built-in controls rather than making our own arbitrary ones, because our app should be consistent with other apps in the platform.

For example, the Android platform has the Toolbar class (which we use for our toolbar) which has a built in progress bar; that's the standard paradigm on the platform, and we'd need a //really// good reason to intentionally make our apps incompatible with material design.
Here are some details:
- [[ http://codepen.io/anon/pen/VYYvXM | Live example ]]
- [[ https://gerrit.wikimedia.org/r/#/c/144873/ | Patchset from the Language team implementing it in Content Translation]]
- More details in [[ https://trello.com/c/2u8W6qn8/53-consistent-load-more-animation-in-core | this Trello card ]]

{F20240}
- [[ http://codepen.io/anon/pen/VYYvXM | Live example ]]
- [[ https://gerrit.wikimedia.org/r/#/c/144873/ | Patchset from the Language team implementing it in Content Translation]]
- More details in [[ https://trello.com/c/2u8W6qn8/53-consistent-load-more-animation-in-core | this Trello card ]]
@pginer-wmf can you link to the indeterminate loaders that are being used in flow/CX please?
In the help bubble that shows the message visualeditor-dialog-meta-settings-newsectioneditlink-help, the message "vector-view-edit" is mentioned. It is supposed to show "Edit" to the user, but it shows "[vector-view-edit]" instead. The value of the message should probably be sent as a parameter instead of using {{int:vector-view-edit}}.
Change 176071 merged by jenkins-bot:
i18n: Pass value to <visualeditor-dialog-meta-settings-newsectioneditlink-help>

[[https://gerrit.wikimedia.org/r/176071]]
Change 176071 had a related patch set uploaded (by Jforrester):
i18n: Pass value to <visualeditor-dialog-meta-settings-newsectioneditlink-help>

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

#patch-for-review
Name: technical-debt
Type of project: Tag
Description:

Technical debt (also known as design debt[1] or code debt) is a recent metaphor referring to the eventual consequences of poor system design, software architecture or software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy. - https://en.wikipedia.org/wiki/Technical_debt
Examples: Missing unit tests, duplicate code.
We need to tag existing bugs with the keyword. But this ticket can be closed. Thanks for creating the keyword.
What needs to be done here for Wikidata, or can we mark this as Resolved?
>>! In T75892#831488, @Qgil wrote:
>> Editable By VisualEditor (Project)
> 
> You do it.  :)

Done: https://phabricator.wikimedia.org/project/view/609/
I also merged all the MobileFrontend tasks into it, archived that project with a note, and added the old projects' tags to the new one.
> Editable By VisualEditor (Project)

You do it.  :)
>>! In T75892#824439, @Qgil wrote:
>>>! In T75892#790593, @Jdforrester-WMF wrote:
>> Rather than create a new project, just re-label one of the existing two and be done with it?
> 
> Should we go for renaming #VisualEditor-TechnicalDebt ?

That would involve the fewest tasks needing to have a project added, so WFM. Let's do it?
>>! In T75892#790593, @Jdforrester-WMF wrote:
> Rather than create a new project, just re-label one of the existing two and be done with it?

Should we go for renaming #VisualEditor-TechnicalDebt ?
>>! In T75892#793155, @JanZerebecki wrote:
> This "old bugs and feature requests that are standing somewhere and we never had the time to address" definitively does not describe _technical_ debt. Some specific technical debt may at the same time also be a functionality bug, but neither is a sufficient condition for the other.
> 
> See the link to en.wp in the description. do you think that does not sufficiently define the term?

Indeed, the definition on enwiki is very badly worded. Technical debt covers "poor" decisions about code structure, but it also covers great decisions that turn out five years later to be inadequate for future needs. //E.g.// a reasonable technical debt bug would be "Have MediaWiki use a NoSQL rather than RDBMS back-end"; the "decision" not to use NoSQL never happened, because MediaWiki's design and creation pre-dates that technology.

Some real-world examples of types from VisualEditor: T51439 is (was) a criticism of our code that we made when we built the original; T49344 is a subsequent decision about what architecture would be better given developing needs.
Yes, yes, I agree with you and I am glad that we have such a good description in Wikipedia. I wasn't referring to the theoretical description but to the deviation in regular use that might occur if we don't pay attention.
This "old bugs and feature requests that are standing somewhere and we never had the time to address" definitively does not describe _technical_ debt. Some specific technical debt may at the same time also be a functionality bug, but neither is a sufficient condition for the other.

See the link to en.wp in the description. do you think that does not sufficiently define the term?
+1 to renaming an existing project and consolidating the rest (tracking bug etc) around it.

+1 also on sharing a clear definition of what is and what is not "technical debt". Frequently I have heard this term in product management and management management conversations with the meaning of "old bugs and feature requests that are standing somewhere and we never had the time to address".
Rather than create a new project, just re-label one of the existing two and be done with it?
Shouldn't we maybe just convert T2700 from a tracking bug into a [[ https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Type_of_project | tag project ]]? :)

Also wondering if that means that tasks in #VisualEditor-TechnicalDebt should be moved to the generic VisualEditor project && that new Technical-Debt tag project (or whatever it will be called). 
And maybe same for #MobileFrontend-Hygiene ?
+1, this would be useful. How much tech debt vs. feature work gets done is a sort of project health metric (as is the number of tech debt tickets, of course). A team might decide to spend X% of its time on working off tech debt, etc. An explicit way of marking tech debt tasks would make it much easier to track that.
The dialog boxes that have extremely small font(T75800)  get stuck on the screen when Cancel button is clicked. 

1. VE in beta with redirect=no&veaction=edit&useskin=monobook
2. Insert -> Template - click Cancel- nothing happens; the dialog box gets stuck on the screen, need to refresh.

The same issue with Cancel in Cite-Website, Book, News, Journal.
The "Leave feedback" option in VE allows to report a bug:
The "list of known bugs" link should point to its equivalent here;
The "I checked, report a new bug" button needs to point to the (possibly partially pre-filled) task creation form here.
Links refer to Phabricator - however, what happened to the color of links? 

From color: #0b0080; in test2 and production to color: #362b36 in beta? 
https://phabricator.wikimedia.org/T85857 is filed.
Change 182464 merged by jenkins-bot:
Update bugzilla links to phabricator

[[https://gerrit.wikimedia.org/r/182464]]
Change 182462 merged by jenkins-bot:
Update bugzilla links to phabricator

[[https://gerrit.wikimedia.org/r/182462]]
Change 182464 had a related patch set uploaded (by Alex Monk):
Update bugzilla links to phabricator

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

#patch-for-review
Change 182462 had a related patch set uploaded (by Alex Monk):
Update bugzilla links to phabricator

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

#patch-for-review
To be precise, the 2 messages are MediaWiki:Feedback-bugornote and MediaWiki:Feedback-bugcheck.
The "Alternative text" label in the VisualEditor media adding dialog is not entirely clear to people who aren't familiar with web authoring and accessibility technologies. It would be useful to add a little explanation in a small font near that label, that would explain what is alternative text for and how to write it so it will be really useful.
Checked in betalabs.
Change 187447 merged by jenkins-bot:
Add help icon for FieldsetLayout

[[https://gerrit.wikimedia.org/r/187447]]
Change 187447 had a related patch set uploaded (by Mooeypoo):
Add help icon for FieldsetLayout

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

#patch-for-review
Change 186108 merged by jenkins-bot:
MWMediaDialog: Add contextual help for controls

[[https://gerrit.wikimedia.org/r/186108]]
Change 186108 had a related patch set uploaded (by Jforrester):
MWMediaDialog: Add contextual help for controls

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

#patch-for-review
There are a lot of them, see T4007 and the #tracking tag.

I suppose they should eventually all be closed and replaced with tags or projects.

See also T266.
Removed {{draft}}, linked from https://www.mediawiki.org/w/index.php?title=Phabricator%2FProject_management&diff=1426794&oldid=1425629

Closing as resolved.
Draft: https://www.mediawiki.org/wiki/Phabricator/Project_management/Tracking_tasks
Copying my steps from T86232#1034556:
* Requested project has been created: MediaWiki-jQuery-Tablesorter
* Dependency tasks of tracking task 33601 have been added to the new project.
* Subscribers of 33601 have been added as project members to the new project.
* Tracking task 33601 has been closed and its summary updated. Also added new summary as a comment as mail notification settings differ among folks.
>>! In T75703#936981, @Qgil wrote:
> So what about this guideline:
> 
> * Subtasks and blockers of real tasks are totally fine.
> * If someone wants to convert a tracking task in a project, they just need to follow the regular process to request a new project, announcing the proposal in the own tracking task. 
> * New tracking tasks are discouraged. If we find one, let's propose the promoter(s) to create a project instead.

+1. Should move these bullet points plus the workaround in T75703#937036 to some wikipage. 
Probably some subpage of https://www.mediawiki.org/wiki/Phabricator/Project_management and linking from "Tasks cannot be worked on yet" (covers dependencies) or "Scope of tasks" (covers subtasks)?

Should also note that the actual work (mass-add new project to open and closed tasks; close old tracking bug by editing description saying "This task is not used anymore for tracking. Tickets have been moved to project #Foobar") to convert a tracking task to a project could be done by the requester having batch-edit permissions.
Might also want to mention advantages: Workboard for project.

After moving this to a wikipage I consider this task done.
>>! In T75703#1006222, @Ciencia_Al_Poder wrote:
> Now in Phabricator I find it a lot harder to do.

See T33.
Adding a bug to a tracking bug in bugzilla was easy, because there were 2 ways of doing that: from the tracking bug or from the bug itself. And it was a matter of adding the bug number in the comma-separated list of bug numbers.

Now in Phabricator I find it a lot harder to do. You can only do that from the tracking task, which usually contains **tons** of blocked tasks (see T2384). It presents you a search to type the task number or description, and below the interminable list of blocked tasks, and you need to scroll until the end of the list to add the new task. I find it crappy enough to comment this situation.

This situation could be alleviated if Phabricator allowed to edit the blocking tasks from the inverse perspective (add the tracking task from the child task itself) as Bugzilla allowed.

Converting tracking tasks into projects would be more helpful
# Select all the blocking tasks
# Paste in Gedit or equivalent
# Save as csv
# Open in Calc or equivalent, using "space" as separator
# Copy the column with the reference numbers
# Paste it in Gedit or equivalent
# Ctrl-H to substitute all colons by commas
# Copy the list of task numbers with commas
# Paste it in "Task IDs" field in Maniphest advanced search and hit "Search"

Sounds complicated but it takes just a couple of minutes. See an example from T2745 to https://phabricator.wikimedia.org/maniphest/query/bKU3kGuAWKFB/#R (278 tasks)
# Select all the blocking tasks
# Paste in Gedit or equivalent
# Save as csv
# Open in Calc or equivalent, using "space" as separator
# Copy the column with the reference numbers
# Paste it in Gedit or equivalent
# Ctrl-H to substitute all colons by commas
# Copy the list of task numbers with commas
# Paste it in "Task IDs" field in Maniphest advanced search and hit "Search"

Sounds complicated it takes just a couple of minutes. See an example from T2745 to https://phabricator.wikimedia.org/maniphest/query/bKU3kGuAWKFB/#R (278 tasks)
# Select all the blocking tasks
# Paste in Gedit or equivalent
# Save as csv
# Open in Calc or equivalent, using "space" as separator
# Copy the column with the reference numbers
# Paste it in Gedit or equivalent
# Ctrl-H to substitute all colons by commas
# Copy the list of task numbers with commas
# Paste it in "Task ID" field in Maniphest advanced search and hit "Search"

Sounds complicated it takes just a couple of minutes. See an example from T2745 to https://phabricator.wikimedia.org/maniphest/query/bKU3kGuAWKFB/#R (278 tasks)
>>! In T75703#936981, @Qgil wrote:
> So what about this guideline:
> 
> * Subtasks and blockers of real tasks are totally fine.
> * If someone wants to convert a tracking task in a project, they just need to follow the regular process to request a new project, announcing the proposal in the own tracking task. 
> * New tracking tasks are discouraged. If we find one, let's propose the promoter(s) to create a project instead.

Sounds good. Note that the line between real tasks and tracking bugs can get a little blurry, though — e.g. "Get Xyz ready to go" or "Release Abc version 1.0", so some judgement may be needed.
>>! In T75703#936775, @Aklapper wrote:
> I wonder if there's a sane way to get all the tasks under "Blocked by" on (e.g. T2745 for T78670) into a "Maniphest search query" format to then use the "Batch editing" mode and mass-add a newly created project tag. I am afraid there isn't, which will make converting really cumbersome.
> 
> https://phabricator.wikimedia.org/maniphest/query/advanced/ does not offer a field "Blocking: T9876543" either.
> 
> Even if I had a list, "Batch editing" does not offer a "Remove Blocker bug T9876543" either so I guess I'd just leave that as is, and add a comment to the tracking bug that it's replaced by a project tag and close it as invalid.
> 
> Meh.

Yeah, I filed this upstream but I'm on my phone right now so can't find it. Consequently all the VisualEditor tracking bugs are waiting for me to have some time and being bored as hell. :-)
So what about this guideline:

* Subtasks and blockers of real tasks are totally fine.
* If someone wants to convert a tracking task in a project, they just need to follow the regular process to request a new project, announcing the proposal in the own tracking task. 
* New tracking tasks are discouraged. If we find one, let's propose the promoter(s) to create a project instead.
I wonder if there's a sane way to get all the tasks under "Blocked by" on (e.g. T2745 for T78670) into a "Maniphest search query" format to then use the "Batch editing" mode and mass-add a newly created project tag. I am afraid there isn't, which will make converting really cumbersome.

https://phabricator.wikimedia.org/maniphest/query/advanced/ does not offer a field "Blocking: T9876543" either.

Even if I had a list, "Batch editing" does not offer a "Remove Blocker bug T9876543" either so I guess I'd just leave that as is, and add a comment to the tracking bug that it's replaced by a project tag and close it as invalid.

Meh.
@Lydia_Pintscher: Yes, sorry, I meant T54385. Comment edited.
@Qgil: I think that is the wrong ticket id you linked? We have a few tasks in Wikidata that are not worth their own project like T73519 but would still be good to mark as tracking somehow. The tag works fine for that for me.
I think we could decide the deprecation of the Tracking tag, but without getting too obsessed about it. The idea is that tracking tasks are either converted to projects or to regular tasks with blockers, having a chance to have more projects associated with them now.

#tracking includes a list of recent changes, which is useful to see which tracking tasks are seeing activity. We could start with these. 

For instance, {T37707} has Tracking and an own project, so Tracking could be safely removed there. 

T54385 is a less clear candidate for an own project, but it seems that its scope fall almost entirely within Wikidata/Wikibase. We could ask @Lydia_Pintscher what does she prefer to do with it.
I think we could decide the deprecation of the Tracking tag, but without getting too obsessed about it. The idea is that tracking tasks are either converted to projects or to regular tasks with blockers, having a chance to have more projects associated with them now.

#tracking includes a list of recent changes, which is useful to see which tracking tasks are seeing activity. We could start with these. 

For instance, {T54385} has Tracking and an own project, so Tracking could be safely removed there. 

T37707 is a less clear candidate for an own project, but it seems that its scope fall almost entirely within Wikidata/Wikibase. We could ask @Lydia_Pintscher what does she prefer to do with it.
I think we could decide the deprecation of the Tracking tag, but without getting too obsessed about it. The idea is that tracking tasks are either converted to projects or to regular tasks with blockers, having a chance to have more projects associated with them now.

#tracking includes a list of recent changes, which is useful to see which tracking tasks are seeing activity. We could start with these. 

For instance, {T37707} has Tracking and an own project, so Tracking could be safely removed there. 

T37707 is a less clear candidate for an own project, but it seems that its scope fall almost entirely within Wikidata/Wikibase. We could ask @Lydia_Pintscher what does she prefer to do with it.
I'm not sure if this needs a "generic solution". I'm curious to see which tracking tasks will actually see activity (adding and removing items) and which ones were and are mostly forgotten.

In general and when still actively used, tracking tasks sound like something to convert into tag projects (as tracking tasks were a workaround in Bugzilla to emulate keywords; keywords needed to be set up by a Bugzilla admin who might have asked questions why something is actually needed, while some folks loved to just go ahead and categorize items).
In #VisualEditor I'm in the process of converting them all into projects, which is quite painful without the bulk edit right. :-)
Goal:

Save page with edit summary "Copyedit".


(Almost) result:

Save page with no edit summary, but with the word 'Copyedit' added in the middle of the link that I had just fixed.


Steps to reproduce:

1) Edit any page.

2) Click the save button.

3) Start typing your edit summary.

4) Stop typing your edit summary and start backspacing.

5) Click inside the Save dialog.

6) Type your edit summary again.

7) File another bug in Bugzilla.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 182976 merged by jenkins-bot:
Re-focus edit summary input when save dialog is ready

[[https://gerrit.wikimedia.org/r/182976]]
Change 182976 had a related patch set uploaded (by Alex Monk):
Re-focus edit summary input when save dialog is ready

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

#patch-for-review
Oh I did manage to reproduce what I think is this issue when I tried it on testwiki though - the focus moves from the summary field to somewhere else when I press save again.
The cursor always goes back to the summary field for me, after following those instructions.
Tricky to reproduce - happens only in test2: 

- make some changes on a page - click Save
- in 'Save your changes dialog box' check(or uncheck) 'This is minor edit' check box - notice that the cursor will be gone from the Summary area.
- click 'Resume editing' and make some changes again
- click Save - the cursor won't be placed in the Summary area anymore
Did anyone other than the reporter ever manage to reproduce this issue?
James also tried this and couldn't reproduce it. I think I may have asked someone else as well since... not sure.

If anything caused this, it's probably https://gerrit.wikimedia.org/r/172658/ (and -maybe- another thing related to the de-isolation of windows?)
Worksforme...
Is this a regression? I thought it used to work…
--------------------------
**Version**: unspecified
**Severity**: enhancement
Not really a tracking bug, on reflection.
Right now ViewPageTarget defines this.active, but it's set to true by mw.Target. This is horrible. The obvious fix is to push the setting to true down to ViewPageTarget, but we should consider whether the Target class itself should have some sort of active state.

--------------------------
**Version**: unspecified
**Severity**: enhancement
From comments at https://gerrit.wikimedia.org/r/#/c/173296/1/src/ui/filedrophandlers/ve.ui.DSVFileDropHandler.js :

* Right now every child class calls createProgress( insertableDataDeferred.promise() ); in its process() method. This seems like something that should be in the base class instead. Would you ever want to not do that, or pass a different promise?

* Child classes should not have to override abort() just to add this.reader.abort();, because this.reader is added by the base class.

--------------------------
**Version**: unspecified
**Severity**: enhancement
The fix 52792 will display a warning "This reference is used [n] times on this page." when editing Basic citation only. 

Apply the same warning when editing mutliple instances of any kind of citations.

--------------------------
**Version**: unspecified
**Severity**: enhancement
This is the same issue as editing the group of a non-basic citation.

It's possible by simply selecting the reference, opening the menu and selecting 'Basic' (even if it isn't basic).
Hi, I'm posting this request on behalf of the https://ca.wikiquote.org admins. They want to bring VisualEditor to their users. We have discussed this idea, and I see no problem at all. At the end, most articles there have a very simple structure with initial paragraph, some pictures, and then the same template used always for adding quotes.

I would be happy to help adding template data to the templates affected, and act as bridge in this test.

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
**URL**: https://ca.wikiquote.org/wiki/Viquidites:La_taverna#Editor_Visual_a_Viquidites
Indeed. Sorry for the mistake and thank you for fixing it so quick.
This was due to an edit to the {{Cita}} template. I've reverted it. https://ca.wikiquote.org/w/index.php?title=Plantilla:Cita&diff=50689
PLEASE REVERT THIS CHANGE ASAP

Something very weird is happening. In all pages "}}}}}}" appears instead of quotes. I mean all pages, not the ones edited with VE. Seeing the source and the history, I can't find any explanation.

See for instance https://ca.wikiquote.org/wiki/Pensaments_den_Goethe
Now done:
https://ca.wikiquote.org/w/index.php?title=Especial:Canvis_recents&tagfilter=visualeditor
Change 174036 merged by jenkins-bot:
Enable VisualEditor by default on Catalan Wikiquote (cawikiquote)

https://gerrit.wikimedia.org/r/174036
Change 174036 had a related patch set uploaded by Jforrester:
Enable VisualEditor by default on Catalan Wikiquote (cawikiquote)

https://gerrit.wikimedia.org/r/174036
(In reply to Glaisher from comment #1)
> Posting a link here to community consensus might be helpful.

Fair enough. I posted https://ca.wikiquote.org/wiki/Viquidites:La_taverna#Editor_Visual_a_Viquidites

Note that the ca.wikiquote.org community of regular contributors is very small (this is why they are so interested in VisualEditor). Docosong is the only admin. Unapersona is the second most active contributor currently. ESM, KRLS, and ArnauGir are veteran contributors (the last two also ca.wiki admins helping bridging this project with the rest of Catalan-speaking sister projects).

You can wait for more voices, or you can trust the current result.  :)

> Also should it
> be enabled by default or should it be enabled as a Beta Feature?

In our discussion at the conference, they said that they preferred to have it side by side next to the "edit source", because new users are very unlikely to find the option to enable it, or even know that such thing exists.
Posting a link here to community consensus might be helpful. Also should it be enabled by default or should it be enabled as a Beta Feature?
Nov 15 12:32:30 mw1023:  #012Notice: Undefined index: newtimestamp in /srv/mediawiki/php-1.25wmf7/extensions/VisualEditor/ApiVisualEditorEdit.php on line 137

--------------------------
**Version**: unspecified
**Severity**: minor
Change 173747 merged by jenkins-bot:
Don't try to get newtimestamp from edit if no change was made

https://gerrit.wikimedia.org/r/173747
Change 173747 had a related patch set uploaded by Alex Monk:
Don't try to get newtimestamp from edit if no change was made

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

Click the Link inspector. Note the local link created.

Click Remove. 

Click the Link inspector again. 

See an entirely different UI showing "New page/Matching pages"

Click in the ContentEditable part. "New page/Matching pages" UI disappears. 

Click the Link inspector again. 

Nothing happens. Link inspector stops working completely.

--------------------------
**Version**: unspecified
**Severity**: normal
This looks like it was fixed a while ago.
Also, happens when you type a text and select that and try to open link inspector for it
Environment:betalabs,test2, en.wiki
Steps to reproduce:

1.Go to this page:http://en.wikipedia.beta.wmflabs.org/wiki/Media_Interface_VisualEditor_Test?veaction=edit

2.Click on link inspector icon from the toolbar , but make sure you do not place your cursor in the article first

3.Once the link inspector opens for the first text "Media" , click on "Done" or "Remove" to close the link inspector.Again, do not place the cursor inside CE

4.Click on link inspector icon from the toolbar again

At this step, you will see a broken UI for link inspector,just the link suggestions are appearing as the screenshot.

Also, after this step link inspector stops working completely, clicking on the link icon from the toolbar does not open link inspector for any other text in the article .
FWIW, I can repro this consistently in Firefox 32.0.3
Created attachment 17126
clicking Link no longer invokes the Link inspector at all

**Attached**: {F15328}
Created attachment 17125
after clicking Remove and then clicking Link inspector again

This is clearly wrong

**Attached**: {F15327}
Created attachment 17124
after invoking Link inspector the first time, before clicking Remove

**Attached**: {F15326}
I cannot reproduce this issue following these steps either.
On http://en.wikipedia.beta.wmflabs.org/wiki/Media_Interface_VisualEditor_Test?veaction=edit - the link was applied to a specific word(s)? 

I tried to follow your scenario with the word Test on that page - "New page/Matching pages" seems to be identical with any attempts.
Note: this behavior is seen in Firefox. Chrome seems to be OK.
Gallery with caption gets added to the table inside the image

Environment- test2, beta, production

1> Insert -> media 
2> insert a table in the caption sub- editor of Media Settings.Click to insert to the main editor.
2> Highlight the media, insert a gallery with just caption(no filename).
3> Now drag and drop the gallery on to the table inside the image. Notice the gallery gets added to the table inside the image.
4> click on the image’s context menu to go to media settings, notice the gallery shows up in the caption pane.See screenshot.

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

**Attached**: {F15189}
Verified the fix in test2.
Verified the fix in betalabs.
**gerritadmin** wrote:

Change 173442 merged by jenkins-bot:
Don't allow dropping inside a handlesOwnChildren node

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

Change 173442 had a related patch set uploaded by Catrope:
Don't allow dropping inside a handlesOwnChildren node

https://gerrit.wikimedia.org/r/173442
Step 3 should not be possible and is fixed by https://gerrit.wikimedia.org/r/#/c/173442/
(In reply to etonkovidova from comment #5)
> Yes, I checked the functionality of inserted tables - all is fine(a tiny bug
> 73435 was filed). 
> 
> Btw, Gallery can be dragged to a Media's Caption.
yes, if there is something in the media's caption(not just tables even plain text)the gallery gets added to the media's caption.

or

if you had something in the media caption and you deleted it.And then if you drag a gallery to the media's caption part it gets added.

steps- 
1> go to media settings dialog. 
2> type in some text in the caption pane,and apply changes.
3> insert a gallery.
4> reopen the media settings dialog and delete the caption you put in, at step#2.
5> now drag the gallery to where the media's caption was. Notice a line is gets drawn and the gallery gets added.
Yes, I checked the functionality of inserted tables - all is fine(a tiny bug 73435 was filed). 

Btw, Gallery can be dragged to a Media's Caption.
Tables inside captions are okay. They probably shouldn't be encouraged but in the cases where they exist, we need to provide the tools to edit them.
Gallery(with just caption) can be added to a table in the main editor.
Gallery cannot be added to an image otherwise and is also not available as an insert sub menu option in the media settings toolbar .But if the image has a table it gets added to it.
In addition to bug 73341 - should tables be allowed for insertion in Media settings?
Also in FF 33.1.
See https://tl.wikipedia.org/wiki/Wikipedia:VisualEditor/Komentaryo#Did_you_know_why.3F .

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
**URL**: https://tl.wikipedia.org/wiki/Wikipedia:VisualEditor/Komentaryo#Did_you_know_why.3F
Now done.
**gerritadmin** wrote:

Change 172993 merged by jenkins-bot:
Enable VisualEditor by default on Tagalog Wikipedia

https://gerrit.wikimedia.org/r/172993
(In reply to Roan Kattouw from comment #3)
> Once the schedule for next week is put on the wiki page, I'll schedule this
> change again, probably for either Monday 16:00-17:00 UTC or Tuesday
> 00:00-01:00 UTC.
> 
Now scheduled for 00:00-01:00 UTC on Tuesday November 18.
(In reply to Gerrit Notification Bot from comment #2)
> Change 172993 had a related patch set uploaded by Jforrester:
> Enable VisualEditor by default on Tagalog Wikipedia
> 
> https://gerrit.wikimedia.org/r/172993

We planned to deploy this about 6 hours ago, but because of an issue with other VisualEditor changes scheduled for the same time, the deployer overlooked this change and I didn't notice that he hadn't deployed it until it was way too late :(

Once the schedule for next week is put on the wiki page, I'll schedule this change again, probably for either Monday 16:00-17:00 UTC or Tuesday 00:00-01:00 UTC.

Sorry for spacing on this :(
**gerritadmin** wrote:

Change 172993 had a related patch set uploaded by Jforrester:
Enable VisualEditor by default on Tagalog Wikipedia

https://gerrit.wikimedia.org/r/172993
Sure.
Link inspector opens at the upper left corner

Only Safari(betalbs, test2, production)

1. In VE type a word and convert it into a link.

2. Place a cursor at the end of the word - the link inspector opens at the upper left corner of the screen. The screenshot is attached. 

Note: The link inspector opens correctly if the cursor is placed in the middle of an inserted link. Place a cursor at the end of the link and start moving left - the position of the link inspector will be changed from the correct.

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

**Attached**: {F15101}
Duplicate to 76083.
Created attachment 17174
Safari link inspector

**Attached**: {F15102}
**gerritadmin** wrote:

Change 173007 merged by jenkins-bot:
Update RangeFix library 0.1.0 -> 0.1.1

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

Change 173007 had a related patch set uploaded by Esanders:
Update RangeFix library 0.1.0 -> 0.1.1

https://gerrit.wikimedia.org/r/173007
Safari browser bug. Applying patch upstream in rangefix.
This is bug 72251 for magic words.  

{{cite book|isbn=1234567890}} displays as a redlink, and it shouldn't.

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to etonkovidova from comment #4)
> I copied  
> {{cite book|isbn=123456789X|url = http://www.amazon.com|title = Fish}} from
> http://en.wikipedia.beta.wmflabs.org/wiki/User:Jdforrester_(WMF)/Bug_73320
> and pasted it into test2 - look at the attached screenshot. 
> 
> 
> <a
> href="/w/index.php?title=International_Standard_Book_Number&amp;
> action=edit&amp;redlink=1" class="new" title="International Standard Book
> Number (page does not exist)">ISBN</a>
> 
> @media screen
> 
> a.new:visited, #p-personal a.new:visited {
> 	.	 color: #a55858;
> 
> 
>  ISBN is still red.

Yeah, because the word "ISBN" links to a page that doesn't exist. This is about the number being red.
I copied  
{{cite book|isbn=123456789X|url = http://www.amazon.com|title = Fish}} from http://en.wikipedia.beta.wmflabs.org/wiki/User:Jdforrester_(WMF)/Bug_73320 and pasted it into test2 - look at the attached screenshot. 


<a href="/w/index.php?title=International_Standard_Book_Number&amp;action=edit&amp;redlink=1" class="new" title="International Standard Book Number (page does not exist)">ISBN</a>

@media screen

a.new:visited, #p-personal a.new:visited {
	.	 color: #a55858;


 ISBN is still red.
Created attachment 17122
ISBN is  displayed in red

**Attached**: {F15070}
Confirmed with http://en.wikipedia.beta.wmflabs.org/wiki/User:Jdforrester_(WMF)/Bug_73320 – marking as FIXED.
I can reproduce this at en.wp today, but not at en.wikipedia.beta.wmflabs.org, so presumably the problem has already been fixed.
screenshot in chrome

Environment- test2, beta

1> Insert a media with default settings.
2> keeping the media highglighted,insert a gallery with just caption(no filename).
3> Now drag and drop the gallery to the image and then image to the gallery. Either way it draws focusablenode dropmarker lines above and below the media content. See screenshots.

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

**Attached**: {F14939}
Confirmed - the "extra" element that appears during drag-and-drop is <p contenteditable="false" class="ve-ce-branchNode-slug ve-ce-branchNode-blockSlug">﻿

However, the saved page does not have any traces of extra lines.
Created attachment 17095
screenshot in FF 33.1

**Attached**: {F14940}
1. Open a document that contains a line of plain (not linked) text with an inline focusable node (e.g. template or reference)
2. Use the mouse to put the cursor on this line, some distance away from the text
3. Use the arrow keys to move the cursor to the focusable node
4. When the node is focused, the context flickers in the position where you clicked in step 2 before moving to the focusable node

This doesn't happen when you use the mouse to focus the node. It also doesn't happen when the context appears for an annotation (e.g. link).

--------------------------
**Version**: unspecified
**Severity**: minor
Verified the fix in beta.
Change 173804 merged by jenkins-bot:
Don't always use updateDimensionsDebounced

https://gerrit.wikimedia.org/r/173804
Change 173804 had a related patch set uploaded by Esanders:
Don't always use updateDimensionsDebounced

https://gerrit.wikimedia.org/r/173804
Change 5130 abandoned by TheDJ:
mediawiki.action.edit: Autosave edit textareas in localStorage

Reason:
No progress on this for the past year, abandoning.

[[https://gerrit.wikimedia.org/r/5130]]
Doesn't fit the definition of stalled. https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle
Change 5130 had a related patch set uploaded (by Jdlrobson):
mediawiki.action.edit: Autosave edit textareas in localStorage

[[https://gerrit.wikimedia.org/r/5130]]
Looks stalled to me.
Merged in ContentTranslation: 00ebcc6e3e31b278092abde755cbd9009ef65cf4
No idea how much of its code/idea is reusable.
(In reply to Umherirrender from comment #3)
> You have linked the bug, but there should also be a link to
> [[mw:Extension:Drafts]], which supports auto saving on the server side.

Sure, though that's not ready and even if it was, is not getting deployed to Wikimedia wikis, for reasons explained at length.
You have linked the bug, but there should also be a link to [[mw:Extension:Drafts]], which supports auto saving on the server side.
Change 159626 had a related patch set uploaded by Nemo bis:
Drafts: Refactor with IndexedDB

https://gerrit.wikimedia.org/r/159626
Change 5130 had a related patch set uploaded by Nemo bis:
mediawiki.action.edit: Autosave edit textareas in localStorage

https://gerrit.wikimedia.org/r/5130
I can successfully drag-n-drop an image from one part of the page to another in VE while using Chrome and Firefox, but not IE.

Chrome and FF provide feedback, indicating where the object will land if it is dropped, but IE doesn't.  Nor does dropping the object move it.

I don't see any errors in the js console on IE during this process.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51669
Change 284361 merged by jenkins-bot:
Fix node drop in IE9

[[https://gerrit.wikimedia.org/r/284361]]
Change 284361 had a related patch set uploaded (by Esanders):
Fix node drop in IE9

[[https://gerrit.wikimedia.org/r/284361]]
Filed the exception as a different bug. Apart from that works in IE11/10 but not 9, where I get a different exception (cannot slice undefined).
Removing the table row where rowspanned cell starts un-merges the remaining spanned cells.

1. Look at the tables.html demo.
2. In "Merged cells" example, place cursor at the "10" cell.
3. Delete row.

The "4" cell has correctly changed from spanning three to two rows. However, the "9" cell has split into three cells, while it should have been changed from spanning four to three rows instead.

Analogous behavior occurs when removing the column where a colspanned cell starts. (Try with the "16" cell.)

--------------------------
**Version**: unspecified
**Severity**: normal
Change 172193 merged by jenkins-bot:
Don't unmerge spanned cells when spanned cell is removed

https://gerrit.wikimedia.org/r/172193
Change 172193 had a related patch set uploaded by Bartosz Dziewoński:
[WIP] Don't un-merge spanned cells when spanned cell is removed

https://gerrit.wikimedia.org/r/172193
VisualEditor: "Insert table" tool should be (also?) in the "Table" menu, not (or in addition to?) "Insert" menu. I was quite confused for a moment by the table icon being grayed out, and I've been told I'm not the only one.
Change 267532 merged by jenkins-bot:
Introduce table and table cell context

[[https://gerrit.wikimedia.org/r/267532]]
Change 267532 had a related patch set uploaded (by Esanders):
Introduce table and table cell context

[[https://gerrit.wikimedia.org/r/267532]]
My client asked about this and I told her "That's how it is on Wikipedia" and found this bug (before I filed my own, yay!).

I vote for enabling the icon when not in a table to allow for table creation.

If I were really sick, I'd say that the option to insert a table should remain available even when in a table cell, so that we could do 90s style webpage layouts in the VisualEditor.

But I'm only a little sick, so activating it to enable table creation/insertion is what I'm going with.
Alternatively, we could put the table inspector in the proper place (i.e., on the table) rather than over-loading the toolbar, which would remove the confusion.
The current option is highly temporary, AFAIK.
+1. When user wants to create a new table, he can see the icon in the toolbar, but it's marked as displayed. Really confusing. Imho, if we have a special menu for tables, "Insert table" should be placed there instead of being in "Insert menu". The current solution is reasonable, but unintuitive. (Maybe "Insert table" could be visible alternatively with "Delete table" #brainstorm).
After editing an unreviewed page using VisualEditor, reviewing the page doesn’t review the just-made edit if the page isn’t reloaded between publishing the edit and pressing review.

How to reproduce:
1) go to some article that hasn't been reviewed yet
2) make an edit to the article using Visual Editor. save the edit
3) review the article
4) when you look at the article history you can see that the article you marked as reviewed has one unreviewed change (the one you just did using VE)

I tried this at https://test2.wikipedia.org/wiki/Testing_something
But if you try to change it, you get "Invalid inclusion parameter key".
That key is actually a hash of several things (including the oldid): https://github.com/wikimedia/mediawiki-extensions-FlaggedRevs/blob/master/business/RevisionReviewForm.php#L211-L213
We'd need to regenerate it somehow I guess...
We're not updating the mw-fr-input-oldid hidden input in the FlaggedRevs page review form when we update the page contents.
We're not updating the oldid hidden in the FlaggedRevs page review form when we update the page contents.
We're not updating the oldid in the FlaggedRevs page review form when we update the page contents.
>>! In T75171#1471012, @Jdforrester-WMF wrote:
> Is this still an issue?

It is. Just tested it again at https://test2.wikipedia.org/wiki/Testing_something
Is this still an issue?
Splitting the bug from 72392.

Open a page in VE and insert a link with the shortcut - Ctrl+K - the link inspector opens and closes momentarily. 

The console displays the following(consistently): 

DOM7009: Unable to decode image at URL: 'data:image/gif;base64,R0lGODdhAQABAADcACwAAAAAAQABAAA'.  File: gif;base64,R0lGODdhAQABAADcACwAAAAAAQABAAA

--------------------------
**Version**: unspecified
**Severity**: normal
Seems to work fine now - please re-open if it is still broken for you.
Re: "Strange presentation"

On further examination, The "File:" bit was presented as a link with the full URL. Clicking the link took me to the contents of a 1x1 pixel.  That is, where you normally see source code or raw HTML in the debugger, I saw:
  1. GIF87a□□□Ü□,□□□□□□□□□

Maybe the data urls are messing with IE's head?
Just updated to the 1.25wmf21 branch and I'm seeing the message in IE11:

  DOM7009: Unable to decode image at URL: 'data:image/gif;base64,R0lGODdhAQABAADcACwAAAAAAQABAAA'.
  File: gif;base64,R0lGODdhAQABAADcACwAAAAAAQABAAA

There is a [[ http://stackoverflow.com/a/28426679 | stackoverflow answer ]] that indicates this may be related to OOM problems -- and the strange presentatoin of this ("File: gif;base64...") leads me to believe that might be  the case.

Note that I'm seeing this blatted on the console multiple times while simply selecting text.
@Etonkovidova: Why was "Verified-in-Phase0" set here?
Yes, the message in the console is unrelated to the issue. 

Reproducible **only in production** - inserting a link with a Ctrl+K displays flickering link inspector and move the cursor to the beginning of a paragraph. The link will, in fact, inserted, and can be edited afterwards without any problems. 

Inserting links with a short cut [[ or from Tool menu does not present any issues.
Can't reproduce. I get the message in the console, but only while VE is loading, unrelatedly to link inspector; the inspector opens and works perfectly fine.
Wait, the link inspector actually closes? I thought it was just the error...
Preformatted text in tables

In betalabs

1. In VE insert a table and double-click in any cell to make it editable.

2. Select the 'preformatted' option - the cell will be yanked from the table(similar to bug 72990). The preformatted are will be displayed outside of the table. 

The same happens when you apply preformatted to the cells' text.

Look at the screenshot.

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

**Attached**: {F15190}
Verified the fix in test2 and production.
Verified the fix in Betalabs.
Definitely fixed, I ran into this in prod today, wanted to file a bug and couldn't reproduce on master. Now I know why. :)
Change 171835 merged by jenkins-bot:
Support pre's in tables

https://gerrit.wikimedia.org/r/171835
Change 171835 had a related patch set uploaded by Esanders:
Support pre's in tables

https://gerrit.wikimedia.org/r/171835
From gerrit 170869:
> Gabriel suggested that in the future we migrate to the PHP Virtual REST Service and through that share code between Flow, VE and anything else that wants to talk with parsoid.
https://www.mediawiki.org/wiki/Requests_for_comment/PHP_Virtual_REST_Service

With [[ https://gerrit.wikimedia.org/r/#/c/181011/ | gerrit 181011]] VisualEditor is doing this, so Flow can do the same and remove whatever cookie hacks @Ebernhardson needed to access Parsoid from the private officewiki.

--------------------------
**Version**: master
**Severity**: minor
screenshot of JS errors in beta

Environment- test2, beta

1> In a blank page, open the Language inspector.
2> While the inspector is open ,select any Heading format from the drop-down,for ex- select Heading.
2> The inspector closes and you see the language context menu. 
3> type in some text, it doesn’t take the language annotation(looks like plain paragraph text)
4> Hit enter and JS error “Uncaught Error: Inserted data is trying to close the root node (at index 0)”. See screenshot.
5> Notice no matter where your cursor is on the page, the language context menu never moves from its place or closes for a new line.

In beta an additional  JS error appears at step#2, “Uncaught Error: Offset could not be translated to a DOM element and offset: 2”.

Reproducible in FF too.

--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Windows XP

**Attached**: {F14776}
Yes, it is. 
Here, I was also pointing at the typed text appearing plain, i.e., without any language annotation.
Isn't that already reported as T76717?
{F27349}Screenshot of the JS Error "Offset could not be translated to a DOM element and offset: 2".
I could not reproduce it either.But I did get the JS  error “Uncaught Error: Offset could not be translated to a DOM element and offset: 2” and the text typed was just plain paragraph-like.

Here are the steps-:

Environment- test2, beta

1> In a blank page, open the Language inspector.
2> While the inspector is open ,select any Heading format from the drop-down,for ex- select Heading.
3> The inspector closes and you see the language context menu. 
4> Type some text, it doesn’t take the language annotation(looks like plain paragraph text).JS error “Uncaught Error: Offset could not be translated to a DOM element and offset: 2” appears.

See the screencast at http://youtu.be/qXID9SlMClo
I can't reproduce this.
Confirmed in betalabs Chrome.
To reproduce:

- Navigate to an article
- Open Chrome's Developer Tools
- Click 'Profiles'
- Select 'Collect JavaScript CPU Profile'
- Click 'Start'
- Click 'Edit [beta]'
- Wait for VisualEditor to finish loading
- Click 'Stop'

Result:

Both oo.Factory.create or oo.EventEmitter.emit are flagged by the profiler with the warning: "Not optimized: Inlining bailed out."

To investigate, I recommend reading <https://github.com/GoogleChrome/devtools-docs/issues/53>

v8 comes with a 'd8' executable that can be used for getting some performance debug info from v8. If you can craft a file that utilizes these functions without depending on the DOM API, you can try running it with:

> d8 --trace-opt --trace-bailout some-js-file.js

--------------------------
**Version**: unspecified
**Severity**: enhancement
Change 186244 merged by jenkins-bot:
v8 opt: Copy arguments into new array rather than use [].slice

[[https://gerrit.wikimedia.org/r/186244]]
Change 186244 had a related patch set uploaded (by Jforrester):
v8 opt: Copy arguments into new array rather than use [].slice

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

#patch-for-review
EventEmitter.emit also seems to be because of arguments. I checked, though, and there's very little "self" time spent in EventEmitter.emit and Factory.create: 25ms and 53ms respectively for Obama. But I'll see what that drops to after optimizing them.
For oo.Factory.create, my version of Chrome tells me "Not optimized: Bad value context for arguments value" which seems to be a consequence of doing args = Array.prototype.slice.call( arguments, 1 ); . I don't really see a way around that, unless there's some way of making the arguments list a real array that V8 is able to optimize.

For oo.EventEmitter.emit it does say "Inlining bailed out". I'm installing d8 now to investigate.

I saw a bunch of other "not optimized" warnings too, but most of those seem to be about try-catch statements. The only other one that jumped out at me was in oo.copy: "ForInStatement is not fast case". Will investigate that too.
Edit summary textbox is black

Steps to reproduce: 

 In IE 11 perform some editing in VE and click Save page.

Observe: 'Edit summary' text box is displayed black. When clicked in it - it becomes white. 

The screenshot is attached.

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

**Attached**: {F15398}
Can't reproduce even if I display input.focus() (which has always worked, I think).
Well you said:
> When clicked in it - it becomes white.

So I assume you focusing it was just hiding the problem, and we now do it automatically.
Is it black if we don't focus? If so, what other dialogs are affected by this IE bug?
So I can't reproduce this in IE11 but I assume that's because we auto-focus that text box now? What shall we do about this task?
So I can't reproduce this in IE11 but I assume that's because we auto-focus this now? What shall we do about this task?
Edit any page in beta labs e.g. http://en.wikipedia.beta.wmflabs.org/wiki/Media_Interface_VisualEditor_Test?veaction=edit

Perform some action, for example highlight text and indent some. 

Click Save page and then click Resume editing from the Save modal dialog.

Upon returning to the edit page, VE edit tools should be enabled but are not enabled.  User must click again in the CE area to enable edit tools.

--------------------------
**Version**: unspecified
**Severity**: minor
Verified in test2.
Change 172658 merged by jenkins-bot:
Restore selection after closing save dialog

https://gerrit.wikimedia.org/r/172658
Change 172658 had a related patch set uploaded by Alex Monk:
Restore selection after closing save dialog

https://gerrit.wikimedia.org/r/172658
screenshot showing multiple Categories with same title

Environment- production, test2

1>Select Categories. Add a category for ex- “Japan”.
2>The cursor moves to the next input field. Type in “Japan” again. Click somewhere else in the modal, to move the focus. 
3>Click back in the input field. While the cursor is in the field,hit enter key.
4>The category with the same name Japan gets added.See screenshot.

In beta, at step#2, after typing in the title, just click twice in the input field(to close the drop-down) and hit enter key. The category with the same title gets added.

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

**Attached**: {F15381}
Verified in production.
The fix is verified in betalabs and test2.
**gerritadmin** wrote:

Change 171033 merged by jenkins-bot:
Kill MWCategoryWidget#onLookupEnter

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

Change 171033 had a related patch set uploaded by Alex Monk:
Kill MWCategoryWidget#onLookupEnter

https://gerrit.wikimedia.org/r/171033
Sorry, Alex.
Confirmed in betalabs, test2, and production.
There is text in these forms that can only be seen when selecting.

The same issue as described in bug 72188 applies in VisualEditor; namely that dark system settings lead to unreadable text in certain forms. This is almost certainly because the background colour has been defined and the text colour has been left to the system, leading, in this case, to white text on a white background.

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

**Attached**: {F15230}
**gerritadmin** wrote:

Change 172174 merged by jenkins-bot:
Match 'color' rules to 'background-color' rules for accessibility

https://gerrit.wikimedia.org/r/172174
(In reply to etonkovidova from comment #1)
> Is it duplicate to 72192? 

It's not a duplicate of bug 72192, but it's the same issue. The codebases are unfortunately still separate.
**gerritadmin** wrote:

Change 172174 had a related patch set uploaded by Bartosz Dziewoński:
Match 'color' rules to 'background-color' rules for accessibility

https://gerrit.wikimedia.org/r/172174
I'll look into this.
Is it duplicate to 72192? 

Tried it with Chrome(Mac) and with 'Cite web' template - it's not reproducible.
Steps to reproduce:

1.  Open a page in Firefox (v. 32.0.3 on Mac 10.8.5) that contains several refs in a row:  [1][2][3][4].

2.  Decide that refs 1, 2, and 3 are inappropriate.  Place cursor between refs 3 and 4.

3.  Press shift + back arrow to start selecting the refs.


Results:

Press shift + left arrow once:  [3] is highlighted.  Press it again (i.e., to extend the selection to include [2]):  [3] is no longer highlighted.  Press it again:  [3] is highlighted again.  

Repeat cycle of select-deselect as long as you would like.


Workaround:

Place cursor before ref [1], and select the three refs by pressing shift + forward arrow.


I cannot reproduce this in Safari 6.1.2.  I haven't tested it in a LTR (left-to-right) language.

--------------------------
**Version**: unspecified
**Severity**: minor
Verified the fix in production(in FF) - backward selection(highlighting) works smoothly and no js errors are displayed.
The fix is confirmed in test2 and betalabs.
Change 170697 merged by jenkins-bot:
Catch backwards selection error in Firefox

https://gerrit.wikimedia.org/r/170697
Change 170697 had a related patch set uploaded by Esanders:
Catch backwards selection error in Firefox

https://gerrit.wikimedia.org/r/170697
Confirmed in FF  test2: cannot select a group of reference with Shift+left arrow(highlighting nackward) - NS_ERROR_FAILURE is displayed.

This is perfectly functioning in Chrome - a group of references can be selected with Shift+right arrow and back wards.
Screenshot

Steps to reproduce:

1.Insert a table
2.Insert an empty caption to the table
3.Save the page
4.Now select any cell in the table

Observe that,the column editing icon at the top of the empty space which looks odd 

See the screenshot attached

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

**Attached**: {F15173}
Verified the fix in production
Verified the fix in Betalabs and test2
**gerritadmin** wrote:

Change 172225 merged by jenkins-bot:
Position the table context relative to the first section node

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

Change 172191 abandoned by Bartosz Dziewoński:
TableNode: Position row/column overlays better when caption is present

Reason:
Superseded by I3d790d71

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

Change 172225 had a related patch set uploaded by Esanders:
Position the table context relative to the first section node

https://gerrit.wikimedia.org/r/172225
(In reply to Bartosz Dziewoński from comment #2)
> To the unfortunate soul tasked with resolving this

Nevermind, it was fun.
**gerritadmin** wrote:

Change 172191 had a related patch set uploaded by Bartosz Dziewoński:
TableNode, TableContext: Position row/column overlays better when caption is present

https://gerrit.wikimedia.org/r/172191
To the unfortunate soul tasked with resolving this: there exists a CSS
'caption-side' property, which allows the caption to be placed on every of the four usual sides (at least on Firefox, Chrome only supports 'top' and 'bottom'). (It is also supposed to accept a number of other unorthodox values, but it seems no one cares much about those.)
(In reply to Rummana Yasmeen from comment #0)
> 3.Save the page
> 4.Now select any cell in the table

Not necessary, this is immediately visible when you add the empty caption and move selection back to a table cell.
Screenshot in Betalabs

Compare the screenshots taken from Betalabs and test2 for the Page Settings tab and see how they are all cramped in Betalabs

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

**Attached**: {F15065}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 170789 merged by jenkins-bot:
Followup d3367bb: make FieldsetLayout <label>s display: block;

https://gerrit.wikimedia.org/r/170789
Change 170789 had a related patch set uploaded by Catrope:
Followup d3367bb: make FieldsetLayout <label>s display: block;

https://gerrit.wikimedia.org/r/170789
Created attachment 16970
Screenshot in test2

**Attached**: {F15066}
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Template
3.Type a template name in the textbox
4.Now click on the "Show Options" button without selecting anything from the dropdown and closing it

Observed Result:
The drop down for search results stays in the dialog in the middle of the left panel and add template panel

See the screenshot attached

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

**Attached**: {F15056}
Verified the fix in production
Verified the fix in Betalabs and test2
**gerritadmin** wrote:

Change 170280 merged by jenkins-bot:
MWTransclusionDialog: Blur active input when switching modes

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

Change 170280 had a related patch set uploaded by Catrope:
MWTransclusionDialog: Blur active input when switching modes

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

Steps to reproduce:

1.Open a page with VE
2.Go to Basic References or References list dialog
3.Place cursor inside the "Use this group" combo box


Observed Result:
The group names for reference list are appearing in a short form

See the screenshot attached

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

**Attached**: {F15039}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
**gerritadmin** wrote:

Change 170784 merged by jenkins-bot:
MWReferenceGroupInputWidget: Remove dummy call to onInputChange()

https://gerrit.wikimedia.org/r/170784
(In reply to Gerrit Notification Bot from comment #6)
> Change 170784 had a related patch set uploaded by Catrope:
> MWReferenceGroupInputWidget: Remove dummy call to onInputChange()
> 
> https://gerrit.wikimedia.org/r/170784

This patch doesn't look like it fixes this bug?
**gerritadmin** wrote:

Change 170784 had a related patch set uploaded by Catrope:
MWReferenceGroupInputWidget: Remove dummy call to onInputChange()

https://gerrit.wikimedia.org/r/170784
(In reply to Elitre from comment #4)
> (Is this different from Bug 72785?)

Yes. That's about the height of the box, this is about the width of the text.
(Is this different from Bug 72785?)
Confirmed that this is a regression from https://gerrit.wikimedia.org/r/#/c/169968/
Trevor says it's probably caused by the menu being shown too early.
James thinks this may be a regression from https://gerrit.wikimedia.org/r/#/c/169968/
Please.

--------------------------
**Version**: unspecified
**Severity**: major
Slugs are now inserted with buttons which are ce=true
(In reply to Ed Sanders from comment #3)
> *sigh* Chrome doesn't even let you set such a selection programmatically, so
> it appears book-ending is required. Although I'd like to do programmatic
> handling too to catch things like table and focusable node selections (where
> the native selection is in the paste target).

So… gerrit 172039 didn't fix this. Is it do-able?
*sigh* Chrome doesn't even let you set such a selection programmatically, so it appears book-ending is required. Although I'd like to do programmatic handling too to catch things like table and focusable node selections (where the native selection is in the paste target).
Solutions:

1. Book-end the document with selectable but invisible content. Have to make sure this doesn't break ve.ce.getOffset.

2. Register CTRL+A as a trigger and do it programmatically.


Further complicating the issue is CE true inside CE false inside CE true, as is the case with table cell editing. In this case CTRL+A should only select the cell contents, so any programmatic solution would have to be aware of that, and any book-end solution would have to work in these "sub-surfaces" as well.
Chromium bug, has been around for a year, but maybe we've made it more common by having ce=false slugs?

https://code.google.com/p/chromium/issues/detail?id=322444

http://jsfiddle.net/edg2s/afhq6ef0/
Convert several MW core special pages to OOUI as a demonstration that it's possible now.

Part of "front-end standardisation" Q2 priority project.
For further work see T107037.
I think this task, as written ("Convert some MW core special pages to OOUI"), is sufficiently resolved. We have converted some special pages, and then some more (although most of the relevant commits weren't linked to this bug).

Quick tally:

* Special:ChangeContentModel (fa31bf1675af7255431aeffd9757066e0ce572e2)
* Special:ChangeEmail (b51076a84446d157bed511246450e70d26e0f945)
* Special:LinkSearch (5bd98dacfaaf08e9645fdb215a6e18e9d7f80c04)
* Special:PageLanguage (b51076a84446d157bed511246450e70d26e0f945)
* Special:PasswordReset (b51076a84446d157bed511246450e70d26e0f945)
* Special:ResetTokens (2550de9552230585e33b45f37cada0f13e396953)

Several more are in progress or waiting for reviews.
This is excellent!

Are you going to Cc a designer to review? E.g. the label was intended to sit closer to the field underneath, which is still the case on [[ https://en.wikipedia.org/wiki/Special:UserLogin | login form ]].

> These pages were previously using the "VForm" style and switching them over to the new "OOUI" style
vform stood for "vertically-stacked form", everything was intended to be the same width.  It was a `$displayFormat` different from the existing div, table, and raw which also used mediawiki.ui styles. I think clients should be able to request  buttons styled as OOUI without getting the vform layout e.g. OOUI buttons in 'table' display format.

When you specify 'vform' as displayFormat, the form width needs to be constrained. (Picking a width for vform was challenging, it ended up being determined by the width of the restyled FancyCaptcha on the login form.).
Change 208285 had a related patch set uploaded (by Mattflaschen):
[WIP] Switch some HTMLForms in special pages to OOUI

[[https://gerrit.wikimedia.org/r/208285]]
Change 208285 had a related patch set uploaded (by Jforrester):
[WIP] Switch some HTMLForms in special pages to OOUI

[[https://gerrit.wikimedia.org/r/208285]]
Also, once the value is changed, we can take out some of the weird special-casing in forms that use OOUI or mwui in part - BetaFeatures comes to mind immediately (so Special:Preferences in general), but OAuth and many other core forms will benefit.
Here are some screenshots of the "first iteration", brought to you by @marktraceur's work on T85291. These pages were previously using the "VForm" style and switching them over to the new "OOUI" style, once implemented, is a matter of changing a single value.

# Special: ChangeEmail
| VForm | OOUI |
| -- | -- |
| {F163967,height=240} | {F163969,height=260} |

# Special: ResetPassword
| VForm | OOUI |
| -- | -- |
| {F163952,height=250} | {F163954,height=250} |

Issues:
* The help icon looks slightly blurry, this will be fixed after T97631.
* The checkbox is smaller, this is a design decision being discussed on T86003.

# Special: PageLanguage
| VForm | OOUI |
| -- | -- |
| {F163958,height=170} | {F163960,height=180} |

Issues:
* The extremely long dropdown list with languages has usability issues, most importantly T91126.
* Radio buttons are not OOUI-like yet, we're working on this on T98855.
Here are some screenshots of the "first iteration", brought to you by @marktraceur's work on T85291. These pages were previously using the "VForm" style and switching them over to the new "OOUI" style, once implemented, is a matter of changing a single value.

# Special: ChangeEmail
| VForm | OOUI |
| -- | -- |
| {F163967,height=240} | {F163969,height=260} |

# Special: ResetPassword
| VForm | OOUI |
| -- | -- |
| {F163952,height=250} | {F163954,height=250} |

Issues:
* The help icon looks slightly blurry, this will be fixed after T97631.
* The checkbox is smaller, this is a design decision being discussed on T86003.

# Special: PageLanguage
| VForm | OOUI |
| -- | -- |
| {F163958,height=170} | {F163960,height=180} |

Issues:
* The extremely long dropdown list with languages has usability issues, most importantly T91126.
* Radio buttons are not OOUI-like yet, we're working on this on T91126.
Change 208285 had a related patch set uploaded (by Bartosz Dziewoński):
[WIP] Switch some HTMLForms in special pages to OOUI

[[https://gerrit.wikimedia.org/r/208285]]
This would be a lot less unpleasant if somebody did T19312, or maybe even T12317, first.
I was wondering if we could have a feature whereby multiline selected text could be enveloped in one <pre> or <code> when the corresponding heading level or text formatting option is clicked from the toolbar.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Ignore the "Viewing Profile Info" part. It could be any section :)
Suppose one visits an article using Google Chrome for Mac OS. After selecting two consecutive paragraphs in the "Viewing Profile Info" section, then choosing either "Preformatted" from the heading level dropdown, or "{ } Computer code" from the text formatting popover "pane", two <code> or two <pre> sections are created, not one. Furthermore, if one starts a new stanza with "Preformatted" or "{ } Computer code" heading level / formatting, upon pressing the Enter key (as well as Command+Enter for the typical non-terminating line break in Mac OS or Shift+Enter), the editing context switches out of <pre> or <code> mode.
(If I select multiple lines, I'm able to wrap them in code tags using the corresponding option in the toolbar. How is this different from your request?)
Found in Safari test2.

1. In VE type some text(spanned several lines), highlight it and apply computer code formatting option. 

2. Delete one line of code - Console shows: Failed to load resource: The operation couldn’t be completed. (kCFErrorDomainCFNetwork error -10.)

--------------------------
**Version**: unspecified
**Severity**: normal
This sounds… odd.
Actually, the console error: "Failed to load resource: The operation..." shows for all formatting options - underline, bold, strikethrough etc

The error is displayed when the previously formatted chunk of text is deleted.
a screenshot with the problem

To reproduce, edit an old version of a Hebrew Wikipedia article, e.g.:
https://he.wikipedia.org/w/index.php?title=ASCII&oldid=15904477&veaction=edit

The popup with the edit notice about editing an old version appears immediately. It's misaligned and shown mostly out of screen.

See the screenshot.

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

**Attached**: {F14738}
Attached is a screenshot from betalabs -Page settings menu box  still overflows. The browser window was  Maximized.
Created attachment 16988
Page settings menu overflow

**Attached**: {F14739}
This was fixed in wmf5 by Roan.
Confirmed on https://he.wikipedia.org/w/index.php?title=ASCII&oldid=15904477&veaction=edit 

Both 'Page options' and 'Help' boxes are cut off.
To reproduce:

1. Edit the Hebrew Wikipedia article about Haifa:
https://he.wikipedia.org/wiki/%D7%97%D7%99%D7%A4%D7%94?veaction=edit

2. Click the infobox on top left.

Observed: The pop-up puzzle bubble for editing the template appears to the left of the infobox, goes off-screen and creates a horizontal scroll-bar.

Expected: The pop-up puzzle bubble must appear in a visible convenient place.

--------------------------
**Version**: unspecified
**Severity**: normal
Checked in beta/test2/production  including the page https://he.wikipedia.org/wiki/%D7%97%D7%99%D7%A4%D7%94?veaction=edit  - all look good to me too.
Looks good to me now. Not sure when it was fixed.
Did we fix this in master? It looks "fine" (different breakage) on http://he.wikipedia.beta.wmflabs.org/wiki/%D7%95%D7%99%D7%A7%D7%98%D7%95%D7%A8_%D7%9B%D7%A8%D7%99%D7%A1%D7%98%D7%A0%D7%A7%D7%95?veaction=edit&uselang=he
screenshot

Environment- test2

1> In a blank page insert an image with a wikilink as caption.
2> Now click on the image in the main editor. Notice in the context menu,  along with the name of the image now the link also appears.
3> click on the context menu and it opens the link inspector for you populated with the target.

See screenshot.

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

**Attached**: {F15374}
Confirmed that the bug exists in betalabs and test2.
(In reply to Ritu Swain from comment #1)
> Also see 72431.
https://bugzilla.wikimedia.org/show_bug.cgi?id=72431
Also see 72431.
For things like auto-save (T57370) and collaboration.
Change 231017 merged by jenkins-bot:
Provide methods to (de)serialize transactions

[[https://gerrit.wikimedia.org/r/231017]]
Change 231017 had a related patch set uploaded (by Esanders):
Provide methods to (de)serialize transactions

[[https://gerrit.wikimedia.org/r/231017]]
IE11 transparency flaws

Steps to reproduce: 


1. Open any page in VE on IE11(test2). 

2. Click on 'Page option' icon and select 'Options'

3. Options-Advanced settings have three small info icons - click on each of them - the box becomes transparent(look at the attched screenshot). There is also a screenshot of how it behaves in Chrome, for comparison. 

Another way to reproduce the bug - when in Step 3 you click on the first info icon, open another browser tab, go and return back - the box for Options will become transparent.  

Note: does not happen with Insert-Template(a template should have one info icon).

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

**Attached**: {F15339}
Also can't reproduce. Please re-open if it re-occurs.
Cannot reproduce on beta with IE11... @Etonkovidova, is this still an issue for you?
The dialog box 'Are you sure?' which appears when switching from Edit mode to Read is transparent too.
Created attachment 16934
Chrome shows correct transparency - to compare

**Attached**: {F15341}
Page options drop down horizontal scroll bar

Steps to reproduce: 

1. In IE 11 in full screen- open any page for edit in VE.
2. Click on Page option icon - the drop down menu options will be displayed partially and a horizontal window scroll bar will be displayed.

{F15330}

--------------------------
**See Also**:
{T74592}
This is caused by some IE bugs with `display: inline-table`. Applying the set of patches from T78499, which gets rid of it, fixes the issue.
Probably the same bug as bug 72592, but leaving distinct for now.
As it was described in 56713 - the bug "alternates"  i.e. 

IE11 test2: Open a page in VE and click on the 'Page options' icon - the drop-down menu options are partially displayed. Then switch to 'Maximize' browser view(or if you were in  'Restore down', switch to 'Maximize'), the menu options will be displayed in full.
First reported by miya at ja.wp:
write something in Japanese; press Enter; the whole line disappears. This also happens when adding a picture - in the Caption field.
This does not seem to be browser or OS-specific.
miya says that adding a "single-byte character" or a number at the beginning of the line, the line doesn't disappear - I don't seem able to confirm this (my tests are in Safari/X Yosemite).
I'm able to reproduce the general issue at mediawiki.org (using the laptop input system for Katakana; hope I'm doing this right).

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=72508
As far as I can tell, this issue and other Japanese text entry issues are all now fixed. Sorry it took so long to confirm!

>>! In T74619#977974, @Yukichi99 wrote:
> Why did you change the priority?
> I recognize this bug is blocked against using by Japanese.
> If you have a reason, let me know.

Sorry, this was done in a mass action for everything we were not working on that month.
Why did you change the priority?
I recognize this bug is blocked against using by Japanese.
If you have a reason, let me know.
Thanks for changing its priority!

For your information, I tried the above case with Google Input method and Google chrome on Mac OS X Yosemite, got the same result. 

Let me know if you need other test cases.
Confirmed in betalabs with hirogana, katakana(and, of course, not for romaji), and kanji. 

Sometime it takes two hit of Enter to delete the entered text in such languages- but the text gets deleted. For English text, 'Enter' behaves normally  - a cursor goes to the new line.
Screenshot

Steps to reproduce:

1.Open a page with Mobile VE
2.Select a link or a citation so that the context menu for it appears on the top

Observed Result:
When the context menu appears observe the positions of the buttons at the left-"Save" and "Settings" icon also gets changed to a much lower position , they should be fixed while the context menu opens at the bottom of the menu bar


See the screenshot attached

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

**Attached**: {F15145}
Needs re-testing.
I just tested the feature
https://lists.wikimedia.org/pipermail/wikitech-ambassadors/2014-October/000991.html
with VisualEditor and it seems to be using a low resolution image instead of MathMl (while editing). When I save the page,
https://pt.wikipedia.org/w/index.php?diff=40380507
the formula disappears and it only reappear after I reload the page.

--------------------------
**Version**: unspecified
**Severity**: normal
Verified in production  - used the sample from https://pt.wikipedia.org/w/index.php?diff=40380507: \frac{\sqrt{(x+1)}}{y^2}
Verified the fix in test2

- resolution of an edited/inserted formula in VE is the same as after saving the page

- <meta name="generator" content="MediaWiki 1.25wmf8"> is present
**gerritadmin** wrote:

Change 172775 merged by jenkins-bot:
Allow <meta> tags in GeneratedContentNodes

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

Change 172775 had a related patch set uploaded by Esanders:
Allow <meta> tags in GeneratedContentNodes

https://gerrit.wikimedia.org/r/172775
Isn't this what gerrit 130828 was for?
Environment:
Ubuntu 14.04.1 LTS
IBus 1.5.5
mozc 1.13.1651.102-2

Test sequence:
0. Open a blank page with VisualEditor.
1. Switch to Japanese input.
2. Enter "nihongo".
3. Convert it (usually by pushing down the space key). You'll see it converted "日本語" here.
4. Disable Japanese input.
5. Enter "a". You'll see here "日本語" removed and only "a" remaining.

--------------------------
**Version**: unspecified
**Severity**: critical
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=72619
As far as I can tell, this issue and other Japanese text entry issues are all now fixed. Sorry it took so long to confirm!

>>! In T74508#1014577, @whym wrote:
> @Jdforrester-WMF: do you have any idea which change fixed it? We'd want to link it here, if possible.
> 
> Anyway, I think it's safe to close this task as resolved already.

Sadly we've done dozens of changes to the typing support system in the past few years to fix this issue and ones like it, and we only added systematic tests for Japanese typing support this week, which helped us confirm that it was working as expected.
@Jdforrester-WMF: do you have any idea which change fixed it? We'd want to link it here, if possible.

Anyway, I think it's safe to close this task as resolved already.
Unsure of what changed, but I'm not experiencing this problem now on MediaWiki.org anymore.
Changed to critical as it involves loss of data, and affects significantly many (effectively all trials of editing in Japanese).
the similar issue is bug 72619.
I first experienced the same bug around 2014-10-24.
Environment:Windows 7　PC （Firefox 33.0.1,　Chrome 38.0.2125.104 m, IE 11.0.13）

Test sequence 1: 
0 - 5. All the same as Yusuke Matsubara's.
(note: you cant move the cursor with right or left key on "日本語")

Test sequence 2: 
0 - 4. same as Yusuke Matsubara's.
5. Push "Enter key" to make a br there. You'll see here "日本語" vanished and nothing remaining. 
(It drove me panicky at first: I couldnt even copy the Japanese text there to　salvage. )

Test sequence 3:
0. Open a blank page with VisualEditor.
1-1. Enter "1" (or any alphabet, any number or any sign like "@", "#", "*", "^", ...).   
1-2. Switch to Japanese input.
2. Enter "nihongo" after "1".
3. Convert it (usually by pushing down the space key). You'll see it converted "日本語" - you'll see here "1 日本語" 
4. Disable Japanese input.
5. Enter "a". You'll see here "1 日本語 a" remaining.
Above was tested browsers below:
Mozilla Firefox 33.0
Chromium Version 37.0.2062.120 Ubuntu 14.04 (281580) (64-bit)
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert a bullet list
3.Add some indentation 
4.Now click on any slug that got created due to indentation
5.Open a link inspector on that position
6.While the link inspector is open, click somewhere else in the document to close the inspector

Observed Result:
The link inspector stays opened in that position and there is an error in the console:
TypeError: Cannot read property 'previousSibling' of undefined

See the screenshot attached

Environment:Betalabs,test2 and en.wiki

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

**Attached**: {F14916}
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.Go to Insert>Media
3.Search for any image and select one 

Observed Result:
As soon as you select any image and the Media Settings dialog appears,the following error appears in the console

Uncaught TypeError: Cannot read property 'isDefault' of undefined

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

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

Change 168675 merged by jenkins-bot:
Make sure initialHash exists before checking its value

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

Change 168675 had a related patch set uploaded by Mooeypoo:
Make sure initialHash exists before checking its value

https://gerrit.wikimedia.org/r/168675
There are different controls for the Cache-Control headers for the API and MediaWiki's OutputPage.  This may have seemed innocuous in the past, but it is causing problems now that VisualEditor is moving page editing to the API.

On my local wiki pages are served with:

  Cache-Control: private, must-revalidate, max-age=0

and, when mCacheMode is set to 'private', the default, API responses are sent with:

  Cache-Control: private

[[ http://www.ietf.org/rfc/rfc2616.txt | RFC 2616 ]] says:

  private
      Indicates that all or part of the response message is intended for
      a single user ... A private (non-shared) cache MAY cache the response.

and:

   A cache MAY be configured to return stale responses without
   validation, but only if this does not conflict with any "MUST"-level
   requirements concerning cache validation (e.g., a "must-revalidate"
   cache-control directive).

and:

   If a cache receives a 5xx response while attempting to revalidate an
   entry, it MAY either forward this response to the requesting client,
   or act as if the server failed to respond. In the latter case, it MAY
   return a previously received response unless the cached entry
   includes the "must-revalidate" cache-control directive (see section
   14.9).

**old description:**
IE 11 seems to cache faulty parsoid responses.

I had a misconfigured server and, even after I fixed the problem and other browsers were able to continue after clicking "edit", IE didn't even attempt to make a request but just kept showing the alert box with the error message.
Since this was merged...
Change 194208 merged by jenkins-bot:
Browser should clear cache for API responses

[[https://gerrit.wikimedia.org/r/194208]]
Change 194208 had a related patch set uploaded (by MarkAHershberger):
Browser should clear cache for API responses

[[https://gerrit.wikimedia.org/r/194208]]
Updated description with my findings.  I think this shows that while IE's behavior may be different, it isn't out-of-spec, especially given that the urls providing the content for reading are different than the urls providing content for the VisualEditor.

Patch to arrive shortly.
Like {T73119}, my client has specified this as an important issue.  I'm looking for information on tracking down these issues.  Any pointers?
Please don't use "MSIE"; we normally call it "Internet Explorer" for clarity.
It isn't just caching errors.  It looks like it is caching all sorts of responses.  I think I've seen this in more than just IE, but I can reliably reproduce it with IE.
Not sure how we could work around browser-intentional behaviour like this…
MWTitleInputWidget should have a .getTitle() getter (which can return null, if the value isn't a valid title). Using this getter should be preferred over .getValue(). Callers of MWTitleInputWidget.getValue() should be converted to .getTitle(), and they should check for null-ness, because we probably have more bugs like bug 71998 hiding in various places.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 169603 merged by jenkins-bot:
Introducing getTitle() in MWTitleInputWidget

https://gerrit.wikimedia.org/r/169603
Change 169603 had a related patch set uploaded by SuchetaG:
Introducing getTitle() in MWTitleInputWidget

https://gerrit.wikimedia.org/r/169603
Also, per bug 71249, now that we have isValid() in TextInputWidget, it makes sense for MWTitleInputWidget to reimplement isValid() as a check for getTitle() not being null.
Make the API call for scalable information unified on load, and make sure the call only comes out once per image (at least) and is persistent between the image and the image model in the edit dialog.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Unassigning myself - but I'm pretty sure this is irrelevant now after the many many refactorings done to the code?
inspector opens up on the left side in FF 33.0

Environment- beta

1> In VE, insert a media(with any settings but no content in "Caption") to blank page.

2> Highlight the image and select link or language from the toolbar.The inspector opens and closes quickly.

This happens in chrome 38 only.

In FF 33.0, when you do the above steps, the inspectors do not open on top of the image.But always on the left side in the CE .See screenshot.

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

**Attached**: {F14768}
Also see 72660, https://bugzilla.wikimedia.org/show_bug.cgi?id=72660
Created attachment 16939
Caption appearing in the link target field

**Attached**: {F14769}
(In reply to James Forrester from comment #2)
> I believe that this is describing intentional functionality for links? You
> can't make an image into a link in wikitext (there's a distinct feature
> about image target but that's tracked elsewhere).
> 
> But yes, this needs to be cleaned up a bit (especially the different
> behavior between Firefox and Chrome).

I also noticed that when i try to apply link to images having caption,the link inspector opens with the caption text as link target in the input field(which i thought was fine).

Environment-test2, beta, production
steps-
1> insert a media with a caption(could be an internal link or text).Highlight the image and select to apply link.
2> Link inspector opens on top of the image, populated with the caption in the input field.
3> Click done and the inspector closes.See screenshot.

Is this expected?
I believe that this is describing intentional functionality for links? You can't make an image into a link in wikitext (there's a distinct feature about image target but that's tracked elsewhere).

But yes, this needs to be cleaned up a bit (especially the different behaviour between Firefox and Chrome).
Now reproducible in test2.

1> insert a media with no captions.Highlight the image and select to apply link or language.
2> Link or language inpsector opens and closes quickly.
Parsoid output has broken output because Mediawiki:common.css is not included.

For example:
http://parsoid-lb.eqiad.wikimedia.org/frwiki/Guerre_froide?oldid=108085194

Here the original version:
https://fr.wikipedia.org/w/index.php?title=Guerre_froide&oldid=108085194

And with the visual editor:
https://fr.wikipedia.org/w/index.php?title=Guerre_froide&oldid=108085194&veaction=edit

Like you can see the infobox width is huge probably because there is no rule for the "infobox_v2" CSS class.

--------------------------
**Version**: unspecified
**Severity**: normal
I've just filed {T155634} which also has some spaces inserted (which may be relevant).
Also, see https://www.mediawiki.org/wiki/Parsing/Replacing_Tidy .. especially Sections 2.2 and 2.5 on that page.

As part of T89331, we are working to replace Tidy with a proper HTML5 parser which will require wikitext fixes of the kind that @Od1n did above.
Please note I have workarounded the above issue since: https://fr.wikipedia.org/w/index.php?title=Mod%C3%A8le:Portail&diff=prev&oldid=126720710
Same issue occurs with <li> tags.
[[https://fr.wikipedia.org/w/index.php?title=Utilisateur:Pols12/brouillon_eve&oldid=126290496|An example]] on fr.wiki: there are a <li> per line in HTML code however all <li> tags are displayed on the same line with VisualEditor (with Template:Portail)
Same issue occurs with <li> tags.
[[https://fr.wikipedia.org/w/index.php?title=Utilisateur:Pols12/brouillon_eve&oldid=126290496|An example]] on fr.wiki: there are a <li> per line in HTML code however all <li> tags are displayed on the same line with VisualEditor.
We'll have to figure out what to do about this Tidy-caused discrepancy. Template edit to not depend on this Tidy effect might be the simplest. For now, moving this out of Q4.
Tidy decodes and moves the space:

```
> print MWTidy::tidy('<span class="a"><span class="b">x</span>&#32;</span>y');

<p><span class="a"><span class="b">x</span></span> y</p>

> $opt = new ParserOptions;

> print $wgParser->parse('<span class="a"><span class="b">x</span>&#32;</span>y', Title::newMainPage(), $opt)->getText();

<p><span class="a"><span class="b">x</span>&#32;</span>y
</p>

> $opt->setTidy(true);

> print $wgParser->parse('<span class="a"><span class="b">x</span>&#32;</span>y', Title::newMainPage(), $opt)->getText();

<p><span class="a"><span class="b">x</span></span> y</p>
```
>>! In T74416#1322436, @ssastry wrote:
> The second part to this puzzle here is: even if the space char entity was *outside*, Parsoid would wrap that entity with a mw:Entity span which would also likely break the CSS rendering in this case.

So, I was wrong it looks like, thankfully. If I manually edited the HTML to:
```</span><span typeof="mw:Entity"> </span><span class="nowrap"```
the rendering is correct, of course, since the nowrap class doesn't apply to the entity span.

So, if we can figure out the action=parse vs action=expandtemplates difference, we might be on our way to solving this issue. We need to figure out whether one of those API endpoints has a bug and/or the template needs fixing.
@tstarling: any clue what is going on there with action=expandtemplates vs action=parse ? Can also dig into code next week.
This is interesting.

Compare: 
https://fr.wikipedia.org/w/api.php?action=parse&format=json&text={{Palette|Seconde%20Guerre%20mondiale|Guerre%20froide|Communisme|Histoire%20des%20%C3%89tats-Unis}}
vs.
 https://fr.wikipedia.org/w/api.php?action=expandtemplates&format=json&text={{Palette|Seconde%20Guerre%20mondiale|Guerre%20froide|Communisme|Histoire%20des%20%C3%89tats-Unis}}

So, action=expandtemplates returns:
```... </span>&#32;</span><span class="nowrap" ... ```
and action=parse returns:
```... </span></span> <span class="nowrap" ...```

How did the &#32; (which is a space char) move from inside the span to outside because of parsing? Parsoid is of course processing the result of action=expandtemplates and faitfully preserves the whitespace char where it exists .. inside the previous span. Something is goofy with the PHP parser there .. Or is it Tidy that is doing this?

The second part to this puzzle here is: even if the space char entity was *outside*, Parsoid would wrap that entity with a mw:Entity span which would also likely break the CSS rendering in this case.
This is interesting.

Compare: 
https://fr.wikipedia.org/w/api.php?action=parse&format=json&text={{Palette|Seconde%20Guerre%20mondiale|Guerre%20froide|Communisme|Histoire%20des%20%C3%89tats-Unis}}
vs.
 https://fr.wikipedia.org/w/api.php?action=expandtemplates&format=json&text={{Palette|Seconde%20Guerre%20mondiale|Guerre%20froide|Communisme|Histoire%20des%20%C3%89tats-Unis}}

So, action=expandtemplates returns:
```.. </span>&#32;</span><span class="nowrap" ```
and action=parse returns:
```</span></span> <span class="nowrap">```

How did the &#32; (which is a space char) move from inside the span to outside because of parsing? Parsoid is of course processing the result of action=expandtemplates and faitfully preserves the whitespace char where it exists .. inside the previous span. Something is goofy with the PHP parser there .. Or is it Tidy that is doing this?

The second part to this puzzle here is: even if the space char entity was *outside*, Parsoid would wrap that entity with a mw:Entity span which would also likely break the CSS rendering in this case.
I verified by manually adding that single space between the spans and the navbox table at the bottom renders properly. The infobox at the top has the same problem and is fixed if I manually added that single space between spans.
Okay, I checked. There is a subtle but important difference that is causing this.

In the PHP output, between the individual links in that column, there is a single whitespace character.
```
... </span> <span class="nowrap"> ...
```
In Parsoid output, there is no whitespace  between the individual links
```
 ...</span><span class="nowrap" data-parsoid='{"stx":"html"}'> ...
```
Without the whitespace, and with the nowrap class on the links, this means that there is no place for the browser to break the line, and hence that column stretches out forever. So, we need to figure out the reason why that single whitespace is being lost in Parsoid output.
I don't think it is mw:Entity entirely ... I am testing a html dump from that page where I replaced the mw:Entity with space or the entity as in the PHP html and it didn't change the rendering substantially. This requires some more digging into the HTML diffs between the two.
Mediawiki:Common.css is included by the parsoid-rendered page, you can see this inspecting the infobox table with Firebug (or similar).

The rendering problem comes from the navboxes at the end, which have all the links in each cell in the 2nd column in the same line, instead of wrapping them. If (using Firebug) the .nowrap style (or just "white-space: nowrap;") is disabled, the page returns to a more appropriate width.

The only difference I can see in the HTML is the presence of multiple mw:Entity elements to indicate the white-space present in wikitext, so maybe that's what's interfering with nowrap.
Screenshot

Steps to reporduce


When you tap on Bold, Italic or Link buttons from the toolbar, the icons for these become highlighted in the toolbar.but when you tap on citation icon , there is no highlight on it, which looks a bit inconsistent

See the screenshot attached

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

**Attached**: {F14712}
Toolbar has changed a lot since this.
Steps to reproduce:

1.Open any page with mobile VE
2.Type a text
3.Select the text and type something else to overwrite it'

Observed Result:
Nothing gets entered into the CE and does not replace the old text


Environment: Production, test2 and Betalabs
Screenshot

Steps to reproduce:

1.Open a page with Mobile VE which has citation note in it using desktop Safari

2.Now double click on citation 

Observed Result:
It opens the Basic Reference dialog , which we explicitly disabled because there were lot of things we didn't implement inside that dialog

See the screenshot attached

Environment: Betalabs, test2 and production

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

**Attached**: {F15388}
In the weekly triage on 2015-04-22, this task was discussed. We decided to decline this task, as making all functions available is part of the plan for mobile.
Screenshot

Steps to reproduce:

1.Load a page with Citations with Mobile VE in iOS safari or desktop Safari
2.Keep the keyboard closed in iOS Safari so that the cursor is not active in CE, for desktop just click somewhere out of CE to keep the cursor inactive on CE
3.Now click or tap on Citation note

Observed Result:
The context menu for it does not appear and a light shade of highlight appears on top of it when I click but it also goes away


  
See the screenshot attached

Environment:test2, Betalabs and production

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

**Attached**: {F15386}
Seems to work for me 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 VE which does not have any reference in it to re-use.


Observed Result:

The "Re-use" label for the button is not greyed out even if the button icon is 

See the screenshot attached
Environment:Production,test2 and Betalabs

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

**Attached**: {F15377}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
**gerritadmin** wrote:

Change 170790 merged by jenkins-bot:
VE: Don't set @grayDark colour for tool titles in disabled widgets

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

Change 170790 had a related patch set uploaded by Alex Monk:
VE: Don't set @grayDark colour for tool titles in disabled widgets

https://gerrit.wikimedia.org/r/170790
(In reply to Alex Monk from comment #1)
> Looks like this is caused by MobileFrontend's
> less/modules/editor/VisualEditorOverlay.less file - specifically this part:
> .oo-ui-tool-title {
>     color: @grayDark;
>     font-size: .9em;
> }
> Which is taking precedence over the styles for the oo-ui-widget-disabled
> stuff.
> 
> What if we changed it to this?
> .oo-ui-widget-enabled > .oo-ui-tool-title {
>     color: @grayDark;
> }
> .oo-ui-tool-title {
>     font-size: .9em;
> }

Eurgh. Another reminder that we need to kill VisualEditorOverlay.less.
Looks like this is caused by MobileFrontend's less/modules/editor/VisualEditorOverlay.less file - specifically this part:
.oo-ui-tool-title {
    color: @grayDark;
    font-size: .9em;
}
Which is taking precedence over the styles for the oo-ui-widget-disabled stuff.

What if we changed it to this?
.oo-ui-widget-enabled > .oo-ui-tool-title {
    color: @grayDark;
}
.oo-ui-tool-title {
    font-size: .9em;
}
Half of dm.MWParameterModel is dedicated to looking things up in the parent template's spec. Despite that, ui.MWParameterPage manually looks up the default value and autoValue because there are no getters in dm.MWParameterModel for those things, for no good reason whatsoever. Those getters should be added.

What's even worse is the "if there is no real value, set the value to the autoValue" logic (added in https://gerrit.wikimedia.org/r/168204 ). Currently this logic (which is fundamentally DM logic) is in ui.ParameterPage as well. Instead, MWParameterPage.getValue() should be smart enough to return either the real value or the autoValue if there is no real value.

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

Change 168926 merged by jenkins-bot:
Move autoValue logic from ui.MWParameterPage to dm.MWParameterModel

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

Change 168926 had a related patch set uploaded by Alex Monk:
Move autoValue logic from ui.MWParameterPage to dm.MWParameterModel

https://gerrit.wikimedia.org/r/168926
(In reply to Roan Kattouw from comment #0)
> Instead, MWParameterPage.getValue() should be
> smart enough to return either the real value or the autoValue if there is no
> real value.

MWParameterModel.getValue()?
Works for me on en.wiki. Feel free to reopen if necessary.
Seems to work for me on En.wiki. Reopen if necessary.
Confirmed in test2 and betalbs.

Steps to reproduce: 

1. Copy all(or part of) Bibliographic information on http://books.google.co.uk/books?id=VYvS7MyaEE8C. It's a html table.  

2. Paste it at the end of an existing line in a chunk of text of test2 or betalabs.  The amount of text should be large enough to allow you to scroll down the page and then paste the table at the end of any line. 


Observed result: after pasting, the page scrolls up. The pasted table is correctly placed though. The issue does not happen if a table is pasted on a new line.
1. Copy to the clipboard the below invalid rich content from NYTimes.com:
   <div><div …><a …><img …></a></div><figcaption …>Foo</figcaption></div>

2. Go to any page in VE

3. Paste; observe crash of paste engine.

Paste rules are probably not checking parentage (HTML spec says no <figcaption>s except as children of <figures>s) and it's breaking things. Instead, we should… eh. Downcast to <div>?

--------------------------
**Version**: unspecified
**Severity**: normal
If you add a file in VisualEditor, then it sometimes adds the file using the English namespace or other English terms.  Examples:

https://ca.wikipedia.org/w/index.php?diff=14187112&oldid=14185423 – "File" is not a Catalan word

https://es.wikipedia.org/w/index.php?diff=77684034&oldid=73098946 – "File" is not a Spanish word

https://de.wikipedia.org/w/index.php?diff=135103424&oldid=135103377 – German uses "mini" instead of "thumb"

https://ro.wikipedia.org/w/index.php?diff=8882945&oldid=7944846 – "File" is not a Romanian word

https://ru.wikipedia.org/w/index.php?diff=66358996&oldid=55356951 – or Russian

https://sv.wikipedia.org/w/index.php?diff=28184524&oldid=20202611 – or Swedish

https://pl.wikipedia.org/w/index.php?title=Pawe%C5%82_z_Eginy&diff=40760929&oldid=38644980 – or Polish 

https://it.wikipedia.org/w/index.php?title=Paolo_di_Egina&diff=68773170&oldid=63002904 – or Italian


In other cases, it did use the local name, including French, Hungarian, and Estonian.  I'm not sure what the common thread is.  It's possible that some of these communities deliberately choose to use the English namespace, but at least a few change such edits.  If we can use the local name more often, then we should be able to reduce the burden on local communities.

--------------------------
**Version**: unspecified
**Severity**: minor
Thought this was already filed with Parsoid, but I can't find it. Please merge if I've missed it!
While observing three librarians editing each their own page, I noticed that they had uncertainties when asked to save their edit. I had to explain them they have to scroll the page, and exactly where to scroll: not the text area, the whole page.

Indeed, the save button is easily outside the screen, even without overly long copyrightwarning areas. We should always give a hint to users so that they know where to proceed.

Something as simple as a biggish button on top of the text area, linking the [[#wpSave]] anchor, might even suffice. Worth some prototyping and usability testing IMHO.

I filed a twin report for VisualEditor without realising:  T90864

--------------------------
**Version**: unspecified
**Severity**: enhancement
Created attachment 16839
Save buttons outside of screen

**Attached**: {F15242}
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Open Link inspector in an empty line 


Observed Result:
A scroll bar is appearing inside the link inspector

See the screenshot attached

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

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

Change 168206 merged by jenkins-bot:
Increase inspector height by 1 to deal with Chrome opacity bug

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

Change 168206 had a related patch set uploaded by Esanders:
Increase inspector height by 1 to deal with Chrome opacity bug

https://gerrit.wikimedia.org/r/168206
Proximate cause is https://gerrit.wikimedia.org/r/#/c/167446/ , it was working before that change.

What seems to be going on is that there's a browser bug in Chrome that causes the inspector's body to immeasurably have a slightly greater height if the opacity of the Open button is not equal to 1. That's why this bug is only reproducible in creation mode, and the scrollbar goes away as soon as you type: the Open button is initially disabled (opacity:0.5), then enabled when you type something (opacity:1).

If you want entertainment, inspect an enabled Open button, add opacity:0.999; to it and toggle it off and on a few times.
This site, https://wiki.transitionnetwork.org/ is running on amd64 Debian Wheezy with Parsoid installed using apt as per the instructions at https://www.mediawiki.org/wiki/Parsoid/Setup#Ubuntu_.2F_Debian_on_amd64

Today the new GPG siging key was installed and Parsoid updated (see https://trac.transitionnetwork.org/trac/ticket/692#comment:103 ) to version 0.1.15 and this has caused all edits using the VisualEditor to generate 500 errors, this is what is logged when you try to save a page:

  [info][localhost/Sandbox2?oldid=946] started parsing
  [fatal/request][localhost/Sandbox2?oldid=946] undefined is not a function
  TypeError: undefined is not a function
      at TreeBuilder.resetState (/usr/lib/parsoid/src/lib/mediawiki.HTML5TreeBuilder.node.js:61:17)
      at new TreeBuilder (/usr/lib/parsoid/src/lib/mediawiki.HTML5TreeBuilder.node.js:28:7)
      at ParserPipelineFactory.makePipeline (/usr/lib/parsoid/src/lib/mediawiki.parser.js:231:17)
      at ParserPipelineFactory.makePipeline (/usr/lib/parsoid/src/lib/mediawiki.parser.js:227:17)
      at ParserPipelineFactory.getPipeline (/usr/lib/parsoid/src/lib/mediawiki.parser.js:363:15)
      at ParserPipelineFactory.parse (/usr/lib/parsoid/src/lib/mediawiki.parser.js:311:20)
      at /usr/lib/parsoid/node_modules/prfun/lib/index.js:436:24
      at new Promise (/usr/lib/parsoid/src/node_modules/es6-shim/es6-shim.js:1228:11)
      at /usr/lib/parsoid/node_modules/prfun/lib/index.js:419:14
      at /usr/lib/parsoid/src/api/routes.js:152:62

The error presented to editors is:

> Error loading data from server: parsoidserver-http-bad-status: 500. Would you like to retry?

I have reverted to the old version of parsoid to get around this issue:

  apt-get install parsoid=0.1.12

There are some more details on this ticket https://trac.transitionnetwork.org/trac/ticket/799

--------------------------
**Version**: unspecified
**Severity**: major
**OS**: Linux
@chrisc, I'm sadly a bit out of ideas. I haven't been able to reproduce this so far (but am running sid), and it seems to be working fine for most users. I would just put it down to wheezy, except that it's a JS error that would be specific to running old JS code.

Is your `sources.list` line matching the one recommended at https://www.mediawiki.org/wiki/Parsoid/Setup#Ubuntu_.2F_Debian_on_amd64 ?
@chrisc, I'm sadly a bit out of ideas. I haven't been able to reproduce this so far (but am running sid), and it seems to be working fine for most users. I would just put it down to wheezy, except that it's a JS error that would be specific to running old JS code.
Yes, I tried that and it didn't make a difference I'm afraid, anything else I could try?
@ChrisC Is the error message still the same after a `apt-get remove --purge parsoid` followed by `apt-get install parsoid`?
I built & tested the 0.2.0 package on sid. Could this perhaps be a wheezy-specific issue? Which node version are you running? There are 0.10 package available in backports: https://packages.debian.org/wheezy-backports/nodejs

We are generally running 0.10 these days, but used to support 0.8 until fairly recently.
No change, switched to the latest version and when I tried to edit a page I got:

//"Error loading data from server: parsoidserver-http-bad-status: 500. Would you like to retry?"//

So I have reverted to the old version.

Is there anything else I could do to help debug this?
We just released v0.2.0 to both npm and the Debian repository. Could you check if this issue is fixed?
The HTML5 library was updated in the deploy repo at the end of August, which was after the 0.1.12 deb release. I'm not sure if the deb packages that (@Gwicke?) but did you try running `npm install`?
gwicke: Any clue about the published debian package? Is this just a matter of updating the debian package?
Yes, looks to me like a conflict with the html5 library. I don't know much about our Debian packaging though.
This sounds like it's caused by the silently-breaking-change made by one of the upstream npm modules – Parsoid team, could you advise?
Open https://it.wikipedia.org/wiki/Categoria:Personalità_del_buddhismo?veaction=edit .
Notice that no categories appear in the category dialog, while that page features 2 of them.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61921
*** This bug has been marked as a duplicate of bug 72080 ***
Screenshot

Steps to reproduce:

1.Load a page from http://en.m.wikipedia.beta.wmflabs.org/wiki/
2.Open the page in Edit Source mode first
3.Now go to the Settings icon and try to open the page with Mobile VE

Observed Result:
The following error appears in the console and VE does not open, stays in Edit Source mode:
"TypeError: Cannot set property 'MWMobileContext' of undefined"

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

**Attached**: {F15064}
Verified the fix in test2
Verified the fix in Betalabs
Change 167850 merged by jenkins-bot:
Followup fbc7ecb: make mediawiki.mobile depend on core.mobile, not core

https://gerrit.wikimedia.org/r/167850
Change 167850 had a related patch set uploaded by Catrope:
Followup fbc7ecb: make mediawiki.mobile depend on core.mobile, not core

https://gerrit.wikimedia.org/r/167850
Change 167715 merged by jenkins-bot:
Followup e20b47f: make .mediawiki.mobile depend on .core

https://gerrit.wikimedia.org/r/167715
Change 167715 had a related patch set uploaded by Catrope:
Followup e20b47f: make .mediawiki.mobile depend on .core

https://gerrit.wikimedia.org/r/167715
From a Wikia staff member working on ZH communities:

Basically we need to type Pinyin (English words) first to select Chinese characters, but the New VisualEditors react very slowly or over fast. Before I make a Chinese word, the en words already pop up and are put in the editor.

Here's a video of the bug happening on Mediawiki.org: http://youtu.be/G1WStvYrPPA 

Report comes from Mac/Chrome but it could be happening on more.

I asked if this was the same issue as T63429 but he said it was not.

--------------------------
**Version**: unspecified
**Severity**: normal
**OS**: Mac OS X 10.9
**Platform**: Macintosh
>>! In T74268#3136097, @Arthur2e5 wrote:
> This happens on zhwiki too. And well, the reporter mentioned MediaWiki.org itself! No reason to keep it in "Non-WMF sites".
> 
> Certain pinyin IMEs (e.g. MS Pinyin) like to give the latin characters in the "pinyin buffer" area ahead of time, since it helps the application (e.g. search engine) make predictions. Visual Editor sometimes randomly trips over a point and keeps prematurely engulfing these characters. The code editor for Lua and JavaScript, on the other hand, consistently displays this problem with near-zero randomness.
> 
> My personal workaround to this problem occurs is switching to RIME until I finish one edit.

Thank you for your clarification, however, I doubt if you have a fixme way due to T155928#3015470:
>>! In T155928#3015470, @dchan wrote:
> Change 336648 (which I've just merged) makes Tab step directly into the next cell. So you still get this problem, but only once when editing multiple adjacent cells.
> 
> I think that's probably the best we can do on this, until/unless Javascript/IME integration improves. (See https://w3c.github.io/input-events/ for current activity in this area).
This happens on zhwiki too. And well, the reporter mentioned MediaWiki.org itself! No reason to keep it in "Non-WMF sites".

Certain pinyin IMEs (e.g. MS Pinyin) like to give the latin characters in the "pinyin buffer" area ahead of time, since it helps the application (e.g. search engine) make predictions. Visual Editor sometimes randomly trips over a point and keeps prematurely engulfing these characters. The code editor for Lua and JavaScript, on the other hand, consistently displays this problem with near-zero randomness.

My personal workaround to this problem occurs is switching to RIME until I finish one edit.
This happens on zhwiki too. And well, the reporter mentioned MediaWiki.org itself! No reason to keep it in "Non-WMF sites".

Certain pinyin IMEs (e.g. MS Pinyin) like to give the latin characters in the "pinyin buffer" area ahead of time, since it helps the e.g. search engine make predictions. Visual Editor sometimes randomly trips over a point and keeps prematurely engulfing these characters. The code editor for Lua and JavaScript, on the other hand, consistently displays this problem with near-zero randomness.

My personal workaround to this problem occurs is switching to RIME until I finish one edit.
This happens on zhwiki too. And well, the reporter mentioned MediaWiki.org itself! No reason to keep it in "Non-WMF sites".

Certain pinyin IMEs (e.g. MS Pinyin) like to give the latin characters in the "pinyin buffer" area ahead of time, since it helps the e.g. search engine make predictions. Visual Editor sometimes randomly trips over a point and keeps prematurely engulfing these characters. The code editor for Lua and JavaScript, on the other hand, consistently displays this problem with near-zero randomness.

My personal workaround when this problem occurs is switching to RIME until I finish one edit.
Red color for link and blue background for language is not applied to the text

Environment- test2

1> Insert an internal link, the target is shown in red color. 
2> Now while the cursor is at the last character of the link ,select the language annotation.
3> Click Done on the inspector and type in some text. Notice although the context menu shows both Language and link labels, but the text typed is not red in color(indicating a link) and also the background color for language annotation is not applied to it. Appears as plain paragraph text.Move the cursor back and forth on the  entire text , still no change.However, when you go to new line by pressing enter key it does appear.

See screenshot.

In beta, the background color for language gets applied immediately but the link color takes effect only after you hit enter key to go to a new line.

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

**Attached**: {F15009}
I widened the scope of bug 72108 to include this bug without realizing this bug existed, so I might as well merge them now.

*** This bug has been marked as a duplicate of bug 72108 ***
(In reply to Ritu Swain from comment #0)
> Created attachment 16820 [details]
> Red color for link and blue background for language is not applied to the
> text
> 
> Environment- test2
> 
> 1> Insert an internal link by selecting the link icon from toolbar and typing in a name, the target is shown in red color. 
> 2> Now while the cursor is at the last character of the link ,select the
> language annotation.
> 3> Click Done on the inspector and type in some text. Notice although the
> context menu shows both Language and link labels, but the text typed is not
> red in color(indicating a link) and also the background color for language
> annotation is not applied to it. Appears as plain paragraph text.Move the
> cursor back and forth on the  entire text , still no change.However, when
> you go to new line by pressing enter key it does appear.
> 
> See screenshot.
> 
> In beta, the background color for language gets applied immediately but the
> link color takes effect only after you hit enter key to go to a new line.

**Attached**: {F15009}
JS error in test2

Environment- test2

1> In VE,insert a media to a blank page with any settings, but without captions.

2> highglight the image and then select the language from toolbar, the inspector opens on top of the image. JS error in console- "Uncaught TypeError: Cannot read property 'resolve' of null". clicking on done or Remove does not close the inspector.

In beta , the inspector does not open when an image is highlighted.

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

**Attached**: {F15001}
Verified the fix in production
Verified the fix in test2.
verified the fix in beta.
**gerritadmin** wrote:

Change 168021 merged by jenkins-bot:
Prevent JS error in getNativeRange()

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

Change 168021 had a related patch set uploaded by Catrope:
Prevent JS error in getNativeRange()

https://gerrit.wikimedia.org/r/168021
Almost certainly the same flaw as bug 72258.
JS errors in test2

Environment- test2, beta

1>In VE, insert a media(with any settings but no content in "Caption") to blank page.

2> Highlight the image and select link from the toolbar.JS Error-

Uncaught TypeError: Cannot read property 'from' of null 
Uncaught TypeError: Cannot read property 'resolve' of null 
Uncaught TypeError: Cannot read property 'from' of null

at this point.The inspector stays open and clicking on Remove or done does not close it.See screenshot. 

In beta, the JS error(following the above steps) is - Uncaught TypeError: Cannot read property 'from' of null.

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

**Attached**: {F14995}
Verified the fix in production.
Verified in test2(wmf5) - FF, Chrome are fine. 

Safari does not display Language and Link inspectors.
verified the fix in beta.
**gerritadmin** wrote:

Change 168021 merged by jenkins-bot:
Prevent JS error in getNativeRange()

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

Change 168021 had a related patch set uploaded by Jforrester:
Prevent JS error in getNativeRange()

https://gerrit.wikimedia.org/r/168021
Since a few days all externl links, incl. coordinates in the upper right edge, are rendered as red links on dewiki. I guess this is a regression?

--------------------------
**Version**: unspecified
**Severity**: minor
Verified the fix in en.wiki
Verified in test2 and betalabs(with 'Cite web' template).
*** Bug 72376 has been marked as a duplicate of this bug. ***
*** Bug 72287 has been marked as a duplicate of this bug. ***
This was fixed in gerrit I35c9bea4.
It's not possible to "Apply changes" from the transclusion dialog after it has been emptied (all template and wikitext blocks in it have been removed), because the button is disabled.

Split off from bug 71701.

--------------------------
**Version**: unspecified
**Severity**: normal
Verified the fix in production.
https://www.mediawiki.org/wiki/MediaWiki_1.25/Roadmap has some more details about what version (see 'Target Milestone') goes to which Wikimedia production wiki and when. Right now this change should be on the following sites in Wikimedia production: mediawikiwiki, testwiki, test2wiki, testwikidatawiki
Hey Elena, it has not yet made it to production(en.wiki), since it got fixed in wmf6.Lets check it on production after wednesday deployment.
test2 is in production.
Works correctly in test2.  The bug still exists in production. 

To check if my steps are correct: 

1.Insert a template 'Cite web' 

2. Open template properties for editing - and click 'Show options'. 

3. Click on a trash can symbol - all fields should be empty, but 'Apply changes' is active.

4. clicking on 'Apply changes' should delete the template.
Verified in betalabs.
**gerritadmin** wrote:

Change 168721 merged by jenkins-bot:
Allow removing all parts from a transclusion to remove the transclusion

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

Change 168721 had a related patch set uploaded by Alex Monk:
Allow removing all parts from a transclusion to remove the transclusion

https://gerrit.wikimedia.org/r/168721
Yeah; this should be available when there are changes (and on clicking it should remove the transclusion), but it should still be disabled in "insert" mode (as there's nothing to insert).
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert an image
3.Change the image size to a custom one
4.Reopen the media Settings dialog
5.Click on "Make full size"
Observed Result:
Its changing the size values in the fields inside the dialog it does not enable the "Apply Changes" button

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

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

Change 167964 merged by jenkins-bot:
Add 'valid' event to MediaSizeWidget

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

Change 167964 had a related patch set uploaded by Mooeypoo:
Add 'valid' event to MediaSizeWidget

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

1.  Open a page that already contains an external link without a label: [http://example.com].

2.  Try to change that link to [http://example.com anything].  No fair removing the whole link and re-adding it.


Results:

Yeah, I couldn't figure out how to do that either.


(According to the bug titles, bug 51309, bug 53505, and maybe some others address this, but the descriptions don't seem to match the titles very closely.)

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

Change 168030 merged by jenkins-bot:
Open the linkNode inspector when pressing Ctrl+K on a link node

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

Change 168030 had a related patch set uploaded by Catrope:
Open the linkNode inspector when pressing Ctrl+K on a link node

https://gerrit.wikimedia.org/r/168030
Phatom87 says he's been using "the tab that shows up after clicking on the link."  He's running Mozilla browser version is 32.0.3 and kde Linux 4.14.1.
Aha, the trick is you're using the toolbar button (or keyboard shortcut) rather than the context menu item. 

This is a regression. It's loading the link annotation editor rather than the link node editor. Clicking the context menu works just fine. Boo.
(Also, works fine in both skins.)
I tried this earlier and works for me in Chrome/Win8 and Safari on my Air. (6.2 isn't the most recent Safari version, but I don't think that matters). Can it be some kind of cache issue?
Steps to reproduce:

1.  1.  Open a page that already contains an external link without a label: [http://example.com], such as   https://en.wikipedia.org/wiki/User:Whatamidoing_%28WMF%29/sandbox?veaction=edit (scroll down to the ==External links== section).

2.  Open the link dialog.

I get the 'wrong' dialog in both Safari 6.2 and Firefox 32 on en.wp, mw.org, and beta labs, so it's not just one version.  Perhaps it's Mac specific?  I've asked Phatom87 (Mozilla Firefox user) for browser and OS information.
(In reply to WhatamIdoing from comment #4)
> Not done.  There's no "Add label" button (see screenshot).

How did you get the wrong link dialog to trigger? Link and reproduction steps please.
Not done.  There's no "Add label" button (see screenshot).
Created attachment 16793
Screenshot of link dialog

**Attached**: {F14724}
1. Select link.
2. Edit link.
3. Click "Add label".

Done?
Add label
Change selection to select all except the last letter
type : anything
delete last letter

not ...
buggy link dialog

Links don't correctly autocomplete when adding them from the references dialog and not the main editor (see screenshot; Chrome, en.wp today).

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

**Attached**: {F15331}
This is still an issue, with the minor difference that the inspector is not clipped, but rather forces the dialog to have a scrollbar:

{F12139380}

It should look like this: (mockup)

{F12139527}
>>! In T74121#3702775, @Elitre wrote:
> Is this still relevant?

The link dialogue is still contained inside the basic reference form, so this is still a valid report. I don't expect a great many people use the basic reference form, so I think the priority here can stay as it is.
Is this still relevant?
I need to pick Trevor's brain about this. Right now the WindowManager for inspectors is in the localOverlay, which is a sibling of the ce-surface (and so is inside the iframe). It would be interesting to explore putting this in the globalOverlay, but then that would be nasty for scrollable surfaces (or even surfaces embedded in a scrollable container; like, for example, an iframe) where the anchor moves as you scroll: in a globalOverlay situation, we'd have to manually reposition the inspector to account for scrolling, but with the localOverlay as it is we get this for free.
The links are autocompleting just fine, it's just that the dropdown is so small that you only see one suggestion, and the rest can be accessed by scrolling (notice the scrollbar).

What we should really be doing though, is not clip the link inspector against the boundaries of the dialog it's in, but allow it to go beyond those boundaries. That's a bit fiddly but probably not very hard.
Patch got merged upstream.
The patch solved the issues of patches being stuck in the event queue whenever the connection is lost with the Gearman server. That happened yesterday on the Wikimedia setup, on reestablishing the connection, all the pending merger:merge function have been executed and the event queue processed everything :-)

Keeping bug open until the patch is approved by upstream.
The patch has been deployed. Lets monitor the issue for a few days.
I am now deploying https://review.openstack.org/#/c/128921/3 by merging in our Zuul fork at integration/zuul.git
I have proposed a change at https://review.openstack.org/#/c/128921/ with a test which most probably has a race condition :D
Turns out I already filled a bug upstream in August.  The case was the connection to Gearman timing out while preparing a reference (same code path): https://bugs.launchpad.net/zuul/+bug/1358517

I have replied there with a potential solution to the issue.


Marking bug as an upstream issue.
Looking at debug.log.2014-10-15


23:21:17
- receives a code review +2 event for change 166678,3
- triggers a merge:merge function

23:21:47 (30 seconds later):

 ERROR gear.Client.unknown:
   Connection <gear.Connection 0x1ca7f90 host: 208.80.154.135 port: 4730>
   timed out waiting for a response to a submit job request:
      <gear.Job 0x7f1809f1dd50
          handle: None
          name: merger:merge
          unique: d928090c54474fa59b51d1661263750b>
 NoConnectedServersError: No connected Gearman servers

Zuul forks to spawn a Gearman server and both process communicate over TCP 4730 via the host public IP.

The Zuul code that handles the creation of the reference (zuul.scheduler.BasePipelineManager.prepareRef() ) does not handle exceptions when submitting the job to Gearman, so it is raised up to the main loop and leave the enqueued change in an inconsistent state.


I am not familiar with that part of the code.  I guess exceptions should be caught and some internal status (there is a `ready` variable) be set accordingly.


To unblock such issue either:

A) potentially a new patchset could be sent (that would remove the previous one from the Zuul queues) then +2ed again to reenter the gate-and-submit pipeline

B) use the Zuul client to move the change ahead in the queue (an action known as 'promote') which would reorder the changes in the pipeline and retrigger merge jobs. Ie:

 zuul promote --pipeline gate-and-submit --changes 166678,3

See doc at http://ci.openstack.org/zuul/client.html#usage


Adjusting priority, we can't have everything highest/critical.
Screenshot

See the screenshot attached to see the position of the arrow

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

**Attached**: {F15292}
The icon was actually missing before; reversing the logic of this bug and marking it FIXED. :-)
What's wrong about the position?
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Insert a group reference
3.Now go to Insert>References list
4.Click on the arrow to bring up the drop down box for the "Use this group" field


Observe Result:
The drop down box with options of group names are not opening unless you type something in the textfield

See the screenshot attached.

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

**Attached**: {F15267}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
**gerritadmin** wrote:

Change 166512 merged by jenkins-bot:
TextInputMenuWidget: Handle undefined value properly when toggling visibility

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

Change 166512 had a related patch set uploaded by Alex Monk:
TextInputMenuWidget: Handle undefined value properly when toggling visibility

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

Steps to reproduce:

1.Open a page with VE
2.Open the basic reference dialog
3.Place the cursor inside the field "Use the group"
4.Type something or keep it empty while the drop down is open.
5.Place cursor somehwhere else in the dialog to close it

Observed Result:
The drop down box does not get closed


See the screenshot attached

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

**Attached**: {F15265}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Now fixed?
**gerritadmin** wrote:

Change 166898 merged by jenkins-bot:
Support MenuWidget's config.widget being in a different document

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

Change 166898 had a related patch set uploaded by Catrope:
Support MenuWidget's config.widget being in a different document

https://gerrit.wikimedia.org/r/166898
Ugh yeah this is because it's in the outer overlay :(
This is from Salix alba, and I don't believe that I can improve upon his description:


I wanted to add {{tl|Infobox musical artist}} to an article and it proved to be much more painful than it needs to be. 

If you want add one of the minor fields like {{param|genre}} you have to
#Click on '''Add more information'''
#Click on '''Show 17 more fields'''
#scroll down to find the field you want and click on it
#The window will then scroll to the top of the form so you have to
#scroll down again to find the field you want and fill in the value
#repeat the whole process again.

This could be made easier. Why do I need to click twice to show all fields? Why do I need to go back to square one after adding a field? Why does it not auto scroll to the correct place (actually why not simply show the field under it description in the list of fields).

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=69734
--------------------------
**Version**: unspecified
**Severity**: normal
Change 166863 merged by jenkins-bot:
Follow normalisation response from category status query

[[https://gerrit.wikimedia.org/r/166863]]
Change 166863 had a related patch set uploaded (by Alex Monk):
Follow normalisation response from category status query

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

#patch-for-review
*** Bug 72303 has been marked as a duplicate of this bug. ***
**gerritadmin** wrote:

Change 166863 had a related patch set uploaded by Alex Monk:
Follow normalisation response from category status query

https://gerrit.wikimedia.org/r/166863
E.g. on https://www.mediawiki.org/wiki/VisualEditor - extra invisible characters at the end of each category name seems to be causing this
See the empty author parameters in this:  https://en.wikipedia.org/w/index.php?diff=629488479&oldid=629487984

Empty, non-required parameters would ideally not be added by Citoid.

--------------------------
**Version**: unspecified
**Severity**: enhancement
There isn't any VE code using citoid yet, just a user script… however, assigning to Marielle.
screenshot

Environment- test2, beta, production.

1> Select template. In the Add a Template dialog when the cursor is in the input box, hit spacebar.
2> The Add a Template button becomes active.click on it. 
JS console error-“Uncaught Error: Unable to parse title”.

Screenshot attached.

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

**Attached**: {F14999}
Verified the fix in production along with the bug fix for 71249.
the fix is a part of 71249.
Fixed for validating template titles - verified in betalabs FF
**gerritadmin** wrote:

Change 170071 merged by jenkins-bot:
Replacing MWTitleInputWidget.getValue() with MWTitleInputWidget.getTitle()

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

Change 170071 had a related patch set uploaded by SuchetaG:
Replacing MWTitleInputWidget.getValue() with MWTitleInputWidget.getTitle()

https://gerrit.wikimedia.org/r/170071
(In reply to Gerrit Notification Bot from comment #3)
> Change 168531 merged by jenkins-bot:
> Add template button remains disabled when entering space as a template
> 
> https://gerrit.wikimedia.org/r/168531

This fixes the issue as filed: when you type a space, the Add template button remains disabled. However, there are still a few values that you can use to make it crash, like "Talk:" (I was expecting "|" to break to, but surprisingly it doesn't because of unrelated evil hacks).

That is part of a larger issue though, which I've filed as bug 72468.
**gerritadmin** wrote:

Change 168531 merged by jenkins-bot:
Add template button remains disabled when entering space as a template

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

Change 168531 had a related patch set uploaded by SuchetaG:
Add template button remains disabled when entering space as a template

https://gerrit.wikimedia.org/r/168531
Confirmed - test2, Betalabs, produciton(Chrome, FF)

The following error is dispayed: 
Uncaught Error: Unable to parse title VM5621:36
TitleVM5621:36 
ve.dm.MWTemplateModel.newFromNameload.php?debug=false&lang=en&modules=ext.disambiguator.visualEditor%7Cext.math.visualEditor%7Cext.v…:257 
ve.ui.MWTemplatePlaceholderPage.onAddTemplateload.php?debug=false&lang=en&modules=ext.disambiguator.visualEditor%7Cext.math.visualEditor%7Cext.v…:277 
oo.EventEmitter.emitVM5625:7 
OO.ui.ButtonWidget.onClickload.php?debug=false&lang=en&modules=ext.visualEditor.core%2CviewPageTarget%7Cmediawiki.feedback%7C…:615 
jQuery.event.dispatchload.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141017T2…:65 
elemData.handleload.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20141017T2…:60
Screenshot of initial render with 1 category present

When opening the dialog and one category is already on the page, that category is rendered on its own line and the input field has its own line too (full width).

When removing that category and re-adding it, the input field shrinks and the category bubble is in front of it on the same line.

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

**Attached**: {F14793}
Can't reproduce. It works as expected now.
Created attachment 16746
Screenshot of later rendering when adding a category

**Attached**: {F14794}
Intermittent bugs are the worst.
This is happening to me randomly in Safari 7.1: when I try to create a new page, what I type won't show up sometimes. It seems like the first line (or two) of the edit window is "hidden" under the edit toolbar. It just happened to me several times in a row on a page similar to https://meta.wikimedia.org/w/index.php?title=Talk:Tech/News/2014/39&action=edit&redlink=1 .
It also happens on existing pages: I remember I had difficulties placing templates at the top of a page on Meta, so I just tried to edit https://meta.wikimedia.org/w/index.php?title=Talk:Community_Engagement_(Product)/Media_Viewer_consultation/Other&action=edit , and the first two lines are "missing". Nothing happens if I try to scroll up and down, with mouse or keyboard (except I can't see the cursor blinking if it is on one of those lines).

--------------------------
**Version**: 1.25-git
**Severity**: normal
**OS**: Mac OS X 10.9
Haven't noticed this in a while.
Actually, I just had this again in Chrome, while trying to update https://meta.wikimedia.org/wiki/VisualEditor/Newsletter/Sandbox :(
Screenshot

Steps to reproduce:

1.Open a page with VE with Firefox
2.Edit the page
3.Save the page or just navigate to Readmode after discarding the edit


Observed Result:
Cursor appears in the last line of the page in readmode.

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

**Attached**: {F15300}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 144089 merged by jenkins-bot:
Blur contentEditable node while destroying surface

https://gerrit.wikimedia.org/r/144089
Still fixed, we're just moving it to a better place.
Change 144089 had a related patch set uploaded by Jforrester:
Blur contentEditable node while destroying surface

https://gerrit.wikimedia.org/r/144089
Change 169546 merged by jenkins-bot:
Clear selection after tearing down surface to work around Firefox bug

https://gerrit.wikimedia.org/r/169546
Change 169546 had a related patch set uploaded by Catrope:
Clear selection after tearing down surface to work around Firefox bug

https://gerrit.wikimedia.org/r/169546
This issue is not fixed by the way, the cursor is still appearing the end of the document after saving a page in Firefox
Gah.
Different issue.
This now seems fixed from my testing?
If you open the editor and click on an image it works fine (albeit alienated), but once you've dropped the cursor anywhere in the document, even in a slug, it doesn't seem possible to select the node any more?

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

1.  Open a long page in Safari 6.2 (maybe others?)

2.  Scroll down a ways and select some text.

3.  Copy (Command-C) that text.


Results:

After a brief delay (one second?), the page scrolls all the way to the top.  The cursor is located at the very beginning of the page.  (The text is correctly copied.)

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**: {T74390}
Update:  As of July 2015, this is still happening in Safari 8.0 on Mac 10.10  

However, instead of scrolling all the way to the top of the page, it scrolls until the selected/copied text is at the very bottom of the screen.
If there is a line on a page that includes the semicolon syntax, VisualEditor does not handle this well. For example:

<example>
;Foo

Some more text.
</example>

In VE, if I place the cursor either immediately before or immediately after the (bold-formatted) text "Foo", and then I add several new lines, I end up with multiple lines that include the semicolon formatting, such as:

<example>
;Bar
;
;Foo
;Baz

Some more text.
</example>

There is no way (that I can tell) to disable such formatting, and highlighting the (apparently) bold text and trying to select "clear formatting" has no effect.

--------------------------
**Version**: unspecified
**Severity**: normal
In 'Edit source' - adding ; in front of a word makes a block displayed in bold in VE You cannot un-bold it in VE.

<dl class="ve-ce-branchNode"><dt class="ve-ce-branchNode"><p class="ve-ce-paragraphNode ve-ce-generated-wrapper ve-ce-branchNode">Foo sjhajshjahssdsd</p></dt><dt class="ve-ce-branchNode"><p class="ve-ce-paragraphNode ve-ce-branchNode">saksjdjskadja</p></dt></dl>

dt {
	.	 display: block;
}

dt {
	.	 font-weight: bold;
	.	 margin-bottom: .1em;
}
Pages with a <link rel="mw:PageProp/redirect" href="./Category:Foo"> but without a <link rel="mw:WikiLink/Category" href="./Category:Foo"> should be serialised to [[:Category:Foo]] per the spec, but instead are becoming [[Category:Foo]] which (a) is wrong and (b) doesn't round-trip.

----

//Original VE complaint://

The VE's Page Settings dialog redirect options work badly for category destinations.

For example, if you choose 'Category:Article stubs' as your destination, it inserts this:

#REDIRECT [[Category:Article stubs]]

While this does redirect the page, it also places that page in the "Article stubs" category.

It *should* put this on the page:

#REDIRECT [[:Category:Article stubs]]

Note the additional ":" - this prevents the category being interpreted wrongly.

https://www.mediawiki.org/w/index.php?title=VisualEditor:Redirecttest&action=history

--------------------------
**Version**: unspecified
**Severity**: minor
**OS**: Mac OS X 10.9
**Platform**: Macintosh
This change was deployed on March 19.
>>! In T73708#1131553, @marcoil wrote:
>>>! In T73708#1126551, @Krenair wrote:
>> What about files?
> 
> What's the situation with files? Should they also be serialized with a ':'?

Hmm... After doing some more checking, I think it may be OK without a ':' actually. Ignore me.
Change 197035 merged by jenkins-bot:
T73708: Serialize category redirects with a ':'

[[https://gerrit.wikimedia.org/r/197035]]
>>! In T73708#1126551, @Krenair wrote:
> What about files?

What's the situation with files? Should they also be serialized with a ':'?
What about files?
Change 197035 had a related patch set uploaded (by Marcoil):
T73708: Serialize category redirects with a ':'

[[https://gerrit.wikimedia.org/r/197035]]
I wonder if there is any use case for allowing the version without ":" with these namespaces, even if it should clearly not be the default. I don't think we want to add an extra button for something so obscure to most users.
Screenshot

Environment: test2, beta

1> Insert a formula .
2>highlight the formula and change its formatting to Bold/Italic/Underline/Strikethrough. None of these styles get applied to it.

Now select Language, it opens the language inspector. Language should be disabled for formulas.

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

**Attached**: {F14907}
Screenshot

Environment- test2, beta, production

1> insert a comment in a blank page.
2> open the Edit comment box
3> while the cursor is still blinking in the comment box, click to add numbered / Bullet point. The comment box closes and the comment is shown as the bullet/numbered list item
4> Now open the edit comment box again and decrease the indentation.I get "JS console error, Uncaught Error: Cannot set attributes on closing element".See screenshot.

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

**Attached**: {F14904}
test2 - checked both scenarios - no js errors.
**gerritadmin** wrote:

Change 173812 merged by jenkins-bot:
Apply comment changes using fragment

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

Change 173812 had a related patch set uploaded by Esanders:
Apply comment changes using fragment

https://gerrit.wikimedia.org/r/173812
This isn't as bad any more (no JS errors), probably thanks to Ed's change making the comment inspector use staging. But there's still a minor bug:

* Insert a comment in a blank page
* Type some text into the comment
* While comment box is still open, click Bullet list
* Comment inspector closes, comment ends up inside list
* Inspect comment
* Comment is empty (?!)
* Close inspector. Comment is automatically removed because it is empty

(If you don't type some text at step 2, the comment is removed at that point because it's empty.)

(Marking as regression pre-wmf5 even though the behavior in wmf4 was much worse.)
Draft namespace articles incorrectly showing as red links in search

Draft namespace articles incorrectly showing as red links in search

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

**Attached**: {F14790}
Verified in en.wiki - not reproducible.
Indeed, this was probably fixed when we modified MW's API return to always give the exact value.
Can't reproduce issue...
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Open the Insert menu

Observe that, the icon for Media and Comment are appearing a bit darker compared to other options in the menu.

Environment:Betalabs

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

**Attached**: {F15228}
Verified the fix in production
checked in BetaLabs and test2.
Maths icon fixed in gerrit 167031, which will be in wmf5 but is relatively minor.
Created attachment 16785
Screenshot

**Attached**: {F15229}
The opacity of Formula icon and Special Character did not get fixed with other icons.Is that intentional?
Fixed with gerrit 166292 and gerrit 166293.
Right now we rely on the API moaning about this, which means you have to wait for the whole page to be serialised, returned and saved before we prompt the user to do something that takes up some cycles, and so avoids them wasting time.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Never mind me, already done. *sighs*
You mean "Prompt me when entering a blank edit summary"? I'm pretty sure we're handling that locally...
Now that it's been created, launching this should be scheduled…

Release requirements from https://www.mediawiki.org/wiki/Beta_Features/Package :

[x]    Make an extension - [[https://www.mediawiki.org/wiki/Extension:VectorBeta |Extension:VectorBeta]]
[]    Get prelim design review
[]    Get prelim security review
[]    Get prelim performance review
[]    Make sure there is a wiki page on mw.org for it that is understandable to the general public
[]    Flowify the Talk page for the project
[]    Make sure there is someone on point for feedback - a product manager (either volunteer or WMF staff)
[]    Make a bugzilla component for the extension
[]    Enable the Final Version of the code on Beta Cluster at least a week before you want to go for production.
[]    Make gerrit change (do not merge) to the BF whitelist in mediawiki config
[]    Deploy!
Change 175406 abandoned by Glaisher:
Enable "Form Refresh" as a BetaFeature

Reason:
Per task

[[https://gerrit.wikimedia.org/r/175406]]
We decided to do {T100161} instead.
>>! In T73477#1298356, @Mattflaschen wrote:
> I hope we can discuss this at the Lyon Hackathon and make a commitment which approach we will take.  There are various possible resolutions:

Filed as {T99827}.  Tentatively scheduled for Workplace 2, Sunday 14:00.
Change 211081 abandoned by Mattflaschen:
Add margin about watchlist submit button, on MW UI

Reason:
So as to focus on the HTMLForm alternative.

[[https://gerrit.wikimedia.org/r/211081]]
I hope we can discuss this at the Lyon Hackathon and make a commitment which approach we will take.  There are various possible resolutions:

1. Finish $wgUseMediaWikiUIEverywhere (see {T72913}, etc. for the progress that has already been made).  A beta feature is not required for this.
2. Completely remove $wgUseMediaWikiUIEverywhere from core, leaving it as if it were false.
3. If there is a commitment to actually convert all of core to OO UI PHP (unlike MW UI, AFAICT, OO UI PHP is available in core, but not used from core), we could consider leaving the status quo until that is done.  This only makes sense if there's actually a commitment to do this, which it doesn't sound like there is if matmarex is describing it as 'allegedly'.
I hope we can discuss this at the Lyon Hackathon and make a commitment which approach we will take.  There are various possible resolutions:

1. Finish $wgUseMediaWikiUIEverywhere (see {T72913}, etc. for the progress that has already been made).  A beta feature is not required for this.
2. Roll back $wgUseMediaWikiUIEverywhere 100% in the meantime.
3. If there is a commitment to actually convert all of core to OO UI PHP (unlike MW UI, AFAICT, OO UI PHP is available in core, but not used from core), we could consider leaving the status quo until that is done.  This only makes sense if there's actually a commitment to do this, which it doesn't sound like there is if matmarex is describing it as 'allegedly'.
It should be pointed out that **these styles have been live on mobile since day one with no problem.** and have made various forms usable.

I don't care how we implement these standard forms, whether it's oojs ui, mediawiki ui classes or some other library but we really should start validating our designs across all our forms and gauging reactions to changes in appearance. Bugs get fixed quicker when in front of people's eyes. The idea of the beta feature was to capture reactions to a new design, regardless of how made, and this feels like a wasted opportunity.

In my opinion, this entire initiative stalled because we were given the impression that the forms would be rewritten in oojs ui and I had thought that would have happened by now. I'd love a roadmap for UX standardisation as it's been a year now on how we plan to get a standard UI across the site and from an outsiders perspective I don't see any improvement to the state of affairs since last year (apart from a much sexier VisualEditor and a tiny bit more infrastructure namely templates and icons).
Bah, I've been repeatedly advising against creating a BetaFeature for this, much less enabling it everywhere, until we've made it work correctly at least most of the time. Apparently it was done quietly while I wasn't looking. I've been told that this will help us spot and fix issues, but I remember reporting the same issue with radio buttons myself a year ago and I see it's still there? Sad to see that all the effort goes into enabling new features and none into polishing them.

We should mark this as "Declined" and focus our effort on something useful that people want to work on, since clearly no one wants to work on this.

The blockers for this would probably amount to a few weeks of work, and it is all redundant anyway since we are allegedly moving from "MediaWiki UI" to "OOjs UI MediaWiki theme". The designs of the two have been rapidly diverging; if the aim is supposed to unify our interfaces, this must not be deployed.
>>! In T73477#1287139, @Mattflaschen wrote:
>>>! In T73477#1266924, @greg wrote:
>> Removed Jared from assignee; who is driving this now? Let's not push something out as a beta feature that doesn't have someone to care for it.
> 
> @greg, there is technical debt in core for this (wgUseMediaWikiUIEverywhere).  We really need to resolve this one way or the other.  
> 
> This is not a 'feature' we want to maintain separately on an ongoing basis the way VE or Flow is.  It is part of core, and the code forks need to be removed.  Then, it needs to be maintained by the UX team and in general engineers leveraging it (same as any core component).
> 
> Using a Beta Feature temporarily is one possible path, but not the only one.  We could also just do it directly (T72424), after sufficient testing.
> 

I have no idea what will come of the BetaFeatures project/process post Jared, but there were (presumably still are) very stringent rules on what can go out as a BF. Without a PM owning it, it doesn't go out (as a BF). Really, for any big UI refresh like this, I want a PM to own it to respond to feedback and drive it to a successful conclusion. Who will be doing that for this?
> The goal should be for the new version to be a productive interface.

If the positioning of radio selects and checkboxes seemingly becomes inverted from the original, with no apparent reasoning behind it, then I call that a problem, not a productive interface.

Examples of these are everywhere:
{F165110}
I'm with @Quiddity. What causes all the control to be misplaced? If checkboxes are placed on one line, I expect them to be on one line. The controls should behave as standard UI controls with regards to being placed inline or as block elements.
>>! In T73477#1287132, @Quiddity wrote:
> The radiobuttons should be on individual lines here (and in TheDJ's second image above)
> {F165030}
> But vice-versa for the checkboxes (and the submit button) here (they should be on the same line)
> {F165033}

It seems like you want them on the same line or not just because they were in the original version. That's not the goal here.  The goal should be for the new version to be a productive interface.
>>! In T73477#1266924, @greg wrote:
> Removed Jared from assignee; who is driving this now? Let's not push something out as a beta feature that doesn't have someone to care for it.

@greg, there is technical debt in core for this (wgUseMediaWikiUIEverywhere).  We really need to resolve this one way or the other.  

This is not a 'feature' we want to maintain separately on an ongoing basis the way VE or Flow is.  It is part of core, and the code forks need to be removed.  Then, it needs to be maintained by the UX team and in general engineers leveraging it (same as any core component).

Using a Beta Feature temporarily is one possible path, but not the only one.  We could also just do it directly (T72424), after sufficient testing.

>>! In T73477#1280648, @Quiddity wrote:
> Beyond the design problems (examples above, plus more: [[http://i.imgur.com/Algh0Se.png| eg1]], [[http://i.imgur.com/FDYzdgX.png |eg2]]), 
> this probably also needs to be QA-checked for functionality.

What exactly are you saying is wrong with the first one?  Do you want them all on one line?

For the second, I guess you're referring to the button wrongly touching 'Associated namespace'.  Fixed in https://gerrit.wikimedia.org/r/#/c/211081/ ; please review.

Please file bugs (you don't need to for the one I already fixed), so we can triage them and decide what's a blocker.
The radiobuttons should be on individual lines here (and in TheDJ's second image above)
{F165030}
But vice-versa for the checkboxes (and the submit button) here (they should be on the same line)
{F165033}
Change 211081 had a related patch set uploaded (by Mattflaschen):
Add margin about watchlist submit button, on MW UI

[[https://gerrit.wikimedia.org/r/211081]]
>>! In T73477#1241123, @TheDJ wrote:
> {F158088}
> {F158090}
> Not sure if people will be too exited when stuff looks like this....

I guess for the first you're referring to the slightly awkward spacing?  This is not a blocker to the Beta Feature in my opinion.  It's something we can refine at any time.

For the second, I don't see anything wrong at all.  Do you just not like the style?
Beyond the design problems (examples above, plus more: [[http://i.imgur.com/Algh0Se.png| eg1]], [[http://i.imgur.com/FDYzdgX.png |eg2]]), 
this probably also needs to be QA-checked for functionality.

I just discovered this Bug: {T98905}
Removed Jared from assignee; who is driving this now? Let's not push something out as a beta feature that doesn't have someone to care for it.
{F158088}
{F158090}
Not sure if people will be too exited when stuff looks like this....
{F158088}

Not sure if people will be too exited when stuff looks like this....
This is now available on the beta cluster. http://en.wikipedia.beta.wmflabs.org/wiki/Special:Preferences#mw-prefsection-betafeatures
As I mentioned on [[ https://gerrit.wikimedia.org/r/#/c/175406/ | gerrit ]], the changes that were needed in mw.ui have been made. But, I am not sure how other parts of the work is progressing. 

@jdlrobson might know more.

***
//oops, made the same comment twice//
As I mentioned on [[ https://gerrit.wikimedia.org/r/#/c/175406/ | gerrit ]], the changes that were needed in mw.ui have been made. But, I am not sure how other parts of the work is progressing. 

@jdlrobson might know more.
>>! In T73477#1198457, @greg wrote:
> What's the plan/timeline, yo?

ETA please.
What's the plan/timeline, yo?
Tagged assuming that this might go ahead, but I have no special knowledge of it. :-)
https://gerrit.wikimedia.org/r/#/c/175406/
screenshot 1

Environment- test2, beta

1> In VE, go to Options  -> Categories. And add two categories.
2> Now delete the categories.Click on “Cancel” to close the  options dialog.
3> Error in console, “Uncaught TypeError: Cannot read property 'disconnect' of undefined”(see screenshot 1)

After this step, reopen the Options dialog , notice the first Category is repeated( see screenshot 2).

Trying to delete any of the categories throws errors in console “Uncaught Error: Cannot remove detached item” and “Uncaught TypeError: Cannot read property 'metaItem' of undefined”.Clicking on Cancel or Apply changes does not close the dialog.

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

**Attached**: {F15029}
Verified the fix in production
Verified the fix in production
Issue is now fixed in beta too.
Verified the fix in test2
Change 164018 merged by Catrope:
Account for categories being removed twice in MWCategoryWidget

https://gerrit.wikimedia.org/r/164018
Change 164018 had a related patch set uploaded by Jforrester:
Account for categories being removed twice in MWCategoryWidget

https://gerrit.wikimedia.org/r/164018
Change 163887 merged by jenkins-bot:
Account for categories being removed twice in MWCategoryWidget

https://gerrit.wikimedia.org/r/163887
Change 163887 had a related patch set uploaded by Catrope:
Account for categories being removed twice in MWCategoryWidget

https://gerrit.wikimedia.org/r/163887
Created attachment 16634
screenshot 2

**Attached**: {F15030}
video capture of the bug

Steps to reproduce:

1.Open a page with VE
2.Insert a link some where towards the end of the current viewport so that when you open the link inspector the link target suggestions overlap with the border of the page
3.After inserting the link, reopen the link inspector and place cursor inside to bring up the link target suggestion 
4.When the link target suggestion dropdown appears, scroll up the page 

Observed Result: 
The UI for the link inspector is open. 

See the video capture attached

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

**Attached**: {F14747}
Verified the fix in production
Verified the fix in test2
This is fixed by https://gerrit.wikimedia.org/r/#/c/163228/ and https://gerrit.wikimedia.org/r/#/c/163280/ as a side effect of fixing bug 52526
Environment-test2, beta

1> Insert Language in RTL direction.
2>insert a comment in the language text, right before the last word. Notice the word moves to the start of line.See screencast.
3>Now place the cursor at the end of the last char in the langauge text and press backspace to delete.

This also happens while inserting a citation or a formula.

--------------------------
**Version**: unspecified
**Severity**: minor
**OS**: Windows XP
Confirmed in test2 and Betalabs in Chrome.
http://youtu.be/6vtjey9UcCU
https://integration.wikimedia.org/ci/job/mediawiki-core-npm/2469/console

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

Etc.

--------------------------
**Version**: unspecified
**Severity**: blocker
I've purged the .npm cache. The coffee-scripts dependency seems to have been a result of cache corruption.

https://integration.wikimedia.org/ci/job/mediawiki-core-npm/2489/console

Passing now on integration-slave1006.
Seems to be an entirely different issue:

00:00:03.045 [mediawiki-core-npm] $ /bin/bash -xe /tmp/hudson6526668683101242560.sh
00:00:03.051 + cd /mnt/jenkins-workspace/workspace/mediawiki-core-npm/src/tests/frontend
00:00:03.052 + npm --version
00:00:03.346 1.3.10
00:00:03.351 + npm install
00:00:03.850 npm WARN package.json mediawiki@0.0.0 No description
00:00:03.851 npm WARN package.json mediawiki@0.0.0 No repository field.
00:00:03.852 npm WARN package.json mediawiki@0.0.0 No README data
00:00:03.910 + npm test
00:00:04.290 
00:00:04.290 > mediawiki@0.0.0 test /mnt/jenkins-workspace/workspace/mediawiki-core-npm/src/tests/frontend
00:00:04.290 > grunt test
00:00:04.291 
00:00:04.390 
00:00:04.390 module.js:340
00:00:04.390     throw err;
00:00:04.391           ^
00:00:04.392 Error: Cannot find module 'coffee-script'

I have took a snapshot of the workspace on integration-slave1006 in /home/hashar/bug71314/ and the issue is reproduced.

Looking at the dependencies:

$ npm list
mediawiki@0.0.0 /home/hashar/bug71314/src/tests/frontend
├─┬ grunt@0.4.2
│ ├── UNMET DEPENDENCY async ~0.1.22
│ ├── UNMET DEPENDENCY coffee-script ~1.3.3
│ ├── UNMET DEPENDENCY colors ~0.6.2
...

$ ls -1 node_modules/
grunt/
grunt-banana-checker/
grunt-contrib-jshint/
grunt-contrib-watch/
grunt-jscs/
grunt-jsonlint/
$

There are no 'node_modules' subdirectories below.

So somehow npm install does not install the dependencies :-/  Maybe it considers them as already installed because they are in the ~/.npm cache ?  I gave it a try by deleting my /home/hashar/.npm and running `npm install`.  That managed to pull all the needed dependencies and npm test is runnable.

I then deleted the node_modules sub directory and ran npm install again.  It installed the dependencies properly.


Maybe it is a cache corruption and we should delete the /mnt/home/jenkins-deploy/.npm/ directory?
This is still broken today, but in a different way now.

https://gerrit.wikimedia.org/r/#/c/163168/
https://integration.wikimedia.org/ci/job/mediawiki-core-npm/2484/console
**gerritadmin** wrote:

Change 163119 merged by jenkins-bot:
Migrate mediawiki-core-npm to Zuul cloner

https://gerrit.wikimedia.org/r/163119
Fixed by migrating the job to Zuul cloner which does not fetch submodules.
**gerritadmin** wrote:

Change 163119 had a related patch set uploaded by Hashar:
Migrate mediawiki-core-npm to Zuul cloner

https://gerrit.wikimedia.org/r/163119
Timo wrote:

> Hi Antoine,
> 
> https://integration.wikimedia.org/ci/job/mediawiki-core-npm/
> 
> As of build 2463[1], it's broken with some git error (there seems to be
> a stray extension directory even though it's against master).
> The previous build 2462[2] passed fine.
> 
> FYI: This is not related to switching to Ubuntu Trusty, since the jobs
> before that were working fine and also on Trusty.
> 
> — Timo
> 
> 
> [1] https://integration.wikimedia.org/ci/job/mediawiki-core-npm/2463/console
> [2] https://integration.wikimedia.org/ci/job/mediawiki-core-npm/2462/console


I noticed it attempt to submodule update and fails on AbuseFilter which
is the first submodule in core wmf branches.

My assumption is that a job previously ran for a wmf branch which has
submodule which were initialized.  Then a job against master is created,
the Jenkins git plugin clean the repo but does not uninitialise
submodules though they are not existant, so it bails out.

That is probably a behaviour change in git (Precise has 1.7.9.x while
Trusty has 1.9.1).


I would recommend to revert the npm jobs back to Precise nodes. Will
look at migrating the job from the evil Jenkins git plugin to the Zuul
cloner.


Do NOT upgrade the Jenkins git plugin.  It is terribly bugged and would
kill everything (I tried on labs, does not work :-D).
I depooled integration-slave1006.eqiad.wmflabs and a rebuild of the last failed mediawiki-core-npm job succeeded: https://integration.wikimedia.org/ci/job/mediawiki-core-npm/2471/
Steps to reproduce:

1.Open a page with mobile VE in iOS Safari
2.Open Cite>Website
3.Keep one of the required parameters empty and click on Insert
4.When the confirmation dialog for required parameter being missing shows up, click on Go back or Continue anyway.


Observed Result:
Observe that, the animation of the confirmation dialog appearing and disappearing is not same as how it is in desktop safari.Also, when closing the dialog, by tapping on "Go back"/"Continue Anyway", instead of sliding up it flickers at the top of the screen.

--------------------------
**Version**: unspecified
**Severity**: minor
Seems to work for me now. Tested on Beta Cluster using iOS Safari 8.0 on an iPad.
I found this bug while trying to swap the captions of two images, but it can be duplicated with just one image:

1. Paste this into a page and save:

Example text<ref name=Ref1>Ref 1</ref>
[[File:Example.jpg|thumb|Example text.<ref name=Ref1/>]]

2. Launch VE
3. Click the image and open the Media settings dialogue
4. Select all the caption text (Ctrl-A) and cut it out (Ctrl-X)
5. Apply changes
6. Reopen the Media settings dialogue
7. Paste the caption text back in (Ctrl-V)
8. Apply changes

VE will now hang on the Media settings dialogue.  The dialogue will not complete and will not cancel.  It is completely impossible to carry on editing, all the changes up to that point have to be discarded.

I am using FF32, Windows 7, Monobooks

--------------------------
**Version**: unspecified
**Severity**: major
See also bug 60919?
Screenshot

Steps to reproduce:


1.Open a page with VE
2.Insert the template "Citation needed"
3.Observe that in the field for "Month and year", the following has been used:
{{subst:CURRENTMONTHNAME}} {{subst:CURRENTYEAR}}
4.Now click on "Apply Changes"
5.Save the page
6.Reopen the page
7.Open the transclusion dialog for the "Citation Needed" template

Observed Result:
The current month name and current year value did not get added in the field.


Environment:Betalabs

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

**Attached**: {F14868}
(In reply to Rummana Yasmeen from comment #7)
> This seem to be not working in production (en.wiki).I dont even see the
> substitute values {{subst:CURRENTMONTHNAME}} {{subst:CURRENTYEAR}} for the
> parameters.

This seems to be because the Citation needed template on enwiki doesn't have the autovalue set up yet. James said he would do this, but he was waiting for this bug to be fixed.
This seem to be not working in production (en.wiki).I dont even see the substitute values {{subst:CURRENTMONTHNAME}} {{subst:CURRENTYEAR}} for the parameters.
Verified in betalabs.
Change 168205 merged by jenkins-bot:
Apply pre-save transform to template previews

https://gerrit.wikimedia.org/r/168205
Change 168204 merged by jenkins-bot:
Actually set parameter autoValues as values

https://gerrit.wikimedia.org/r/168204
Change 168205 had a related patch set uploaded by Catrope:
Apply pre-save transform to template previews

https://gerrit.wikimedia.org/r/168205
Change 168204 had a related patch set uploaded by Catrope:
Actually set parameter autoValues as values

https://gerrit.wikimedia.org/r/168204
Definitely VE's fault. We're somehow not sending the parameter value to Parsoid when saving.
Screenshot

Steps to reproduce:


1.Open a page with VE
2.Insert a bullet list or numbered list
3.Now try to add indentation to one of the item

Observed Result:
Apart from adding indentation, it ia also adding a new line and a new bullet point/numbered point


Environment:Betalabs

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

**Attached**: {F14804}
(In reply to Ed Sanders from comment #8)
> Recommend wontfix. There's no regular case to start a list at double
> indentation. This change doesn't event prevent that, just makes it visually
> clear what structure you should use.

Very well.
Recommend wontfix. There's no regular case to start a list at double indentation. This change doesn't event prevent that, just makes it visually clear what structure you should use.
(In reply to Mark A. Hershberger from comment #6)
> This is probably part related to Bug #37938, Bug #48010, and Bug #58335.

No, this has nothing to do with those bugs; it's about the visual display of empty structural list items.
This is probably part related to Bug #37938, Bug #48010, and Bug #58335.
(In reply to Ed Sanders from comment #4)
> I think it makes sense to have a slug there, as a double indented list is
> actually a list wrapped in a list, so you need to be able to split them and
> insert content.
> 
> Also you shouldn't double indent a list without content between, so this
> make it clear something is being done wrongly.

Sure, except you were the one to change the behaviour to this a few months ago, to match read mode rendering…
I think it makes sense to have a slug there, as a double indented list is actually a list wrapped in a list, so you need to be able to split them and insert content.

Also you shouldn't double indent a list without content between, so this make it clear something is being done wrongly.
Created attachment 16592
Screenshot in wmf22

Okay, so if I compare the behavior of indentation in wmf 22 , it didnt add any slug when I increase indentation for any bullet list.It just added indentation for that bullet point moving it to the right.But now it is adding a slug ,See the screenshot attached for wmf 22 to compare how it used to work.

**Attached**: {F14805}
Can you give more detailed instructions. I'm seeing slugs in lists but only in sensible places.
Due to the changes in how slugs work, presumably?
**Author:** `d_iarnov`

**Description:**
win 8.1  сенсорный .вообще нереально написать нажимая backspace  чтоб стереть  ошибочно написанное страницу подбрасывает вверх. и на этом точка. дальше работать соответственно не возможно. мало того в плиточном браузере вообще говорится что он не поддерживается. все браузеры у меня IE

**See Also**: {T73561}

---
Alternative steps to reproduce (in English, from T89196):

1. Edit [[Nausea]] in VE: https://en.wikipedia.org/wiki/Nausea?veaction=edit
2. Scroll down to the "Medications" section
3. Click in the middle of a sentence and hit "backspace" a few times.

Each time you do this, the page jumps, and the sentence in which the cursor is located always ends up at the very bottom of the viewport.

4. Press "delete" key a few times

Same behaviour.

5. Now click in the middle of the very long paragraph under "Diagnostic approach". Hit "backspace" a few times.

Once again, the page jumps, but now it is worse, because the page lands with the cursor offscreen.
This task is about VisualEditor. It sounds like you are talking about the mobile source editor, so please file a new task.
On android, mobile view, editing any wikimedia page, using backspace or cut for deleting text, makes the screen scroll up to almost top of page. For example, I try to edit https://en.m.wikipedia.org/wiki/Ringwoodite top paragraph, backspace to delete the dot on the end scrolls me back to | class... in the infobox.
Change 207875 merged by jenkins-bot:
ui.ListAction: Fix screen jumping in Internet Explorer

[[https://gerrit.wikimedia.org/r/207875]]
Change 207875 had a related patch set uploaded (by MarkAHershberger):
Fix screen jumping

[[https://gerrit.wikimedia.org/r/207875]]
Probably not. We keep all existing documentation public, in source code or on mediawiki.org.
I'd like to get a better understanding of how to troubleshoot and extend VE and this issue has been marked as very important by a client.

I've poked at similar bugs, but I'm not sure how they relate to this one and their solutions confuse me.  Is there anywhere I can look for more information on tracking it down?
*** Bug 72646 has been marked as a duplicate of this bug. ***
For me it scrolled abruptly almost to the top of the page (but not quite) and stayed there when I continued backspacing. I was testing on https://pl.wikipedia.org/wiki/Fotografia_cyfrowa (random page), for the record.
Added possibly-related bug 71561?
Testing VE (both mobile and desktop) on a tablet (not phone) with both
Windows 7 and 8.1, backspacing (both using software or hardware keyboards) works, but causes the page to abruptly scroll up. Just typing text doesn't cause this behavior. I'm going to assume that this was the original issue that was meant to be reported here :)
Marking as "Low" priority until more details are provided.
Thanks for taking the time to report this!

Am I correct that this is about Windows 8.1 phone?
Could you provide exact steps to reproduce (step by step) in English what exactly is broken with backspace, and where exactly this happens (web address)?

Please also see https://www.mediawiki.org/wiki/How_to_report_a_bug because "doesn't work" isn't a good bug summary. :)
Steps to reproduce:

1.Open a page with VE
2.Insert an image with caption
3.Reopen the media settings dialog 
4.Now apply link to the existing caption

Observed Result:
The "Apply changes" button does not become enabled after applying link unless user make some other change for that image

Environment: Betalabs, Test2 and Production

--------------------------
**Version**: unspecified
**Severity**: normal
>>! In T73065#959930, @Whatamidoing-WMF wrote:
> No, this is still broken.  I could reproduce this problem at mediawiki.org this morning.

Re-broken in T8… something.
No, this is still broken.  I could reproduce this problem at mediawiki.org this morning.
This apparently is long-ish-fixed?
This was also reported in Mac OS X 10.9.5 in both Firefox and Safari.
**Author:** `physik`

**Description:**
On a fresh vagrant box with the role math enabled I get the following error message while trying to run the browser tests for math

 unable to obtain stable firefox connection in 60 seconds (127.0.0.1:7055) (Selenium::WebDriver::Error::WebDriverError)
  /srv/vagrant/mediawiki/extensions/Math/tests/browser/.gem/ruby/2.0.0 /gems/selenium-webdriver-2.42.0/lib/selenium/webdriver/firefox
see
 https://gist.github.com/physikerwelt/8a9ff6b292609449a2df

I was doing nothing else beside running
 bundle exec cucumber features/math.feature

I checked my environment variables
MW_INSTALL_PATH=/vagrant/mediawiki
MEDIAWIKI_API_URL=http://127.0.0.1/w/api.php
MEDIAWIKI_USER=Selenium_user
MEDIAWIKI_PASSWORD=vagrant
INSTANCEPROJECT=math
COMPOSER_CACHE_DIR=/vagrant/cache/composer
MEDIAWIKI_URL=http://127.0.0.1:8080/wiki/

but could not detect any problems there

--------------------------
**Version**: unspecified
**Severity**: normal
**physik** wrote:

Technically you are right.
I added a section to 
https://www.mediawiki.org/wiki/Quality_Assurance/Browser_testing/Running_tests#Running_VisualEditor_browser_tests_via_labs-vagrant
X isn't required as headless mode runs Firefox through xvfb. Use of phantomjs (note the "js") as the browser is inherently headless so you don't need to specify the HEADLESS env var.

You can also try using X forwarding but it's a little trickier since your labs instance may not allow it. You can inquire on #wikimedia-labs or #wikimedia-qa IRC channels about getting that setup.

This bug is technically resolved if you're not seeing the firefox connection error. Your feature looks to be executing correctly, and the scenario is either failing positively or falsely. You'll have to jump into the browser session to find our more. Jump on the #wikimedia-qa channel or email the QA list for help! [1]

[1] https://lists.wikimedia.org/mailman/listinfo/qa
**physik** wrote:

Thanks. This changes the problem
And I am at page that does not exist           # features/step_definitions/math_steps.rb:13
    And I click link Create source                 # features/step_definitions/math_steps.rb:17
      timed out after 5 seconds, waiting for {:text=>"Create source", :tag_name=>"a"} to become present (Watir::Wait::TimeoutError)
      ./features/step_definitions/math_steps.rb:18:in `/^I click link Create source$/'
      features/math.feature:18:in `And I click link Create source'
    When I type <math>3 + 2</math>                 # features/step_definitions/math_steps.rb:25

I did not setup an x environment. Is that required?
I tried to set my environment variable BROWSER=phantom but this did not help either.
Those error messages from Firefox don't necessarily indicate failure. I would kill the firefox processes and try again, running in headless mode first to rule out X-forwarding issues.

HEADLESS=true bundle exec cucumber ...
Those error messages from Firefox don't necessarily indicate failure. I would kill the firefox processes and try again, running in headless mode first to rule out X-forwarding issues.

HEADLESS=true bundle exec cucumber ...
**physik** wrote:

Thanks for the tip.
However, that did not change anything.
tests/browser$ bundle show selenium-webdriver
/var/lib/gems/2.0.0/gems/selenium-webdriver-2.43.0
tests/browser$ firefox --version
(process:21861): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Mozilla Firefox 32.0

Even downgrading to ff28 did not help.
This issue was recently documented on the QA list. [1]

Issue: selenium-webdriver < 2.42 doesn't work with Firefox 32.
Solution: Update your gems by running `bundle update` in your tests/browser directory and verify that you're using selenium-webdriver >= 2.43 by running `bundle show selenium-webdriver`.

[1] https://lists.wikimedia.org/pipermail/qa/2014-September/001890.html
TODO someone needs to figure out what the visual treatment should look like

The inputs in question already match :required:empty , so we can probably do most of this with CSS.

--------------------------
**Version**: unspecified
**Severity**: enhancement
Verified the fix in production
**gerritadmin** wrote:

Change 161613 merged by jenkins-bot:
Style required but currently-invalid parameters on the template dialog

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

Change 162511 merged by jenkins-bot:
TextInputWidget: Add setValidation function to change pattern used to validate text

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

Change 162511 had a related patch set uploaded by Alex Monk:
TextInputWidget: Determine validity in onEdit rather than in setValue

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

Change 161516 merged by jenkins-bot:
TextInputWidget: Determine validity on blur and change.

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

Change 161613 had a related patch set uploaded by Alex Monk:
Style required but currently-invalid parameters on the template dialog

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

Change 161516 had a related patch set uploaded by Alex Monk:
Make InputWidget mixin FlaggedElement

https://gerrit.wikimedia.org/r/161516
Possible options:

* Put a red(?) ring/border around the field
* Put a red(?) ring/border around the field's label
* Make the field's indicator red(?)
* Make the field's background red(?)

This class we'd toggle on/off should probably be in OOUI.
screenshot

Environment- Test2, beta, production

Highlight a citation and select any text style from the drop-down. I get "Uncaught TypeError: Cannot read property 'getSurface' of null".

--------------------------
**Version**: unspecified
**Severity**: minor
**OS**: Windows XP

**Attached**: {F14829}
(In reply to Rummana Yasmeen from comment #4)
> (In reply to Ritu Swain from comment #3)
> > (In reply to Rummana Yasmeen from comment #1)
> > > I could reproduce it while applying the text style, but the heading styles
> > > on Citation,your screenshot also matches with the later case.
> > 
> > Rummana,it happens when the citation is highlighted and i change the text
> > style to anything(not just Heading). In the screenshot, i had changed the
> > style from paragraph to Heading, while the citation was highlighted.
> 
> Ritu, yes that is what I am referring to by "applying Heading Style" which
> includes any of those heading formats (Heading,sub-heading 1 etc). By "Text
> style", I thought you are referring to text formatting (Bold/Italic etc),
> which I think is not how you reproduced this issue?

i am not in front of my system to actually check it. but yes by "Text Style" i meant the headings and not the font styles.
(In reply to Ritu Swain from comment #3)
> (In reply to Rummana Yasmeen from comment #1)
> > I could reproduce it while applying the text style, but the heading styles
> > on Citation,your screenshot also matches with the later case.
> 
> Rummana,it happens when the citation is highlighted and i change the text
> style to anything(not just Heading). In the screenshot, i had changed the
> style from paragraph to Heading, while the citation was highlighted.

Ritu, yes that is what I am referring to by "applying Heading Style" which includes any of those heading formats (Heading,sub-heading 1 etc). By "Text style", I thought you are referring to text formatting (Bold/Italic etc), which I think is not how you reproduced this issue?
(In reply to Rummana Yasmeen from comment #1)
> I could reproduce it while applying the text style, but the heading styles
> on Citation,your screenshot also matches with the later case.

Rummana,it happens when the citation is highlighted and i change the text style to anything(not just Heading). In the screenshot, i had changed the style from paragraph to Heading, while the citation was highlighted.
(In reply to Rummana Yasmeen from comment #1)
> I could not reproduce it while applying the text style, but the heading styles
> on Citation,your screenshot also matches with the later case.
I could reproduce it while applying the text style, but the heading styles on Citation,your screenshot also matches with the later case.
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Add a citation in the page
3.Now click outside the page

Observed Result:
The Cite option and the Re-use option inside it remains enabled in the toolbar

See the screenshot attached

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

**Attached**: {F14780}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 160556 merged by jenkins-bot:
Check whether there is a range selected when enabling/disabling re-use citation tool

https://gerrit.wikimedia.org/r/160556
Change 160556 had a related patch set uploaded by Alex Monk:
Check whether there is a range selected when enabling/disabling re-use citation tool

https://gerrit.wikimedia.org/r/160556
size invalid message shown

Environment- Test2, beta

1> Go to media settings dialog for any image.
2>Go to Advanced Settings -> In Image size, click on custom and change its size to 0x0px.Notice message saying “Size values are invalid” shows up under the Make Full size button.
3> Now choose a different image and for that image repeat steps #2.Notice “Size values are invalid” does not show up.

Also if the image size is invalid then the insert button should get disabled, preventing the user from inserting it.

--------------------------
**Version**: unspecified
**Severity**: minor
**OS**: Windows XP

**Attached**: {F14762}
Not pulled through yet, but will be.
**gerritadmin** wrote:

Change 164784 merged by jenkins-bot:
Emit change event when dimensions change in MediaSizeWidget

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

Change 164784 had a related patch set uploaded by Mooeypoo:
Emit change event when dimensions change in MediaSizeWidget

https://gerrit.wikimedia.org/r/164784
When the image size is default, inserting a non-numeric char changes it to custom.And if i keep entering non-numerics, then it gives the message "Size values are Invalid", but the "Insert" button stays active.

It gets disabled only when you further make any changes to the settings. for ex-uncheck the “Wrap text around this item” checkbox or change the Image type to Basic /Frameless.Notice when any change is made to the settings then only the Insert button gets disabled and not when an invalid size is detected.
(In reply to Rummana Yasmeen from comment #9)
> Right now, it is not doing what you are suggesting here,the widget just does
> not let you type anything when you try to input 0 and "not" making it
> "default"

It's making it default, which erases the visible values. Technically it does what I explained; practically it does what you say. It's the same thing, but different user experiences.

I am not sure if it's right to change the current behavior on that, though.

> But, this is what it is doing right now.It is changing the value
> automatically to default when user inputs non-numeric character.So, I
> suggested to have similar behavior for both cases.

I see what you're saying, but my point is that there's a difference conceptually between the two cases, so I think it's okay that the two behaviors are different two.

When a user inserts "0" value, they likely meant for the image to have no dimensions, which effectively means it is defaulted.

When a user inserts a non-numeric letter like "a" or "-" it is very likely that it's an error and even if it's not, we have no way of knowing what the user meant. Hence, we don't assume anything and instead we mark the values as "invalid".
(In reply to Moriel Schottlender from comment #8)
> We didn't want to force an input on the user, which is why non-numeric input
> is allowed (but invalid.) The only problem with 0's is that practically
> speaking, an empty input and 0 are more or less the same, so 0 (or empty)
> assumes the user *meant* to say they don't want to set values -- which means
> they wanted to go with "default".

Right now, it is not doing what you are suggesting here,the widget just does not let you type anything when you try to input 0 and "not" making it "default"

> 
> Changing the value automatically when the user inputs a non-numeric
> character can be annoying if it was done by mistake. If I want to type 156
> and I accidentally type 15t, it wouldn't be very comfortable to have the
> widget automatically make my values into default.

But, this is what it is doing right now.It is changing the value automatically to default when user inputs non-numeric character.So, I suggested to have similar behavior for both cases.

> 
> I think that the 0-to-default makes sense, but the other behavior will be
> more of a hinderance to the user than help.
We didn't want to force an input on the user, which is why non-numeric input is allowed (but invalid.) The only problem with 0's is that practically speaking, an empty input and 0 are more or less the same, so 0 (or empty) assumes the user *meant* to say they don't want to set values -- which means they wanted to go with "default".

Changing the value automatically when the user inputs a non-numeric character can be annoying if it was done by mistake. If I want to type 156 and I accidentally type 15t, it wouldn't be very comfortable to have the widget automatically make my values into default.

I think that the 0-to-default makes sense, but the other behavior will be more of a hinderance to the user than help.
Right now, if you try to input 0 , the widget just does not let you to enter it, but as soon as you type some non numeric character, it automatically sets to default size , I think both cases should have same action: set to default size.
**gerritadmin** wrote:

Change 160790 merged by jenkins-bot:
Set size to default on 0 value

https://gerrit.wikimedia.org/r/160790
I can still reproduce this on Betalabs.
**gerritadmin** wrote:

Change 160789 merged by jenkins-bot:
Validate size widget when activating/deactivating apply button

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

Change 160790 had a related patch set uploaded by Mooeypoo:
Set size to default on 0 value

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

Change 160789 had a related patch set uploaded by Mooeypoo:
Validate size widget when activating/deactivating apply button

https://gerrit.wikimedia.org/r/160789
Created attachment 16474
size invalid message not shown when choosing a different image

**Attached**: {F14764}
Environment- Test2, beta

1> Go to Media Search dialog, it opens with the input box populated with the user name in it.
2> I get JS console error Uncaught TypeError: undefined is not a function   , while the media search is still in progress .

--------------------------
**Version**: unspecified
**Severity**: minor
(In reply to James Forrester from comment #3)
> This was fixed in MediaWiki core as of wmf4 (to be released tomorrow to
> MediaWiki.org).

James is talking about a different thing that was fixed in wmf4.

This bug is caused by an issue in jQuery with canceling JSONP requests. It can only be fixed if jQuery fixes it upstream, and I don't think that will happen.

Closing as WONTFIX for lack of a RESOLVED UPSTREAM status.
This was fixed in MediaWiki core as of wmf4 (to be released tomorrow to MediaWiki.org).
This is a problem with the API in general, and while it is throwing an error, it shouldn't actually affect anything in the system -- that is, this error is stating that the API is unhappy about uselang variable, but the system is still working through the responses properly.
Created attachment 16625
screenshot

1> Open insert -> Media. click "cancel"to close the dialog.
2> reopen the media search dialog,JS console error at this point.

**Attached**: {F14759}
The list of allowed skins of the BetaFeatures extension (in $prefs[$key]['requirements']['skins']) is not displayed in the HTML code.

--------------------------
**Version**: master
**Severity**: normal
**URL**: https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-betafeatures
Thank you!
Change 161629 merged by jenkins-bot:
Display allowed skins if and only if the current skin is not allowed

https://gerrit.wikimedia.org/r/161629
(In reply to Seb35 from comment #9)
> Yes, I didn’t describe exactly the bug: the allowed skins were never
> displayed in the HTML, neither when the current skin is an allowed skin,
> neither when the current skin is not an allowed skin.
> 
> With the patch, the JS warning is now correctly triggered. When a blacklist
> is specified for a beta feature, it is always added in the HTML.
> 
> For the skin, you are right, it should be displayed only when the current
> skin is not allowed. See next patch.

This looks good, thank you. :-)
Change 161629 had a related patch set uploaded by Seb35:
Display allowed skins if and only if the current skin is not allowed

https://gerrit.wikimedia.org/r/161629
Yes, I didn’t describe exactly the bug: the allowed skins were never displayed in the HTML, neither when the current skin is an allowed skin, neither when the current skin is not an allowed skin.

With the patch, the JS warning is now correctly triggered. When a blacklist is specified for a beta feature, it is always added in the HTML.

For the skin, you are right, it should be displayed only when the current skin is not allowed. See next patch.
I'm… confused.

The purpose of the Beta Feature warning section is to inform you why enabling it won't be useful to you.

I.e.:

* if you don't have JS working, tell you if it needs JS;
* if you don't use Vector, tell you if it only works for that skin;
* if you don't have Internet Explorer, tell you if it only works in that browser.

If none of these are met (i.e., it should work), the warnings should not appear.

The title of this bug suggests that this is not understood.
Hah, fascinating. Okay, let's do this then.

Should we mark this as resolved after merging the patch, or do you want to actually display this information?
Change 160213 merged by jenkins-bot:
Display the required skins

https://gerrit.wikimedia.org/r/160213
Thanks for your comment, I didn’t paid attention to the JS warning who disappeared, but by further investigating:
1/ it is a feature to hide the warning "JS is required" when JS is enabled (see resources/betafeatures.js, there is the comment "We're here so JavaScript works"), and
2/ it was previously displayed because no skins were found in BetaFeaturesHooks::getPreferences (there are warnings in the debug log "[BetaFeatures] The visualeditor-enable BetaFeature has no valid skins installed."), which results not to add these beta features in the wgBetaFeaturesFeatures JS variables, which results betafeatures.js don’t loop into these beta features and don’t hide the JS warning (and don’t test if the browser is supported).

So the bug is deeper I first thought, and I find it worth fixing it. But I aggree the skins requirements are not necessary and it is a change from the current behaviour, so I hide them in the LESS file (to keep consistency with current behaviour).
Fixing this bug will result in big red warnings being displayed under most BetaFeatures. The warnings also mention the hidden Minerva skin (e.g. for VisualEditor). Furthermore, they override the warnings about JavaScript being required.

The bug is real and the fix is correct, but I'm pretty sure people started relying on the bug being a feature, and fixing this brings out a few more bugs. The existing beta features need be reviewed in context of this first, and I have no idea who's going to do it. :/
The current state on the Wikimedia project is without the names of the required skins. In the case it is wanted to keep the current state (for Wikimedia and/or for the master branch of BetaFeatures), this feature can be hidden with CSS, similarly to the browser requirements, by editing BetaFeatures/resources/betafeatures.less.
Change 160213 had a related patch set uploaded by Seb35:
Display the required skins

https://gerrit.wikimedia.org/r/160213
The problem comes from BetaFeaturesHooks::getPreferences, in the code

  $prefs[$key]['requirements']['skins'] = array_intersect( $prefs[$key]['requirements']['skins'], Skin::getAllowedSkins() );

because Skin::getAllowedSkins() is an array key-value and we want the key and not the value, so it should be used array_keys( Skin::getAllowedSkins() ).

I prepare the patch.
**Author:** `thalia.chan`

**Description:**
Copied the heading "Lilypond source" and the line of text below from this page: https://commons.wikimedia.org/wiki/File:C_sharp_and_double_sharp_music.svg?veaction=edit

Pasted it into a similar page, open in a different tab, and a grey circle containing a question mark appeared at the end, which I am reliably informed is a comment. (Abandoned my edit in the end, so there's nothing to clean up.)

--------------------------
**Version**: unspecified
**Severity**: normal
**Platform**: PC
**gerritadmin** wrote:

Change 160179 merged by jenkins-bot:
Strip Start/EndFragment comments from paste

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

Change 160179 had a related patch set uploaded by Esanders:
Strip Start/EndFragment comments from paste

https://gerrit.wikimedia.org/r/160179
The copied element here is just the LilyPond source template. Confirmed this bug in Win8/Chrome but not Ubuntu/Chrome. The comment inserted is <!-- EndFragment --> and comes from the clipboard API, not CE paste.
This is not really a ResourceLoader bug but serious enough that some workaround is needed and that probably has to be done via RL.

Due to jQuery bug #10251 [1] (wontfixed), errors in a jQuery domready handler prevent all subsequently added domready handlers from running. This means that errors in less reliable scripts like gadgets or user scripts can break any production code that is loaded after them and relies on $.ready (which is true for most extensions).


[1] http://bugs.jquery.com/ticket/10251
* This applies to any event handler, not just DOMContentLoaded. E.g. click events: http://jsfiddle.net/mj8yeLmy/. Most instances of domready-handlers should probably use a `mw.hook` if they want to work as expected in the future of partial documents changing without refresh (as is already happening in LiquidThreads, VisualEditor, Flow and core's LivePreview).
* Regarding gadgets not breaking, the same policy as extensions applies. Extensions can interfere with core, just as gadgets. If they misbehave with a certain language/wikiproject/skin combination; that should be fixed, or the relevant module excluded from running in that case, or disabled/not-enabled by those users (it's common for gadgets to say in their description "Vector-only"). Can you given an example of a gadget causing errors in a certain skin-browser combination? That's relatively rare in my experience (except for outdated copies of gadgets on small wikis; this is generally addressed by loading the gadget from commons/meta/enwiki/mworg directly). It's generally fixed quickly when reported to gadget maintainers.
* I've seen gadgets affecting the DOM of MediaWiki core and extension modules plenty. It's not rare.

I'm still open to exploring a workaround on our side (in MediaWiki core). Note however that:
* The $.ready promise does not expose its internal `jQuery.Callbacks` instance. Neither does it keep track of which have fired.
* domready handlers should become rare over time. There are very few use cases left for it in our environment.
* Beware the inconsistency with other event handlers.
* This applies to any event handler, not just DOMContentLoaded. E.g. click events: http://jsfiddle.net/mj8yeLmy/. Most instances of domready-handlers should probably use a `mw.hook` if they want to work as expected in the future of partial documents changing without refresh (as is already happening in LiquidThreads, VisualEditor, Flow and core's LivePreview).
* Regarding gadgets not breaking, the same policy as extensions applies. Extensions can interfere with core, just as gadgets. If they misbehave with a certain language/wikiproject/skin combination; that should be fixed, or the relevant module excluded from running in that case, or disabled/not-enabled by those users (it's common for gadgets to say in their description "Vector-only"). Can you given an example of a gadget causing errors in a certain skin-browser combination? That's relatively rare in my experience (except for outdated copies of gadgets on small wikis; this is generally addressed by loading the gadget from commons/meta/enwiki/mworg directly). It's generally fixed quickly when reported to gadget maintainers.
* I've seen gadgets effecting the DOM of MediaWiki core and extension modules plenty. It's not rare.

I'm still open to exploring a workaround on our side (in MediaWiki core). Note however that:
* The $.ready promise does not expose its internal `jQuery.Callbacks` instance. Neither does it keep track of which have fired.
* domready handlers should become rare over time. There are very few use cases left for it in our environment.
* Beware the inconsistency with other event handlers.
See the blocked bug (T72756) for an example.

Broken code should definitely not be silenced; the jQuery bug is not about silencing but limiting the effect of an error to the code which caused it. Which is a good practice in general, but I can see how jQuery has no easy way of following it in this case, without causing massive B/C breaks in promise behavior (although special-casing $.ready might be easier).

This wouldn't be a problem on Wikimedia sites if there was an expectation for gadgets to not break, but my experience on medium-to-small wikis is that a few gadget-skin-browser combinations are broken at any given time, so seeing errors in the console in itself is not surprising, and if a completely unrelated product starts misbehaving, gadget maintainers are not going to attach any significance to it. So I'm not sure "loudly" is a fair description of a gadget throwing an exception.

I don't think the same if true for gadgets messing up the DOM or otherwise affecting other modules; while in theory it's possible for that to happen in such a way that the gadget is not suspected, in practice I haven't ever seen that happening.

One way to handle this (that could be inside or outside of jQuery) is to set up a timeout to check whether all domready handlers were executed, and force execution manually if it was broken by an exception. That would not stop the exception from being thrown and reported, but would limit its effect to the domready handler which caused it.
An example of where this happened would be useful to assess what kind of code did this, who the affected users were, how and by whom it was addressed, etc.

Initially I'm inclined to agree with jQuery and, here too, consider this an invalid bug. Broken code should not be silenced. There's a 1001 ways for gadgets and user scripts to break unrelated modules. That's the DOM for you. 

This problem is in many ways similar to extensions vs MediaWiki core. When it goes wrong, the bug is reported, the broken module is found and either fixed or temporarily disabled until a maintainer can look into it. I think it's acceptable to encourage the community to apply a similar policy to their gadgets.

If a gadget is broken, you can't leave it enabled and expect everything to degrade gracefully. There's too many asynchronous paths for code to take that absorbing it would be impossible (or unpractical). That's a responsibility gadget authors carry and should be familiar with if they've been given such access. And even if we could, trying to absorb it is in my opinion not we should want to achieve.

I'm all for graceful degradation and often try to address hurdles and make user experiences as smooth as we can.

But in cases like this, I'm all for letting it fail loudly. That's what errors are for.
double Toolbars in VE

Environment- Test2, beta

1> switch from Edit beta mode to Read mode notice the toolbar has slide down and is still visible in the Read mode.

2> Click on Edit beta again,the Editor is displayed with two toolbars.See screenshot.

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70770
https://bugzilla.wikimedia.org/show_bug.cgi?id=70782

**Attached**: {F15240}
Verified the fix in production
verified the backport in test2
**gerritadmin** wrote:

Change 162497 merged by Catrope:
Don't drop 1px rects for FocusableNodes if all we have is 1px rects

https://gerrit.wikimedia.org/r/162497
Verified the fix in Betalabs
**gerritadmin** wrote:

Change 162497 had a related patch set uploaded by Catrope:
Don't drop 1px rects for FocusableNodes if all we have is 1px rects

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

Change 162360 merged by jenkins-bot:
Don't drop 1px rects for FocusableNodes if all we have is 1px rects

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

Change 162359 merged by jenkins-bot:
Tolerate null boundingRect in all code paths in DesktopContext#updateDimensions

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

Change 162360 had a related patch set uploaded by Catrope:
Don't drop 1px rects for FocusableNodes if all we have is 1px rects

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

Change 162359 had a related patch set uploaded by Catrope:
Tolerate null boundingRect in all code paths in DesktopContext#updateDimensions

https://gerrit.wikimedia.org/r/162359
Ok thanks so much Ritu! I can now reproduce it.The following error appears in the console as well:
Uncaught TypeError: Cannot read property 'height' of null
(In reply to Rummana Yasmeen from comment #11)
> I cannot reproduce it following your steps.In steps 4, you mentioned to
> repeat step 2, what change have you done in the page for the second time to
> save it?

http://youtu.be/CNqxmnconN8
I cannot reproduce it following your steps.In steps 4, you mentioned to repeat step 2, what change have you done in the page for the second time to save it?
This issue is reappearing.

Steps-
1> in a blank page insert a Reflist or Notelist Template.
2> Save the page and reopen it in VE mode.
3> Now cilck on the Read tab. 
4> Repeat steps #2 and #3. Toolbars are getting added.
Verified the fix in test2
Verified the fix in Betalabs
https://gerrit.wikimedia.org/r/160076 (the fix for bug 70770 fixes this too).
Created attachment 16454
Screenshot

Ok, so I reproduced it on my user page too.This is happening when you just have the following on your page:

 __NEWSECTIONLINK____NOTOC__

**Attached**: {F15241}
(In reply to Rummana Yasmeen from comment #4)
> Ritu, can you share the link to the page where you are getting this, I can't
> reproduce it either.

links-:
https://test2.wikipedia.org/wiki/User:Swainr?veaction=edit

http://en.wikipedia.beta.wmflabs.org/wiki/User:Swainr?veaction=edit
Ritu, can you share the link to the page where you are getting this, I can't reproduce it either.
(In reply to Roan Kattouw from comment #2)
> I can't reproduce this. Does this also happen when you're logged out?

I can reproduce it(tried with a clear cache). Yes, it happens even when i am logged out.
I can't reproduce this. Does this also happen when you're logged out?
Browsers- FF and Chrome. Couldn't test on Safari.
There are no unit tests exercising features of dm.Converter that are currently unused by our node types, like returning null/undefined from toDataElements to trigger alienation, returning one a different type from toDataElements, returning an annotation type from a node's toDataElements, etc.

--------------------------
**Version**: unspecified
**Severity**: enhancement
1. place cursor in large body of text in FF
2. Cursor up then down, everything is fine
3. Cursor right a dozen or so times, then up

Then cursor jumps up and left to the same place it was after (2).

Initial investigations show that disabling handling of up/down arrows makes no difference, but disabling handling of left/right does fix, so probably something to do with the surfaceObserver state?

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
https://bugzilla.mozilla.org/show_bug.cgi?id=1075901
Possibly not anything we can actually fix…
Workaround reverted, caused bug 71580 (ugly-looking "NS_ERROR_FAILURE" exceptions in some cases).
More "worked around" than actually fixed, but…
**gerritadmin** wrote:

Change 164162 merged by jenkins-bot:
ve.ce.Surface: Magic workaround for broken Firefox cursoring

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

Change 164162 had a related patch set uploaded by Bartosz Dziewoński:
ve.ce.Surface: Magic workaround for broken Firefox cursoring

https://gerrit.wikimedia.org/r/164162
Upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1075901
Calling nativeSelection.collapseToStart() seems to magically fix the erroneous behavior (http://jsfiddle.net/ybawstce/3/), we can probably use that as a workaround for selections that are already collapsed.

(I see no neat way to fix non-collapsed ones; randomly calling some other Selection methods might help, but they probably won't be no-ops. These are a smaller problem anyway and can wait for Firefox to fix their bug.)

I'm filing this upstream.
Minimal test case: http://jsfiddle.net/ybawstce/1/

(This will throw errors in some edge cases, but that's not the point; try arrowing around near the middle of the text.)
Looks like a browser bug with Firefox's native selection having inconsistent state. I'm going to try poking some more at this tomorrow and maybe file some upstream bugs.
Per Ed:

| FIXME: This should be a sibling of the description label, with enough space
| left to the right of the description so it shows even if the description is
| too wide (e.g. an external link)

--------------------------
**Version**: unspecified
**Severity**: normal
This code has been substantially re-written since this task was created; the concern no longer applies.
There is an issue in Chrome when using the VisualEditor extension. The dropdowns in the VE toolbar seem to be opening "under" the content area, hiding their contents.

The problem is a bug in the jQuery 1.8 lib used in MW <1.24 (or a variation thereof): http://bugs.jquery.com/ticket/11635

Todo: Backport the fix in jQuery 1.11.

--------------------------
**Version**: 1.23
**Severity**: normal
Works with latest versions of VE and Chameleon skin.
… and use them.

--------------------------
**Version**: unspecified
**Severity**: enhancement
... Doesn't it do this already?
screenshot1

Environment- test2, beta, production

1> open a page in VE, add a template. Add a Field name to the template, now delete that name.
2>click to add more information again, notice  the previous field name entry is shown  in a list.
3>  In the same Field name, type in another name , now delete that name.
4> Repeat steps #2 and 3. Until you get the show one more field(this appears after the 4th entry). Click on it and it seems to add nothing to the existing Template data.
Same behavior can be seen with Templates having at least 4 parameters, for ex- Reflist.
See screenshots.

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

**Attached**: {F14783}
Issue fixed in test2, beta, production.
**gerritadmin** wrote:

Change 160500 merged by jenkins-bot:
Template dialog: Show up to the limit of parameters, not up to the limit + 1

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

Change 160500 had a related patch set uploaded by Jforrester:
Template dialog: Show up to the limit of parameters, not up to the limit + 1

https://gerrit.wikimedia.org/r/160500
Created attachment 16415
screenshot2

**Attached**: {F14784}
In Chrome and Internet Explorer it is perfectly possible to click repeatedly on the Save button and achieve nothing. On large portions of it (especially at the top, but you can also place the pointer exactly between the two words and get the same result) the pointer won't change.

--------------------------
**Version**: unspecified
**Severity**: normal
Nope. Just tried again incognito mode on IE, FF and Chrome.
(In reply to Elitre from comment #4)
> It's not gone for me.

It works for me. Does it work for you when you're logged out?
It's not gone for me.
Yes.
This is probably the bug fixed by 2aebe8054eed2516ac06c62101f2793f29c416aa.
Actually, Safari is probably the only browser where this doesn't happen. You can reproduce on all the 3 buttons near the Save one, but not on the dialogs' ones.
The LST markers <section begin="2011-07-25" /> and <section end="2011-07-25" /> used to be unparsed, but now that Parsoid parses them to <meta>s they're uneditable. Boo.

(The actual transclusion {{#lst:Foo|Bar}} as a parser function "just works".)

--------------------------
**Version**: master
**Severity**: enhancement
how would you activate the alienextensionnode editor/module on a Wiki? I've played around with the $wgVisualEditorPluginModules array, but cannot get it to work.
Ok, it seems to me that the alienextensionnode editor is activated on the Page: namespace but not on the main namespace (or something like that).

But as we should definitely create an editing widget for this tag, we will fix this issue at the same time.
I tried this page and unfortunately it was just changed today so that the <section> tag at the beginning was removed; so I created another page on that Wiki with a section tag:

[[ https://en.wikisource.org/w/index.php?title=Sectiontest&veaction=edit | https://en.wikisource.org/w/index.php?title=Sectiontest&veaction=edit ]]

unfortunately I don't see that the section tag is handled at all; it doesn't seem to be rendered. Can you take a look?
I tried this page and unfortunately it was just changed today so that the <section> tag at the beginning was removed; so I created another page on that Wiki with a section tag:

[[ https://en.wikisource.org/w/index.php?title=Sectiontest&action=edit | https://en.wikisource.org/w/index.php?title=Sectiontest&action=edit ]]

unfortunately I don't see that the section tag is handled at all; it doesn't seem to be rendered. Can you take a look?
It seems to me that the latest versions of VisualEditor and Parsoid provides basic support (with an editing UI) for the <section> tag.

For example: https://en.wikisource.org/wiki/Page:Dictionary_of_Christian_Biography_and_Literature_(1911).djvu/161?veaction=edit (there is a <section begin=""> tag at the beginning of the page's body.

But we should definitely create a nicer UI for them.
will this task be worked again?
**gerritadmin** wrote:

Change 162652 had a related patch set uploaded by Jforrester:
[WIP] In VisualEditor, show <section> elements and let them be edited

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

Change 159182 abandoned by Jforrester:
[WIP] Show LST <section> elements and let them be edited

Reason:
Moving to LST repo.

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

Change 159182 had a related patch set uploaded by Jforrester:
[WIP] Show LST <section> elements and let them be edited

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

1.Open a page with VE
2.Open Media Settings dialog for a Frameless/Basic type image which does not have "Border" set to it.
3.Now check the "Border" checkbox


Observed Result:
It does not enable the "Apply Changes" button in the media Settings dialog

Environment:Betalabs

--------------------------
**Version**: unspecified
**Severity**: minor
Verified the fix in production
Verified the fix in test2
Released in OOjs 1.1.1, now in MW-core etc.
Should be fixed by https://gerrit.wikimedia.org/r/#/c/159639/
This is due to an OOjs bug.

>>> OO.compare( { foo: 3 }, { foo: 4 } )
false

>>> OO.compare( { foo: false }, { foo: true } )
true

Because we have special cases for 'number' and 'string' but not 'boolean'.
This is similar to Bug 69711.

Steps to reproduce:

1.  Type some text:  "Foo bar baz bat"

2.  Add a citation.

3.  Finish typing the sentence.

6.  Oops, where did the citation go?


Results:

When you exit the ref dialog, the new ref text remains highlighted, and typing results in it being overwritten by your next character.  

Expectation:  after I've made a ref, de-select the ref and put the cursor at the end, so I can keep writing or add a second ref.

--------------------------
**Version**: unspecified
**Severity**: enhancement
> Do you think that design decision should be reversed

Yes.  Unless I'm likely to need that thing to be selected when I'm done (e.g., if I'm likely to create a link *and* italicize it – which isn't a likley case), then I want it to be de-selected by default.
(In reply to Mike Christie from comment #4)
> On reflection I agree; "Save and add another" isn't a common case.  I'll see
> if I run into situations where that would be a useful option and will post
> an enhancement request if I do.

Thanks! :-)
On reflection I agree; "Save and add another" isn't a common case.  I'll see if I run into situations where that would be a useful option and will post an enhancement request if I do.
(In reply to Mike Christie from comment #2)
> I wouldn't want to make a blanket statement, and I can recall situations
> where the fact that an object remains selected was useful -- going straight
> back into a cite to fix an error I just realized I made, for example.  For
> some things, such as links, I think it's definitely better to deselect --
> it's absolutely normal for a user to want to continue typing.  For
> templates, I can see an argument for keeping the selection.  Citations seem
> to me more like links than templates in this way.
> 
> I think the design question is: what would a user who is expert in VE want
> the system to do to maximize productivity?  I think the answer is going to
> be to leave it unselected more often than not.

That's a reasonable way of looking at it; I think I agree. There are some possible issues with block images (where, especially if you have a long infobox on a short screen, the content may have been inserted off-screen), but maybe we should optimise for the most common case? Will ask others on the team to weigh in, but broadly this seems sensible. Thanks!


> One other thought: just as there's a "Save" and also a "Save and new" pair
> of buttons in some interfaces, there might be a "Save and add another
> citation" button on the interface, or something along those lines.  But
> perhaps that's a separate enhancement suggestion.

(Yes, this should be a new bug, but…)

Hmm. I think that "Save and also add a new one" is really rare for inserting content, and really confusing. Wouldn't it be better to have easily-rememberable keyboard shortcuts instead?
I wouldn't want to make a blanket statement, and I can recall situations where the fact that an object remains selected was useful -- going straight back into a cite to fix an error I just realized I made, for example.  For some things, such as links, I think it's definitely better to deselect -- it's absolutely normal for a user to want to continue typing.  For templates, I can see an argument for keeping the selection.  Citations seem to me more like links than templates in this way.

I think the design question is: what would a user who is expert in VE want the system to do to maximize productivity?  I think the answer is going to be to leave it unselected more often than not.

One other thought: just as there's a "Save" and also a "Save and new" pair of buttons in some interfaces, there might be a "Save and add another citation" button on the interface, or something along those lines.  But perhaps that's a separate enhancement suggestion.
In VE, new stuff always gets selected after you insert it – images, references, templates, comments, …. Do you think that design decision should be reversed, or do you think that there is something special about references that deserves different treatment?
Steps to reproduce:


1.Open a page with VE which has some text in it
2.Place somewhere outside the CE to disable it
3.Now click at the end of a text to place your cursor on that position of article to make an edit

Observed Result:
The cursor jumps to the beginning of the first line of the article.


Envionment:Betalabs,test2,production

--------------------------
**Version**: unspecified
**Severity**: normal
This may be the opposite of bug 68226:  

The References List dialog in Firefox 31 on my Mac is the expected width, but it is the full height of the screen.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70317
Verified the fix in production
Yeah, part of Roan's fixes.
Can't reproduce using Firefox 32 on Windows 7, nor any other browser. Is this still happening for you? I think it was fixed along with other dialog sizing bugs in OOjs UI recently.
Is this another OOUI breakage?
I was cutting & pasting sentences and it worked nearly flawlessly, including the references! :)

Though, somehow during cut & paste of a reference to the end of a sentence, the period ended up inside the wiki link:

https://en.wikipedia.org/w/index.php?title=Tim_Hortons&diff=624612573&oldid=624559527

--------------------------
**Version**: unspecified
**Severity**: enhancement
Yup, good spot.
I think this has been resolved a while ago by the "active link" functionality. It is still possible to paste things into a link rather than after it, but it should be clear that this is what you're doing.

{F7267037}

{F7267050}
If you're typing at the end of a link and press ' ' (space), '.', or one of a bunch of other characters defined in Unicode as word-separators, we terminate the link before the new character.

It's possible, however, to insert a sequence with a '.' or similar via rich copy-and-paste; I'm not sure if we should strip it here or not. Seems a bit magical…
it's possible there is some user error involved, although see if this can be reproduced...
cmd K (and link button) after a space lost previous italic or/and bold formatting

Mac OS/X Chrome and Safari

--------------------------
**Version**: unspecified
**Severity**: normal
Change 160216 merged by jenkins-bot:
ve.ui.AnnotationInspector: Apply existing annotations to inserted content

https://gerrit.wikimedia.org/r/160216
Change 160216 had a related patch set uploaded by Bartosz Dziewoński:
ve.ui.AnnotationInspector: Apply existing annotations to inserted content

https://gerrit.wikimedia.org/r/160216
> (but inserted language annotations do)

That's because they don't insert any content, unlike link annotations.
Steps to reproduce:

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


Observed Result:
The link inspector is not opening up in the first session

Environment:Betalabs

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

Change 158807 merged by jenkins-bot:
Followup 67f83f1: fall back to empty string to avoid 'undefined'

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

Change 158807 had a related patch set uploaded by Catrope:
Followup 67f83f1: fall back to empty string to avoid 'undefined'

https://gerrit.wikimedia.org/r/158807
It also happens when you try to inspect an existing link
Compare https://www.mediawiki.org/wiki/Talk:VisualEditor/Beta_Features/Language
with https://www.mediawiki.org/wiki/Roadmap/Archive

The Flow page doesn't show the < Talk:VisualEditor | Beta_Features "crumb trail" to parent pages that you normally see under the page title of a subpage in a <div id="contentSub"><span class="subpages">.

I think includes/skins/Skin.php's subPageSubtitle() normally fabricates this.

--------------------------
**Version**: master
**Severity**: normal
Missing template field name

On any page e.g. http://en.wikipedia.beta.wmflabs.org/wiki/0.2619265827018721?veaction=edit

Click Insert/Template


Type a name like "New template" and click "Add template"

In the resulting box, type "New template field" or some such. 

Click the "Unknown field" to add the field to the template

Result should show "New template field" but instead is blank.  Note that a "Remove field" icon is in place for the invisible template field. 

See screen shot comparing beta labs with test2wiki.

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

**Attached**: {F14914}
Verified the fix in production
Yes, working properly in Betalabs and test2
Seems to be working properly in beta labs now
Should be fixed on master.
**gerritadmin** wrote:

Change 158508 merged by jenkins-bot:
Rename $label to $labelElement in MWParameterPage to avoid naming conflict

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

Change 158508 had a related patch set uploaded by Jforrester:
Rename $label to $labelElement in MWParameterPage to avoid naming conflict

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

Change 158503 merged by jenkins-bot:
Rename $label to $labelElement in MWParameterPage to avoid naming conflict

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

Change 158503 had a related patch set uploaded by Alex Monk:
Rename $label to $labelElement in MWParameterPage to avoid naming conflict

https://gerrit.wikimedia.org/r/158503
If you keep it as $label, then add a parameter to a template, then get parameterPage.$label, it appears in place of the outline item widget's label.

Looks like the OOUI element mixin refactor is to blame...
Renaming this.$label to something else (e.g. $labelElement) in modules/ve-mw/ui/pages/ve.ui.MWParameterPage.js fixes this
We should even if it's a minuscule part of the market for tablets, because we're going to eventually support phones (and for decency's sake).

--------------------------
**Version**: unspecified
**Severity**: enhancement
Please do not break the history.
Moved to projects instead.
(In reply to Alex Monk from comment #1)
> Is this a tracking bug?

Yes.
Is this a tracking bug?
Kdammers is running the current version of Mozilla on Windows 7 with a dual-script keyboard.  Typing in Hangul (한글) is not working in VisualEditor:  letters can be removed but when they are typed, they just disappear.


Stefan2 did some related testing:

Ibus-hangul (Korean) seems to work correctly in Firefox 32.0. In Chromium 37.0.2062.94, it produces spaces instead of Hangul letters. However, if a syllable only consists of two letters, the syllable shows up after typing in the second letter. It seems that syllables consisting of more than two letters can't be typed in using Chromium.

Anthy (Japanese) is broken in both browsers.

**See Also**: {T52631}
Follow-up in {T127108}.
>>! In T72353#1864840, @revi wrote:
> Nope., It's still happening, in different form now.

I think that's the same as {T120156} right?
Nope., It's still happening, in different form now.

----
Current status of Korea page
---

(`|` means cursor)
```
가나다라마바사아자차카파타하|
```
After I put two enters,
```
가나다라마바사아자차카파타하

|
```
And now I put the word "치킨".
Expected behavior
---
```
가나다라마바사아자차카파타하

치킨|
```
Actual Behavior
---
```
가나다라마바사아자차카파타하치킨|

// blank lines still there, phabricator doesn't recognize blank lines...
```

OS: Win7, 64bit, MS default IME, UserAgent: `Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0` See also P2386.
Nope., It's still happening, in different form now.

----
Current status of Korea page
---

(`|` means cursor)
```
가나다라마바사아자차카파타하|
```
After I put two enters,
```
가나다라마바사아자차카파타하

|
```
And now I put the word "치킨".
Expected behaviors
---
```
가나다라마바사아자차카파타하

치킨|
```
Actual Behavior
---
```
가나다라마바사아자차카파타하치킨|

// blank lines still there, phabricator doesn't recognize blank lines...
```

OS: Win7, 64bit, MS default IME, UserAgent: `Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0` See also P2386.
Nope., It's still happening, in different form now.

----
Current status of Korea page
---

(`|` means cursor)
```
가나다라마바사아자차카파타하|
```
After I put two enters,
```
가나다라마바사아자차카파타하

|
```
And now I put the word "치킨".
Expected behaviors
---
```
가나다라마바사아자차카파타하

치킨|
```
Actual Behavior
---
```
가나다라마바사아자차카파타하치킨|

// blank lines still there, phabricator doesn't recognize blank lines...
```

OS: Win7, 64bit, MS default IME, UserAgent: `Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0`
OK, @revi, any chance you could re-check http://deployment.wikimedia.beta.wmflabs.org/wiki/Korea?veaction=edit ? If I type 'ganada' into my Korean IME I get 가나다  correctly. However, {T120156} is a horrible bug but I think a distinct blocker from this one. Provisionally re-closing.
Change 247800 merged by jenkins-bot:
Diff richtext to build model changes

[[https://gerrit.wikimedia.org/r/247800]]
I have optimistically tagged this bug in change 247800, because it will fix many DOM/DM synchronization errors, and I suspect that is the underlying cause of the symptoms @revi reports above.
Change 247800 had a related patch set uploaded (by Divec):
Diff richtext to build model changes

[[https://gerrit.wikimedia.org/r/247800]]
Typed ##가나다## in the page.

It makes newline (I thought like I typed enter.) and then 가나다. When I clicked the first line, it just don't let me write there and wrote my 가  at the newline.

So, more graphically.

what I did:
My browser is in this stage;
```
|(cursor)
```
type ##가나다## now.

what I expected:
```
가나다|(cursor)
```
what I get:
```
(empty line)
가나다|(cursor)
```
At this stage, further "enter" command does not work, and I am stuck in that particular line.

If I try to put the words on empty line...

```
|
가나다
```
then it becomes...
```
(empty)
가|가나다
```

Really weird, isn't it?

OS: Win 7, Browser: FireFox 41.0.
Hello, does it now work correctly on http://deployment.wikimedia.beta.wmflabs.org/wiki/Korea?veaction=edit ? It works for me there with IE/Windows 8 .

@Revi, Thanks for the updated log for Firefox!
Hello, does it now work correctly on http://deployment.wikimedia.beta.wmflabs.org/wiki/Korea?veaction=edit ? It works for me there with IE/Windows 8 .
OK, @dchan I updated the P2090 and P2091 to FF info.

Also, @Jdforrester-WMF I still can reproduce this.
I haven't got any time to sit in front of the desk, run FF, verify whether
this is fixed (in this case I will close the bug as I did on T52631) or not
(in this case I will provide additional debug information as requested by
@dchan.) Since dchan cannot reproduce the bug, it seems that I am the SPoF.

It's national holiday in Korea and I'm currently at a house without any
computer. So, please wait until I can touch computers ;)
Is this now resolved?
>>! In T72353#1675748, @dchan wrote:
> Thanks for the event log!
> 
> That's on Chrome 45 right? Are you seeing the issue in Chrome too? It seems to work correctly for me in Chrome on Windows 8, and I get an essentially identical event log, so I'm confident our IMEs are essentially the same :-)
> 
>  Could you also provide a log created on Firefox? Thanks!

Oh well, my bad. I was proven stupid. New log will be uploaded later tomorrow or Monday. (since it's [[ https://en.wikipedia.org/wiki/Chuseok | Chuseok ]] )
Change 241124 merged by jenkins-bot:
Ignore slugs and chimeras when preventing identical re-renderings

[[https://gerrit.wikimedia.org/r/241124]]
Change 241124 had a related patch set uploaded (by Divec):
Ignore slugs and chimeras when preventing identical re-renderings

[[https://gerrit.wikimedia.org/r/241124]]
I can reproduce similar symptoms on IE on Windows 8. It can be reproduced by pressing Enter then 'ㄱ', which triggers the issue in T91244 . Perhaps the Firefox on Windows 7 issue is essentially the same; if you provide a log I will confirm.
Thanks for the event log!

That's on Chrome 45 right? Are you seeing the issue in Chrome too? It seems to work correctly for me in Chrome on Windows 8, and I get an essentially identical event log, so I'm confident our IMEs are essentially the same :-)

 Could you also provide a log created on Firefox? Thanks!
Here you are. P2090 for English and P2091 for Korean.

{P2090}
{P2091}
Hi, unfortunately I can't reproduce the problem. (I guess it may depend on the IME version, which is very common). So to help us debug this, could you help us by sending the event log when you type '가나다' on your platform?

1. Go to https://rawgit.com/wikimedia/VisualEditor/master/demos/ve/eventLogger.html
2. Click 'Start Logging Keyboard Events'
3. Type the text (i.e. just press 'rkskek' - don't press any other key)
4. Click on the big box full of debug info
5. Copy the text with the mouse
6. Paste into a file and attach the file to this bug

Thanks very much!
Hi, unfortunately I can't reproduce the problem. So to help us debug this, could you help us by sending the event log when you type '가나다' on your platform?

1. Go to https://rawgit.com/wikimedia/VisualEditor/master/demos/ve/eventLogger.html
2. Click 'Start Logging Keyboard Events'
3. Type the text (i.e. just press 'rkskek' - don't press any other key)
4. Click on the big box full of debug info
5. Copy the text with the mouse
6. Paste into a file and attach the file to this bug

Thanks very much!
I can reproduce this. Win 7, 64bit, (I don't know what IME I'm using but default IME for Korean in Windows). Firefox Version 41.0.

== Step to reproduce==

1. Go to [[https://ko.wikipedia.org/wiki/%EC%82%AC%EC%9A%A9%EC%9E%90:Gisado/VEtest?veaction=edit|https://ko.wikipedia.org/wiki/%EC%82%AC%EC%9A%A9%EC%9E%90:Gisado/VEtest?veaction=edit]]
2. Type enter twice.
3. Try to type ##가나다##

== Expected result ==
 ##가나다## shows up below ##가나다라마바사아자차카파타하##., like this.
{P2083}

==Result bug==
Two enters magically removed, and two ##ㅏ##s are put after ##가나다라마바사아자차카파타하##, like:
{P2084}
Hi, typing phonetically with Nalgaeset keyboard seems to work for me on Windows 8, Firefox 40.0.3 (and also Chrome 45.0.2454.99 m), both on en.wikipedia.org and on VE-standalone master.

Can we close this, or is anyone still seeing corruption?
When I tried to do test for bug 50631 on [[en:User:Hym411/VETest]] (second line), I got this bug. bug 50631 at least returns some result - though it's full of errors - but this gives some nonsense.

Test envorinment: Win7, Google Chrome version 37.0.2062.120 m
Are we sure?  Bug 50631 can get something.  I believe that this user can't get anything.
Exactly same problem of bug 50631. This should be merge into 50631.
What is "the current version of Mozilla"? Firefox? Seamonkey?
This is probably a dupe of bug 50631, but leaving it open.
Screenshot of bug.

The anoneditwarning message now takes parameters apparently. ApiVisualEditor.php.

See mediawiki-core's EditPage.php for example.

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

**Attached**: {F14741}
Fixed in gerrit Ia28f59a34.
**Author:** `gryllida`

**Description:**
[[MediaWiki:Noarticletext]] is shown when someone is creating a page, above the edit box. See:

https://en.wikiversity.org/w/index.php?title=MediaWiki:Noarticletext
https://en.wikiversity.org/w/index.php?title=Lalala&action=edit

VisualEditor should respect this and also show such text in some prominent place.

--------------------------
**Version**: unspecified
**Severity**: normal
Indeed.
https://en.wikiversity.org/w/index.php?title=Lalala&action=edit&uselang=qqx is showing 'newarticletext' (not 'noarticletext'), which VE already does...

'noarticletext' is shown on action=view.
**Author:** `josephsieh`

**Description:**
screen shot of "Switch to source editing" dialog too tall issue on Safari.

After user modified something in Visual Editor and then tries to click on "Edit" without clicking "Save page", the "Switch to source editing?" dialog appears to be too tall as the attached screenshot shows.

It happens on 

OSX 10.9.4
Safari 7.0.6.

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

**Attached**: {F14706}
Verified the fix in production
Yeah, checked on a Mac.
This might be the same issue as bug 70545 and looks similarly fixed to be, but I don't have a Mac to test on.
This can be seen by placing the cursor right at the beginning of any existing wikilinked word, then trying to add any kind of link. 
User's expectation is that this changes the wikilink target with no corruption.

<<To reproduce this:
* [https://fr.wikipedia.org/w/index.php?title=Boys_band&veaction=edit Edit Boys band on frwiki]
* In the history chapter, 4th paragraph, put the cursor before the S of the link to Super Junior
* Click on link icon in the toolbar
* Copy the URL <code><nowiki>https://fr.wikipedia.org/wiki/B.A.P</nowiki></code> in the link inspector and click Terminé
* When previewing modifications, you can see that it has been replaced by <code><nowiki>[[B.A.P]] [[Super Junior|<nowiki/>]][[B.A.P|Super]] Junior</nowiki></code> which shows several problems: there's a link without text displayed, the existing link has been cut in two
* And also, what is displayed in VE doesn't match at all what the result will be when saved:
** "Super" is displayed as an external link, but in the modifications preview, you see it's an internal link
** If you hover over "Super", both "Super" and "Junior" get underlined, but in the modifications preview, "Junior" is not inside the link
** "Junior" is displayed as an internal link, but in the modifications preview, you see it's now just text
** If you hover over "Junior", both "Super" and "Junior" get underlined, but in the modifications preview, "Junior" is not inside a link .>> Instructions by NicoV.

--------------------------
**Version**: unspecified
**Severity**: normal
Resolved with this: https://gerrit.wikimedia.org/r/#/c/197425
The root cause here is very odd; I've opened {T86399} to work this out.
The qqq documentation for the message Visualeditor-dialog-action-done is either misleading or I misunderstand it :)

It says: "Label text for button to exit from a dialog that has no changes to make."

However, this message is used in the link inspector - this is not quite a dialog, and it does make changes.

I can think of three options:
* I misunderstand something :)
* This message shouldn't be used in the link inspector
* This message's documentation should be changed

--------------------------
**Version**: unspecified
**Severity**: normal
Change 184642 merged by jenkins-bot:
Create separate message for find-and-replace-done

[[https://gerrit.wikimedia.org/r/184642]]
I think this is just a copy and paste error from visualeditor-dialog-action-cancel
Change 184642 had a related patch set uploaded (by Esanders):
Create separate message for find-and-replace-done

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

#patch-for-review
After reading @Jdforrester-WMF's reasoning on T85852 I am even more convinced that this is a problem.

UI consistency is a good idea, but enforcing too much of it is not. In particular, reusing the same message in several different dialogs is a bad idea. See
https://www.mediawiki.org/wiki/Localisation#Avoid_message_reuse

"Done" is used now in several contexts that may seem similar to developers, but are not actually the same. In Russian and Hebrew it's definitely wrong to apply the same message too all these different dialogs. As the localisation guide says, this may seem counter-intuitive, but it is also based on a lot of experience.
... This caused T85852.

"Done" just doesn't sound like a button in a dialog that has no changes to make.
Just discovered this tool, and since it makes it so much easier to add TemplateData, it would be a huge improvement for us template editors, and consequently for the VisualEditor users out there. Can't see any reason it should be controversial, but if requested I'll bring it up in our village pump.

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement
Merged and deployed!
**gerritadmin** wrote:

Change 157476 merged by jenkins-bot:
Enable TemplateData GUI on Norwegian Bokmål (nowiki)

https://gerrit.wikimedia.org/r/157476
Start to involve the projects in the decision process, or at least don't try to override existing processes. This request does _NOT_ follow due process and will interfere with the project own decision.

Why does it seem like I always repeat myself.. ;/
(In reply to jeblad from comment #5)
> There is no consensus at WP:Tinget, and that would usually take at least a
> week. There is a notice about this at WP:Torget, but this page is not used
> for project wide decisions at nowiki.

This isn't really seeking a "decision", in the same way that most of the hundreds of improvements which are rolled out every week.

> Before final consensus is reached all system messages should be translated

Your input on https://translatewiki.net/w/i.php?title=Special:Translate&action=proofread&group=ext-templatedata&language=nb&filter=translated%7C%21reviewer%3A8576%7C%21last-translator%3A8576 is of course welcome in ensuring that. :-)

> and necessary help pages created.

Obviously you're not suggesting that WMF should interfere with a project and re-write their help pages here, I assume. :-)
There is no consensus at WP:Tinget, and that would usually take at least a week. There is a notice about this at WP:Torget, but this page is not used for project wide decisions at nowiki.

Before final consensus is reached all system messages should be translated and necessary help pages created. Only then should this be scheduled.

In short, this request is invalid.
Currently scheduled for 15:00 UTC on Tuesday 2 September; we can postpone it if there are an issues.
**gerritadmin** wrote:

Change 157476 had a related patch set uploaded by Jforrester:
Enable TemplateData GUI on Norwegian Bokmål (nowiki)

https://gerrit.wikimedia.org/r/157476
To be on the safe side I posted in our village pump asking if there are any objections:

https://no.wikipedia.org/wiki/Wikipedia:Torget#.C2.ABManage_TemplateData.C2.BB
Sure, no problem.
There is a noticeable lag observed while trying to add any citation in mobile in Beta labs environment.
Tested and performance is more than adequate on my iPhone.
*Sorry about the lame summary*

This bug can probably have a better title.

A rather simple and innocent edit in the Hebrew Wikipedia introduced an element that had no reason to appear in the code. Here's the edit:
https://he.wikipedia.org/w/index.php?title=%D7%9B%D7%99%D7%91%D7%95%D7%A9%D7%99_%D7%90%D7%9C%D7%9B%D7%A1%D7%A0%D7%93%D7%A8_%D7%94%D7%92%D7%93%D7%95%D7%9C_%D7%91%D7%90%D7%A1%D7%99%D7%94_%D7%94%D7%AA%D7%99%D7%9B%D7%95%D7%A0%D7%94&diff=15812721&oldid=15812716

The problematic element appears between the words "מטרות נוספות היו" and the colon.

The element was removed in the following edit:
https://he.wikipedia.org/w/index.php?title=%D7%9B%D7%99%D7%91%D7%95%D7%A9%D7%99_%D7%90%D7%9C%D7%9B%D7%A1%D7%A0%D7%93%D7%A8_%D7%94%D7%92%D7%93%D7%95%D7%9C_%D7%91%D7%90%D7%A1%D7%99%D7%94_%D7%94%D7%AA%D7%99%D7%9B%D7%95%D7%A0%D7%94&diff=15887470&oldid=15878013

When editing it in the VisualEditor, the element appears as "Sorry, this element can only be edited in source mode for now."

When I showed this to David, he thought that it may be somewhat related to the "unicorn" patch, but it is not certain.

--------------------------
**Version**: unspecified
**Severity**: normal
Confirmed in betalabs - for en wiki too.
- Insert a colon into a paragraph text and - Important!- put white spaces around it

The colon (:) will be transformed into 
```<span typeof="mw:Placeholder" data-parsoid="{&quot;src&quot;:&quot; &quot;,&quot;isDisplayHack&quot;:true,&quot;dsr&quot;:[83,84,null,0]}" class="ve-ce-leafNode ve-ce-focusableNode" contenteditable="false">&nbsp;</span> ```

with

```<div class="ve-ce-focusableNode-highlight ve-ce-alienNode-highlight" title="Sorry, this element can only be edited in source mode for now." draggable="false" style="top: 11px; left: 391px; width: 5px; height: 15px;"><img class="ve-ce-focusableNode-highlight-relocatable-marker" src="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw=="></div>```
Verified with Chrome and Safari.
If you type wikitext ( I tried with * ) and then delete it, the wikitext warning won't go away automatically.
If you click on it to make it disappear, proceed to add more wikitext and delete this again, then the box will auto-hide correctly.

(Two square parentheses don't seem to trigger the warning at all?)

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

Change 157278 merged by jenkins-bot:
Make sure mediawiki.notification is loaded -before- calling ViewPageTarget#checkForWikitextWarning

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

Change 157278 had a related patch set uploaded by Alex Monk:
Make sure mediawiki.notification is loaded -before- calling ViewPageTarget#checkForWikitextWarning

https://gerrit.wikimedia.org/r/157278
Taking this bug
1. Type some text which is an invalid title in MW, e.g. "|InvalidTitle"
2. Select it and hit link
-  Notice that there are no suggestions, and no initial link is applied
3. Type in a valid page name, e.g. "Main page" and press Done
-  Notice some of your text has been deleted (by and undo operation) before the link was applied

The bug is actually in core AnnotationInspector#getTeardownProcess. We call a surface undo() to remove the initial annotation, but in the case of an invalid title there is no initial annotation.

--------------------------
**Version**: unspecified
**Severity**: normal
**gerritadmin** wrote:

Change 157053 merged by jenkins-bot:
Only undo if an initial annotation was applied

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

Change 157053 had a related patch set uploaded by Esanders:
Only undo if an initial annotation was applied

https://gerrit.wikimedia.org/r/157053
--------------------------
**Version**: wmf-deployment
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70744
This build now exists at https://integration.wikimedia.org/ci/job/browsertests-VisualEditor-en.wikipedia.beta.wmflabs.org-windows_8.1-internet_explorer-11-sauce/

Notice the rather nifty failure due to javascript error.
**gerritadmin** wrote:

Change 157164 abandoned by Zfilipin:
WIP Trying to create IE11 Jenkins job for VisualEditor

Reason:
moved to https://gerrit.wikimedia.org/r/#/c/160008/

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

Change 157480 merged by jenkins-bot:
browsertests: Enable VE on IE and Safari; remove Chrome on Windows XP

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

Change 157164 had a related patch set uploaded by Zfilipin:
WIP Trying to create IE11 Jenkins job for VisualEditor

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

Change 156448 abandoned by Jforrester:
browsertests: Enable VE on IE11 and Safari; remove Chrome on Windows XP

Reason:
Moved to master branch.

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

Change 157480 had a related patch set uploaded by Jforrester:
browsertests: Enable VE on IE11 and Safari; remove Chrome on Windows XP

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

Change 156448 had a related patch set uploaded by Jforrester:
browsertests: Enable VE on IE11 and Safari; remove Chrome on Windows XP

https://gerrit.wikimedia.org/r/156448
Education Programme:
> On page
> https://pt.wikipedia.org/wiki/User:Alpha_Centaurus?veaction=edit&oldid=39924153&uselang=en
> the link to
> https://pt.wikipedia.org/wiki/Ensino:Universidade_Federal_do_Rio_Grande_do_Sul/C%C3%A1lculo_Num%C3%A9rico_%28MAT01169%29_%282014-2%29
> is red, but it should be blue because (from the user's point of view) the page exists.

GlobalUserPages:
> Viewing https://www.mediawiki.org/wiki/Extension:TemplateData shows a blue link for "James Forrester". However, when editing with VisualEditor, the link is red.


----
See also: {T134073}
Change 315432 merged by jenkins-bot:
mw.LinkCache: Links aren't missing if they're known

[[https://gerrit.wikimedia.org/r/315432]]
Change 315455 merged by jenkins-bot:
TitleWidget: Take 'known' status into account when deciding page existence

[[https://gerrit.wikimedia.org/r/315455]]
Change 315455 had a related patch set uploaded (by Alex Monk):
TitleWidget: Take 'known' status into account when deciding page existence

[[https://gerrit.wikimedia.org/r/315455]]
Change 315432 had a related patch set uploaded (by Jforrester):
mw.LinkCache: Links aren't missing if they're known

[[https://gerrit.wikimedia.org/r/315432]]
I filed a blocker bug to expose Title::isKnown() via the API, so VE can use it.

Once that is in place, someone will need to update `ve.init.mw.LinkCache` to use it.
Extension:WikimediaIncubator also uses this hook so "Valid Wx/xyz info pages should be considered as existing pages". SemanticMediaWiki also uses it for something.

There are other issues due to Title::isAlwaysKnown that aren't just the TitleIsAlwaysKnown hook - existence of files vs. file pages, and existence of system messages.
Unfortunately, that page doesn't actually exist. EducationProgram just pretends it does via the hook I mentioned in T72504#942697.
Steps to reproduce:

1.Open a page with mobile VE
2.Tap somewhere in the middle of the page or towards the end

Observed Result:
The page focus bumps up to the top of the page, not getting scrolled down to the point where the cursor is actually positioned.

--------------------------
**Version**: unspecified
**Severity**: normal
Seems to work for me now. Tested on Beta Cluster using iOS Safari 8.0 on an iPad.
**jgonera** wrote:

Maryana said that she doesn't consider that very high priority so I might not get to it before I leave. Unassigning myself.
**jgonera** wrote:

Correction: the page doesn't scroll up. It should scroll up when the keyboard opens and covers up the cursor. Instead, the page stays in place.

This is because we no longer scroll the whole page on iOS (we scroll inside of a div) and Safari's default mechanism for preventing the cursor from being covered by the keyboard doesn't work anymore (that's my guess).

I think an easy solution would be to implement scrolling the CE on focus in such a way that the cursor ends up being close to the top of the screen. This way the keyboard won't occult it. We have to keep in mind though that this code should only run on iOS (which is easy because we already let MobileViewTarget know that we're on iOS using isIos config argument).
The page scrolls up, the cursor is correctly positioned with the fix of https://bugzilla.wikimedia.org/show_bug.cgi?id=66697
**jgonera** wrote:

"The page focus bumps up to the top of the page" - you mean the page is scrolled to the top or the cursor moves to the top?
Screenshot

Steps to reproduce:

1.Open a page with VE
2.Go to Insert>Template
3.Click on "Show Options"
4.Add the template "Cite Web"
5.Select one of those required parameter from the left panel of the dialog
6.Add some more template with some optional parameters and content in the transclusion dialog
7.Now select one of the required parameter for the "Cite Web" template from the left panel
8.Now from left panel,select any other template/optional parameter/content or even the "Cite web" template 

Observe that the trash icon that used to appear at the corner of the left panel for other template/optional parameter/content or "Cite web" template are not appearing now.


See the screenshots attached

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

**Attached**: {F14309}
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 156671 merged by jenkins-bot:
Toggle trash button (on transclusion dialog) visibility when changing to non-parameter pages

https://gerrit.wikimedia.org/r/156671
Change 156671 had a related patch set uploaded by Alex Monk:
Toggle trash button (on transclusion dialog) visibility when changing to non-parameter pages

https://gerrit.wikimedia.org/r/156671
Created attachment 16297
The missing trash icon

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

1.  Open page containing the {{good article}} (or similar) template in VisualEditor, such as https://en.wikipedia.org/w/index.php?oldid=622810787 (which contains only that template)

2.  Click the good article icon/template

3.  VisualEditor exits, and you are reading the Wikipedia:Good article page (the same one that you would be reading if you clicked that icon in 'read' mode).


Expected behavior:

1.  Open page containing {{good article}} in VisualEditor

2.  Click the good article icon/template

3.  Edit the template just like any other.


It's possible that this can only be reproduced on Windows, because on my Mac, when I open the page, the template isn't even visible.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 161957 merged by jenkins-bot:
Prevent page elements from displaying on top of highlights

https://gerrit.wikimedia.org/r/161957
Ed, that's bug 23796, with the related bug 51420 in VE.
Change 161957 had a related patch set uploaded by Bartosz Dziewoński:
Prevent page elements from displaying on top of highlights

https://gerrit.wikimedia.org/r/161957
Setting topicons with CSS like this is a horrible hack. Imagine if we did the same with category links!

We should create a simple extension to add topicons to a page, so that they are rendered in the correct place in the HTML (i.e. not the article body). Parsoid can then provide them to VE as metadata and we can handle them accordingly.

I've discussed this with Trevor and Roan and we think it's a fairly simple project to take on.
While this could possibly be fixed on-wiki for this particular case, we should prevent people from accidentally or intentionally breaking this in VE, too.
Caused by "z-index: 10;" in [[w:en:MediaWiki:Monobook.css]].
It was reported on Firefox 31 on Windows 7, using Monobook.

There's a screenshot at https://commons.wikimedia.org/wiki/File:VE_with_GA_icon.png
Which browsers are you using ?
Take this query from the suggester:

https://en.wikipedia.org/w/api.php?format=jsonfm&uselang=en&action=query&list=allcategories&acprefix=1895+es&acprop=hidden&redirects=

Now read [[mw:Manual:Category table]]:
"Track all existing categories. Something is a category if it has an entry somewhere in categorylinks, or it once did."

So it's logical that something like 1895 establisANONYMOUS IS LEGIONhments is in the suggestion list, but it is really not desirable. It contains many 'bad' words and deleted stuff that we don't really want to present to users.


https://en.wikipedia.org/w/api.php?format=jsonfm&uselang=en&action=query&list=allcategories&acprefix=1895+es&acprop=hidden&redirects=&acprop=size|hidden

This can be easily solved by adding:
acmin=1 to the query.

--------------------------
**Version**: unspecified
**Severity**: minor
*** Bug 69927 has been marked as a duplicate of this bug. ***
Actually, i forgot, HotCat now actually runs 2 queries on both of these tables, and then combines them into a result..


Perhaps we should fix the api ? :)
Change 156250 merged by jenkins-bot:
Categories: Don't suggest empty or old categories

https://gerrit.wikimedia.org/r/156250
Alternative is to use the HotCat methodology:

Here only categories that have their own page are considered to exist:
https://en.wikipedia.org/w/api.php?format=json&action=query&list=allpages&apnamespace=14&aplimit=30&apfrom=1895%20es&apprefix=1895%20es
Change 156250 had a related patch set uploaded by TheDJ:
Categories: Don't suggest empty or old categories

https://gerrit.wikimedia.org/r/156250
Reference dialog in test2

The size of the Reference dialog got changed to a bigger size after wmf18

See the screenshots attached

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

**Attached**: {F14691}
*** Bug 70601 has been marked as a duplicate of this bug. ***
Verified the fix in production
Verified the fix in test2
**gerritadmin** wrote:

Change 161165 merged by jenkins-bot:
Fix automatic sizing of windows

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

Change 161165 had a related patch set uploaded by Catrope:
Fix automatic sizing of windows

https://gerrit.wikimedia.org/r/161165
Many other dialogs have this problem too, including referenceList. It looks like getBodyHeight() is returning a value that's way too high.
Created attachment 16279
Reference dialog in production

**Attached**: {F14692}
--------------------------
**Version**: unspecified
**Severity**: minor
Verified the fix in Production
So the first patch set I made (to deal with existing links when you clear the target page) should be deployed to all Wikimedia wikis. But the second one (per Rummana's comment 4) was merged a day later which just happened to put it on the next deployment version (so it should be another week).
I just tested this on MediaWiki.org and it seems to have been fixed. . .
Again in production, the "open" button remains enabled when I open a link inspector in a blank line without selecting a text.I will wait for a while to see whether it gets started working automatically like it did in Betalabs.Reopening it for now.
Yeah, just started working for me! Marking as Resolved .
Works for me. Gerrit change 157212 should've sent my fix to beta labs.
Created attachment 16315
Screenshot

hmm..but I still see that button as active :/

**Attached**: {F14688}
I uploaded Gerrit change 157017 to resolve that issue, and Roan just merged it. I forgot to link it to this bug, sorry!
The "Open" button is now getting disabled when you clear the link target name , but if you just open the link inspector in any empty line and there is no link target name specified yet , the "Open" button still remains enabled
**gerritadmin** wrote:

Change 156582 merged by jenkins-bot:
Link target input widget: Make '' an invalid link target

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

Change 156582 had a related patch set uploaded by Alex Monk:
Link target input widget: Make '' an invalid link target

https://gerrit.wikimedia.org/r/156582
Right now, when you open link inspector and keep the link target field empty, you will still be able to click on "Open" button as it remains active, though it serves no purpose.We should disable it in this case
Steps to reproduce:

1.Open a page with VE
2.Add some categories to the page
3.Save the page
4.Reopen the page and go to the categories section

Observed Result:
The categories are not appearing immediately,after waiting for approx. 6-7 secs they do appear in that section.

--------------------------
**Version**: unspecified
**Severity**: normal
This was happening because of HHVM issue. Now it is working fine.
This may be related to bug 51289 and bug 61777.


Steps to reproduce:

1.  Open a page that contains refs formatted like this:  {{#tag:ref|Text goes here. |group=n |name=Foo}}

2.  Add a references list for the group.

3.  Read the error message.  VisualEditor says that there are no refs in group 'n' on the page.


Expectation:

Refs would be properly recognized and displayed even if they use this rather odd format.

--------------------------
**Version**: unspecified
**Severity**: normal
Trying to edit the article [[Sindhi language]] in VE while the language tool is enabled produces gets the browser stuck with the animated loading bar and produces a JavaScript error in the console:
Uncaught TypeError: Cannot read property 'toLowerCase' of null ve.ce.LanguageAnnotation.js:52

(This is from Chrome; the error in Firefox is slightly different, but it's broken there as well.)

If the language tool beta feature is disabled, then the article can be edited.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 156143 merged by jenkins-bot:
Fix JS error in ce.LanguageAnnotation when dir is set but lang isn't

https://gerrit.wikimedia.org/r/156143
Change 156143 had a related patch set uploaded by Catrope:
Fix JS error in ce.LanguageAnnotation when dir is set but lang isn't

https://gerrit.wikimedia.org/r/156143
Sometimes you want a single quotation mark next to an italicized (or bolded) word. 
It would be nice if VisualEditor/Parsoid did something elegant with the wikitext, like "celui d'<nowiki/>''Homo sapiens''" instead of wrapping half a sentence inside nowiki tags to deal with a single character.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 193842 merged by jenkins-bot:
T71950: Output <nowiki> closer to quotes

[[https://gerrit.wikimedia.org/r/193842]]
> [[https://gerrit.wikimedia.org/r/193842]]

This is a WIP that should fix the https://fr.wikipedia.org/w/index.php?title=Grand_Line&curid=4571652&diff=111992974&oldid=111360543 case, but I want to make sure it doesn't break anything else.
Change 193842 had a related patch set uploaded (by Marcoil):
WIP: T71950: Output <nowiki> closer to actual reason

[[https://gerrit.wikimedia.org/r/193842]]
nowiki addition for quotes has improved since this ticket was created. We should investigate what needs fixing here. But, one recent diff that could be investigated (as reported by @NicoV) is https://fr.wikipedia.org/w/index.php?title=Grand_Line&curid=4571652&diff=111992974&oldid=111360543
See https://fr.wikipedia.org/w/index.php?title=La_Horde_sauvage_(film,_1969)&curid=88578&diff=106771550&oldid=106771188

https://fr.wikipedia.org/w/index.php?title=Archelon&curid=1273494&diff=106770342&oldid=105728402

If in a long string, only a single small piece of it needs nowiki-ing, that single string can be wrapped. In general, this requires knowing that nothing else in the long string needs a nowiki wrapper, but heuristics could work for common scenarios. This seems to be a problem that affects frwiki especially.
This might be related to Bug 49524.

See https://commons.wikimedia.org/wiki/File:VE_selection_box_goes_over_menus.png

When you open https://en.wikipedia.org/w/index.php?oldid=620028233 in Firefox on Windows 7, the sandbox template is autoselected.  If you click on a menu (e.g., to set bold text), the menu drops down but the items that overlap with the auto-selected template can't be chosen.

I am unable to reproduce this in either Safari or Firefox on a Mac.

--------------------------
**Version**: unspecified
**Severity**: normal
Change 156723 merged by jenkins-bot:
Fix various bugs in our Monobook stylesheet

https://gerrit.wikimedia.org/r/156723
Change 156723 had a related patch set uploaded by Catrope:
Fix various bugs in our Monobook stylesheet

https://gerrit.wikimedia.org/r/156723
I couldn't reproduce this bug, and realized it was specific to Monobook. There are other minor display issues with the toolbar in Monobook as well (like its height).
This appears to only happen if you are at the top of the page.  If you scroll down at all, then it works correctly.
This is needed to allow VisualEditor to support such lovely wikitext as {{echo|{{echo|Foo!}}}} and more complex variations.

--------------------------
**Version**: unspecified
**Severity**: enhancement
A different approach that we have considered over the last few months is to generate these HTML representation of tpl params on demand rather than for Parsoid to generate this all the time and then store it.

So, whenever a template is opened up for editing in VE, VE would request Parsoid for HTML representation of these parameters, and then use that to enabled HTML editing of these params. If  this is considered a workable approach, we can work out the details and this can see the light of day much faster.
(In reply to Marc Ordinas i Llopis from comment #1)
> With this enabled, it's possible to make Parsoid accept new transclusion
> parameters from HTML by removing the wt ones. We are also planning on adding
> support for detecting changes in parameters (so that the wikitext ones don't
> have to be removed) in the future.

That sounds great.

> I'll be working on improving performance shortly.

Excellent. :-)
The current status for DOM transclusion parameters is: The code is there, but it is disabled by default as it affects performance. For example, it increases the rendering of [[Barack_Obama]] by more than 3s.

To enable it (in case someone wants to try it out), add
parsoidConfig.addHTMLTemplateParameters = true;
to localsettings.js.

With this enabled, it's possible to make Parsoid accept new transclusion parameters from HTML by removing the wt ones. We are also planning on adding support for detecting changes in parameters (so that the wikitext ones don't have to be removed) in the future.

I'll be working on improving performance shortly.
Save button not working after creating citation

After fixing https://bugzilla.wikimedia.org/show_bug.cgi?id=69856

Do everything to create a Citation as shown in the screen shot. 

Click Save. Save does nothing.

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

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

Change 155601 merged by jenkins-bot:
Followup 67f304a: use .openWindow(), not .open(), to open save dialog

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

Change 155601 had a related patch set uploaded by Jforrester:
Followup 67f304a: use .openWindow(), not .open(), to open save dialog

https://gerrit.wikimedia.org/r/155601
This happens while trying to save a page after adding anything in the page, not just citations.The error that appears in the console is:
Uncaught TypeError: Cannot read property 'openWindow' of null
Screenshot

VisualEditor shows double page title after edit when the 'edittop' gaget (or similar) is enabled.

This is because the code to update page's DISPLAYTITLE is too aggressive.

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

**Attached**: {F14331}
Change 155577 merged by jenkins-bot:
mw.ViewPageTarget: Be more careful when updating page title

https://gerrit.wikimedia.org/r/155577
Change 155577 had a related patch set uploaded by Bartosz Dziewoński:
mw.ViewPageTarget: Be more careful when updating page title

https://gerrit.wikimedia.org/r/155577
The firsteditve tour (the "first edit" tour, specialised for VE) relied on the ve-ui-toolbar-saveButton class to attach a guider to the "Save page" toolbar button. The class was removed as part of https://git.wikimedia.org/commit/mediawiki%2Fextensions%2FVisualEditor.git/cc089d6bd3334791453c6474c56f49d4a2d243dd.

At the moment, there's no resilient selector that we can use to reference just that element. Can the class be reinstated?

--------------------------
**Version**: unspecified
**Severity**: minor
**gerritadmin** wrote:

Change 155280 merged by jenkins-bot:
Reinstate the ve-ui-toolbar-saveButton class

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

Change 155280 had a related patch set uploaded by Phuedx:
Reinstate the ve-ui-toolbar-saveButton class

https://gerrit.wikimedia.org/r/155280
This is somewhat related to {T64917}.

When you add an internal link, or otherwise are looking at search results, VisualEditor should defaultly select any page that is an exact match for what you've typed.  In particular, if you search for "Computer", and there actually is a page at [[Computer]], then it should default to [[Computer]], not to [[Computer science]] or whatever else comes up first in the search system.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T71780}
{T57390}
{T64917}
{T71716}
Current situation:

* If you type "fool" and press return or click "Insert" you get a link to "fool", even if it doesn't appear in the suggestions list.
* If you type "fool" and there are no title matches, you'll get what you've typed in as a redlink suggestion.
* If you type "fool" and the only title match result is "Fool's gold" as a redirect to "Pyrite", you'll get the latter shown first with the former directly below it. You won't get a redlink suggestion.
* If you type "fool" and there are several title match results, the "best" match from the search engine will show first even if that isn't the closest match.

I think this is "good enough", and much better than when this task was filed.
This is aggravated if the exact match is a redirect, because matching redirects are in a separate section of the suggester, and the auto select only considers the first match in the 'articles' section of the suggester.


When trying to link to the en.wp redirect "Republic of Vietnam" by typing this directly into the link dialog, the article "Republic of Vietnam Airborne Division" is selected. Ideally, as I type, I would expect that the exact redirect match of "Republic of Vietnam is chosen and that after done, I get: [[Republic_of_Vietnam_Airborne_Division|Republic of Vietnam]].
I get "TypeError: undefined is not a function" when saving after pasting an external link into a basic citation. This is rather insidious, as the error only happens when trying to save the page, which causes you to lose some work. (The same error happens when trying to switch to wikitext.)

1. https://en.wikipedia.org/wiki/Combining_Grapheme_Joiner?veaction=edit
2. Click the "[1]" link in the first paragraph, "Add label" from inspector
3. Ctrl+X to cut the link (which should have been automatically selected)
4. Click "Cite" → "Basic" to insert citation at the same spot
5. Ctrl+V to paste the link, "Insert reference"
6. Click "Save page", receive error

I'm not sure if step 2 is relevant, but I can consistently reproduce like this.

--------------------------
**Version**: unspecified
**Severity**: major
Indeed, works for me too now.
I just followed these steps exactly (I opened the save dialog and viewed the diff, but did not actually change the content) and it worked fine. FIXED, or am I missing something?
(In reply to marielle.volz from comment #1)
> I ca
Whoops. Premature enter there.

I can confirm, but in my case upon inserting the reference, I can no longer open any dialogs, including the citation dialog, nor the save dialog (i.e. when I hit save, nothing happens.)
I ca
Let's stop using inline <img> for thumbnail magnify icon. According to bug 69277 comment 11, there are 87619775 requests per day for 'magnify-clip.png'. It should be embedded in some piece of CSS.

(Bug 65160 / [[mw:Thumbnail style update]] call for complete removal of the icon, but it would only affect the Vector skin.)

--------------------------
**Version**: 1.24rc
**Severity**: normal
Change 161625 merged by jenkins-bot:
Remove WMF deployment hack for 'Enlarge' image

https://gerrit.wikimedia.org/r/161625
Change 154831 merged by jenkins-bot:
Remove WMF deployment hack for 'Enlarge' image

https://gerrit.wikimedia.org/r/154831
Change 161625 had a related patch set uploaded by Jforrester:
Remove WMF deployment hack for 'Enlarge' image

https://gerrit.wikimedia.org/r/161625
Deeming this merged now, as this is 'fixed' even without the clean-up from gerrit 154831 landing.
Change 154830 merged by jenkins-bot:
Generate 'Enlarge' image in CSS rather than HTML (Linker)

https://gerrit.wikimedia.org/r/154830
Change 154831 had a related patch set uploaded by Bartosz Dziewoński:
Remove WMF deployment hack for 'Enlarge' image

https://gerrit.wikimedia.org/r/154831
Change 154830 had a related patch set uploaded by Bartosz Dziewoński:
Generate 'Enlarge' image in CSS rather than HTML (Linker)

https://gerrit.wikimedia.org/r/154830
(In reply to Bartosz Dziewoński from comment #0)
> Let's stop using inline <img> for thumbnail magnify icon. According to bug
> 69277 comment 11, there are 87619775 requests per day for
> 'magnify-clip.png'. It should be embedded in some piece of CSS.
> 
> (Bug 65160 / [[mw:Thumbnail style update]] call for complete removal of the
> icon, but it would only affect the Vector skin.)

Makes sense to me.
(In reply to James Forrester from comment #2)
> At this point this artefact would become a Monobook-only item, right? Should
> it be moved to that repo at that point?

No, it would become every-skin-but-Vector-including-custom-skins-only item.


> VisualEditor only uses it through mediawiki.content.styling.parsoid

It is also used in ve.ce.MWImageCaptionNode.js via 'magnifyClipIconURL' config item.
(In reply to Bartosz Dziewoński from comment #0)
> (Bug 65160 / [[mw:Thumbnail style update]] call for complete removal of the
> icon, but it would only affect the Vector skin.)

At this point this artefact would become a Monobook-only item, right? Should it be moved to that repo at that point?

(In reply to Bartosz Dziewoński from comment #1)
> A number of extensions also refer to this file directly, including
> VisualEditor and WikiEditor. These will need to be updated.

VisualEditor only uses it through mediawiki.content.styling.parsoid (faked Vector-like content rendering; yes yes, I know…), which should be fixed as the fixing for bug 65160.
A number of extensions also refer to this file directly, including VisualEditor and WikiEditor. These will need to be updated.

There are probably also innumerable user scripts that refer to it. Looking at bug 69277 comment 10, the Popups gadget is a big offender.
Steps to repro:

1. In prod/stable on iPad, enter VE edit mode and tap on a 2-word wikilink (e.g. [[European robin]])
2. Open link inspector
3. Tap on the end of the second word (e.g., after "European") to drop cursor between the two words
4. Attempt to backspace and enter new text

I've seen a number of weird things happen after this step:

* No suggestions come up in the drop-down, even when there clearly should be some
* Adding new text or spaces is impossible; you can only backspace
* Backspacing too fast closes the dialog (known issue) or crashes Safari (not sure if known issue)

None of these seem to happen if you tap at the end of the text in the link inspector (e.g., after "robin") and backspace/add new text from there.

--------------------------
**Version**: unspecified
**Severity**: normal
Seems to work for me now. Tested on Beta Cluster using iOS Safari 8.0 on an iPad.
Sorry, that should be:

3. Tap on the end of the FIRST word (e.g., after "European")
Steps to reproduce:

1.  Add a short category or three.  (At en.wp, you can add Category:1, Category:2, and Category:3, etc.)  The box for adding the next cat should still be on the same (first) line.

2.  Now try to add a very long category name.  If you're on Meta, try Category:Association of Wikipedians - AWWDMBJAWGCAWAIFDSPBATDMTD


Result:  

The search field pops up, but you can't really see much of it.  In particular, unless what you're trying to add can be reliably added from the first and last few characters, then you might add the wrong category.


Expectation:  

The category field will be wide enough to see what's in the search list.

--------------------------
**Version**: unspecified
**Severity**: minor
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57200
[[ https://www.mediawiki.org/wiki/Topic:T8cllr8xqawliza4 | We got a new report about this from Ziko. ]]
*** Bug 71657 has been marked as a duplicate of this bug. ***
Fonts for Japanese and Chinese must be installed for VisualEditor localized screenshots. Without this all the screenshots in these languages show squares instead of the correct characters.

--------------------------
**Version**: unspecified
**Severity**: normal
I'm closing this. Installing fonts in the future should be simple enough... I think :)

Thanks a lot for the help!
Amir can we close this bug or maybe we can keep it open to track the installation of fonts for all the other languages?
Change 162869 merged by jenkins-bot:
Running language screenshot job using local Firefox

https://gerrit.wikimedia.org/r/162869
Change 162869 had a related patch set uploaded by Zfilipin:
Running language screenshot job using local Firefox

https://gerrit.wikimedia.org/r/162869
Change 162604 merged by Filippo Giunchedi:
contint: labs slaves +mediawiki::packages::fonts

https://gerrit.wikimedia.org/r/162604
Thanks Antoine, screenshots are fine now! :)
Change 162604 had a related patch set uploaded by Hashar:
contint: labs slaves +mediawiki::packages::fonts

https://gerrit.wikimedia.org/r/162604
Kartik proposed a change to add the font 'fonts-wqy-zenhei' https://gerrit.wikimedia.org/r/#/c/154086/  but it has been abandoned.

Daniel Zahn pointed out it is made by https://github.com/wikimedia/operations-puppet/blob/8f14fc7cdbfb5c6f16cb4b1a3bbc64dfd5d200e8/modules/mediawiki/manifests/multimedia.pp#L91

But:

hashar@integration-slave1002:~$ apt-cache policy ttf-wqy-zenhei 
ttf-wqy-zenhei:
  Installed: (none)
  Candidate: 0.9.45-3.1ubuntu1
  Version table:
     0.9.45-3.1ubuntu1 0
        500 http://nova.clouds.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages


So apparently mediawiki::packages::fonts is not applied on the continuous integration slaves though we include ::mediawiki::packages , we apparently need to explicitly add that puppet class.
I have created a short script[1] and a simple jenkins job[2] to demonstrate the problem.

The script opens main page using firefox in several languages and takes screenhots[3-5]. Screenshots show that Chinese and Japanese characters are not displayed properly.

Are we doing something wrong? Or, is the jenkins slave where the firefox is running missing the fonts?

1: https://gerrit.wikimedia.org/r/#/c/162576/2/modules/ve-mw/tests/browser/fonts.rb,cm
2: https://integration.wikimedia.org/ci/job/browsertests-VisualEditor-language-screenshot-linux-firefox-69535/
3: https://integration.wikimedia.org/ci/job/browsertests-VisualEditor-language-screenshot-linux-firefox-69535/lastSuccessfulBuild/artifact/modules/ve-mw/tests/browser/ja.png/*view*/
4: https://integration.wikimedia.org/ci/job/browsertests-VisualEditor-language-screenshot-linux-firefox-69535/lastSuccessfulBuild/artifact/modules/ve-mw/tests/browser/zh-hans.png/*view*/
5: https://integration.wikimedia.org/ci/job/browsertests-VisualEditor-language-screenshot-linux-firefox-69535/lastSuccessfulBuild/artifact/modules/ve-mw/tests/browser/zh-hant.png/*view*/
Change 162576 abandoned by Zfilipin:
WIP [BrowserTest] reproducing bug 69535

https://gerrit.wikimedia.org/r/162576
Change 162576 had a related patch set uploaded by Zfilipin:
WIP [BrowserTest] reproducing bug 69535

https://gerrit.wikimedia.org/r/162576
Change 162569 abandoned by Zfilipin:
WIP reproducing bug 69535

https://gerrit.wikimedia.org/r/162569
Change 162569 had a related patch set uploaded by Zfilipin:
WIP reproducing bug 69535

https://gerrit.wikimedia.org/r/162569
Submitted Sauce Labs support ticket:

https://support.saucelabs.com/requests/15238
The jobs as they are configured now run on Sauce, whee we cannot control the fonts.

We need to run the jobs on a machine where we can install the required fonts.
Change 154086 abandoned by Dzahn:
Add Chinese fonts for VE screenshots feature

Reason:
abandoning because the related bug is resolved. also it's easy to restore if needed. cheers, Daniel

https://gerrit.wikimedia.org/r/154086
(In reply to Željko Filipin from comment #5)
> Vikas, Amir, are Japanese and Chinese screenshots now good?

ping :)
Vikas, Amir, are Japanese and Chinese screenshots now good?
Daniel Z. pointed out that "ttf-wqy-zenhei" works as a package name on both Precise and Trusty. On Trusty, it is a virtual package that depends on "fonts-wqy-zenhei", to make migration easier. And, in fact, we already install it:

https://github.com/wikimedia/operations-puppet/blob/8f14fc7cdbfb5c6f16cb4b1a3bbc64dfd5d200e8/modules/mediawiki/manifests/multimedia.pp#L91
"fonts-wqy-zenhei" is available on Trusty but not Precise:

    [mw1001:~] $ cat /etc/issue
    Ubuntu 12.04.4 LTS \n \l

    [mw1001:~] $ apt-get --dry-run install fonts-wqy-zenhei
    NOTE: This is only a simulation!
          apt-get needs root privileges for real execution.
          Keep also in mind that locking is deactivated,
          so don't depend on the relevance to the real current situation!
    Reading package lists... Done
    Building dependency tree
    Reading state information... Done
    Package fonts-wqy-zenhei is not available, but is referred to by another package.
    This may mean that the package is missing, has been obsoleted, or
    is only available from another source

    E: Package 'fonts-wqy-zenhei' has no installation candidate
Change 154086 had a related patch set uploaded by KartikMistry:
Add Chinese fonts for VE screenshots feature

https://gerrit.wikimedia.org/r/154086
Moving to Wikimedia -> Quality.  Will have to figure out the font packages to install.  Maybe we could reuse the one defined in puppet class mediawiki::multimedia::fonts
1. Create an image in VE standalone with no width/heigh attrs (using the html editor mode)
2. Resize the image in VE and undo

The image doesn't go back to it's original size (in the view).

--------------------------
**Version**: unspecified
**Severity**: normal
**gerritadmin** wrote:

Change 154036 merged by jenkins-bot:
Make sure image attribute is cleared if set to null

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

Change 154036 had a related patch set uploaded by Esanders:
Make sure image attribute is cleared if set to null

https://gerrit.wikimedia.org/r/154036
**Author:** `ryan.wold`

**Description:**
When disabling an Editor's .target.surface (by calling .disable()), the text is no longer editable, which is great.  However, the text in the disabled Editor cannot be copied and pasted.  It does not appear to make it to the clipboard. 

Desired behavior is that the text can be be copied even when the editor is disabled.  Or perhaps there could be a setting/option around that.



We traced this to ve.dm.Surface.prototype.changeInternal, where it returns immediately if the surface is disabled.

if ( !this.enabled ) {
  return;
}

I found this here: https://doc.wikimedia.org/VisualEditor/master/source/ve.dm.Surface.html#ve-dm-Surface-method-changeInternal


I'm using OSX Mavericks and Google Chrome Version 36.0.1985.125.

Thanks!

- Ryan Wold
  ryan.wold@neo.com

--------------------------
**Version**: unspecified
**Severity**: normal
The surface model also tracks selections so disabling the surface model would also disable any meaningful copy/paste functionality. dm.Surface#disable is not really intended for putting the surface into a useful read-only mode. What exactly are you trying to achieve?
**ryan.wold** wrote:

%%%*** Bug 69516 has been marked as a duplicate of this bug. ***%%%
"Before".  This is what you see at step #4.

See attached screenshots.  

Steps to reproduce:

1.  Open VisualEditor and Insert > Media.

2.  Pick and image and add a caption.

3.  Select a word and press Command-K to make an internal link. 

4.  Notice that the link inspector ought to be bigger, so you can see all the new buttons.

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

**Attached**: {F14165}
Works for me in Firefox 31 and Safari 6.
This appears to now be fixed?

(Tested: Vector & Monobook on wmf19, wmf20, and pre-wmf21 with Firefox and Chrome.)
Created attachment 16188
"After":  This is what you get when you click inside the box, to get past bug 69510's focus problem.

**Attached**: {F14166}
In Internet Explorer, if you open a link or comment inspector, it closes immediately after opening. It doesn't matter if you use Ctrl+K or the context or the toolbar or double-click or enter to open the inspector, the exact same thing happens.

--------------------------
**Version**: unspecified
**Severity**: normal
Fixed in https://gerrit.wikimedia.org/r/#/c/155182/
This is related to bug 50872.

If you click the edit link on a section, then that section's heading is pre-populated in the edit summary when you save.

This does not work very well if you have turned on https://en.wikipedia.org/wiki/MediaWiki:Gadget-edittop.js ("Add an [edit] link for the lead section of a page") in the gadgets for your preferences.  Editing the first (lead) section of the page gets a suggested edit summary that includes the first section heading on the page i.e., the section heading immediately underneath the section you were actually editing.

The link for 'edit source' says:

https://en.wikipedia.org/w/index.php?title=User:WhatamIdoing&action=edit&section=0&summary=/*%20top%20*/%20 

The link for 'edit' says:

https://en.wikipedia.org/w/index.php?title=User:WhatamIdoing&veaction=edit&vesection=1

The subsequent section editing links are all correct.

--------------------------
**Version**: unspecified
**Severity**: normal
I went back and fixed up that gadget so it should handle VE links correctly. This change to pick up 'summary' from the URL should take affect on all Wikipedias on Thursday (it should already be on test and test2).
**gerritadmin** wrote:

Change 156744 merged by jenkins-bot:
Pick up 'summary' parameter from URL to use as initial edit summary

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

Change 156744 had a related patch set uploaded by Alex Monk:
Pick up 'summary' parameter from URL to use as initial edit summary

https://gerrit.wikimedia.org/r/156744
Although VE should probably pick up the default summary from the URL.
It looks like the gadget needs to be fixed to deal with VE. In particular, it needs to be able to deal with 've' between the '&' and 'section='.
Steps to reproduce:

1.  Open VisualEditor and select a word.

2.  Press Command-K to open the link inspector.

3.  We're going to make an external link to http://www.example.com so start typing:  h-t-t-p-:-/-/-w-w-w-

4.  Why is it trying to find an internal page for the URL I'm typing?


If you're obviously typing in a URL, the search feature should be disabled.  Offering to make a link to the "local page" http://www.example.com risks broken links like this:  https://en.wikipedia.org/w/index.phpdiff=621124784&oldid=620566012

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=44011
See also {T76398}
>>! In T71500#749617, @Krenair wrote:
> Interesting that MediaWiki allows you to create pages that are URLs, but you can't link to them...

Sorry - it turns out you can link to internal pages named like URLs in MediaWiki, but you have to use the ':' prefix.
Bug 44011 sounds slightly related
Interesting that MediaWiki allows you to create pages that are URLs, but you can't link to them...
In https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&diff=621079160&oldid=621075505 it is pointed out that if an argument to a template contains a | then <nowiki>|</nowiki> is added. The new magic word {{!}} might be a better alternative.

See also bug 67863

--------------------------
**Version**: unspecified
**Severity**: normal
Change 195559 merged by jenkins-bot:
T71482: Convert | to {{!}} in template parameters

[[https://gerrit.wikimedia.org/r/195559]]
Change 195559 had a related patch set uploaded (by Marcoil):
T71482: Convert | to {{!}} in template parameters

[[https://gerrit.wikimedia.org/r/195559]]
A relevant diff is https://en.wikipedia.org/w/index.php?title=Bone_remodeling&diff=prev&oldid=621072608
For citation template references we may also want to specify a subset of parameters to show first.
Links and citation mocks:
{F18090}

{F18092}
--------------------------
**Version**: unspecified
**Severity**: enhancement
(In reply to Bartosz Dziewoński from comment #6)
> (I tried messing around with ve.dm.Converter too, but it seems impossible to
> render the contents of templated references without involving the surface,
> probably because they're magically generated in ve.ce.)

Yeah, this needs CE. I think we may have to rethink how we do descriptions a little.
(I tried messing around with ve.dm.Converter too, but it seems impossible to render the contents of templated references without involving the surface, probably because they're magically generated in ve.ce.)
I played with it and the following sort of works for all reference node types. There must be a better way to do it, but I can't find one. (It also doesn't update the tooltip after reference contents are changed, probably because that is done deferred or something.)
```
ve.ce.MWReferenceNode.static.getDescription = function ( model ) {
  var refModel = ve.dm.MWReferenceModel.static.newFromReferenceNode( model );
  var surface = ve.init.target.createSurface( refModel.getDocument() );
  var text = $( surface.getView().$element ).text();
  surface.destroy();
  return text;
};
```
I played with it and the following sort of works for all reference node types. There must be a better way to do it, but I can't find one. (It also doesn't update the tooltip after reference contents are changed, probably because that is done deferred or something.)

ve.ce.MWReferenceNode.static.getDescription = function ( model ) {
  var refModel = ve.dm.MWReferenceModel.static.newFromReferenceNode( model );
  var surface = ve.init.target.createSurface( refModel.getDocument() );
  var text = $( surface.getView().$element ).text();
  surface.destroy();
  return text;
};
Any attempt to "parse" the template parameters is going to become very complex or fail to address the needs of wikis other than the English Wikipedia. How about just displaying the parsed content of the reference, stripped of links and any block markup, and limited to some length?
I think we'd much rather keep the current model of showing the name of something shown, or the value of something not shown (like for HTML comments)…
We could list template values in order until we run out of room, but this may not lead to desirable results, for example the first parameter in {{Cite web}} is URL.

A more complex solution would be to come up with a format for defining how to generate the summary of a template and store it in template data, either as a value on the column (summary order):

Field     Desc  Summary order
url       ...   null
publisher ...   2
title     ...   1
date      ...   3
month     ...   null

A simplified version of this would just flag one field as being used in the summary.

etc.

Or as a string concatenation message somewhere:

"{{{title}}}, {{{publisher}}} - {{{date}}}"
*** Bug 69744 has been marked as a duplicate of this bug. ***
When you just change image on a media, the border parameter is lost.

https://test2.wikipedia.org/w/index.php?title=BorderLost&diff=98843&oldid=98842

Safari/Mac OS X

--------------------------
**Version**: unspecified
**Severity**: normal
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
screenshot

1> open a page in VE, insert a comment.
2> While the comment is still highlighted, insert a link. Notice the cursor is in between the comment and the link.
3>Now select the Language style text. Click “Done” in the language inspector.
Notice the cursor has now moved to the end of the comment. Type in some text, it gets inserted after the link. See screenshot.

Try the above steps, but instead of comment insert a Formula.

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

**Attached**: {F14630}
Confirmed in Betalabs and test2. 

After inserting a comment and a link, a cursor is moved at the end of the line, but typed text gets inserted between the comment and the link.
Environment-test2 and beta
Found only in chrome and Safari.
See e.g. http://parsoid-lb.eqiad.wikimedia.org/wikimania2014wiki/Submissions%2FVisualEditor_%E2%80%94_engineering_against_the_odds?oldid=47825 vs https://wikimania2014.wikimedia.org/wiki/Submissions/VisualEditor_%E2%80%94_engineering_against_the_odds?oldid=47825

Wikitext:

; '''Sunday August 10, 12:30, [[Frobisher 123]]'''

Parsoid HTML:

<dl><dt> <b>Sunday August 10, 12</b></dt><dd><b>30, <a rel="mw:WikiLink" href="./Frobisher_123">Frobisher 123</a></b></dd></dl>


PHP parser HTML:

<dl><dt><b>Sunday August 10, 12:30, <a href="/wiki/Frobisher_123" title="Frobisher 123">Frobisher 123</a></b></dt></dl>

It looks like this might be a syntax ambiguity, but hopefully we can have bug-for-bug compatibility with the PHP parser? :)

--------------------------
**Version**: unspecified
**Severity**: normal
Change 155868 merged by jenkins-bot:
Context aware parsing of definition list colon

[[https://gerrit.wikimedia.org/r/155868]]
Change 155868 had a related patch set uploaded (by Arlolra):
Context aware parsing of definition list colon

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

#patch-for-review
Updating the title to reflect that this is not just i/b wikitext context, but more general. As indicated in comment 2, this could use some more testing to better spec out what the right behavior is.
Change 155868 had a related patch set uploaded by Arlolra:
b/i context aware parsing of definition list colon

https://gerrit.wikimedia.org/r/155868
Thankfully, this is not related to time, but more related to context-sensitive tokenization of the ":" char in a dt-dl list.

;a:b
;''a:b''

The behavior require a bit more testing. Ideally, this is reasonably well-behaved that it can be fixed in the tokenizer without requiring a DOM transformation fixup.
Also, if you try to edit this, the resulting wikitext is something like '''Sunday August 10, 11''':30, [[Frobisher 123]]''' . It's trying to close the bolding twice.
VE's help icon popup includes this "visualeditor-beta-warning" text:

"VisualEditor is in 'beta'. You may encounter software issues, and you may not be able to edit parts of the page. To switch back to source editing at any time without losing your changes, open the dropdown next to \"{{int:visualeditor-toolbar-cancel}}\" and select \"{{int:visualeditor-mweditmodesource-title}}\"."

But I don't see this Cancel button in the VE UI these days. The page options "hamburger" dropdown is now between (?) and [Save page].  It would be more helpful to show the hamburger icon in the help message, maybe WikiFont some day.

--------------------------
**Version**: unspecified
**Severity**: minor
Fixed in gerrit I36f13b2ff this morning. :-)
In the image advanced settings dialog the image alignment buttons say "right", "center" and "left". In RTL UI their order is confusing, because the "right" button is on the "left" and vice versa. They should be in a more logical order. (The icons are correct, however.)

--------------------------
**Version**: unspecified
**Severity**: normal
Change 152043 merged by jenkins-bot:
Flip direction buttons in media dialog in RTL

https://gerrit.wikimedia.org/r/152043
Change 152043 had a related patch set uploaded by Amire80:
Correct buttons order in media advanced settings

https://gerrit.wikimedia.org/r/152043
I have two overrides for vagrant_ram:

* CirrusSearch has a puppet-managed override setting it to 1536
* I have a .settings.yaml with the following contents:
---
vagrant_ram: 2048
git_user: ''
puppet_debug: true

However, sometimes it's lower than both of those.  I.E.:
------
             total       used       free     shared    buffers     cached
Mem:           993        933         60         18          0         23
-/+ buffers/cache:        909         84
Swap:            0          0          0
------

Tested with 6b27f39 (I know that's a little old, so feel free to close if you think it's been fixed since).

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=69720
Probably fixed by 9da72b12c40f3e7a54870da8f6ec3c235ec6c337 ("Load settings if vagrant is run from subdirectory")
Went back to:

===
vagrant@mediawiki-vagrant:~$ free -m
             total       used       free     shared    buffers     cached
Mem:          2001       1037        964          8         17        370
-/+ buffers/cache:        649       1352
Swap:            0          0          0
===

after a vagrant reload --provision
Possibly fixed by https://gerrit.wikimedia.org/r/154975 .
The new Save dialog has two buttons at the top:  "Cancel" and "Save"

It's not clear whether Cancel means "exit this dialog" or "lose all your work".  Please change the label to something like "Return to editing" or "Resume editing", or something that clearly indicates that this button allows you to keep editing and will not exit VisualEditor and cause you to lose all of your work.

--------------------------
**Version**: unspecified
**Severity**: minor
Verified the fix in production
Verified the fix in test2
Verified the fix in Betalabs
Change 159806 merged by jenkins-bot:
Relabel the cancel button in the save dialog to "Resume editing"

https://gerrit.wikimedia.org/r/159806
Change 159806 had a related patch set uploaded by Jforrester:
Relabel the cancel button in the save dialog to "Resume editing"

https://gerrit.wikimedia.org/r/159806
Currently, LivePreview only passes the $wikiPreview to the hook
https://github.com/wikimedia/mediawiki/blob/6709a1fd082bcbc1b89d499edeafa04fd2e8a517/resources/src/mediawiki.action/mediawiki.action.edit.preview.js#L101
but the script changes the page content in many other places:
https://github.com/wikimedia/mediawiki/blob/6709a1fd082bcbc1b89d499edeafa04fd2e8a517/resources/src/mediawiki.action/mediawiki.action.edit.preview.js#L31-L43
The new content for these parts should also be made available to the user, by passing them to the hook (as VisualEditor does, for example
https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/ccdc215a9882d6bb3e079ca822f64c9089c0d363/modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.js#L1574
).

This would allow scripts like
https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-featured-articles-links.js&oldid=619815637
to update the modifications of the language links after the user makes some changes and use the live preview (in the example, the "badges" for featured/good articles in other languages).

Also, this is likely what UniversalLanguageSelector needs in order to fix bug T53029.
See diff at https://de.wikipedia.org/w/index.php?title=Schotts_Sammelsurium&diff=prev&oldid=132639553 .

--------------------------
**Version**: unspecified
**Severity**: normal
(In reply to Kurt Jansson from comment #1)
> The "<em>" tag was inserted via italicised text in the clipboard. Source for
> the text was a web page. I would expect that the VE drops the tag or
> replaces it with two singe quotes.

Yeah, good point. I thought we already did this?

> Ich have no idea where the "<nowiki>" tag came from. I wasn't able to delete
> it in the VE.

That's because you ended up with a paragraph starting with a ' ', and to stop it turning into a <pre> block it instead – bug 66628. It's harmless, if irritating.
Looking at this again, I believe VE used to add those nowiki tags to prevent the line being displayed differently from the others because of the space at its beginning; and VE does retain formatting when pasting, but that can be avoided by using the shortcut Ctrl + Shift + V.
The "<em>" tag was inserted via italicised text in the clipboard. Source for the text was a web page. I would expect that the VE drops the tag or replaces it with two singe quotes.

Ich have no idea where the "<nowiki>" tag came from. I wasn't able to delete it in the VE.
When resizing the window, after a certain point the MediaWiki page layout may change (media queries). This affects the offset from the left side of the page (specifically, width of the sidebar).

However the toolbar caches its computed offset once and never updates it.

1. Open window wider than 1024px with Vector skin in MediaWiki.
2. Enter VisualEditor.
3. Resize to < 980px.

Expected:

Sidebar shrinks (per Vector styles) and toolbar should still align with left edge of the page.

Actual:

Sidebar shrinks but toolbar stays behind causing an awkward gap to appear as well as odd interruption in the shadow. It results in part of the Save page button to go off-screen. 

Other:

The reverse happens as well. Opening a narrow window and scaling it up will cause it to stay behind in the other direction. It results in part of the toolbar overlapping links in the sidebar.

--------------------------
**Version**: unspecified
**Severity**: minor
Verified the fix in production.
Change 169232 merged by jenkins-bot:
Recalculate toolbar size on window resize

https://gerrit.wikimedia.org/r/169232
Change 169232 had a related patch set uploaded by Esanders:
Recalculate toolbar size on window resize

https://gerrit.wikimedia.org/r/169232
Created attachment 16109
Screenshot of bug.

**Attached**: {F14581}
These seem to be the leading cause of edit corruption right now.

myEventWatcherDiv: https://ru.wikipedia.org/?diff=64516612 https://ru.wikipedia.org/?diff=64516412 https://pt.wikipedia.org/?diff=39659121 https://pt.wikipedia.org/?diff=39659108

<embed> tags: https://pt.wikipedia.org/?diff=39696565

<object> tags: https://fr.wikipedia.org/?diff=105796883 https://fr.wikipedia.org/?diff=105796959 https://fr.wikipedia.org/?diff=105797061

I'm thinking we should put in hacks to remove these kinds of tags. Maybe at the point where we serialize the HTML and send it to Parsoid (ve.init.mw.Target#getHTML). If these tags are added immediately upon document creation (we'd need to get our hands on one of these bad plugins to test that) we could also consider trying to work around this in ve.createDocumentFromHtml instead. I suspect, though, that these tags are probably added asynchronously, and probably only in cases where we fall back to the iframe trick because DOMParser HTML support is not available.

--------------------------
**Version**: unspecified
**Severity**: normal
Marking this as fixed, will keep an eye on the others in the next couple of weeks or so to see if those are resolved by it.
Change 163961 merged by jenkins-bot:
Remove certain blacklisted elements when getting HTML from document

https://gerrit.wikimedia.org/r/163961
Change 163961 had a related patch set uploaded by Alex Monk:
Remove certain blacklisted elements when getting HTML from document

https://gerrit.wikimedia.org/r/163961