bug 31176 mentionned an issue with {{SERVERNAME}} returning the full
URL instead of servername when using relative URLs (//localhost).
The fix was made by r98193.
This patch test three different URL protocols (http, https & relative)
and check we return the expected 'localhost'.
r85856 fixed a CSS injection issue but lacked testing. This
test verify we properly strip out CSS comments even when the
token delimiter '/*' is backslash-escaped : \2f\2a
Using same technique as ApiExpandTemplates to serialize the object tree back to XML, rather than asking for the DOM implementation's internal XML return function.
Have to also perform normalization on the test cases, as they aren't normalized to what libxml2 serializes. :P
Note that there are 4 test failures currently with Preprocessor_Hash, as it makes a separate <equals> element around = which doesn't appear to be in Preprocessor_Dom's output.
There are many cases this method will fail for non-latin languages,
but not added now since there are bugs reported on that already and results
a rewrite of the method as per UAX 31 standard.
Basically, in XMP you can specify partial date (for example 2011-04 for april 2011 with no day).
We were extracting that, and fulling out the day to 01 if it wasn't present (My original resoning when writing
the code was that the nice localized date functions need a full date, but that's a pretty poor rationale for displaying
wrong date). This changes it to just display such year-month things as YYYY:MM.
Followup r91591, r93020: patch to jsminplus to support Unicode chars and char escapes in identifiers
Fast-path check keeps runtime about the same on most scripts (eg jquery.js parsing was abround 4100ms both before and after on my test machine)
Slow-path code kicks in if plain ASCII word chars don't extend all the way to the next whitespace or punctuation char.
Using PCRE's Unicode properties magic to ensure that we're catching everything, following ECMA-262 edition 5.1 spec.
Note that identifiers using escapes don't get normalized to their UTF-8 form; this might be a nice thing to do as it saves a couple bytes, but currently there's no change made to output.
Added QUnit tests to verify that unicode letter & escapes work in identifiers in all supported browsers (ok back to IE 6, yay)
- sets an image's reported width/height to the logical form (portait image reports itself as portait)
- everything works in logical coordinates when sizing -- we don't touch the physical pre-rotation dimensions again until it's actual low-level resize time. This fixes several problems with incorrect thumb sizing (eg getting a 600x800 image when we asked for something that fits in 800x600 box)
- fixes unit test cases in ExifRotationTest that were reporting that the width/height were coming back with the physical form which we don't want
- removes some test cases on ExifRotationTest that tested dimension swapping in a place where we don't want it
- ensures that only logical width/height need be exposed to API etc, making exif-rotated images work via ForeignAPIRepo
Note that this may actually cause file metadata to get loaded twice during File::getPropsFromPath, as the $image parameter it passes in to the handler's getImageSize function is bogus and can't be used to fetch an already-loaded metadata blob. This should not generally be too expensive though; it's not a fast path.
Rotated files that were uploaded under previous versions may still have their width/height reversed; an action=purge on the file page will refresh it and cause thumbs to be regenerated.
Follows up on r79845, r90016, r92246, r92279, r96687, r97651, r97656, r97659.
Needs merge to 1.18.
This should fix issues reported in http://lists.wikimedia.org/pipermail/wikitech-l/2011-September/055212.html Lots of these tests loaded the exif extension dynamically, but then didn't reset $wgShowEXIF var properly.
Also change some of the markTestIncomplete to markTestSkipped as that seemed more correct.
