Multiple fast clicks get interpreted as DBLCLICK by the browser,
so it makes sense to stop propagation of DBLCLICK events when
they happen on elements on the overlay container. This is also
a good change because DBLCLICK might have a meaning on other map
overlays as well.
We have constructors, like ol.View2D and ol.control.Attribution, whose "options" argument is optional (opt_options). But currently, we cannot do "new ol.View2D()" in uncompiled code that uses an ol3 build compiled in advanced mode. This commit fixes that by changing the generated Export constructors.
This is a workaround for our check-example.js PhantomJS script to work with this example. Without this check-example.js fails because xhr.status is 0. I tried to give the explicit file:/// scheme as indicated in https://groups.google.com/d/msg/phantomjs/wFGme0pE-Tk/WUjU5s-27NwJ, but that didn't work for me.
As more and more examples will be processed with this script, the
progresbar would grow way too long. This commit makes the width of
the bar fixed. Every character in the bar now equals 5% progress,
regardless of the number of examples.
When opening an example through the `file:`-protocol, e.g.
`file:///ol3/examples/full-screen.html` our `loader.js` would inject
a `<script>` tag with a `src` pointing to an illegal URL
`http://:9810/compile?mode=ADVANCED&id=full-screen`.
This changes the respective logic, so that in the case that we are accessed
through the `file:`-protocol, we fallback to using `localhost` as hostname
for the plovr-compiler.
The examples that do not use XHR (like e.g. `wms-capabilities.html`) now
work as expected when accessed through `file:`-protocol.
Take this example:
```
goog.require('ol.projection.addCommonProjections');
ol.projection.addCommonProjections();
```
Without this patch, the build_check_requires_timestamp target would report
that ``ol.projection`` is missing.
This is because ``ol.projection.addCommonProjections();`` would match both
``ol.projection.addCommonProjections and ``ol.projection`` provide
directives.
