maps4html / mapml-extension Goto Github PK

Web extensions allow developers to define their own custom context menu items. This maybe useful for MapML but may not be required.

This requires collaboration between https://github.com/Maps4HTML/Web-Map-Custom-Element and the extension

The idea brought up by @prushforth was as follows:

• allow the user to store a set of features from a MapML viewer for offline use
• allow the user to set a threshold, once the user is within that threshold of a feature from the stored sets, notify the user they are near the given feature
• allow the user to delete sets
• allow the user to turn off notifications for the various sets separately

This can also be used to set the locale of the mapml-viewer. The messages.json files can contain the translations that are then used to by the mapml-viewer through options, since the extension is able to detect the browsers locale, the extension can simply conform to it, without the need of an explicit language selector.

There is a slight discrepancy between extension options right after first install and after storage reset. Specifically:

On first install (inside of chrome.runtime.onInstalled listener) extension sets options to {renderMap: true}:

This means that the following scenario is possible once extension is released on some extension store:

1. User installs extension for the first time and has renderMap option enabled
2. User clears storage (removing options) and gets renderMap option disabled and uses extension for a while
3. Extension gets updated, chrome.runtime.onInstalled listener is called, sees that options are not there, populates them with default enabling renderMap.

This leads to change in settings upon update (which is invisible to user), which can be considered a bug.

Could we integrate the UI locale strings into the same or different json files, perhaps?

When turn off the "Rendering MapML resources" button and turn on the other buttons, and then print M.options into the console:

Expected:

Received:

The announceMovement and featureIndexOverlayOption are not set to true, as expected, but are using the default value instead.

I believe the extension adds and then removes a <map-options> element containing the parameters set in the extension, including feature indexing. If the extension synthesizes a Web page around a MapML / XML resource, it may be that its not pushing the <map-options> into its own page.

Steps to reproduce:

Enable rendering and feature indexing in the mapml-extension

Open an extension-rendered page, like this one

Hit Tab to focus the map.

Expected result:

Feature index is displayed.

Observed result:

The map is focused but no feature index is displayed. If you hit Tab another time, the features of the map are focused, indicating that the feature index has been skipped / missed.

Regardless of the browser locale, the fullscreen text remains "View fullscreen" and "Exit fullscreen". These strings should be included in the extension translations.

Currently the Mozilla's webextension-polyfill is not used but if it's ever reintroduced re-add @babel/core package to package.json.

This polyfill may also not behave as expected with Manifest V3.

add localization to "Zoom To Here".

          > I noticed that when rendering features via the extension (if you put a build of this branch in the extension), you can't visually delete features that are [extension-rendered](https://maps4html.org/experiments/shared/restaurants/restaurants.xml) from the layer-.shadowRoot (within the console) i.e. it doesn't remove the linked \<g\> element when you do that.

I believe the "link" / "connection" between the map-feature element and <g> element is set up properly when the extension renders the map, so the codes should work as our expectation in this process:

I think the issue might be related to the webcomponent-bundle.js file. It seems that when we use the extension to render XML files, it may "clone" the custom elements we defined (layer-, map-feature, etc.) and attach the cloned element to the DOM instead of the ones that we create. If you remove the <layer- > element in the experiment (https://maps4html.org/experiments/shared/restaurants/restaurants.xml), you will notice that the layer is still present, just as we observed with <map-feature>. These "cloned" elements in the DOM do not have accessibility for any properties that we set (e.g. <layer- >._layer):

So even though the links between and feature elements that we created are properly set, they are not "reflected" to the "cloned" elements that we can handle in DOM.

Originally posted by @yhy0217 in Maps4HTML/Web-Map-Custom-Element#801 (comment)

Spec, Polyfill, Documentation and experiments issues

The following property maybe of use: web_accessible_resources in Manifest V3

Another alternative is to append a <script> element to document.head

The render.test.js "Projection from map-meta[content*=projection] attribute / mime type parameter" is currently skipped pending resolution of Maps4HTML/Web-Map-Custom-Element#899

When that's fixed, un-skip the test and make sure it's all good. The feature that this tests is actually not yet supported by the web-map-custom-element.

If you type the URL of an image or video into the URL bar, the browser synthesizes an HTML page into which it injects an <img src="the URL you typed into the URL bar"> or <video src="the URL you typed into the URL bar">.

Although the browser doesn't know about MapML's media type (yet), the extension could implement this behaviour.

We've used a sleight of hand server trick to make this (seem to) work without the help of the extension. For example, this URL will return either a text/html or a text/mapml response, depending on the Accept: header value (content negotiation). In practice, the browser always prefers text/html (it sets that preference in the Accept: header), but the web-map-custom-element always fetches and sends the Accept: text/mapml header.

For services that leverage the "trick", the implementation of this feature in the extension should not make a difference, since the extension won't be overriding any client-side header values.

It should enable the viewing of MapML documents for URLs that always send text/mapml, for example this URL

Default should be false

Currently CI uses NodeJS 12:

See: Maps4HTML/HTML-Map-Element-UseCases-Requirements#256 and
Maps4HTML/Web-Map-Custom-Element#546

We should be able to control this via a maps setting / option. Let's start with a simple option: on or off, and then if we like it we can refine, perhaps by domain.

If there are user preferences anyone feels are needed feel free to discuss about it below.

A mechanism is also needed to allow the stored preferences to be used within the custom elements suite.

One solution is to inject a script the custom element interacts with to set it's internal variables. For this the run_time needs to be set to document_start (this does have performance concerns and isn't preferred).

Another alternative is to use the external messages functionality or the connect function described here. The drawback is that you cannot listen for external communication from any website, i.e. no wildcards option allowed for externally_connectable

Currently requested preferences:

• Button size
• Ability to reduce or turn off pan/zoom animations
• #11

Default (currently, only) blue line shown here: