Status

()

Core
DOM
6 years ago
5 days ago

People

(Reporter: gal, Unassigned)

Tracking

(Depends on: 24 bugs, {meta})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

6 years ago
Tracker bug for new WebAPIs
(Reporter)

Updated

6 years ago
Depends on: 673922
(Reporter)

Updated

6 years ago
Depends on: 673917
Keywords: meta
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → Trunk
Depends on: 674062
Depends on: 674066
Depends on: 594543
Depends on: 674080
Depends on: 391286
Depends on: 650295, 525444
Depends on: 451674
Depends on: 665909
Depends on: 545812
Depends on: 674693
Depends on: 674701
Depends on: 674718
Depends on: 674720
Depends on: 674725
Depends on: 674726
Depends on: 674728
Depends on: 674734
Depends on: 674737
Depends on: 674739
Depends on: 674741
Depends on: 664147

Updated

6 years ago
Depends on: 649154
Depends on: 604039
Chris, bug 594543 is about Desktop Notifications for Firefox Desktop. According to bug 573588 and bug 595094, this is already implemented for Firefox Mobile. Is this bug really depending on the implementation on Desktop?
I just want to track it to completion.  It's a capability we sorely need on desktop too.

Updated

6 years ago
Depends on: 633602
WAC (http://www.wacapps.net/specifications) has done some work that's relevant here.  Looks like they based their work on W3C WIPs and extended them.
Depends on: 677166

Comment 4

6 years ago
WAC's APIs aren't Web-compatible, I wouldn't spend much time looking there for this specific project. There might however be value in getting resources from them as B2G is IMHO far closer to what WAC's goal should have been than what they've actually produced to date.
What do you mean by "Web-compatible"?  I'm not sure and I would like to know :).
Alias: webapi
Depends on: 677937
No longer depends on: 677937
Depends on: 677989
(Reporter)

Comment 6

6 years ago
bug 649154 doesn't seem like a strict dependency here

Comment 7

6 years ago
(In reply to Andreas Gal :gal from comment #6)
> bug 649154 doesn't seem like a strict dependency here

That particular bug is for implementing the DOMCrypt API in a "moz" prefixed window property. The current draft of the spec from there only references Mozilla bug 649154 and bug 657432 as well as WebKit bug 62010. Bug 649154 is where all the current work seems to be, but should a new bug be filed for the final Javascript Cryptography API then that bug would be a better fit here.
(Reporter)

Updated

6 years ago
Depends on: 678694
(Reporter)

Updated

6 years ago
Depends on: 678695
Depends on: 679966
Depends on: 680289

Updated

6 years ago
Depends on: 680617
Depends on: 681009

Comment 8

6 years ago
(In reply to Chris Jones [:cjones] [:warhammer] from comment #5)
> What do you mean by "Web-compatible"?  I'm not sure and I would like to know
> :).

[Sorry for not replying earlier, I've been on vacation.]

Web-compatible can mean many things and a full definition would be rather long. (In previous discussions on this topic it has been suggested that one should write one such Characterization of the Open Web. Known as the COW document, it is largely believed to be mythical.) I'll therefore stick to the issues that I see with WAC's current specifications.

First, they often fail to integrate with existing Web APIs. For instance they have a File interface which is not the W3C File API and is unlikely to be compatible with it. Interfaces they define that accept files will therefore not accept W3C File objects, and conversely operations that accept W3C File objects will not take WAC files. There are often reasons for such overlaps, usually because the W3C (or other) version of the same functionality is not finalised and a large part of WAC's original goal being to ship an application runtime based on Web technology quickly, at the risk of being dirty. Nevertheless, it doesn't make for a great starting point in general (though ideas can naturally be cherry-picked here and there — smart people have put effort into several of these APIs).

Second, and IMHO far more problematic, is the fact that WAC's APIs have not at all been defined with a Web security model in mind. The assumption is that there is a policy mechanism of some form that selectively enables/forbids specific interfaces or methods for a given application. This may seem minor — why not just front usage of such APIs with some kind of prompt as is done with Geolocation? — but in practice it has deeper implications. You don't want to put something like unfettered file system access behind a simple Geolocation-like prompt and providing specific, subsetted, and properly protected access to privileged device functionality will often require different API designs than if you assume full access in the design followed by some policy-based sieving.

Beyond that one could also mention stylistic issues (which people often refer to as "APIs that look like Java) but I think those can generally be fixed rather easily, and aren't as important.

I believe however that it would be useful to engage WAC one way or another. They have developers, domain experts, testers, real-world use cases, a desire to see Open Web technology power applications, and a number of other things that could open the door to useful cooperation. I just meant to caution about jumping into using WAC APIs as a starting point.

PS: Full disclosure: I've done paid contracting work for WAC in the past and might again. Not that this affects my point of view or that I've been any less candid with them about the approaches I think work best.
(In reply to Robin Berjon from comment #8)

> 
> Web-compatible can mean many things and a full definition would be rather
> long. (In previous discussions on this topic it has been suggested that one
> should write one such Characterization of the Open Web. Known as the COW
> document, it is largely believed to be mythical.) I'll therefore stick to
> the issues that I see with WAC's current specifications.
> 
> First, they often fail to integrate with existing Web APIs. For instance
> they have a File interface which is not the W3C File API and is unlikely to
> be compatible with it. Interfaces they define that accept files will
> therefore not accept W3C File objects, and conversely operations that accept
> W3C File objects will not take WAC files. There are often reasons for such
> overlaps, usually because the W3C (or other) version of the same
> functionality is not finalised and a large part of WAC's original goal being
> to ship an application runtime based on Web technology quickly, at the risk
> of being dirty. Nevertheless, it doesn't make for a great starting point in
> general (though ideas can naturally be cherry-picked here and there — smart
> people have put effort into several of these APIs).
> 

Agree that some of the WAC APIs are now superseded by other W3C APIs, e.g. Accelerometer, Orientation and File system come to my mind at a glance. However some of them may be still a good starting point, if not for the final API itself, at least for the use cases that those APIs enable. We (Telefónica) have already developed applications that enable the use cases listed in the WebAPI Wiki on top of a WAC implementation, and the only couple of functionalities we missed in the WAC APIs were a telephony API and another API for managing device settings. 

> Second, and IMHO far more problematic, is the fact that WAC's APIs have not
> at all been defined with a Web security model in mind. The assumption is
> that there is a policy mechanism of some form that selectively
> enables/forbids specific interfaces or methods for a given application. This
> may seem minor — why not just front usage of such APIs with some kind of
> prompt as is done with Geolocation? — but in practice it has deeper
> implications. You don't want to put something like unfettered file system
> access behind a simple Geolocation-like prompt and providing specific,
> subsetted, and properly protected access to privileged device functionality
> will often require different API designs than if you assume full access in
> the design followed by some policy-based sieving.
> 

Yeah, WAC has that policy-based security model, but from my point of view, the APIs are very decouple from the security model. Furthermore, our implementation of the use cases is running on top a WAC 2.0 solution and it works smoothly (with no impact from the security model).

> Beyond that one could also mention stylistic issues (which people often
> refer to as "APIs that look like Java) but I think those can generally be
> fixed rather easily, and aren't as important.
> 
> I believe however that it would be useful to engage WAC one way or another.
> They have developers, domain experts, testers, real-world use cases, a
> desire to see Open Web technology power applications, and a number of other
> things that could open the door to useful cooperation. I just meant to
> caution about jumping into using WAC APIs as a starting point.

I think those are fair statements, and more precise than "WAC's APIs aren't Web-compatible" :) , however, I would say that if there are no equivalent APIs out there for a functionality, it would not harm to have a look at what WAC did. 

> 
> PS: Full disclosure: I've done paid contracting work for WAC in the past and
> might again. Not that this affects my point of view or that I've been any
> less candid with them about the approaches I think work best.

PS: Full disclosure also on my side: I have been also involved in WAC specifications (and working together with Robin in some of them).

Updated

6 years ago
Depends on: 681455

Comment 10

6 years ago
I would like the suggest that proper management of local storage permissions become part of this specification. Storage quotas / limits, in particular, are abysmally inflexible and non-standard, as per: 
http://dev-test.nemikor.com/web-storage/support-test/

I have filed a separate bug for the storage quota requests here:
https://bugzilla.mozilla.org/show_bug.cgi?id=681545
which is somewhat related to:
https://bugzilla.mozilla.org/show_bug.cgi?id=658117

There is an interesting storage-related issue being tracked against Chromium (Google Chrome) here:
http://code.google.com/p/chromium/issues/detail?id=61676
It deals with unifying the storage quotas so that all persistent mechanisms (webSQL, IndexedDB, localStorage) share a single quota, and all temporary mechanisms (sessionStorage, etc) share a single quota. This approach might be worth evaluating.
An issue we've discussed but apparently not documented anywhere is that it's possible that the only sane security model for hyper-abusable APIs like telephony or SMS is a URL whitelist, prepopulated by a trusted party like a device vendor (and editable by the user, if they jump through the right hoops).  Rob suggests it could be worth clearly separating APIs intended for the "whitelisted Web" and those for all of it, back alleys and dark corners included.
Gerv Markham posted some thoughts on using EV certificates as the basis for other mechanisms to grant permissions to web apps

  http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/aaf8c1cf01bf8d1f#

Noting that here so that folks CC'd on this bug are aware of the mozilla-dev-webapi mailing list / newsgroup.  Please post followups to Gerv's post on dev-webapi.

Comment 13

6 years ago
Hi, just joining the discussion here, and pre-disclosure, I am currently involved in WAC and have worked with Robin and Daniel on WAC and W3C (DAP, Webapps).

To Robin's points on the WAC APIs as a basis, particularly re "not Web-friendly":

- Separate the WAC APIs from the policy framework (which is just one way to manage permissions) and its reliance upon DigSig, and the differences pale. A user-preference/permissions feature can be built various ways, and WAC's approach is just one and can be replaced without significantly impacting the APIs.

- W3C is still trying to find its feet on APIs (and their design) outside traditional HTML5 and Webapps Web APIs, for which the declarative/Javascript approaches are fairly well established (WAC chose the Javascript approach also). But outside HTML5/WebAPIs the design approaches in W3C have not stabilized (even RESTful/resource-based approaches to device feature APIs are being considered - maybe they will also be considered here?). Clearly alignment with stable/supported W3C APIs would be a good thing, But until W3C really establishes a pattern for these supplemental APIs (e.g. the ones in B2G's scope), WAC's patterns are IMO just as good as anyone's. Until real rationales for design approaches are clarified, to me its still just a matter of style.

But to be clear: for B2G, which I am very excited to see as a project, I welcome any approach that promotes SDO/initiative convergence, ease of use, and user safety for apps that want to use these APIs. I'll be following and contributing as possible on the mailing list.
Depends on: 690056
Depends on: 692677
Hey, do we have any bugs filed yet for device access to:

-proximity sensor
-compass (does MozOrientation cover cardinal directions?)
-accelerometer
-light sensor
-microphone input

Comment 15

6 years ago
Those functionalities are covered by the Sensor AP:  http://dev.w3.org/2009/dap/system-info/Sensors.html
Depends on: 693515
Depends on: 697132
Depends on: 697355
Depends on: 697361
(Reporter)

Updated

6 years ago
Depends on: 697383
Depends on: 698821

Updated

6 years ago
No longer depends on: 451674

Updated

6 years ago
Depends on: 692955
Depends on: 684620
(Reporter)

Updated

6 years ago
Depends on: 702157
(Reporter)

Updated

6 years ago
Depends on: 702356
(Reporter)

Updated

6 years ago
Depends on: 702360
(Reporter)

Updated

6 years ago
Depends on: 702363
(Reporter)

Updated

6 years ago
Depends on: 702367
(Reporter)

Updated

6 years ago
Depends on: 702369
Depends on: 702880
Depends on: 702256
Depends on: 712378
Depends on: 713471
Depends on: 714349
Depends on: 714358
Depends on: 715041
Depends on: 707625
Depends on: 715814
Depends on: 717103

Updated

5 years ago
Depends on: 721193

Updated

5 years ago
Depends on: 721199

Updated

5 years ago
Depends on: 721200
Depends on: 729173
Depends on: 708964

Updated

5 years ago
Depends on: 726593
Depends on: 746069
Depends on: 737110
Depends on: 749551
Depends on: 751750
Depends on: 755245
No longer depends on: 755245
Depends on: 755245
Depends on: 755352
No longer depends on: 707625
Depends on: 707625
Depends on: 736710
Depends on: 776027
Depends on: 791962
No longer depends on: 791962

Comment 16

5 years ago
Is there a reason there is no mention of Web Audio API on the Web API list?
(In reply to comment #16)
> Is there a reason there is no mention of Web Audio API on the Web API list?

Bug 779297 tracks the implementation of Web Audio.
Depends on: 796110
Depends on: 839446

Updated

4 years ago
Depends on: 865789
Depends on: 871445
Depends on: 876397

Comment 18

4 years ago
https://bugzilla.mozilla.org/show_bug.cgi?id=881071
Depends on: 903431
Depends on: 910387

Updated

3 years ago
Depends on: 960426
Depends on: 1003330
Depends on: 988469
No longer depends on: 1003330
You need to log in before you can comment on or make changes to this bug.