Summary: An API that allows websites to declare themselves as web share
targets, which can receive shared content from either the Web Share API, or
system events (e.g., shares from native apps).
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1476515
Fenix bug: https://github.com/mozilla-mobil
Was looking at how WebKit implements the WebShare API, and they have this nice
method `completeURL(str)` [1] that resolved URLs relative to, I guess, the
`Document` object (or whatever context is). So they can basically do this c++:
```
Optional url;
if (!data.url.isEmpty()) {
u
> On 1 Jul 2019, at 20:02, Michael de Boer wrote:
>
> Dale Harvey implemented native share functionality on Desktop before, which
> you can access through the meatball menu, inside the urlbar.
> So if you’d like to go for parity across platforms, please feel free to reach
> out.
That’s aweso
Summary: Experiment with Web Share API to figure out if the current spec is
implementable in Gecko/GeckoView. The specification defines an API for sharing
text, links and other content to an arbitrary destination of the user's choice.
The available share targets are either OS specific, or can be
> On Jan 9, 2018, at 4:29 AM, L. David Baron wrote:
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it. (Given our involvement, we should almost
> certainly say something.)
Fyi, I sent
On Thursday, April 6, 2017 at 2:57:52 PM UTC+10, David Baron wrote:
> On Thursday 2017-04-06 00:33 -0400, Ehsan Akhgari wrote:
> > In general, I should also say that designing features with
> > fingerprinting in mind is *extremely* difficult and takes a lot of
> > effort on the part of all browser
On Wednesday, December 21, 2016 at 12:51:10 AM UTC+11, Eric Rescorla wrote:
> I'm not really following this argument. Usually when a document has been
> floating
> around a long time but clearly has basic design issues and can't get
> consensus,
> even when a major vendor has implemented it, that's
On Saturday, December 17, 2016 at 3:38:45 AM UTC+11, Ehsan Akhgari wrote:
> On 2016-12-15 6:28 PM, Boris Zbarsky wrote:
> > On 12/15/16 6:15 PM, Ehsan Akhgari wrote:
> >> (I personally agree with most of what you said, except that I'm
> >> convinced that we should expose that one bit.)
> >
> > Exp
On Tuesday, December 20, 2016 at 3:48:10 AM UTC+11, Ehsan Akhgari wrote:
> The only potential for user control through this API is if a noticeable
> portion of websites used this API to decide whether to give the users a
> "low-res" version, and for the browser to provide some kind of a UI to
> all
On Friday, December 16, 2016 at 8:33:48 AM UTC+11, Tantek Çelik wrote:
> On Thu, Dec 15, 2016 at 11:51 AM, Boris Zbarsky <> wrote:
> > On 12/15/16 12:20 PM, Ben Kelly wrote:
> >>
> >> Its more information than nothing.
> >
> >
> > I'm not sure it is. At least when you have nothing you _know_ you h
## Summary
The Payment Request API allows web sites selling goods and services to utilize
one or more payment methods through the browser. The browser then facilitates
the payment flow between merchant and user.
Initial implementation is going to be limited to “basic card” payments, based
on
11 matches
Mail list logo
