Re: Intent to implement: File system provider API

[Kershaw Chang]

Hi All,

It seems there is no strong objection to this API, so we would like to
start the implementation.
If you have any further question, please leave your comment on *Bug 1187223*
.

Thanks.


On Wed, Jul 29, 2015 at 12:39 AM, Jonas Sicking  wrote:

> On Tue, Jul 28, 2015 at 7:52 AM, Jesper Kristensen
>  wrote:
> > Den 28-07-2015 kl. 02:05 skrev Jonas Sicking:
> >>
> >> I don't think registerProtocolHandler has nearly enough API surface to
> >> support what's needed here. But if you mean copying the idea that
> >> there's a function call which displays a UI prompt which allows the
> >> user to accept/deny then that could work.
> >
> > I don't think anyone should try to copy the registration UX of
> > registerProtocolHandler (or Web Intents or Web Activities). None of these
> > technologies have gained any popularity, and I suspect that may be
> because
> > the registration UX is bad. It prompts the user about something technical
> > the user may not understand at a time the user don't need it.
>
> WebActivities doesn't really have a registration UI. But it depends on
> installation, and it is FirefoxOS specific. Both of which is likely
> big reasons that it hasn't seen much pickup.
>
> / Jonas
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: File system provider API

[Kershaw Chang]

The motivation behind this is to let Firefox OS has the ability to access
files on cloud storage. With file system provider API, we can allow device
storage API to read/write files on cloud storage seamlessly. From user's
point of view, I think it would be better to use our current
music/video/gallery apps to acces user's files on cloud, but not other apps.


On Mon, Jul 27, 2015 at 8:00 PM, Ted Mielczarek  wrote:

> On Fri, Jul 24, 2015, at 04:13 AM, Kershaw Chang wrote:
> > Link to standard:
> > No formal specifications found on w3c. This API is only supported by
> > Chrome
> > OS now.
>
> What's the motivation here? Do we expect this to get used by apps if
> it's Chrome OS only right now? I've been looking into this problem space
> (cloud storage for use by webapps) and the neatest thing I've run into
> so far is https://remotestorage.io/ . That has the benefit of being
> entirely content-side right now, which seems like a smart way to start
> out. Extending something like that with browser hooks to make it better
> seems like a smarter play than copying Chrome privileged APIs.
>
> -Ted
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: File system provider API

[Kershaw Chang]

Since the addon model on Firefox OS is not implemented now, I still use the
old term "apps" in previous mail.
I also think it makes much more sense to make this API to be only available
for addons.
In addition, do we have a way to let an API only be used by addons now?

Thanks.

On Sat, Jul 25, 2015 at 12:43 AM, Jonas Sicking  wrote:

> On Fri, Jul 24, 2015 at 3:49 AM, David Rajchenbach-Teller
>  wrote:
> > On 24/07/15 11:38, Jonas Sicking wrote:
> >> I think we should allow addons to implement something like this. But I
> >> don't think it's something that we should let apps do.
> >>
> >> / Jonas
> >
> > So Dropbox, Cozy Cloud, etc. should be add-ons instead of apps?
>
> Yes. For FirefoxOS we're working on getting rid of installation for
> "apps". Instead apps will be treated just like other web content that
> you simply browse to.
>
> In this model it doesn't make as much sense for apps to be changing
> the behavior of the user agent. Why would navigating to Dropbox and
> then navigating away from it suddenly change the behavior of your OS?
> How do you revert it?
>
> Instead we're going to use addons as the way that you customize your
> device.
>
> / Jonas
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: File system provider API

[Kershaw Chang]

Hi all,

Summary:
File system provider API [1] is now supported by Google. This API allows
developers to create apps that support virtual file systems and make files
stored on these to be available by Device Storage API.

Use case:
One of the use cases is to let Firefox OS have the ability to access cloud
storage. With this API, users who install the app can have the cloud
storage seamlessly integrated into Firefox OS. Accessing files on cloud
becomes as easy as accessing locally.

