Page MenuHomePhabricator

Visual Editor removes alt text from video in gallery
Closed, ResolvedPublicBUG REPORT

Description

What happens?:

It appears that when Visual Editor encounters a .webm file with alt text inside a gallery (and maybe outside it), it will remove the alt text. This occurs even when a completely different section is being changed. Some diffs where I've seen this behavior:

Event Timeline

Confirmed -- I can visit https://en.wikipedia.org/w/index.php?title=Green_Line_Extension&veaction=edit, add a word to the lead section, and the wikitext diff before saving will show it stripping the alt text from the file in the gallery.

image.png (800×1 px, 194 KB)

Haven't actually looked at the code yet, but I'd speculate that it could be stripping it out because the webm file doesn't wind up with an alt attribute in its output -- the video player created by the gallery doesn't use the alt text anywhere.

For the video there's no alt attribute in the markup and it's instead provided in the data-mw attribute. Having looked at ve.dm.MWGalleryImageNode, I think we're ignoring that and 100% using whatever's in the (absent) alt attribute of the .mw-file-element when we initially parse the Parsoid HTML. (This is why you can set the alt text on a video with VE.)

Parsoid HTML for a video:

<li class="gallerybox" style="width: 286.66666666667px;" id="mwA-0"><div class="thumb" style="width: 284.66666666667px;" id="mwA-4"><span typeof="mw:File" data-mw='{"attribs":[["alt",{"txt":"A video of a large brick building being demolished by a wrecking ball"}]]}' id="mwA-8"><span title="Demolition of the Homans Building in April 2019" id="mwA_A"><video poster="//upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Homan_Building_demolition%2C_April_2019.webm/427px--Homan_Building_demolition%2C_April_2019.webm.jpg" controls="" preload="none" height="160" width="285" resource="./File:Homan_Building_demolition,_April_2019.webm" data-durationhint="25" class="mw-file-element" id="mwA_E"><source src="//upload.wikimedia.org/wikipedia/commons/f/f6/Homan_Building_demolition%2C_April_2019.webm" type='video/webm; codecs="vp9, opus"' data-file-width="1280" data-file-height="720" id="mwA_I"/><source src="//upload.wikimedia.org/wikipedia/commons/transcoded/f/f6/Homan_Building_demolition%2C_April_2019.webm/Homan_Building_demolition%2C_April_2019.webm.240p.vp9.webm" type='video/webm; codecs="vp9, opus"' data-width="426" data-height="240" id="mwA_M"/><source src="//upload.wikimedia.org/wikipedia/commons/transcoded/f/f6/Homan_Building_demolition%2C_April_2019.webm/Homan_Building_demolition%2C_April_2019.webm.360p.vp9.webm" type='video/webm; codecs="vp9, opus"' data-width="640" data-height="360" id="mwA_Q"/><source src="//upload.wikimedia.org/wikipedia/commons/transcoded/f/f6/Homan_Building_demolition%2C_April_2019.webm/Homan_Building_demolition%2C_April_2019.webm.360p.webm" type='video/webm; codecs="vp8, vorbis"' data-width="640" data-height="360" id="mwA_U"/><source src="//upload.wikimedia.org/wikipedia/commons/transcoded/f/f6/Homan_Building_demolition%2C_April_2019.webm/Homan_Building_demolition%2C_April_2019.webm.480p.vp9.webm" type='video/webm; codecs="vp9, opus"' data-width="854" data-height="480" id="mwA_Y"/><source src="//upload.wikimedia.org/wikipedia/commons/transcoded/f/f6/Homan_Building_demolition%2C_April_2019.webm/Homan_Building_demolition%2C_April_2019.webm.720p.vp9.webm" type='video/webm; codecs="vp9, opus"' data-width="1280" data-height="720" id="mwA_c"/></video></span></span></div><div class="gallerytext" id="mwA_g">Demolition of the Homans Building in April 2019</div></li>

vs Parsoid HTML for a JPEG:

<li class="gallerybox" style="width: 244.66666666667px;" id="mwA-c"><div class="thumb" style="width: 242.66666666667px;" id="mwA-g"><span typeof="mw:File" id="mwA-k"><a href="./File:Broadway_bridge_demolition_(1),_March_2019.jpg" class="mw-file-description" title="Broadway bridge under reconstruction in March 2019" id="mwA-o"><img alt="A bridge being demolished by four excavators" resource="./File:Broadway_bridge_demolition_(1),_March_2019.jpg" src="//upload.wikimedia.org/wikipedia/commons/thumb/a/a8/Broadway_bridge_demolition_%281%29%2C_March_2019.jpg/364px-Broadway_bridge_demolition_%281%29%2C_March_2019.jpg" decoding="async" data-file-width="2516" data-file-height="1662" data-file-type="bitmap" height="160" width="243" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/a/a8/Broadway_bridge_demolition_%281%29%2C_March_2019.jpg/545px-Broadway_bridge_demolition_%281%29%2C_March_2019.jpg 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/a/a8/Broadway_bridge_demolition_%281%29%2C_March_2019.jpg/727px-Broadway_bridge_demolition_%281%29%2C_March_2019.jpg 2x" class="mw-file-element" id="mwA-s"/></a></span></div><div class="gallerytext" id="mwA-w">Broadway bridge under reconstruction in March 2019</div></li>

Change 965592 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/VisualEditor@master] Gallery image nodes: fall back to alt attributes in container mw-data

https://gerrit.wikimedia.org/r/965592

Also, I made T348785 for the accessibility issue of video thumbnails entirely discarding the provided alt text in our output.

Change 965592 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Gallery image nodes: fall back to alt attributes in container mw-data

https://gerrit.wikimedia.org/r/965592

DLynch added a project: Editing QA.

To sum up some out-of-ticket discussions, there’s two problems:

  1. Parsoid ignores the data-mw attribute that it currently outputs on videos that have alternate text if we submit it. That’s why there’s always a dirty-diff on those pages even when selser should mean that VE's output is ignored. This is (probably) T214603.
  2. VE ignores the data-mw attribute because it only looks for an alt on the thumb. Thus it thinks that all video thumbs have no alt text.

My patch fixes the latter issue, because it reads the alt from data-mw and VE's existing behavior then puts it (incorrectly, but Parsoid reads it) into an alt on the <video>. We should revisit this behavior once Parsoid fixes its round-tripping of these bits of gallery metadata, because this isn't an ideal solution.

  1. Parsoid ignores the data-mw attribute that it currently outputs on videos that have alternate text if we submit it. That’s why there’s always a dirty-diff on those pages even when selser should mean that VE's output is ignored. This is (probably) T214603.

This is fixed in https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/967323 and should roll out with the next train.

  1. VE ignores the data-mw attribute because it only looks for an alt on the thumb. Thus it thinks that all video thumbs have no alt text.

VE seems to drop the data-mw altogether for the mw:File, which means that |thumbtime or |page or any other media option in there won't roundrip as well, not just alt. See T214603 and note that that also depends on the above patch rolling out.

Change 968376 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/extensions/VisualEditor@master] [WIP] Set alt in data-mw for non-img media

https://gerrit.wikimedia.org/r/968376

My patch fixes the latter issue, because it reads the alt from data-mw and VE's existing behavior then puts it (incorrectly, but Parsoid reads it) into an alt on the <video>.

As far as I can tell, if a gallery isn't edited, the data-mw is left as is on the <video> tag. If the gallery is edited in VE, the <video> element becomes an <img> where an alt attribute is valid.

The FIXMEs in the above patch highlight that issue.

VE seems to drop the data-mw altogether for the mw:File, which means that |thumbtime or |page or any other media option in there won't roundrip as well, not just alt.

Yeah, sorry, I was very imprecise there -- I meant ignores in the sense that it doesn't read any data from it into its own model, and then reconstructs the DOM entirely rather than passing through unknown attributes if anything at all changes. It's unfortunate that galleries are so tied-together that even editing only a different thumb within it seemed to be enough to lose the video's data-mw on submission.

It's unfortunate that galleries are so tied-together that even editing only a different thumb within it seemed to be enough to lose the video's data-mw on submission.

That should be fixed in the patch in T348703#9278326

Change 968726 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/extensions/VisualEditor@master] Roundtrip media tag name in galleries

https://gerrit.wikimedia.org/r/968726

As far as I can tell, if a gallery isn't edited, the data-mw is left as is on the <video> tag. If the gallery is edited in VE, the <video> element becomes an <img> where an alt attribute is valid.

That should be fixed in the patch in T348703#9281055

ppelberg subscribed.

@Arlolra, T348703#9267181 is causing me to think this task is resolved. Tho, please re-open if you see more work needing to be done.

Change 968376 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Set alt in data-mw for non-img media

https://gerrit.wikimedia.org/r/968376

Change 968726 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Roundtrip media tag name in galleries

https://gerrit.wikimedia.org/r/968726

matmarex subscribed.

These patches changed how the fix works, so it might be good to verify it again. Sorry about that.