On 17/04/14 01:22, Kyle Huey wrote:
I definitely recall attending a brownbag presentation from a
researcher who had built a record and replay scheme for JS at the
office in MV sometime in the last few years.
- Kyle
That would be https://air.mozilla.org/timelapse/ .
A short video: https://www.y
Hey Vlad,
yep timing/latency is definitely the key.
It's great to hear that rAF will be able to support future scheduling to
make time sensitive things better. But wouldn't it be best to have this
sort of implementation utilised by DeviceOrientation/DeviceMotion too?
The Rift is really just u
On Tuesday, April 15, 2014 8:17:44 PM UTC-4, Rob Manson wrote:
> We've also put together a plugin for our open source awe.js framework
> that uses getUserMedia() to turn the Rift into a video-see-thru AR
> device too. And for the 6dof tracking we just use the open source
> oculus-bridge app that
And, for some reason, Komodo (which definitely lives out-of-tree).
Dunno, we're weird and crufty, or something.
(This is not a disagreement to archiving, of course.)
--
Mook
On 04/16/2014 02:22 PM, Gavin Sharp wrote:
The code in toolkit/components/help is only used by SeaMonkey, as far
as I c
On Wednesday, April 16, 2014 9:00:40 PM UTC-4, Eric Rahm wrote:
> So who actually needs to talk to Oculus? I can try to reach out some
> folks I used to work with who are there now and see if they're
> interested in making license modifications.
Already in the works. :)
The good news is that wi
So who actually needs to talk to Oculus? I can try to reach out some
folks I used to work with who are there now and see if they're
interested in making license modifications.
-e
On 4/16/14, 7:01 AM, Gervase Markham wrote:
On 14/04/14 23:41, Vladimir Vukicevic wrote:
I'd like to get this che
- Original Message -
> When you say "intent to implement" what is it you're planning on
> implementing?
> * web activities between b2g-style webapps on Android
Yes
> * web activities called by sites loaded in the Firefox for Android browser?
> * web activities provided by sites loaded i
On Tue, Apr 15, 2014 at 4:14 PM, Gijs Kruitbosch
wrote:
> On 16/04/2014 00:05, Robert O'Callahan wrote:
>>
>> We just released rr 1.2 and I think this would be a good time for people
>> to
>> try to use it for one of the tasks it was designed for: debugging
>> intermittent test failures.
>
>
> Thi
Building a debugger for a high-level language on top of a low-level
recording is unexplored territory but it's definitely possible and it would
have some nice features. However, you can't get much leverage from any
existing debugging support built into a VM.
We could build some JS debugging suppor
On Tue, Apr 15, 2014 at 10:08 PM, Joshua Dover wrote:
> - Notes from the Extensible Web Summit this month
> (http://oksoclap.com/p/8pYs44D5CQ) :sicking should be able to provide more
> info on standardization progress.
I'm not sicking, but there was some interest there from Google and we
defini
On 2014-04-16, 5:50 PM, Gavin Sharp wrote:
The question was simply "are there non-tracking use-cases for
sendBeacon", and it sounds like the simple answer is "yes". Still not
clear how common they will be relative to the tracking use cases in
practice, though. What we do in terms of UI and exposi
The question was simply "are there non-tracking use-cases for sendBeacon",
and it sounds like the simple answer is "yes". Still not clear how common
they will be relative to the tracking use cases in practice, though. What
we do in terms of UI and exposing the ability to disable it depends on
bette
On 2014-04-16, 12:14 PM, Anne van Kesteren wrote:
On Wed, Apr 16, 2014 at 2:30 PM, Richard Barnes wrote:
The specification is currently under development in W3C, but has been
substantially stable for a while.
http://www.w3.org/TR/beacon/
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/
On 2014-04-16, 2:25 PM, Benjamin Smedberg wrote:
On 4/16/2014 2:18 PM, Richard Barnes wrote:
I don't know about "problematic", but ISTM that it might be useless.
If people disable sendBeacon in an effort to avoid tracking, then the
trackers can always just test and polyfill with XHR. If you re
The code in toolkit/components/help is only used by SeaMonkey, as far
as I can tell.
I think you can archive that article.
Gavin
On Wed, Apr 16, 2014 at 2:05 PM, Eric Shepherd wrote:
> I'm continuing our documentation cleanup, and found this article:
>
> https://developer.mozilla.org/en-US/docs
I'm continuing our documentation cleanup, and found this article:
https://developer.mozilla.org/en-US/docs/Help_Viewer
I don't think this Help Viewer is used anymore, but want to confirm
before I archive the documentation. Anyone?
--
Eric Shepherd
Developer Documentation Lead
Mozilla
Blog: ht
On 4/16/14, 10:02 AM, Bobby Holley wrote:
On Wed, Apr 16, 2014 at 9:47 AM, Robert Kaiser wrote:
That's a good step. IMHO, often another good step is to mostly separate
every patch to its own bug (I know there are cases where it might not makes
sense, but often it does) so that individual chunk
Are there any legitimate use-cases for, say, saving document drafts before
navigating? It seems pretty bad to make that silently fail.
On Wed, Apr 16, 2014 at 11:25 AM, Benjamin Smedberg
wrote:
> On 4/16/2014 2:18 PM, Richard Barnes wrote:
>
>>
>> I don't know about "problematic", but ISTM that
On 4/16/2014 2:18 PM, Richard Barnes wrote:
I don't know about "problematic", but ISTM that it might be useless. If people disable
sendBeacon in an effort to avoid tracking, then the trackers can always just test and polyfill with
XHR. If you really want "disable tracking", you're going to h
On Apr 16, 2014, at 1:49 PM, Gavin Sharp wrote:
> On Wed, Apr 16, 2014 at 8:56 AM, Ehsan Akhgari
> wrote:
>>> Are beacons primarily meant as tracking devices, or is it also meant as
>>> a way to persist unsaved page state when the user navigates?
>
>> Beacons do not enable any new ways of tra
>On 2014-04-15, 5:58 PM, Gijs Kruitbosch wrote:
>> On 15/04/2014 22:34, K. Gadd wrote:
>>> Arguably if you wait for other vendors to expose VR before you do it,
>>> you'll end up having to implement a sub-standard proprietary API like
>>> you did with Web Audio.
>>
>> We had an alternative implemen
> When you say "intent to implement" what is it you're planning on
> implementing?
For the initial drop here, we've implemented a way for web apps (or sites if we
decide to enable this for them, but after talking here and with the team, I
think restricting this to WebApps is a good idea), to fi
On Wed, Apr 16, 2014 at 8:56 AM, Ehsan Akhgari wrote:
>> Are beacons primarily meant as tracking devices, or is it also meant as
>> a way to persist unsaved page state when the user navigates?
> Beacons do not enable any new ways of tracking which is not already
> possible.
That's not an answer
Benoit Jacob schrieb:
In this respect, more innovation is not necessarily better, and in fact,
the cost of innovating in the wrong direction could be particularly high
for the Web compared to other platforms.
But innovation is part of our mission (yes, the very short statement of
it that must
On 4/16/2014 12:37 PM, Wes Johnston wrote:
Something like this is needed for integration of B2G WebApps on
Android. Without it, they have no way of talking to one another, let
alone any way of talking to Native Apps. The best they can provide is
launching a uri with a specific scheme and to hop
Rob Manson schrieb:
I know I'm lobbing in from the sidelines on what is essentially a
licensing debate internal to Mozilla...but wouldn't any VR
implementation like Vlad described be best done as an extension of
existing open web standards where possible.
Excellent points, I really think that s
On Wed, Apr 16, 2014 at 9:47 AM, Robert Kaiser wrote:
> That's a good step. IMHO, often another good step is to mostly separate
> every patch to its own bug (I know there are cases where it might not makes
> sense, but often it does) so that individual chunks can be accounted for
> separately in
Karl Tomlinson schrieb:
Joshua Cranmer 🐧. writes:
On 4/13/2014 4:42 PM, Robert O'Callahan wrote:
Honestly, I think we're already pretty close to most of those
recommendations, most of the time.
Some experienced Mozillians are breaking up their large changes
well, but some are not. And many
Something like this is needed for integration of B2G WebApps on Android.
Without it, they have no way of talking to one another, let alone any
way of talking to Native Apps. The best they can provide is launching a
uri with a specific scheme and to hope something on the other end is
able to pic
Yep, my plan was to to not let this get beyond Nightly, maybe Aurora, but
not further until the functionality and standards were firmer.
- Vlad
On Wed, Apr 16, 2014 at 12:08 PM, Anne van Kesteren wrote:
> On Wed, Apr 16, 2014 at 4:59 PM, Ehsan Akhgari
> wrote:
> > I think a great way to de
On Wed, Apr 16, 2014 at 2:30 PM, Richard Barnes wrote:
> The specification is currently under development in W3C, but has been
> substantially stable for a while.
> http://www.w3.org/TR/beacon/
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html
I think that is mostly because
On Wed, Apr 16, 2014 at 4:59 PM, Ehsan Akhgari wrote:
> I think a great way to deal with that is to keep features on the beta
> channel and continue to make breaking changes to them before we feel ready
> to ship them. The reality is that once we ship an API our ability to make
> any backwards in
On 2014-04-16, 11:38 AM, Anne van Kesteren wrote:
On Wed, Apr 16, 2014 at 12:43 AM, Andreas Gal wrote:
Innovation happens all over the place, and we iterate towards a stable,
standardized point after innovation happened.
One of the problems we face with iterating towards that standardized
pl
On 2014-04-16, 10:52 AM, Benjamin Smedberg wrote:
On 4/16/2014 9:30 AM, Richard Barnes wrote:
Allows pages to send a "beacon" HTTP request. Beacons are allowed a
limited subset of HTTP (only a few content types), and the JS cannot
receive the content of the response. However, beacon requests
Thanks Richard!
Do you think you'll be able to fix bug 988107 soon so that we can ship
this on Firefox OS at the same time as desktop and Android?
Cheers,
Ehsan
On 2014-04-16, 9:30 AM, Richard Barnes wrote:
Primary eng emails
rbar...@mozilla.com, eh...@mozilla.com
Spec
http://www.w3.org/TR
On Apr 16, 2014, at 10:52 AM, Benjamin Smedberg wrote:
> On 4/16/2014 9:30 AM, Richard Barnes wrote:
>>
>> Allows pages to send a "beacon" HTTP request. Beacons are allowed a limited
>> subset of HTTP (only a few content types), and the JS cannot receive the
>> content of the response. Howe
On Wed, Apr 16, 2014 at 12:43 AM, Andreas Gal wrote:
> Innovation happens all over the place, and we iterate towards a stable,
> standardized point after innovation happened.
One of the problems we face with iterating towards that standardized
platform is legacy. https://hsivonen.fi/vendor-prefi
On 4/16/2014 9:30 AM, Richard Barnes wrote:
Allows pages to send a "beacon" HTTP request. Beacons are allowed a
limited subset of HTTP (only a few content types), and the JS cannot
receive the content of the response. However, beacon requests will
survive after the page is unloaded, removin
On 14/04/14 23:41, Vladimir Vukicevic wrote:
> I'd like to get this checked in so that we can either have it enabled
> by default in nightlies (and nightlies only), or at least allow it
> enabled via a pref. However, there's one issue -- the LibOVR library
> has a not-fully-free-software license [
On 15/04/14 06:21, Nick Alexander wrote:
> Can somebody save me some license reading and explain what the existing
> framework around shipping libovr is? Is it explicitly allowed?
> Explicitly dis-allowed? If I read gerv's post [1] correctly, it is
> allowed, but it's hard to distinguish gerv's o
On Wed, Apr 16, 2014 at 7:14 AM, Till Schneidereit <
t...@tillschneidereit.net> wrote:
> On Wed, Apr 16, 2014 at 1:52 AM, Ehsan Akhgari wrote:
>
>> On 2014-04-15, 7:14 PM, Gijs Kruitbosch wrote:
>>
>>> On 16/04/2014 00:05, Robert O'Callahan wrote:
>>>
We just released rr 1.2 and I think this
Primary eng emails
rbar...@mozilla.com, eh...@mozilla.com
Spec
http://www.w3.org/TR/beacon/
*Summary*
Allows pages to send a "beacon" HTTP request. Beacons are allowed a
limited subset of HTTP (only a few content types), and the JS cannot
receive the content of the response. However, beac
On 4/15/2014 5:08 PM, Joshua Dover wrote:
Summary: Allow webpages, web apps, and addons to interact with native Android
apps via MozActivity
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=970707
Link to standard: current MozActivity not on standards track:
https://developer.mozilla.org/en-US
On 04/15/2014 07:14 PM, Gijs Kruitbosch wrote:
1) Is anyone working on something similar that works for frontend code
(particularly, chrome JS)? I realize we have a JS debugger, but
sometimes activating the debugger at the wrong time makes the bug go
away, and then there's timing issues, and th
On Wed, Apr 16, 2014 at 11:14 PM, Till Schneidereit <
t...@tillschneidereit.net> wrote:
> At the JS work week in Toronto in late March, we discussed this.
> Unfortunately, that was one of the relatively few sessions for which no
> protocol exists. :(
>
> The gist of the results was that, sadly, th
On 16/04/2014 12:14, Till Schneidereit wrote:
On Wed, Apr 16, 2014 at 1:52 AM, Ehsan Akhgari wrote:
On 2014-04-15, 7:14 PM, Gijs Kruitbosch wrote:
On 16/04/2014 00:05, Robert O'Callahan wrote:
We just released rr 1.2 and I think this would be a good time for
people to
try to use it for one
On Wed, Apr 16, 2014 at 1:52 AM, Ehsan Akhgari wrote:
> On 2014-04-15, 7:14 PM, Gijs Kruitbosch wrote:
>
>> On 16/04/2014 00:05, Robert O'Callahan wrote:
>>
>>> We just released rr 1.2 and I think this would be a good time for
>>> people to
>>> try to use it for one of the tasks it was designed fo
On 04/15/2014 11:08 PM, Joshua Dover wrote:
as this current specification is not on a standards track
(and will probably not be compatible with what we have now).
That sounds like a clear "no" to me.
HTH
Ms2ger
___
dev-platform mailing list
dev-platf
48 matches
Mail list logo
