Reverse QUERY_LAYERS order in GetFeatureInfo requests

[marcjansen]

See this thread on the developers mailing list:  http://osgeo-org.1803224.n2.nabble.com/layer-order-in-findLayers-of-WMSGetFeatureInfo-and-WMTSGetFeatureInfo-controls-td6252895.html

When we issue a GetFeatureInfo request through the OpenLayers.Control.GetFeatureInfo, we merge possible layers to the same service in the order they are returned from the candidates array.

Some WMS servers return the GetFeatureInfo-response ordered in the same way the QUERY_LAYERS were given in the original request.

If we reverse the order in which we merge the layers, the output of a GetFeatureInfo request seems more natural.

You can experience the (slightly unexpected) behaviour in the getfeatureinfo-popup.html example: if you click on a water body, you'll currently end up with the response for the water body layer drawn below the state layer.

The attached patch proposes to inverse the order of layers when we issue the GetFeatureInfo-request.

The inversion of layers is in accordance to the behaviour the WMTSGetFeatureInfo-control shows.

The tests for Control.WMSGetFeatureInfo needed to be adjusted to the new logic to still pass (With this patch applied they pass in FF4).

Thanks for any review or comment.

[bartvde]

This looks fine Marc, please commit. Respective tests also pass in IE8. Only minor comment I have is that there is no need to define len outside of the for loop.

for (var i=candidates.length-1; i>=0; --i) {

[marcjansen]

Fixed in  https://github.com/openlayers/openlayers/commit/760d5a584cc363d2d724929d092a0975d3b27bd4