Closed cookiengineer closed 3 years ago
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.
Additionally, the stealth:media
Page needs a browser-widget-Media
element which shows a URL input field that changes the content once submitted.
As of https://github.com/tholian-network/stealth/commit/f90256bc557dd52b41bf55fcbc2ac32d22e94107 this has been implemented.
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 displayimage
,audio
andvideo
files with a given specific URL. That means it must have support forstealth:media?url=
parameter, and reuse what theENVIRONMENT.flags.url
object.browser-widget-image
widget, which accepts a{source}
parameter.browser-widget-audio
widget, which accepts a{source}
parameter.browser-card-video
widget, which accepts a{source}
parameter.type
image
, display a<img>
element.type
audio
, display an<audio>
element.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, asBlink
has removed support for it whileGecko
kept its support for it. [1][1] http://thenewcode.com/820/Make-HTML5-Video-Adaptive-With-Inline-Media-Queries