After great sleuthing from @elemoine, we have a solution closer to the heart of the problem. In a funny twist, the excessive call to `updateSize` ended up hinting at the solution. Thanks to `git bisect` for making things a bit easier.
The Yahoo API doesn't accept quotes in the callback (e.g. foo['bar']). Since the callback registry is an object and all identifiers are prefixed with "c" now, we can use dot notation.
In f08119b01e, the default syntax for the script protocol's callback made it so the callbacks looked like `OpenLayers.Protocol.Script.registry[c1]`. This essentially breaks the script protocol everywhere except where `c1` is defined and equals "c1" (the string).
Tests with this change demonstrate that default callbacks will now look like `OpenLayers.Protocol.Script.registry['c1']` (properly accessing the `c1` property of the registry object).
Sticking with sans-serif gives a more uniform experience on desktop Webkit, Safari on iOS, and the default Android browser.
Using `-webkit-tap-highlight-color` gets rid of the blue highlight when clicking on the map tiles or zoom control.
The UTFGrid layer's `getTileInfo` method was not correctly handling dateline wrapping (and was a bit more complicated than it needed to be). Since it would be useful to all grid layers to be able to retrieve a tile and pixel offset for any map location, this functionality deserves to be on the Grid layer.
The WMTS layer currently exposes a `getTileInfo` method that is used within the layer and by the WMTSGetFeatureInfo control. This method could be renamed to `getRemoteTileInfo` or something to differentiate it from a method that gets locally cached tile info. Until that change is made, the method on the Grid layer will be called `getGridData`.
The zoom control allows for zoom in/out links that can be styled with CSS.
Note: This change was originally captured in #269. It involves nice additions thanks @ahocevar. The changes were unintentionally merged and then reverted with fb3caf1561, so the history of commits is not immediately apparent (though still likely there somewhere due to the magic of git).
Previously, a map could not be destroyed if it included a permalink control without an "element". In addition, a permalink control could not be destroyed if it didn't have a reference to a map.
The super handy quick filter that Marc added in 57c16b7345 was causing a bit of trouble in IE. First, `input` was undefined where it was used as a misspelling for `window`. After that, IE choked on the nice CSS3 selector when filtering the test list. It turns out we don't need to be as selective and can treat all anchor elements within the table rows as candidates.
In IE, events don't have a `hasOwnProperty` method. Instead of trusting that the source objects have this method, we call the same on the Object prototype. If we want to be safer about the `hasOwnProperty` calling done in e3cc96dbfb, we could create an `OpenLayers.Object.has` method that also used the Object prototype.
If a map is configured with a permalink control and a center, the permalink control tries to work with the map center before setCenter is called. This sequence assumes that the map center will already be a LonLat. This fails if the map is constructed with a coordinate array. Safer move is to convert center to LonLat before controls are added.
Having to call two methods to get complete feature information (id and data) is cumbersome. The `getFeatureInfo` method returns an object with both feature id and data.
The tile now has responsibility for resolving feature ids and fetching feature data given x, y pixel offsets with getFeatureId and getFeatureData methods. The layer has corresponding getFeatureId and getFeatureData methods that take a map location, lookup the appropriate tile, and delegate to the tile for the rest of the work.
To get IE7 support, the OpenLayers.Format.JSON parser should be used. This leverages the native JSON.parse method where available. It does add extra weight to UTFGrid builds. However, as of this commit date, we lose large portions of US govt agencies when we exclude IE7.
I would think there would still be an error thrown here. Will put together a test to determine for sure, but I'd think that the default GeoJSON parser used by the protocol would choke on the UTFGrid json.
I think it should be the job of the layer to retrieve data for a given location (instead of the control). The first part of this change creates a `getData` method on the layer and updates the control to use this method.
The second part of this change removes the assumption that the data returned will be an simple object representing feature attributes. The UTFGrid specification doesn't say anything about the structure of property values in the optional data member. The examples given in the spec use string values. The default callback previously assumed that the data could be rendered in a two column table. I think it would make more sense not to make this assumption. With this change, the user must always provide a callback to do anything with returned data.
When the list of event types became unconstrained in 501b42228a, we lost the documentation for events that are triggered. This change adds the list of events triggered to the API docs for events properties.
As an optimization, certain browsers (e.g. Firefox) may not execute functions sent to `requestAnimationFrame` while the window is not visible. Because our tests run in an iframe, the tests fail unless we open a popup to run the animation methods.
The old `containsPoint` method was sensitive to failure when looking for ray crossings with nearly vertical edges. These added tests demonstrate the simple cases where `containsPoint` succeeds. The tests also now include a case that covers the failure for polygons with nearly vertical edges. The previous `getX` method (within the `containsPoint` method) and the new one are mathematically equivalent. The updated version performs better in cases using coordinates with many significant figures.
Tim Schaub