Intent to prototype: Web Share Target

[mcaceres]

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-mobile/fenix/issues/5783

Standard: https://wicg.github.io/web-share-target/

Platform coverage: Android.

DevTools bug:  https://bugzilla.mozilla.org/show_bug.cgi?id=1586160

Other browsers: "shipped" in Chrome 71 - 
https://www.chromestatus.com/features/5662315307335680.

Web-platform-tests: requires manual tests.

Secure contexts: Yes.

Is this feature enabled by default in sandboxed iframes? No.

If not, is there a proposed sandbox flag to enable it? No.

Link to standards-positions discussion: 
https://github.com/mozilla/standards-positions/issues/176

How stable is the spec: somewhat stable, as it's shipping in Chrome. We hope by 
implementing we will tease out any additional issues and make it stable.

Security & Privacy Concerns: 
https://wicg.github.io/web-share-target/#security-and-privacy-considerations

Web designer / developer use-cases: PWAs may want to receive data from other 
apps, such as sharing a URL to Twitter or sharing an image to Squoosh. Web 
Share Target lets installed PWAs show up as entries in the Android share sheet. 
Eventually this could be extended to other platforms as they add support for 
sharing with websites (and not just native apps, as is currently the case on 
Windows and MacOS). 

Example: Please see 
https://developers.google.com/web/updates/2018/12/web-share-target
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Resolving URLs in c++

[mcaceres]

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()) {
url = context.completeURL(data.url);
}
```

Do we have an equivalent in Gecko? 

Right now, in Gecko, I'm having to do this:

```
  nsAutoString url;
  if (aData.mUrl.WasPassed()) {
auto doc = mWindow->GetExtantDoc();
if (!doc) {
  aRv.Throw(NS_ERROR_UNEXPECTED);
  return nullptr;
}

nsresult rv;
nsCOMPtr resolvedUri;
rv = NS_NewURI(getter_AddRefs(resolvedUri), aData.mUrl.Value(), nullptr,
   doc->GetDocumentURI(), nsContentUtils::GetIOService());
if (NS_WARN_IF(NS_FAILED(rv))) {
  aRv.ThrowTypeError(aData.mUrl.Value());
  return nullptr;
}
nsAutoCString utf8href;
nsresult resolveURLRv = resolvedUri->GetSpec(utf8href);
if (NS_FAILED(resolveURLRv)) {
  aRv.Throw(NS_ERROR_DOM_BAD_URI);
  return nullptr;
}
CopyUTF8toUTF16(utf8href, url);
  }
