Browser: Media Page

[cookiengineer]

The stealth:media page needs to be implemented.

The idea behind the separate media page is that it includes a Media card with full width and height, and it allows to display image, audio and video files with a given specific URL. That means it must have support for stealth:media?url= parameter, and reuse what the ENVIRONMENT.flags.url object.

• [x] Implement the browser-widget-image widget, which accepts a {source} parameter.
• [x] Implement the browser-widget-audio widget, which accepts a {source} parameter.
• [x] Implement the browser-card-video widget, which accepts a {source} parameter.
• [x] If the URL is of type image, display a <img> element.
• [x] If the URL is of type audio, display an <audio> element.
• [x] If the URL is of type video, display a <video> element.

Currently, it is unsure whether it's possible to support the srcset attributes that are only available for <picture> elements, because it would be nice to have the same API for audio/video elements, too, in order to be able to download video streams based on the configured connection bandwidth in the Browser settings.

Simply using a <source media="..."> attribute here won't do the trick, as Blink has removed support for it while Gecko kept its support for it. [1]

[1] http://thenewcode.com/820/Make-HTML5-Video-Adaptive-With-Inline-Media-Queries

[cookiengineer]

After a long day of implementation prototypes, there are a couple of issues using the <source>'s srcset and src attributes, because apparently, at least in Chromium there's a different parsing mechanism for the URL in place.

If there's a <source src="http://what.ever.tld:123/stealth/https://foo.bar/image.png"> URL being used, the second occurance of https:// will get stripped down to a https:/, which does NOT happen the same way in <a href>, <img src> and neither with <audio src> or <video src>.

So, apparently, the URL parser for source elements seems to be using a different parsing mechanism than the other src attributes. As of now, it's unclear whether this is an upstream Chromium bug, or an expected behaviour. There's not a single specification that explicitely describes the URL parsing mechanism; and all HTTP/s proxies out there rely on the possibility of using an https:// somewhere in the path, so I guess Chromium might be broken here.

[cookiengineer]

Additionally, the stealth:media Page needs a browser-widget-Media element which shows a URL input field that changes the content once submitted.

[cookiengineer]

As of https://github.com/tholian-network/stealth/commit/f90256bc557dd52b41bf55fcbc2ac32d22e94107 this has been implemented.