Image provided with non-default (smaller) width/height in template
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Krinkle
	Jul 1 2013, 9:34 PM

Description

Screenshot comparing MW (PHP Parser) dom to VE dom

The image is displayed too small, not due to CSS but due to the width/height attributes explicitly being incorrectly set. No idea where its getting these values from.

Strangely enough, when editing the template with the template dialog, making no changes, and clicking "Apply changes" (causing a re-rendering) it shows up correctly (though that's likely because we're getting that from the php parser api).

Version: unspecified
Severity: normal
URL: http://parsoid.wmflabs.org/en/Peter_Hammill

Attached:

Screen_Shot_2013-07-01_at_11.28.27_PM.png (1×2 px, 837 KB)

Details

Reference: bz50523

Event Timeline

• bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:57 AM

• bzimport added projects: Parsoid, Performance Issue.

• bzimport set Reference to bz50523.

Krinkle created this task.Jul 1 2013, 9:34 PM

That suggests Parsoid is giving us HTML with the wrong image dimensions. Possibly because of the intricate web of preference and configuration logic that determines the thumb size in production.

The template in question uses {{#invoke:InfoboxImage}} and a bunch of ludicrously-complex wikitext, but when not given a size will use the standard thumbnail size, which enwiki uses on default MW options - i.e. 220px wide. Instead, Parsoid comes up with the size of 128x180px, though from where I can't quite see.

180px happens to be the default size (index 2 in $wgThumbLimits). We *could* add the default thumb size setting in the MediaWiki API, but afaik right now that information is not available.

As documented in http://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Images, we set the mw-default-size class on images that should be scaled to preferences. User-specific scaling can then done with client-side JS by matching on the class. That avoids the need for different versions of the page content in caches, which is good for performance.

I think this should be reassigned to VE? It seems like VE should be observing the mw-default-size class when it displays the image.

We are moving closer to using Parsoid HTML for page views and would like it to represent the content anonymous users actually see. Additionally, clients like VE currently don't implement default thumbnail size handling, which leads to extra requests for smaller thumbnails when switching to edit view. For these reasons I believe that it makes sense for us to track the currently configured default size in Mediawiki.

As mentioned in comment #3, this means that we'll have to

expose the currently configured default thumb size in the MediaWiki API, and

use it instead of the MediaWiki default size.

As an easy temporary hack, we can also change the Parsoid default to match the Wikipedia default rather than the MediaWiki default.

Change 100393 had a related patch set uploaded by GWicke:
Bug 50523: Hard-code Wikipedia rather than MW defaults

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

Change 100393 merged by jenkins-bot:
Bug 50523: Hard-code Wikipedia rather than MW defaults

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

Change 101286 had a related patch set uploaded by GWicke:
Merge "Bug 50523: Hard-code Wikipedia rather than MW defaults"

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

Change 101347 had a related patch set uploaded by GWicke:
Bug 50523: Hard-code Wikipedia rather than MW defaults

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

Change 101286 merged by GWicke:
Merge "Bug 50523: Hard-code Wikipedia rather than MW defaults"