```

Which could maybe be wrapped into a nice utility function and placed somewhere? 
Or maybe something like that already exists? 

Also, having to use `nsIURI` feels kinda sad when we implement the URL 
Standard Can we use URL  somehow be used as a drop in replacement for 
nsIURI?  

https://github.com/WebKit/webkit/blob/master/Source/WebCore/page/Navigator.cpp#L123
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to experiment: Web Share API

[mcaceres]

> 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 awesome to hear. Will definitely reach out. 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to experiment: Web Share API

[mcaceres]

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 other websites 
that are registered as "Share Targets". Web-based Share Targets are not in 
scope right now - that's a different spec [1].

Bug: 
  DOM side - https://bugzilla.mozilla.org/show_bug.cgi?id=1312422
  Android side - https://bugzilla.mozilla.org/show_bug.cgi?id=1402369

Link to Standards: https://wicg.github.io/web-share/
(This spec is migrating to the W3C's Web Platform WG in the next few weeks).

Platform coverage: Initially, Android (Fenix).
  
Estimated or target release: N/A 

Preference behind which this will be implemented: dom.share

Is this feature enabled by default in sandboxed iframes? no
 
DevTools bug: N/A 

Do other browser engines implement this?: Yes, WebKit, Blink. Shipping in 
Chrome for Android and Safari on both iOS and Desktop.

web-platform-tests:  
https://github.com/web-platform-tests/wpt/tree/master/web-share

Is this feature restricted to secure contexts? Yes


[1] https://wicg.github.io/web-share-target/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Payments Working Group

[mcaceres]

> 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 feedback before TPAC (all of which was addressed, including 
dropping HTTP Payments, which can be addressed by the Fetch API). I’m 
personally supportive of current direction and the reduced work items on which 
the group is focused on. This includes incrementally supporting the whole gamut 
of payment systems: from credit cards, tokenized payments, to crypto 
currencies. 

I’d personally like to see Mozilla continue to support the working group, 
particularly as we continue to open up (and see continued innovation in) the 
payments ecosystems over the next 5-10 years.

Kind regards,
Marcos 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Enabling Pointer Events in Firefox (desktop) Nightly on Mac and Linux

[mcaceres]

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 vendors, which would be difficult to
> > do effectively without some broad agreement that the extra effort spent
> > is worth it.  WHATWG (in HTML at least) mostly treats this by
> > documenting the exposed vectors
> > .
> >  I wonder what the position of the W3C TAG is?
> 
> That's actually a pretty easy question to answer:
> https://www.w3.org/2001/tag/doc/unsanctioned-tracking/
> (Unsanctioned Web Tracking, W3C TAG Finding 17 July 2015)
> 

There is a PR to add privacy in security considerations:
https://github.com/w3c/pointerevents/pull/193

I've pointed one of the Editors to this thread already (hopefully they will 
scoop up what's already been mentioned here and add it as appropriate). 

People should feel free to add more comments to that pull request with their 
concerns. 

Like any open source project, web standards are a community effort and al that 
:)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[mcaceres]

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 a sign that it
> *shouldn't*
> be standardized until those issues are resolved. That's not standards
> fatigue,
> it's the process working as designed.

The API addresses the use cases, but people here see those use cases as too 
basic because they don't represent average users (e.g., Boris' somewhat 
esoteric network setup). Most people have wifi at home, which is somewhat 
unmetered - and access to mobile data, which often costs more (but not always 
true). 

The API, though ".type", allows the user and app to have a conversation about 
that: "you want me to download stuff over mobile? Its might cost ya, but if you 
are ok with it...".
 
> None of this seems to add up to a strong argument that this functionality
> should be in Firefox

Certainly things could be improved - but again, the API just addresses the 
basic use cases (i.e., the 80% case - that gives us parity with native apps). 
The web still can't do most of the things this API is actually needed for 
(e.g., enabling apps like audio books, magazine subscriptions, etc.) so it's 
not too much of a big deal right now that it's not available. 

However, if we do get better native integration in the platform (particularly 
as it relates to multimedia assets), then this will be needed (or people will 
just use Chrome, as it will provide better control over downloads on mobile - 
which will be sad).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[mcaceres]

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.)
> > 
> > Exposing this one bit makes a lot of sense to me.
> > 
> >> From a more practical perspective, we have two shipping implementations
> >> of this API.  What are you proposing to do with that for starters?
> > 
> > After we finish crying?  I think we fundamentally have two options:
> > 
> > 1)  Create a new API, convince everyone to ship it and deprecate the
> > other thing, and eventually hopefully remove it.
> 
> CCing Marcos, as he may have an idea about the practicality of this
> approach.

I don't know tbh...  given that there has been no agreement about this since 
2011 (it's definitely the most controversial API I've ever been involved with - 
and I only got involved when we moved it to the WICG). We can definitely try to 
improve the current one - and learn from what Google shipped (by talking to 
them and see if we can find out a bit more about who is using it and how). I 
think Facebook was using it to not load video for ads when the connection is 
2G, for example. 

If other people want to have a go at trying to come up with something sensible, 
then by all means they can try... but be warned... it's a political s***show 
for something that has such clear use case on mobile.
 
> > 2)  Figure out a way to map the one bit of information we actually want
> > to expose into some sort of values that look like the existing API.
> > Change the spec as needed to allow tweaks we want to make here (e.g. to
> > allow having the max speed thing not be defined or always be 0 or always
> > +Infinity, or always NaN, or always 42 or something).
> 
> This would be interesting to think about...

I'm all ears... I'm sure Ilya would be super open to that too on the Chrome 
side.  
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[mcaceres]

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
> allow the user to override the information the browser receives from the
> OS about your network connection.

Agree... and that's the footgun of the API.
 
> As things stand now, neither of the above are true to the best of my
> knowledge.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[mcaceres]

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 have
> > nothing, so might think about other ways to find out what you want to know.
> > This way you think you know something but you don't.
> 
> Agreed with Boris. "more information than nothing" is not an absolute
> value, when that information is deceiving, which as others have
> pointed out in this thread, is quite likely to occur with non-trivial
> frequency in common uses of this API (the "if bandwidth>x then slow
> download" example proves this point).
> 
> E.g. a high % of the time, (most of the time when I'm not at home or
> work), I am on a 4G (high bandwidth) mifi (metered cost).
> 
> This API would report misleading results for me 100% of the time I am
> on my mifi, and for anyone else on a 4G mifi.

But you know you are on a mifi as a user: you bought the mifi, you paid for the 
mifi's contract, you connected to the mifi. Same with hotel wifi, etc. which 
may be metered. 

The point of the API is to allow the end-user and the application to negotiate 
when it's best to perform a download (not to make decisions about what is best 
and what is going to cost money). There is nothing preventing an app from 
asking the user what network type would be best to perform synchronization 
over. 

The general assumption that WIFI is cheap and 3G/4G may be sometimes wrong, but 
it holds for most users. 

> Real experience, all (AFAIK) the "sync to cloud automatically" code
> out there makes this mistake, e.g. iCloud, DropBox etc., so I've had
> to turn all of it off or just not use it.

Sure, but that goes back to Ehsan's point about perfect information: we can't 
currently get that until we get better WIFI standards or whatever. Until then, 
your mifi will look like WIFI - but that's not the APIs fault.  

Again, see the use cases document. 
 
> Let's learn from the error of "native" implementations/uses of this
> kind of API / use thereof and not repeat that mistake on web,
> certainly not ship an API that misleads web developers into doing the
> wrong thing.

The use cases document shows that native apps get this right a lot of the time. 

We are weighting the iCloud/DropBox problem against all the app examples given 
in the document. Right now, sites use a bunch of hacks to figure out if you are 
on a metered connection or not (see BBC example in the document). 

> >> Bluetooth networking is also a thing.
> >
> >
> > That's a good point.
> >
> >> I think being able to distinguish this stuff provides some value even if
> >> its not perfect for all cases.  And I don't see how it causes any harm.
> >
> >
> > I think it causes harm to give people information they have no business
> > having ("wifi" vs "ethernet") and it does harm to given them information
> > that's likely to be bogus (the last hop speed in the wifi/ethernet cases).
> 
> Precisely. Obvious harms:
> 
> 1. Privacy compromise without obvious user benefit
> 2. Causes web apps to waste user bandwidth/financial resources
> 
> If the response to that is "but doing it right is too hard", then
> don't do it all.
> 
> > Maybe the answer is that we should just reconsider the set of types that
> > gets exposed and how they get mapped to connection speeds
> 
> I'm not sure that would sufficiently address harm 2.
> 
> As far as I can tell, the only useful bit of information (as bz
> pointed out) is the
> 
> Am I on a cell data connection "for sure or maybe not"?
> a) Where cell data "for sure" -> will *almost certainly cost the user*
> b) Whereas "or maybe not" -> you have no idea whether it will cost the
> user or not, do not make any assumptions.
> 
> Given that the one pseudo-code example provided earlier in this thread
> makes the mistake of using case (b) to errantly initiate bandwidth/$
> wasting downloads (which may not even be necessary), I think this API
> has not been well thought through in terms of actual user benefit, and
> needs further incubation.

Yeah, that's why it's currently in the WICG. 

> Not to mention we shouldn't even be getting to an "Intent to *ship*"
> on something we expect to standardize that hasn't even been published
> as a FPWD yet (which only *starts* the count-down clock to IPR
> commitment).

It was originally part of DAP, so it's actually gone through years of 
publication (first published in mid 2011):
https://www.w3.org/TR/2011/WD-netinfo-api-20110607/

All the arguments presented here also got raised by the WG, which made it go 
nowhere... so we took it to the WICG for further incubation - because Google 
shipped it, and thus we were hoping for buy in from some other browser vendor.  

> Implementing behind a flag should be good enough for prototyping
> purposes to advocate for moving this from WICG to WPWG, and if 

Intent to implement: Payment Request API

[mcaceres]

## 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 a wallet Firefox will manage… The Firefox folks will have UI mockups and 
further details about the wallet (and security aspects), as it's outside the 
scope of the Platform work (but we are working together on it as a team).

At time of writing, the interface are limited to the following methods and 
event handlers. However, this is subject to change as the spec is still 
evolving (there are also attributes, but I’ve omitted them as they mostly 
reflect what goes into the constructor). New methods/attributes/events will be 
sent with a new intent to implement:

### interface `PaymentRequest`
How a developer requests payment.

   - promise show() - request show payment panel. 
   - promise abort() - request close payment panel, aborting the payment. 
   - promise canMakeActivePayment()* - not in spec, proposed by Google.
   - Events (see PaymentRequestUpdateEvent): 
   - onshippingaddresschange
   - onshippingoptionchange

For discussion around canMakeActivePayment(), please see: 
https://github.com/w3c/browser-payment-api/pull/316
  
### interface `PaymentResponse` 
The resulting response from the end-user. 

  - promise complete() - let’s you know when the flow is done.  

### interface `PaymentRequestUpdateEvent` 
  - updateWith(Promise d) - request an update be made to the 
payment panel with new payment details. 

### interface `PaymentAddress`
A serializable object that represents a physical address in the real world… 
trying to get this changed to a dictionary, as it's just a bunch of DOM 
Strings, and an array. 

### Extension to IFRAMEs 
The API also extends the `HTMLIframeElement` interface by adding a new 
attribute:

  * allowPaymentRequest - defaults to false. Similar in behavior to 
`.allowFullScreen`. 

## Bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1318984

## Link to standard
https://w3c.github.io/browser-payment-api/

## Platform coverage
Desktop first, Android later.

## Estimated or target release:
Sometime in 2017 - not sure yet.  

## Preference behind which this will be implemented: 
dom.payments.enabled

## DevTools bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1318994

## Do other browser engines implement this? 

### Shipped
Chrome for Android release 53.
Blink-dev intent to ship: 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/p1DYoxHlkKg
https://www.chromestatus.com/feature/5639348045217792

### Considering
According to Microsoft’s Platform Status, the feature is “in development” in 
Edge. 
https://developer.microsoft.com/en-us/microsoft-edge/platform/status/webpaymentsapi/?q=payments

## Tests
Initial tests have been taken from Chrome’s implementation. However, these have 
not yet been verified by us, nor merged into the the web platform tests. We 
intend for those to be merged, and for us to contribute additional tests there. 
  
 https://github.com/w3c/web-platform-tests/pull/3441

Kind regards,
Marcos
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform