There was a missing parameter in GIFMetadataExtractor's skipBlock() call for 'netscape 2.0' data blocks, which threw a monkey in the works.
Now also checking for exceptions thrown by the metadata load and stubbing out null metadata for files which can't be read, rather than letting the exception bubble up and kill MediaWiki. :)
target page
* (bug 20365) Page name with with c/g/h/j/s/u + x are now correctly handled in
Special:MovePage with Esperanto as content language
+* (bug 20364) Fixed regression in GIF metadata loading
== API changes in 1.16 ==
class GIFHandler extends BitmapHandler {
function getMetadata( $image, $filename ) {
- if ( !isset($image->parsedGIFMetadata) )
- $image->parsedGIFMetadata = GIFMetadataExtractor::getMetadata( $filename );
+ if ( !isset($image->parsedGIFMetadata) ) {
+ try {
+ $image->parsedGIFMetadata = GIFMetadataExtractor::getMetadata( $filename );
+ } catch( Exception $e ) {
+ // Broken file?
+ wfDebug( __METHOD__ . ': ' . $e->getMessage() . "\n" );
+ return '0';
+ }
+ }
return serialize($image->parsedGIFMetadata);
// NETSCAPE2.0 (application name)
if ($blockLength != 11 || $data != 'NETSCAPE2.0') {
fseek( $fh, -($blockLength + 1), SEEK_CUR );
- self::skipBlock();
+ self::skipBlock( $fh );
continue;
}