Last modified: 2013-11-20 18:28:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T57431, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 55431 - Reupload should purge File page (aka image has malformed dimensions)
Reupload should purge File page (aka image has malformed dimensions)
Status: NEW
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.22.0
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 41371
  Show dependency treegraph
 
Reported: 2013-10-07 18:17 UTC by Krinkle
Modified: 2013-11-20 18:28 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Krinkle 2013-10-07 18:17:43 UTC
Just now someone reported in #wikimedia-commons that this file:

https://commons.wikimedia.org/wiki/File:%D0%A6%D0%B5%D1%80%D0%BA%D0%B2%D0%B0_%D1%81%D0%B2%D1%8F%D1%82%D0%BE%D0%B3%D0%BE_%D0%9C%D0%B8%D1%85%D0%B0%D1%97%D0%BB%D0%B0_%28%D1%81._%D0%A7%D0%B5%D1%81%D0%BD%D0%B8%D0%BA%D0%B8%29_%D0%92%D0%B8%D0%B4_%D1%96%D0%B7_%D0%B7%D0%B0%D0%B4%D1%83.JPG

is displayed on that page with the wrong dimensions (making it look completely distorted, resized and scaled out of proportion by the browser).

Both the main thumbnail on top and the top row of the File history were affected.

They've purged it and that fixed it. However it was the MediaWiki-page that needed purging, the file itself was fine.

The main reason this happens is because we link to the canonical "current" version  of an image by a version-less url. As a result, when a reupload occurs that changes the dimension (e.g. a crop, rotate, whatever), and this canonical url is purged, every existing <img> referencing that url will show the image in the browser out of proportion because we hardcode the width/height everywhere.

Note:
* The example file above has a different unrelated problem (the first revision of the file has gone missing, 404).
* I wonder whether this is limited to the File page. I doubt it. This probably affects usage in articles as well, including cross-wiki.

Now, before someone says it is unlikely the dimensions of a file change, I"ll respond: It is unlikely that a file changes at all because (at least Commons) actively discourages re-upload. It should only be done for non-trivial changes (anything else should be done as a new upload). So the few re-uploads that do happen quite change the dimensions (e.g. fix wrong orientation, or crop away borders of some kind).
Comment 1 Krinkle 2013-10-07 18:20:48 UTC
Yikes, this uncovers a whole range of problems. Sounds like we should:

* Purge the File page (no matter what)

As for usage in articles (please file a different bug), we should either:
* Use versioned urls (e.g. merge file and filearchive)
* or; Somehow purge all usage, cross-wiki - at least if the dimensions changed.
* or; Say both is infeasible and we will accept distorted dimensions in favour of caching.
Comment 2 Krinkle 2013-10-07 18:23:45 UTC
(In reply to comment #1)
> * Use versioned urls (e.g. merge file and filearchive)

I meant here that we'd not have /8/84/Example.svg and later /archive/8/84/20080323205329%21Example.svg, but always have a direct url that stays the same.

But using actual revision ids instead of timestamps as ID would be much better, but that means we need to actually *have* file revision ids (see bug 26741).
Comment 3 Bawolff (Brian Wolff) 2013-10-07 23:36:21 UTC
I agree that urls should change (there are many issues this should change). However I don't think (going off the top of my head) that particular part is cached (in parser cache anyhow. It would be cached by squid if anon), so I'm not sure that such a solution would actually fix this issue. The dimensions/other file metadata is cached, which was probably out of sync (likely due to a race condition judging by timestamps).

Regarding the missing original version - that's due to a race condition that was easily triggered by upload wizard, which has now been fixed.
Comment 4 Bryan Davis 2013-10-10 17:29:13 UTC
This is related to the "Emit page purge jobs for commons files" task in the Multimedia backlog.
Comment 5 Bryan Davis 2013-10-10 17:33:43 UTC
Also related to "Version URLs to help stop cache problems".

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links