If we are talking about checking (a separate thing, in my opinion), then we
should be talking about linting :) Checking for formatting is probably less
useful than something more concrete. Having run jshint over some of the code,
I was horrified at the output it produced.
That said, checking
-
From: Bobby Holley bobbyhol...@gmail.com
To: Martin Thomson m...@mozilla.com
Cc: Till Schneidereit t...@tillschneidereit.net, Mike Hommey
m...@glandium.org, Ehsan Akhgari ehsan.akhg...@gmail.com,
dev-platform@lists.mozilla.org, Andrea Marchesini amarches...@mozilla.com
Sent: Thursday, December 19
a template
for that.
- Original Message -
From: Bobby Holley bobbyhol...@gmail.com
To: Martin Thomson m...@mozilla.com
Cc: Till Schneidereit t...@tillschneidereit.net, Mike Hommey
m...@glandium.org, Ehsan Akhgari ehsan.akhg...@gmail.com,
dev-platform@lists.mozilla.org, Andrea Marchesini
is where a style is imposed
from upon high in the form of an edict.
- Original Message -
From: Jeff Gilbert jgilb...@mozilla.com
To: Ehsan Akhgari ehsan.akhg...@gmail.com
Cc: Till Schneidereit t...@tillschneidereit.net, Martin Thomson
m...@mozilla.com, Gregory Szorc g...@mozilla.com
I think that this is a good start, but it doesn’t go quite far enough.
Part of the problem with a policy that requires people to avoid reformatting of
stuff they don’t touch is that it propagates formatting divergence. Sometimes
because it’s better to conform to the style immediately adjacent
On 2014-01-06, at 11:25, Gregory Szorc g...@mozilla.com wrote:
Clang provides access to the low-level token stream [1]. This is available
via libclang (the C API) and the Python bindings and I'm pretty sure you can
access this info from plugins.
Each token is associated with a source
On 2014-01-06, at 12:36, Karl Tomlinson mozn...@karlt.net wrote:
I'm sceptical about the value of such changes out-weighing the
cost here. I know there will be a cost now and in the future, but
I don't recall seeing any entire files so badly formatted that it
took me more time to understand
On 2014-01-06, at 13:27, Brian Smith br...@briansmith.org wrote:
As far as PSM is concerned, my main ask is that such reformatting of
security/manager/ssl/src/* be done in February or later, so that the
current urgently-needed big refactoring in that code is not disrupted.
For one, I don’t
On 2014-01-06, at 17:05, Karl Tomlinson mozn...@karlt.net wrote:
if (condition1)
if (condition2)
foo();
else
bar();
Sure, you could argue that style conversion makes the actual
behaviour clearer, but you'd have to know the intended behaviour
to know there was a bug.
On 2014-01-06, at 19:28, Patrick McManus mcma...@ducksong.com wrote:
I strongly prefer at least a 100 character per line limit. Technology
marches on.
Yes. I’ve encountered too many instances where 80 was not enough.
Good identifier names are hugely important, no matter what the language,
On 2014-01-07, at 11:28, Benjamin Smedberg benja...@smedbergs.us wrote:
Especially for new contributors we shouldn't assume that most editors can do
this correctly. I personally think that the risk of introducing a new member
and then having locals shadow members is real enough that we
On 2014-01-07, at 14:52, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
I don't have any opinions on gFoo.
Aside from “should not exist” ?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 2014-01-07, at 17:38, Mike Hommey m...@glandium.org wrote:
Do we need so much boilerplate in all our files? With this and
vim-modeline, we now have editor boilerplate that takes as much space as
the MPL boilerplate. Also, afaik, vim modelines are mostly useless, since
vim doesn't use them
On 2014-01-07, at 17:49, Joshua Cranmer pidgeo...@gmail.com wrote:
Since I'm seeing a lot of people advocating that the wrap margin should be
100,
let me reiterate
David Baron's comment that the wrap margin must either be 80 or infinite […]
I have always preferred no wrapping, with the
On 2014-01-08, at 09:57, Adam Roach a...@mozilla.com wrote:
Automated wrapping to a column width is less than optimal. If you look back
at bz's example about how he would chose to wrap a specific conditional, it's
based on semantic intent, not the language syntax. By and large, this goes to
On 2014-01-08, at 10:06, Adam Roach a...@mozilla.com wrote:
The second is that we need to be careful if we decide to run a reformatter
over the code wholesale, since you can actually lose useful information about
author's intent. I'm not the first to raise that point in this discussion;
On 2014-01-09, at 08:48, Milan Sreckovic msrecko...@mozilla.com wrote:
For example, I find the consistency of the positioning of {} for the loops
and conditionals extremely important for readability.
Outside of any real extremes, I’ve found that consistency is far more important
than any
On 2014-03-03, at 18:54, Jan Honza Odvarko odva...@gmail.com wrote:
URLs in stack traces for exception objects have been recently changed. There
is a column number appended at the end (I am seeing this in Nightly, but it
could be also in Aurora).
For my gratification, why is this
On 2014-04-01, at 15:15, Rob Arnold tell...@gmail.com wrote:
the similarity to a non-atomic integer type actually has prompted me to
have a (temporary) false sense of thread unsafety, rather than a false
sense of thread safety.
That was my impression too. I usually find that I have to chase
On 2014-04-01, at 16:17, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
Just to clarify my position a bit more, I think criticizing my position by
pretending that I'm advocating for a brain-off way of programming with
atomics is a bit contrived. I definitely understand that atomics require
On 2014-04-01, at 16:48, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
My contention is that it is obvious enough by looking at (a) to tell that
mRefCnt is an atomic value which should be handled with the necessary care,
so the pattern (b) would be caught either at code writing time or at
On 2014-04-02, at 14:01, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
AtomicFetchAndSub(mRefCnt, -1);
I think that I’ll join those who seem to favour member functions over statics,
as you seem to prefer for some reason.
If you want to avoid inventing names and such, how about copying from
On 2014-04-04, at 14:02, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
That's not true, we were in that state once, before I stopped working on this
issue. We can get there again if we wanted to. It's just a lot of hard work
which won't scale if we only have one person doing it.
It’s
On 2014-04-08, at 11:40, Anne van Kesteren ann...@annevk.nl wrote:
Related to this, https://www.w3.org/Bugs/Public/show_bug.cgi?id=25235
is awaiting our input I'm told. Background:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Apr/0010.html
In the spirit of ocean boiling
On 2014-04-24, at 05:31, Henri Sivonen hsivo...@hsivonen.fi wrote:
* Are there obvious places that people should inspect for code that's
being built but not used? Some libs that got imported for WebRTC
maybe?
https://bugzilla.mozilla.org/show_bug.cgi?id=1001114
I’m told that sipcc is 3M
Summary:
WebRTC enables peer-to-peer communications. Identity features enable the
identification of WebRTC peers using a generic identity provider interface.
Stream isolation provides sites a way to foreswear access to media so that - in
combination with identity - users can be sure that
...@gmail.com wrote:
Thanks, Martin!
Do you know if other UAs are also implementing this API?
On 2014-05-02, 4:09 PM, Martin Thomson wrote:
Summary:
WebRTC enables peer-to-peer communications. Identity features enable the
identification of WebRTC peers using a generic identity provider
On 2014-05-30, at 21:00, Benoit Jacob jacob.benoi...@gmail.com wrote:
2x3 matrices
representing affine 2D transformations; this mode switch corresponds to the
is2D() getter
Am I the only one that finds this method entirely unintuitive? After looking
at only the IDL, admittedly, is2D() ===
On 2014-06-02, at 08:53, Rik Cabanier caban...@gmail.com wrote:
it conveys that this is a 2d matrix and that you can ignore the 3d
components.
Maybe you misunderstood what I was implying. You are describing an intended
application of the matrix to 2d or 3d graphics. The problem is that
On 2014-06-02, at 16:24, Chris Peterson cpeter...@mozilla.com wrote:
btw, in the mozilla.dev.tech.javascript-engine.internals fork of this thread,
bz and David Bruant pointed out that W3C's testharness and TC39's test262
each use yet another set of assertion function names. Any tests we
On 07/07/14 09:25, gkee...@mozilla.com wrote:
We have no unit test framework for internal JS, does anyone have any
interesting ideas on how to accomplish this with our existing testing
frameworks?
I've successfully used mochitest with specialpowers to access the
internal interfaces.
The latest version of the API spec is here:
https://w3c.github.io/push-api/index.html
That’s potentially in flux. What are your plans should something major change?
On 2014-07-21, at 09:22, Tyler Smith tylsm...@gmail.com wrote:
Summary: New Push API to replace the current specification for
Did I miss the announcement about this feature? Nightly just told me
about an add-on that it thinks I might want. Apparently because I
download a lot of files.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 31/07/14 09:55, Mike Conley wrote:
Can you show us a screenshot of this button?
Well I customized it off and now I can't get it back.
I found out what it was though:
https://github.com/raymak/contextualfeaturerecommender
I don't remember installing that addon.
On 31/07/14 15:31, Gavin Sharp wrote:
Does it appear inabout:addons for the affected profile, under Experiments?
I've no Experiments category, but it appears in the list.
What is the value of the experiments.manifest.uri pref in that profile?
+rbarnes is responsible for adding WebCrypto, which includes some JOSE features.
On 2014-08-12, at 10:22, Gregory Szorc g...@mozilla.com wrote:
The possibility of using JavaScript Object Signing and Encryption (JOSE) -
specifically the verification part of the JSON Web Signature (JWS)
On 20/08/14 17:37, Jonas Sicking wrote:
It would however be really cool if we were able to pull data on which
tests tend to fail in a way that affects all platforms, and which ones
tend to fail on one platform only.
Here's a potential project that might help. For all of the trees
(probably
One idea that has been floated
(https://bugzilla.mozilla.org/show_bug.cgi?id=1002676) is to restrict
persistent permissions to secure origins. The reasoning there being that a
persistent grant can be trivially intercepted if you work in the clear. That's
a real security concern. One that
It's more the case that a persistent positive grant from permission manager
would be ignored for non-secure origins and non-secure origins would not show
any option to persist.
- Original Message -
From: Mounir Lamouri mou...@lamouri.fr
To: Martin Thomson m...@mozilla.com, Ehsan Akhgari
On 07/09/14 07:09, Jesper Kristensen wrote:
Cookies are segregated by http vs https, right?
No, unfortunately they are not. Numerous attempts at fixing it has been
rejected by browser vendors. For example
http://tools.ietf.org/html/draft-abarth-cake-01
They are, somewhat.
All cookies are
On 08/09/14 04:05, Henri Sivonen wrote:
Considering that the remedy would be migrating the app to an
authenticated origin, how useful is it to have gUM available (without
persistent permissions) for unauthenticated origins?
That's been the question people have asked, and I think that the
On 08/09/14 10:08, Anne van Kesteren wrote:
That's been the question people have asked, and I think that the answer was
that we don't want to break test pages and that sort of thing unnecessarily.
Whoa, that definitely seems like the wrong way to prioritize things.
Tests or demos should not
On 08/09/14 17:10, Daniel Veditz wrote:
It wouldn't be every API call, it'd be the first API call. Would it help
to have an option to remember for the session (rather than
per-document)? We have no guarantee that the foo.com you connect to
tomorrow is the same foo.com you trusted today,
On 2014-09-10, at 16:38, Justin Dolske dol...@mozilla.com wrote:
It's particularly egregious on Google Maps... The maps.google.com site
redirects tohttps://google.com/maps, which means using geolocation on Google
Maps in Chrome will automatically allow geolocation for all of google.com. I
On 2014-09-11, at 00:56, Anne van Kesteren ann...@annevk.nl wrote:
Are we actually partitioning permissions per top-level browsing
context or could they already accomplish this through an iframe?
As far as I understand it, permissions are based on domain name only, they
don’t include scheme
On 2014-09-11, at 10:04, Anne van Kesteren ann...@annevk.nl wrote:
Well, if there's https://maps.example/ that I share my location with,
we could make it so that it if https://maps.example/ is embedded from
https://mercent.example/, it no longer has the permission. That's what
I meant with
On 2014-09-11, at 22:55, Henri Sivonen hsivo...@hsivonen.fi wrote:
Moreover, https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-00
has the performance overhead of TLS, so it doesn't really address the
TLS takes too much compute power objection to https, which is the
usual
On 12/09/14 13:37, Anne van Kesteren wrote:
That is something that we should have fixed a long time ago. It's
called meta name=referrer and is these days also part of CSP.
I'll forward that on to those involved. Thanks.
___
dev-platform mailing list
On 12/09/14 13:59, Anne van Kesteren wrote:
But shouldn't it be aware of this so you can adequately scope the
permission? E.g. I could granthttps://amazingmaps.example/ when
embedded throughhttps://okaystore.invalid/ permission to use my
location. But it would not be given out if it were
On 2014-09-23, at 13:53, Daniel Holbert dholb...@mozilla.com wrote:
Link to standard:
http://dev.w3.org/csswg/css-images/#valuedef-pixelated
Reading the spec it doesn’t say anything about what to do when the image is
scaled up on one axis and down on the other. It’s probably not a
On 02/10/14 12:52, Chris Peterson wrote:
SpiderMonkey already forces ES5 strict mode and extra warnings mode
for all self-hosted JS: bug 784295.
The problem is that this only generates an exception, not a test
failure, so if the error is in code that isn't depended upon (also a
problem),
On 02/10/14 11:58, Ehsan Akhgari wrote:
What data specifically? I'm fairly confident that we can make this
change no matter how many websites use geolocation from
non-authenticated origins.
I believe that usual practice before we remove something we don't like
is to provide some warning.
roc said:
Probably not the worst, but always deserves a mention:
http://dxr.mozilla.org/mozilla-central/source/layout/xul/nsSprocketLayout.cpp#632
That's relatively short. This is 800 lines, complete with several layers of
goto:
We're already doing screen capture in Firefox 33. Video, not still I think.
But the APIs are in place, if the implementation is not.
This is not web-facing in the classic sense
(https://wiki.mozilla.org/Screensharing) but there are plans to make at least a
limited feature set available.
On 2014-10-24, at 22:56, Jonas Sicking jo...@sicking.cc wrote:
It's unclear to me what you are suggesting that we should or should not do.
Also, often times there's much more sensitive information captured
from a user's camera, than from a user's screen. Doesn't SOP and CSRF
concerns apply
On 02/11/14 18:13, Mike Hoye wrote:
We found that blocking on a slow connection used consistently more
power than idle. This could be solely due to network traffic, but
network traffic was very periodic (1 packet in and 1 packet out per
second), thus much of the work could likely be attributed
I’m not all that enthused by the blow-by-blow here. Nonetheless, there are
some distortions to correct.
On 2014-11-12, at 20:23, Henri Sivonen hsivo...@hsivonen.fi wrote:
That's true if the server presents a publicly trusted cert for the
wrong hostname (as is common if you try to see what
On 2014-11-13, at 21:25, Henri Sivonen hsivo...@hsivonen.fi wrote:
Your argument relies on there being no prior session that was not
intermediated by the attacker. I’ll concede that this is a likely situation
for a large number of clients, and not all servers will opt for protection
On 2014-11-21, at 08:19, Justin Dolske dol...@mozilla.com wrote:
Is that a direct or indirect cause? AFAIK nothing directly requires Google to
offer this, but the alternative would be organizations and networks who do
want/need to see traffic simply blocking Google services. And so Google
On 2014-12-03, at 02:50, Boris Zbarsky bzbar...@mit.edu wrote:
I can't think of sane use cases for location.origin. Afaict the only reason
it's on there is that all URLUtils things have a .origin...
I think that you will find that there are a few uses of location.origin
already. I’m
On 2014-12-04, at 10:51, Nicholas Nethercote n.netherc...@gmail.com wrote:
What fraction of these cases can't be distinguished by making non-out
ref/pointer parameters const?
The non-const-ness of a parameter is a weak, indirect indication that
it's an outparam, and one that is probably
On 10/12/14 09:46, Ehsan Akhgari wrote:
Do you think we can avoid doing that and focus on making XHR/fetch work
with cross origin SWs?
I like this idea! Accomplish the basic task with the tools already at hand.
___
dev-platform mailing list
On 2014-12-10, at 11:08, Nikhil Marathe nsm.nik...@gmail.com wrote:
I guess having some primitives for structured clone like behavior would be
nice. That too can be handled by use of Response.blob() and
FileReader[Sync]() on workers, but having primitives means that UAs could
optimize the
Why not simply provide a way to show the password always? I believe
that Microsoft always provides the little eye icon in their new password
input fields. If anything, I'd have this feature on by default.
If you are pwned to the extent that an attacker is scraping pixels, I
don't think we
On 12/12/14 15:19, Tanvi Vyas wrote:
A touch event or mouseclick-and-hold on the eye icon could show the
password, and as soon as the user releases the password can go back to
being obfuscated. That would prevent accidental leakage through screen
sharing. The tricky part is adding such an icon
On 12/12/14 15:29, Ehsan Akhgari wrote:
FWIW screen sharing has a ton of other unsolved privacy issues as well.
Yes, I would put this in the wholly manageable category of issues. I
think that a straight toggle (rather than click/touch and hold) is fine
for this.
How does this relate to use strict?
On Dec 19, 2014 12:19 PM, Jason Orendorff jorendo...@mozilla.com wrote:
So if you go to about:config and set the javascript.options.strict pref,
you'll get warnings about accessing undefined properties.
js Math.TAU
undefined
/!\
On Tue, Dec 23, 2014 at 9:55 AM, L. David Baron dba...@dbaron.org wrote:
But that's an implicit constructor that's causing extra refcount
traffic, which is one of the things we didn't want here.
I don't think that it's quite fair to complain about implicit conversion if
the whole point is to
On Tue, Dec 23, 2014 at 1:51 PM, L. David Baron dba...@dbaron.org wrote:
Just to be clear, is your problem the implicit conversion itself
or the reference count increment/decrement?
The latter -- the problem is that there's an implicit conversion
that has surprising side-effects.
Why are
I've been using TreeStat by Adam Roach for a while:
https://addons.mozilla.org/en-US/firefox/addon/treestat/?src=api
On Thu, Feb 5, 2015 at 7:53 AM, Jordan Santell jsant...@mozilla.com wrote:
Hey all,
If anyone's interested, I made an addon that lets you select an integration
tree (fx-team,
On Fri, Jan 16, 2015 at 12:41 AM, Jonas Sicking jo...@sicking.cc wrote:
FWIW, a difference in load time of 100ms is quite big. Websites like
Amazon has measured significant changes in clickthrough rates when
they have experimentally increased loadtime by 100ms.
I believe that significant
On Thu, Jan 15, 2015 at 4:30 PM, Steve Fink sf...@mozilla.com wrote:
But that's not the point. I totally agree that non-unified builds will
get broken immediately and will stay broken most of the time. That's not
in question. The point is how hard it is for someone who comes along and
wants
On Fri, Jan 16, 2015 at 12:58 AM, Anne van Kesteren ann...@annevk.nl
wrote:
* Permissions API this has been tried several times before. Given
that there's hardly any involvement from UX in standards, it's not
clear that this is a good idea. See also
Please note the need to liaise with the groups that are affected by the
permissions work. Otherwise, this is good.
On Fri, Jan 30, 2015 at 3:20 PM, L. David Baron dba...@dbaron.org wrote:
Here's a revised set of comments, mainly changing:
- describes the objection to powerfulfeatures (part
On Fri, Jan 30, 2015 at 10:40 PM, Brian Smith br...@briansmith.org wrote:
Anyway, my point isn't to suggest that Mozilla should ask for this
item to be removed from the charter. Rather, my point is that this
item has some pretty big, non-obvious ramifications (not just related
to tracking)
On Tue, Jan 27, 2015 at 2:51 AM, Daniel Stenberg dan...@haxx.se wrote:
I personally think it would be wrong to do it in connection with HTTP/2
since it'll bring a bunch of unrelated breakage to be associated with the
protocol bump.
I'd rather we didn't for similar reasons.
If we're
On Tue, Mar 17, 2015 at 12:05 PM, Aryeh Gregor a...@aryeh.name wrote:
1) SNI is reportedly still not usable if you care about IE on XP.
This means HTTPS is not usable on shared hosting, which is most small
sites, unless you don't care that your site doesn't load in IE on XP.
This is also a
On Tue, Mar 3, 2015 at 7:04 PM, Gregory Szorc g...@mozilla.com wrote:
This spreadsheet contains a list of files and their most frequently
associated bug component from commits landed since 2014.
Is there any harm in automatically marking files based on this then having
the community review
On Fri, Mar 27, 2015 at 7:59 PM, Botond Ballo bba...@mozilla.com wrote:
It would be really nice if there was a way to annotate whitespace-only
changesets as being such, and then configure tools such as hg blame
to look past them.
You mean `hg blame -w` ?
On Thu, Jan 29, 2015 at 1:59 PM, L. David Baron dba...@dbaron.org wrote:
Is this arguably a violation of the priority of constituencies principle?
It seems like it may serve the site more than the user.
Do you want to insist that it be removed from the charter, or is
this something you
On Mon, Apr 13, 2015 at 12:11 PM, Gervase Markham g...@mozilla.org wrote:
Are you sure privileged contexts is the right phrase? Surely contexts
are secure, and APIs or content is privileged by being only
available in a secure context?
There was a long-winded group bike-shed-painting session on
On Mon, Apr 13, 2015 at 3:53 PM, Eugene imfasterthanneutr...@gmail.com wrote:
In addition to APIs, I'd like to propose prohibiting caching any resources
loaded over insecure HTTP, regardless of Cache-Control header, in Phase 2.N.
This has some negative consequences (if only for performance).
On Thu, Apr 23, 2015 at 11:22 AM, Ed Lee edi...@mozilla.com wrote:
Similar to how we iterate on code to make Firefox faster, more usable, or
more functional; we would like to improve on user trust and transparency for
Suggested Tiles.
I don't think that piecemeal treatment of these issues in
On Thu, Apr 23, 2015 at 12:33 PM, e...@mozilla.com wrote:
Do you have suggestions on where each of the 4 topics I posted should be
discussed?
In a meeting, where a small number of participants are well-prepared.
___
dev-platform mailing list
On Tue, Apr 21, 2015 at 3:43 PM, Ryan VanderMeulen rya...@gmail.com wrote:
Seeing how often I get pushback from people over backouts, I wouldn't agree
with this premise, FWIW.
People, remember to *thank* the person who backs out your code.
Just like you should thank people for finding your
This is a digression, but it touches on an important question that
others are asking in response to this general push [1].
Fundamentally, better client authentication doesn't do anything to
help make the web a more secure place (in any of the dimensions that
we're primarily concerned about in
On Tue, Apr 28, 2015 at 3:52 AM, Aryeh Gregor a...@aryeh.name wrote:
Personally, I was surprised when I first learned that override/final
can only be used on virtual functions. I was definitely unaware that
override/final imply virtual until I read this thread. It seems David
Baron also
On Tue, Apr 21, 2015 at 10:02 AM, Christopher Lord cl...@mozilla.com wrote:
I'd appreciate any feedback (even if it's You're an idiot and this is not
how we go about this) before taking this any further.
Doesn't this increase the effective page transition latency by adding
the animation
On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert dholb...@mozilla.com wrote:
(I think there's a strong case for disabling *persistent* fullscreen
permission, for the reasons described in ekr's response to you here. I
haven't seen any proposal for going beyond that, but I might've missed it.)
A
On Fri, May 1, 2015 at 11:06 AM, Eric Shepherd esheph...@mozilla.com wrote:
There are a lot of things that don't need encryption,
This assertion is made quite often in this context. It's been shown to
be false in every example I've seen. I think Richard provided several
citations where this was
On Fri, May 1, 2015 at 11:25 AM, Chris Hofmann chofm...@mozilla.com wrote:
Is there a wiki page or some other comprehensive reference that defines the
issues and arguments around this central question?
Richard was - I think - in the process of assembling an FAQ that
covered this and other
On Wed, May 6, 2015 at 11:55 AM, Adam Roach a...@mozilla.com wrote:
Keep in mind the thesis of that plan isn't that we restrict
security-sensitive features to https -- it's that /all new stuff/ is
restricted to https. If this falls under the definition of a new feature,
and if it's going to be
On Wed, May 6, 2015 at 8:42 AM, Doug Turner do...@mozilla.com wrote:
This is important. We could mitigate by requiring https, only allowing the
top level document access these clipboard apis, and doorhangering the API.
Thoughts?
A doorhanger seems like overkill here. Making this
On Thu, May 14, 2015 at 10:35 AM, Gijs Kruitbosch
gijskruitbo...@gmail.com wrote:
I mean, obviously the example is simplified. You seem to think that ===
means I'm sure this will be the right type. In the same way you imply that
== indicates uncertainty about type (or acceptance of multiple
On Thu, May 14, 2015 at 9:40 AM, Gijs Kruitbosch
gijskruitbo...@gmail.com wrote:
Do you think the people that wrote the style guide (not me, so I'm not
trying to be defensive over the document, to be clear) did not understand
what they wrote? :-)
No, but I do think that they were wrong.
On Thu, May 14, 2015 at 5:17 AM, Gijs Kruitbosch
gijskruitbo...@gmail.com wrote:
On 14/05/2015 01:21, Martin Thomson wrote:
On Wed, May 13, 2015 at 4:54 PM, Matthew N.
mattn+firefox-...@mozilla.com wrote:
In JavaScript, == is preferred to ===. from
https://developer.mozilla.org/en-US/docs
On Wed, May 13, 2015 at 3:46 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
ise() was an alias to is() as of bug 949614. I landed bug 1154275 on
inbound today which removes ise() and replaces its usages with is(). Since
is() now does a === comparison by default, there should be no reason to
On Wed, May 13, 2015 at 4:54 PM, Matthew N.
mattn+firefox-...@mozilla.com wrote:
In JavaScript, == is preferred to ===. from
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Operators
Ahh, that's where it was hiding. Can we reverse that statement please?
On Thu, May 14, 2015 at 11:16 PM, Panos Astithas p...@mozilla.com wrote:
This. From the perspective of a library method validating inputs, I've
always found it pays off to rely on Postel's principle.
Sorry, that's a red flag for me. Postel was wrong. (Search for that phrase.)
On Tue, Apr 14, 2015 at 3:29 AM, Henri Sivonen hsivo...@hsivonen.fi wrote:
Specifically, on point #2, I think we should start by, by default,
forgetting all cookies that don't have the secure flag set at the
end of the Firefox session. Persistent cookies have two main use
cases:
* On
1 - 100 of 251 matches
Mail list logo