Idea of implementation:
The idl should be very similar to Google's [2]. We plan to have this
available to certified apps only. This will be released to privileged app
until we think the implementation is mature enough.

Link to standard:
No formal specifications found on w3c. This API is only supported by Chrome
OS now.

Platform coverage:
Firefox OS only.

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

Estimated or target release:
We are looking to have this completed by Dec. 2015.

[1] https://developer.chrome.com/apps/fileSystemProvider
[2]
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/common/extensions/api/file_system_provider.idl

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

Re: Intent to implement: Touchpad event

[Kershaw Chang]

Hi Jonas,

That’s a good point.
I agree with you that we should only expose this to certified or
privileged apps.

Thanks and regards,
Kershaw

於 2014/9/12 上午1:22，"Jonas Sicking"  寫道:

>Hi Kershaw,
>
>Has there been any discussions with other browser vendors about this
>API? Or is there an official standard somewhere for them?
>
>If not, I don't think that we'll want to expose this to the web at
>large. It would still be fine to expose to certified apps, or even to
>expose to privileged apps under a permission.
>
>Does this sound ok?
>
>/ Jonas
>
>On Wed, Sep 10, 2014 at 11:18 PM, Kershaw Chang 
>wrote:
>> Hi All,
>>
>> Summary:
>> Touchpad(trackpad) is a common feature on laptop computers. Currently,
>>the
>> finger activities on touchpad are translated to touch event and mouse
>>event.
>> However, the coordinates of touch event and mouse event are actually
>> associated to display [1]. For some cases, we need to expose the
>>absolute
>> coordinates that are associated to touchpad itself to the application.
>> That's why AOSP also defines another input source type for touchpad
>>[2]. The
>> x and y coordinates of touchpad event are relative to the size of
>>touchpad.
>>
>> Use case:
>> Handwriting recognition application will be benefited from this touchpad
>> event. Currently, OS X supports handwriting input by touchpad [3].
>>
>> Idea of implementation:
>> The webidl of touchpad event is like touch event except that x and y
>> coordinates are relative to touchpad rather than display.
>>
>> --- /dev/null
>> +++ b/dom/webidl/Touchpad.webidl
>> +
>> +[Func="mozilla::dom::Touchpad::PrefEnabled"]
>> +interface Touchpad {
>> +  readonlyattribute long identifier;
>> +  readonlyattribute EventTarget? target;
>> +  readonlyattribute long touchpadX;
>> +  readonlyattribute long touchpadY;
>> +  readonlyattribute long radiusX;
>> +  readonlyattribute long radiusY;
>> +  readonlyattribute floatrotationAngle;
>> +  readonlyattribute floatforce;
>> +};
>>
>> --- /dev/null
>> +++ b/dom/webidl/TouchpadEvent.webidl
>> +
>> +interface WindowProxy;
>> +
>> +[Func="mozilla::dom::TouchpadEvent::PrefEnabled"]
>> +interface TouchPadEvent : UIEvent {
>> +  readonly attribute TouchpadList touches;
>> +  readonly attribute TouchpadList targetTouches;
>> +  readonly attribute TouchpadList changedTouches;
>> +
>> +  readonly attribute short   button;
>> +  readonly attribute boolean altKey;
>> +  readonly attribute boolean metaKey;
>> +  readonly attribute boolean ctrlKey;
>> +  readonly attribute boolean shiftKey;
>> +
>> +  [Throws]
>> +  void initTouchpadEvent(DOMString type,
>> + boolean canBubble,
>> + boolean cancelable,
>> + WindowProxy? view,
>> + long detail,
>> + short button,
>> + boolean ctrlKey,
>> + boolean altKey,
>> + boolean shiftKey,
>> + boolean metaKey,
>> + TouchPadList? touches,
>> + TouchPadList? targetTouches,
>> + TouchPadList? changedTouches);
>> +};
>>
>> --- /dev/null
>> +++ b/dom/webidl/TouchpadList.webidl
>> +
>> +[Func="mozilla::dom::TouchpadList::PrefEnabled"]
>> +interface TouchpadList {
>> +  [Pure]
>> +  readonly attribute unsigned long length;
>> +  getter Touchpad? item(unsigned long index);
>> +};
>> +
>> +/* Mozilla extension. */
>> +partial interface TouchpadList {
>> +  Touchpad? identifiedTouch(long identifier);
>> +};
>>
>> Platform converge: all
>>
>> Welcome for any suggestion or feedback.
>> Thanks.
>>
>> [1]
>> 
>>http://developer.android.com/reference/android/view/InputDevice.html#SOUR
>>CE_
>> CLASS_POINTER
>> [2]
>> 
>>http://developer.android.com/reference/android/view/InputDevice.html#SOUR
>>CE_
>> CLASS_POSITION
>> [3] http://support.apple.com/kb/HT4288
>>
>> Best regards,
>> Kershaw
>>
>>
>> ___
>> dev-webapi mailing list
>> dev-web...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-webapi


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

Re: Intent to implement: Touchpad event

[Kershaw Chang]

Hi Mounir,

The finger activity on touchpad can be still translated to touch event and
mouse event as usual. But for the application that wants to know the
absolute finger position on touchpad, we will need this new touchpad event.
So, this proposal is about creating new standard rather than re-using.

Best regards,
Kershaw

於 2014/9/11 下午6:49，"Mounir Lamouri"  寫道:

>On Thu, 11 Sep 2014, at 18:26, Ms2ger wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>> 
>> On 09/11/2014 08:18 AM, Kershaw Chang wrote:
>> 
>> First of all, you neglected to explain the standardization situation
>> here. Is this feature being standardized? If not, why not? How do
>> other browser vendors feel about it?
>
>Where does this stand in the current Touch Events vs Pointer Events
>situation, is the intent to re-use of those or create yet another
>standard?
>
>-- Mounir
>___
>dev-platform mailing list
>dev-platform@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-platform


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

Re: Intent to implement: Touchpad event

[Kershaw Chang]

Hi Ms2ger,

Please see my response below.

Thanks and regards,
Kershaw

於 2014/9/11 下午4:26，"Ms2ger"  寫道:

>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>On 09/11/2014 08:18 AM, Kershaw Chang wrote:
>
>First of all, you neglected to explain the standardization situation
>here. Is this feature being standardized? If not, why not? How do
>other browser vendors feel about it?
Sorry that I missed the standardization part.
I think this feature is not standardized, since I cannot find any
discussion or draft from w3c or whatwg. The most closed is that Google
defines one input source type for touchpad in AOSP.

In most cases, I think the inputs from touchpad can be translated to touch
event or mouse event. Only few applications need the raw data from
touchpad. That’s why we don’t see others discussing about this.


>
>> +interface TouchPadEvent : UIEvent { +  [Throws] +  void
>> initTouchpadEvent(DOMString type, + boolean
>> canBubble, + boolean cancelable, +
>> WindowProxy? view, + long detail, +
>> short button, + boolean ctrlKey, +
>> boolean altKey, + boolean shiftKey, +
>> boolean metaKey, + TouchPadList? touches, +
>> TouchPadList? targetTouches, +
>> TouchPadList? changedTouches);
>
>Regardless of whether this feature is something we'd want to
>implement, we most definitely shouldn't introduce new init*Event methods.
Thanks for this suggestion. Actually, this webidl is copied from touch
event. I don’t quite understand about this. Could you please explain more?

>
>Ms2ger
>-BEGIN PGP SIGNATURE-
>
>iQEcBAEBAgAGBQJUEVzEAAoJEOXgvIL+s8n2YWYH/i9h3e3GvQ9dPrYYg72F/mdD
>BXdyHiyKarz4dSI8H0UJHwDhCtBKi92AskHhCeT3l4KX4h7pX87144LYNYiZ9qzv
>rMXDFvf5Oo8M4uaEPo82z1M2OW6jADuFCfs4SeK+1aqW5DLRRMlYiGfop4yeGp+g
>m81ciytaLr08ro6+K+HgIP/zCo5KLtvp54kGLRg0EMqWnNE4SxG8Nrvm/xe65udz
>+3z21DhapAu8jMFhJ2JeAy+0ivu0pnCm0JUXiLmOCmzweSlO1w3Qr5KGwWqS9qjA
>6k74T7+Pp95cFgELK03IvhWyQCHNLhPdH/qJex59jF2i7N9SV47FGMOq8wjLFBU=
>=UeuN
>-END PGP SIGNATURE-
>___
>dev-platform mailing list
>dev-platform@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-platform


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

Intent to implement: Touchpad event

[Kershaw Chang]

Hi All,

Summary:
Touchpad(trackpad) is a common feature on laptop computers. Currently, the
finger activities on touchpad are translated to touch event and mouse event.
However, the coordinates of touch event and mouse event are actually
associated to display [1]. For some cases, we need to expose the absolute
coordinates that are associated to touchpad itself to the application.
That’s why AOSP also defines another input source type for touchpad [2]. The
x and y coordinates of touchpad event are relative to the size of touchpad.

Use case:
Handwriting recognition application will be benefited from this touchpad
event. Currently, OS X supports handwriting input by touchpad [3].

Idea of implementation:
The webidl of touchpad event is like touch event except that x and y
coordinates are relative to touchpad rather than display.

--- /dev/null
+++ b/dom/webidl/Touchpad.webidl
+
+[Func="mozilla::dom::Touchpad::PrefEnabled"]
+interface Touchpad {
+  readonlyattribute long identifier;
+  readonlyattribute EventTarget? target;
+  readonlyattribute long touchpadX;
+  readonlyattribute long touchpadY;
+  readonlyattribute long radiusX;
+  readonlyattribute long radiusY;
+  readonlyattribute floatrotationAngle;
+  readonlyattribute floatforce;
+};

--- /dev/null
+++ b/dom/webidl/TouchpadEvent.webidl
+
+interface WindowProxy;
+
+[Func="mozilla::dom::TouchpadEvent::PrefEnabled"]
+interface TouchPadEvent : UIEvent {
+  readonly attribute TouchpadList touches;
+  readonly attribute TouchpadList targetTouches;
+  readonly attribute TouchpadList changedTouches;
+
+  readonly attribute short   button;
+  readonly attribute boolean altKey;
+  readonly attribute boolean metaKey;
+  readonly attribute boolean ctrlKey;
+  readonly attribute boolean shiftKey;
+
+  [Throws]
+  void initTouchpadEvent(DOMString type,
+ boolean canBubble,
+ boolean cancelable,
+ WindowProxy? view,
+ long detail,
+ short button,
+ boolean ctrlKey,
+ boolean altKey,
+ boolean shiftKey,
+ boolean metaKey,
+ TouchPadList? touches,
+ TouchPadList? targetTouches,
+ TouchPadList? changedTouches);
+};

--- /dev/null
+++ b/dom/webidl/TouchpadList.webidl
+
+[Func="mozilla::dom::TouchpadList::PrefEnabled"]
+interface TouchpadList {
+  [Pure]
+  readonly attribute unsigned long length;
+  getter Touchpad? item(unsigned long index);
+};
+
+/* Mozilla extension. */
+partial interface TouchpadList {
+  Touchpad? identifiedTouch(long identifier);
+};

Platform converge: all

Welcome for any suggestion or feedback.
Thanks.

[1] 
http://developer.android.com/reference/android/view/InputDevice.html#SOURCE_
CLASS_POINTER
[2] 
http://developer.android.com/reference/android/view/InputDevice.html#SOURCE_
CLASS_POSITION
[3] http://support.apple.com/kb/HT4288

Best regards,
Kershaw


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