Hi,
Unfortunately I don't think consensus is possible with code formatting.
Partly for that reason, we (Fx engineering leadership and others) have
concluded that automatic, standardized code formatting is the right thing
to do. We've already done this for a few languages and Python is up next.
R
đź‘Ź Thank you!
On Wed, Aug 28, 2019 at 1:51 PM Emma Humphries wrote:
> When work on https://bugzilla.mozilla.org/show_bug.cgi?id=1417229 is
> completed and the patch deployed to Bugzilla, users who are a Triage Owner
> will be able to see security bugs in their components without needing
> members
It's been a long time coming :) Do you know if Chrome plans to drop
support, too?
On Wed, Aug 21, 2019 at 5:01 PM Jonathan Kingston wrote:
> The design of AppCache brings many problems to the web platform from a
> performance and security perspective. Service workers have long solved the
> same
The recent improvements to Bugzilla are greatly appreciated! Congrats and
thank you to you and the team on the steady stream of awesomeness.
On Thu, Jun 27, 2019 at 8:18 PM Kohei Yoshino wrote:
> Hi there,
>
> We have enhanced search features on Bugzilla over the past months, because
> we know p
That looks like it could be incredibly useful! Thanks for pointing it out
and for doing the work.
On Thu, Jan 17, 2019 at 11:50 AM Calixte Denizet
wrote:
> Hi,
>
> A few months ago, we published the first version of the crash-stop addon
> [1]. The goal was to integrate crash data along with some
Congrats on getting this far, Xidorn! I know it's been years of work by you
and others.
On Mon, Sep 17, 2018 at 7:48 PM Xidorn Quan wrote:
> As of Firefox 64, I intend to turn on unprefixed Fullscreen API by default
> on all platforms. It has been developed behind the
> full-screen-api.unprefix.
On Fri, Feb 2, 2018 at 8:45 AM, Tom Schuster wrote:
> Chrome seems to
> want to add a kill pref for this, from my experience more difficult
> for us with the way we define methods in SpiderMonkey. Should that be
> a requirement for shipping?
>
If it's not too difficult it does make it a lot eas
We got a bug report that things are not working here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1429900. Ben, can you take a
look?
On Mon, May 23, 2016 at 2:25 AM, Ben Tian wrote:
> Hi,
>
> I’m planning to enable scrollbars by default for windows opened by
> window.open().
>
> Bug: https://bu
Custom Elements is being tracked separately. Watch for an intent email
regarding them soon.
On Tue, Nov 28, 2017 at 8:05 AM wrote:
> Is this just shadow dom or there will be also support for custom elements?
>
> Thanks
> ___
> dev-platform mailing list
On Thu, Oct 26, 2017 at 12:34 AM, Boris Zbarsky wrote:
> Either approach would break at least some legitimate sites.
>
Thanks for confirming this.
In general, as Myk points out, the question of when web pages should be
> able to respond to what sorts of input, and whether they should be able to
Is there precedent for doing what a user intended which would be contrary
to what the site is attempting?
In the case that prompted my question, the user was attempting to
middle-click open photos from a Facebook photo album in tabs but the
middle-click was handled by the page's JS:
https://bugzil
Not a bad idea! You can feel free to add it to the wiki page under
suggested additions. And remember, they're just guidelines :)
On Sat, Oct 21, 2017 at 4:25 AM Philipp Kewisch wrote:
> Hey Folks,
>
> One thing I've often been thinking when reading the Intent to
> Ship/Implement emails is "Hey, t
On Wed, Sep 6, 2017 at 2:53 PM, Daniel Veditz wrote:
> I do not know what are plans are about Client Hints in general, whether we
> intend to or when, and obviously that's a prerequisite.
>
Client Hints is https://bugzilla.mozilla.org/show_bug.cgi?id=935216, FWIW.
___
On Thu, Aug 10, 2017 at 11:29 PM, Ben Kelly wrote:
> Many thanks to Till and Andrea for their hard work on streams!
>
And to you, too, Ben! And to Boris and others for their reviews.
Congratulations, all, this has been some great teamwork and it's great to
see it get this far!
_
On Tue, Jul 25, 2017 at 3:06 PM, David Teller wrote:
> Should we moz-prefix moz-specific extensions?
We have been trying not to do that for Web-exposed APIs but maybe the
extensions case is different?
https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Guiding_Principles
Did we make a decision here? If not, what are we missing to make one?
On Fri, Apr 28, 2017 at 1:55 PM, Anne van Kesteren wrote:
> On Fri, Apr 28, 2017 at 7:10 PM, Eric Rescorla wrote:
> > Rather, the policy is
> > that we will move to requiring all new features to have HTTPS [0].
>
> We should
On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla wrote:
> Going back to Jonathan's (I think) question. Does anyone use this at all in
> the field?
>
Chrome's usage metrics say <= 0.0001% of page loads:
https://www.chromestatus.com/metrics/feature/popularity#AmbientLightSensorConstructor.
We are go
On Thu, Sep 22, 2016 at 2:03 AM, smaug wrote:
>
> On 09/21/2016 04:42 AM, Shawn Huang wrote:
>
>>
>> ​Because ​Storage API needs to have SecureContext support, but currently
>> not having isSecureContext available in Workers (bug 1269052) is
>> problematic. Can we initially release the Storage AP
Implement Client-Hints HTTP header
https://bugzilla.mozilla.org/show_bug.cgi?id=935216
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Thu, Jan 7, 2016 at 4:27 AM, Anne van Kesteren wrote:
> On Thu, Jan 7, 2016 at 10:24 AM, L. David Baron wrote:
> > Could you give a brief explanation of what the storage mutex is, and
> > why it was/should be removed?
>
> It prevents races for storage and cookies when your tabs run in
> indep
Harald (on CC) is working on it here:
https://github.com/mozilla/platatus
On Oct 29, 2015 6:38 PM, "Tom Schuster" wrote:
> Seems like this kind of died. I still would like to see this happening. Is
> this on somebody's agenda?
>
> On Tue, Jul 21, 2015 at 8:40 PM, Tom Schuster wrote:
>
> > I see
We're using this meta-bug to track shipping Service Workers to the release
channel on desktop and Android:
https://bugzilla.mozilla.org/show_bug.cgi?id=1059784
For B2G-specific Service Worker issues we're using this meta-bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1131322
And for "post-v1
On 01/10/14 04:46 AM, Mounir Lamouri wrote:
On Wed, 1 Oct 2014, at 10:51, Jonas Sicking wrote:
On Tue, Sep 30, 2014 at 3:54 AM, Mounir Lamouri
wrote:
On Thu, 25 Sep 2014, at 02:49, Jonas Sicking wrote:
Yes!
Though as previously expressed, I don't think we should ship this until
it
supports s
A few of us have written some tips and suggestions to make standardizing
web APIs easier. They're mostly intended for Mozillians and are most
useful for those doing this for the first time. If you have
suggestions, please let me know.
https://wiki.mozilla.org/WebAPI/DesignGuidelines
Tomorrow (Wed June 11th) we're starting short weekly sync-ups on our
Service Worker efforts with a primary focus on offline functionality for
the web.
*Where*: WebAPI Vidyo room
*When*: see this URL for the time in your timezone:
http://arewemeetingyet.com/Toronto/2014-06-11/11:00/w/Offline%20s
Hi,
I've been told that it would be nice if we had stronger language in our
API exposure guidelines [1] around when we deviate from them. This is
mostly applicable when we expose things to Firefox OS applications. The
changes I propose to the "Special cases" section [2] are:
-There will o
58 PM, Andrew Overholt wrote:
I'm planning to coordinate development material for new contributors and
I'd like your input on what should be included:
https://etherpad.mozilla.org/mozbootcamp
Thanks!
___
dev-platform mailing li
I'm planning to coordinate development material for new contributors and
I'd like your input on what should be included:
https://etherpad.mozilla.org/mozbootcamp
Thanks!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozi
After some more suggested revisions (thanks again), I made these
guidelines "official" as of October 22, 2013.
Even though they aren't rules that are set in stone or anything like
that, please consider these guidelines when exposing things to web content:
https://wiki.mozilla.org/WebAPI/Exp
Hi,
When we expose new things to web developers, I'd like us to consider
some suggestions. Due to a number of factors, I've made them
suggestions and not a set of pan-module hard rules.
https://wiki.mozilla.org/User:Overholt/APIExposurePolicy
I've incorporated lots of feedback given on pr
Last notice: we've moved the meeting 2 hours earlier!
8 AM in California
11 AM in Toronto and New York, etc.
16:00 in the UK and Portugal
17:00 in most parts of Europe
23:00 in Taipei
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130820T08&p1=224&am=30
We've moved the meeting 2 hours earlier!
8 AM in California
11 AM in Toronto and New York, etc.
16:00 in the UK and Portugal
17:00 in most parts of Europe
23:00 in Taipei
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130813T08&p1=224&am=30
Meeting Detai
We've moved the meeting 2 hours earlier!
8 AM in California
11 AM in Toronto and New York, etc.
16:00 in the UK and Portugal
17:00 in most parts of Europe
23:00 in Taipei
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130806T08&p1=224&am=30
Meeting Detai
We're moving the meeting 2 hours earlier!
8 AM in California
11 AM in Toronto and New York, etc.
16:00 in the UK and Portugal
17:00 in most parts of Europe
23:00 in Taipei
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130730T08&p1=224&am=30
Meeting Deta
Meeting Details:
* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office
* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone #
Meeting Details:
* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office
* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone #
Due to most regular attendees being at a work week this week, we'll skip
our call and restart it next week (July 16th).
Send email or hop on #webapi for any issues.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/
Thank you to everyone that provided feedback. I've read everyone's
comments and taken them into account with my new draft:
https://wiki.mozilla.org/User:Overholt/APIExposurePolicy
In general I tried to make it more of a set of requests and guidelines
than a set of "must"s. I also clarified
Meeting Details:
* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office
* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone #
On 26/06/13 11:48 AM, Ehsan Akhgari wrote:
On 2013-06-26 11:21 AM, Andrew Overholt wrote:
On 24/06/13 05:52 PM, Ehsan Akhgari wrote:
There are two things that I think can use clarification. One is what
we're going to do about "trivial changes"? Do all web facing features
ne
On 25/06/13 12:15 PM, Mounir Lamouri wrote:
Note that at this time, we are specifically focusing on new JS APIs
and not on CSS, WebGL, WebRTC, or other existing features/properties.
I think the "JS APIs" here is unclear. I think saying "Web APIs" would
be more appropriate, assuming this is wh
On 25/06/13 10:11 AM, Brian Smith wrote:
In the document, instead of creating a blacklist of web technologies to which
the new policy would not apply (CSS, WebGL, WebRTC, etc.), please list the
modules to which the policy would apply.
I started building up a list of modules to which the polic
On 24/06/13 05:52 PM, Ehsan Akhgari wrote:
There are two things that I think can use clarification. One is what
we're going to do about "trivial changes"? Do all web facing features
ned to go through this process?
I was going to put a blurb about "trivial changes" but thought it would
be too
On 24/06/13 01:50 PM, Kyle Huey wrote:
1. "at least one other browser vendor ships -- or publicly states their
intention to ship -- a compatible implementation of this API"
Because Apple and Microsoft generally do not publicly comment on
upcoming features, and Presto is no more, in practice this
On 21/06/13 05:56 PM, Adam Roach wrote:
On 6/21/13 15:45, Andrew Overholt wrote:
I'd appreciate your review feedback. Thanks.
I'm having a hard time rectifying these two passages, which seem to be
in direct contradiction:
1. "Note that at this time, we are specifically f
On 21/06/13 06:05 PM, Benoit Jacob wrote:
Just to say, WebGL won't have to be an exception after all --- at least
not newer WebGL extensions.
Ah, thanks for letting me know.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.m
On Fri 21 Jun 2013 06:44:08 PM EDT, Robert O'Callahan wrote:
I think "APIs which only Mozilla is interested in at that time" needs
clarification that this refers to APIs that solve use cases that only
Mozilla is interested in. If other vendors are interested in those
use-cases, but don't like our
Meeting Details:
* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office
* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone #
Back in November, Henri Sivonen started a thread here entitled
"Proposal: Not shipping prefixed APIs on the release channel" [1]. The
policy of not shipping moz-prefixed APIs in releases was accepted AFAICT.
I've incorporated that policy into a broader one regarding web API
exposure. I'd lik
Meeting Details:
* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office
* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone #
Meeting Details:
* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office
* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone #
Meeting Details:
* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office
* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone #
Meeting Details:
* Agenda: https://wiki.mozilla.org/WebAPI/2013-05-28
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office
* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1-800
Meeting Details:
* Agenda: https://wiki.mozilla.org/WebAPI/2013-05-07
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office
* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1-800
Meeting Details:
* Agenda: https://wiki.mozilla.org/WebAPI/2013-04-30
* WebAPI Vidyo room
* Amoeba conf. room, San Francisco office (7A)
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office
* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1
Meeting Details:
* Agenda: https://wiki.mozilla.org/WebAPI/2013-04-23
* WebAPI Vidyo room
* Amoeba conf. room, San Francisco office (7A)
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office
* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1
Meeting Details:
* Agenda: https://wiki.mozilla.org/WebAPI/2013-04-09
* WebAPI Vidyo room
* Amoeba conf. room, San Francisco office (7A)
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office
* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone #
Yesterday a number of people discussed future plans for the WebAPI team.
Our discussion resulted in the ideas and comments that are on this
wiki page:
https://wiki.mozilla.org/WebAPI/PlannedWork
We'll add items to that page as time goes by and we'll pop items off it
as we work on them. As
58 matches
Mail list logo
