I think that it is reasonable to expose this sort of information to
web extensions, and - for some things - possibly even to the web.
I don't think that we should start with nsISSLStatus directly. Though
it does have some relevant values, we should be careful to specify -
and justify - individual
On Fri, Feb 17, 2017 at 10:39 AM, Robert O'Callahan
wrote:
>> Using clang-format on the entire tree has the massive value of:
>
> Also, it's very liberating not having to think about formatting while
> writing code, knowing it will be automatically fixed up later. This is
> especially helpful for
On Sat, Feb 18, 2017 at 9:28 AM, Bobby Holley wrote:
>> If our main repository is going to always be under the control of some
>> official clang-format style, it should be possible for anybody to pull the
>> repository, and use a different formatter locally with their favorite
>> style. And when p
On Mon, Feb 20, 2017 at 3:18 AM, smaug wrote:
> I don't care too much about &&/|| coding style, though the current style
> does feel easier to
> read, per the reasoning dmajor gave.
I suspect that a lot of people think this way. While it's tempting to
suggest that arguments like "that's the way
I think that 60Hz is too high a rate for this.
I suggest that we restrict this to top-level, foreground, and secure
contexts. Note that foreground is a necessary precondition for the
attack, so that restriction doesn't really help here. Critically,
rate limit access much more than the 60Hz recom
On Wed, Apr 26, 2017 at 10:26 PM, Eric Rescorla wrote:
>> Surely we can avoid this problem without being so
>> drastic?
>
>
> Perhaps, but actually designing such security measures is expensive, so
> absent some argument that this is in wide use, probably doesn't
> pass a cost/benefit test.
Yeah,
On Fri, Apr 28, 2017 at 1:56 PM, Ehsan Akhgari wrote:
>> While it does not address the attack, it should be limited to secure
>> context, if we keep the API. It's actually in the spec.
>
> Why is that an advantage? Any attacker can use a secure context. The word
> "secure" here relates to the sec
On Thu, May 11, 2017 at 5:57 PM, Lars Hansen wrote:
> We do think there are
> architectural improvements that hardware manufacturers, operating systems,
> and browsers can make [19], and we intend to investigate them.
I think that the work you cite is promising. However, listening to
this presen
On Sat, May 20, 2017 at 4:55 AM, Kris Maglione wrote:
> Can we make some effort to get clean warnings output at the end of standard
> builds? A huge chunk of the warnings come from NSS and NSPR, and should be
> easily fixable.
Hmm, these are all -Wsign-compare issues bar one, which is fixed
upstr
On Sat, May 20, 2017 at 2:05 AM, Ben Kelly wrote:
> Can the people who have concerns about the NetworkInformation API please
> provide the feedback to google on this blink-dev thread:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/UVfNMH50aaQ/FEQNujAuBgAJ
In short, I don't think that t
On Thu, May 25, 2017 at 6:03 AM, Nathan Froyd wrote:
> Where does NSS do this? Cloning the NSS tree and grepping for
> sign-compare turns up no disabling of -Wsign-compare, except perhaps
> in XCode for gtest itself.
My bad, -Wsign-compare is in -Wextra, and we don't enable anything
extra. We d
On Wed, Jul 12, 2017 at 6:41 AM, Mark Côté wrote:
> * MozReview and Splinter turned off in early December.
Is this bugzilla-wide? I know that other project use splinter still.
Will those projects be able to use phabricator for their projects?
For instance, NSS uses a separate instance of phabri
On Wed, Jul 12, 2017 at 1:34 PM, Byron Jones wrote:
> instead of disabling splinter for phabricator backed products, we could make
> it a read-only patch viewer.
Given the number of bugs that exist with patches attached, that would
be greatly appreciated. I would also assume that attaching patch
On Wed, Jul 26, 2017 at 6:20 AM, Andrew Overholt wrote:
> 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?
I don't think that it is. If
More than fine, this is an overdue change :)
Notifications being available on http:// origins is a source of a
small amount of pain for web push, because the two share the same
permission.
On Tue, Aug 8, 2017 at 2:24 AM, Eric Rescorla wrote:
> This seems fine.
>
> -Ekr
>
>
> On Mon, Aug 7, 2017
On Wed, Aug 30, 2017 at 12:07 PM, L. David Baron wrote:
> I think I do this because (b) has the disadvantage that more code
> changes require touching additional lines, which is both changes
> blame and is extra work (although it's not extra work if we're using
> clang-format tree-wide). Option (
On Wed, Aug 30, 2017 at 5:21 PM, Sylvestre Ledru wrote:
> Could you report a bug? We wrote a few patches upstream to improve
> the support of our coding style.
This isn't a bug either, but I've noticed that alignment anywhere can
cause collateral changes. `clang-format -style=Mozilla -dump-confi
Why do the numbers need to be standardized? Could we give browsers
the ability to change the value in response to their understanding of
the current situation.
Surely an Android device is easily identifiable as such, so we could
choose values that reflect our Android population at the current
mom
On Fri, Sep 8, 2017 at 5:32 AM, Tom Ritter wrote:
> On Thu, Sep 7, 2017 at 1:09 PM, Shubhie Panicker via dev-platform
> wrote:
>> Curious - are there concerns with implementing Client Hints in general?
>
> Yes. But the fingerprinting team (specifically, I'm not sure what
> other teams have done)
On Fri, Sep 8, 2017 at 1:08 AM, Ehsan Akhgari wrote:
> The great majority of code changing is quite expected for any project
> switching to clang-format, since as it turns out automated tools are much
> better at doing this grunt work than humans are. The reason projects choose
> to switch to usi
On Tue, Sep 26, 2017 at 10:49 PM, Sylvestre Ledru
wrote:
>> clang-format messes up really badly many macros.
>> For example nsElementTable.cpp becomes unreadable.
>
> Yeah, for this kind of structure & presentation layout, we should just
ignore the formatting on these.
>
> It is hard for reformatt
On Wed, Sep 27, 2017 at 7:34 AM, Mike Hommey wrote:
> And then you end up with something like:
>
> class Foo {
> Type MethodA() { do_something(); }
> Type MethodB()
> {
> do_something_that_happens_to_be_long_enough_not_to_fit_on_the_same_line();
> }
> Type MethodC() { do_something_el
The suggestion that was made in the past was to tie orientation to
geolocation. I think that this would be obvious enough to pass.
Orientation is basically a refinement of position. It clearly makes
sense for AR applications. Pure VR applications might only care about
relative orientation and so
On Thu, Jan 4, 2018 at 2:52 AM, Blair MacIntyre wrote:
> I was more concerned about the idea (or, at least what I though might be
> suggested) that you only get orientation if they give location permission.
> This seems overkill: even if I know what the data means, I can see uses of
> orientation
On Thu, Jan 4, 2018 at 1:09 PM, Blair MacIntyre wrote:
> We could chat about it, sure; how do you envision it working without
> breaking old websites?
With the understanding that this is purely spitballing...
We would stop providing events (or provide them with extremely low
frequency [1]), bu
Without the protocol pieces, this remains vendor-specific. We should
comment on this and make it clear that we think that definition of a
generic protocol for interacting with the second display has not been
given sufficient priority. Allowing this to proceed without a generic
protocol would be b
On Thu, Jan 4, 2018 at 5:50 PM, wrote:
> FYI: As implemented in Chrome, permission is automatically granted to use the
> Generic Sensor API (`chrome://flags/#enable-generic-sensor`) in secure
> contexts (e.g., HTTPS, localhost).
Requiring secure contexts is not a security feature. It's necess
On Thu, Jan 4, 2018 at 9:06 PM, chris wrote:
> Thanks for the clarification, Martin. Providing that the UA persists
> permissions (based on user action –or perhaps also leveraging Google’s Safe
> Browsing API which Firefox and all other browsers already rely upon –
> revoked and prompted -> denied
t, perhaps this is too confusing.
>
> For the perms API, I imagined it might just work with devicemotion: setting
> up the callback could trigger a perms request, and the data would only start
> flowing on acceptance.
>
>> On Jan 3, 2018, at 11:52 PM, Martin Thomson wrote:
>>
hope it will allow for interoperable
> >> > > discovery of, identification of, and communication with presentation
> >> > > displays. However, we're deeply concerned about chartering a second
> >> > > iteration of the work that continues building
What Anne said. None of these actions help address the primary concern.
On Wed, Jan 10, 2018 at 2:23 PM, wrote:
> Exciting to hear, Kyle!
>
> As mentioned earlier, Chrome for Android M63+ has shipped an implementation
> (disabled by default, with an Origin Trial) of the Generic Sensor API, but
On Thu, Jan 11, 2018 at 3:39 PM, Chris Van Wiemeersch wrote:
> Anne and Martin, can you think of changes to request for the Sensor API that
> we would resolve or reasonably improve the existing fingerprinting concerns?
In general, we can't improve the situation by adding more
functionality. That
As Anne said, I don't know why you would define a new API rather than
enhancing the existing one, other than NIH. But I guess the damage is
now done.
On Fri, Jan 12, 2018 at 4:48 AM, Blair MacIntyre wrote:
>> On Thu, Jan 11, 2018 at 5:30 PM, Blair MacIntyre
>> wrote:
>>> First, this discussion
Great news. Thanks to all those involved for getting to this point.
Anne, your posting suggests an exception is likely if:
* other browsers already ship the feature insecurely
* it can be demonstrated that requiring secure contexts results in
undue implementation complexity.
Either of these cri
On Tue, Feb 6, 2018 at 3:37 AM, Andreas Tolfsen wrote:
> Motivation:
> To give web authors a way to infer if user agent is controlled by
> automation, so the document can take alternate code paths when under
> test.
Can you speak more about why this is a good idea? I've poor
experience with "thi
+ffxdev
There's a tangible difference between text saying "Not Secure" and a
broken lock icon. I think that we're close, but we'd be making a
stronger statement than Chrome if we did this.
On Fri, Feb 9, 2018 at 8:17 AM, Chris Peterson wrote:
> Chrome will start marking HTTP pages as "Not secur
Yes, it pays to remember that this is Nightly.
The precautions Henri suggests are good, but more appropriate to
experiments we would do on Release. For TLS 1.3, we did that sort of
thing so that we could get measurements from Release; we just flipped
the switch to "on" for Nightly.
I don't know
This seems like a good idea.
Please consider adding hg.mozilla.org to your list of things you will
clone from. That will allow us to remove some ugly hacks from the
tree for vendoring NSS and NSPR. (libffi uses the same script, but it
seems to be on GitHub now, so that seems like an easy win ass
On Tue, Apr 10, 2018 at 6:41 AM, glob wrote:
>> You don't permit the use of a tag for vendoring, is that intentional?
>
> to echo gps and mike's responses use of a sha to is preferred over tags.
Maybe. We currently use tags.
Think about the usage model. If the process is to author the YAML,
th
This seems like it's about time. bz's numbers aren't awe-inspiring,
but low enough that I think we'll manage.
I checked, and there was a question about reviving this in the spec,
but that resolved over a year ago (just before when the deprecated
message was added in Firefox, perhaps coincidentall
Hi Chris,
I assume that "just fix it" is still a viable alternative to the processes
you describe. For small things, that might be easier for all involved.
On Thu, May 17, 2018 at 5:39 AM Chris Mills wrote:
> Hi all,
> I am sending a mail around to explain how to request MDN documentation
for
On Thu, Jun 28, 2018 at 1:21 AM Benjamin Francis wrote:
> On 25 June 2018 at 16:50, Brannon Dorsey wrote:
>
> > As far as I see it, a
> > domain name should never be allowed to respond with a private IP address
> > moments after it first responded with a public IP address.
> >
>
> If I understand
On Mon, Aug 3, 2015 at 6:07 PM, Jonas Sicking wrote:
> How would you make a factory function like the above fail?
Don't allow for the possibility. If Foo::Create() is directly
analogous to new Foo(), then it can't fail. Leave the failing for
later method calls.
On Tue, Aug 4, 2015 at 8:24 AM, Tim Taubert wrote:
>> Can we just reduce the accuracy of the API? Only give battery level at
>> certain broad breakpoints?
>
> The authors of the cited paper [1] filed a bug report and we fixed that
> for 38 [2].
I should think that more aggressive rounding would
On Tue, Aug 4, 2015 at 9:33 AM, Jonas Sicking wrote:
> So disabling the API, or fudging its return values, in private
> browsing windows sounds like a good idea. The same applies to features
> like device orientation, proximity/light sensors, network information
> (wifi vs. mobile etc), device ori
On Wed, Aug 5, 2015 at 3:59 PM, Matthew N. wrote:
> If we have data on CPU architecture I don't think the OS version is relevant
> unless I'm missing something.
My understanding is that OS version is all that matters. 64-bit apps
require a 64-bit OS. (Such an OS requires a 64-bit processor of
c
On Tue, Aug 11, 2015 at 3:07 AM, Julien Wajsberg wrote:
> Can you share what the plan is for Fx/Android and Firefox OS ?
Firefox OS can (and likely will) use the same basic technology, though
the UX story there is incomplete.
Fennec needs extra work in order to integrate with GCM (or Google Play
On Fri, Aug 14, 2015 at 2:56 PM, Vladan D wrote:
> Tests are reliable if they detect regressions, aren't very noisy, and if they
> measure things that have a real impact on actual Firefox user experience.
Do we track false positives on these? I say that because I got a mail
just last week for t
On Fri, Aug 14, 2015 at 3:44 PM, Vladan Djeric wrote:
> Is this the ts_paint regression you're referring to?
> https://groups.google.com/forum/#!searchin/mozilla.dev.tree-alerts/ts_paint/mozilla.dev.tree-alerts/FArVsa8guXg/FfY91JK7AAAJ
Yeah. I only ask because in exercising judgment suppresses
i
On Tue, Aug 25, 2015 at 2:12 AM, Anne van Kesteren wrote:
>>> 3) It seems the API is evolving in ways to also request permission
>>> without then directly using that permission. It's not clear that is a
>>> good idea.
>>
>> This is something that is already doable. If a webpage calls
>> navigator.
WebRTC was shipped with a prefix.
Bug 1155923 moves our codebase to non-prefixed names, but includes a
patch to restore aliases with the prefix. Thus we will expose
`RTCPeerConnection` and use that ourselves, but permit legacy code to
use `mozRTCPeerConnection`.
Maybe some day we can remove the
On Tue, Aug 25, 2015 at 2:16 PM, Ehsan Akhgari wrote:
> On 2015-08-25 4:07 PM, Martin Thomson wrote:
>>
>> WebRTC was shipped with a prefix.
>>
>> Bug 1155923 moves our codebase to non-prefixed names, but includes a
>> patch to restore aliases with
Henry, I would rather you attempt to address Ryan's point 5, namely:
5) just generates keys, and relies on
application/x-x509-*-cert to install certificates. This MIME handling,
unspecified but implemented by major browsers, represents
yet-another-way for a website to make persistent modification
I have some questions, to which I was unable to find answers for in
the (numerous and long) threads on this subject.
1. When we download and install a client cert, what checking do we do?
Do we insist upon it meeting the same algorithm requirements we have
for servers with respect to use of thing
i wrote:
> [No idea if these will show up on the lists since I'm not subscribed]
>
> On Fri, Sep 11, 2015 at 9:30 PM, Martin Thomson wrote:
>
>> I have some questions, to which I was unable to find answers for in
>> the (numerous and long) threads on this subject.
&g
I want to get some very rough numbers for our entire userbase, but I
don't know how to go from "number of users who opted in to telemetry"
to "all users". Do we have any information on the proportion of users
opt in to telemetry?
___
dev-platform mailing
On Wed, Oct 14, 2015 at 6:32 PM, Gregory Szorc wrote:
> As you stated, this helps detect errors earlier during development, which
> is a huge win. Is there a good reason configure doesn't enable the clang
> plugin by default?
Yes please. If the checks are expensive, ac_add_options
--disable-cla
On Fri, Oct 16, 2015 at 6:39 AM, Boris Zbarsky wrote:
> You should _especially_ not create attributes of type Date.
Well, that's interesting. I think that I might have to eat crow:
https://github.com/w3c/webrtc-pc/issues/324
I didn't read all the discussion, but what is wrong with treating Dat
On Fri, Oct 16, 2015 at 9:30 AM, Boris Zbarsky wrote:
> I'm not sure what custom code you're talking about. What exactly are you
> proposing?
Date is fundamentally just an integer when you get down to it. Treat
it like one. An integer value is copied when you return it, so
modifications don't
WFM. I'll see what I can do about fixing RTCCertificate. I think
that the breakage should be minimal if I just change it.
On Fri, Oct 16, 2015 at 11:44 AM, Boris Zbarsky wrote:
> On 10/16/15 2:00 PM, Martin Thomson wrote:
>>
>> On Fri, Oct 16, 2015 at 9:30 AM, Boris Zbarsky
On Fri, Dec 4, 2015 at 8:04 PM, Robert O'Callahan wrote:
> However, for USB the "Web driver" approach seems better than that, to me.
> It makes it easy to update the vendor library to fix security bugs and
> update the API. If the Web API is baked into the device firmware that's a
> lot harder.
T
On Thu, Dec 10, 2015 at 5:17 PM, Robert O'Callahan wrote:
> On Fri, Dec 4, 2015 at 4:56 PM, Eric Rescorla wrote:
>
>> (4) Have the APIs hidden behind access controls that need to be enabled by
>> an extension
>> (but a trivial one). Perhaps you think this is #2.
>>
>
> I realized I don't understa
On Thu, Dec 31, 2015 at 5:40 PM, Daniel Holbert wrote:
> Summary:
> A good chunk of the web today (and particularly the mobile web)
> effectively relies on -webkit prefixed CSS properties & features. We
> wish we lived in a world where web content always included
> standards-based fallback (or a
On Fri, Jan 1, 2016 at 8:15 AM, Daniel Holbert wrote:
> (3) False positives: There are many "legitimate" ways that authors can
> use prefixed properties
Yep, you convinced me with this.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https
Well, if khuey ever got into splitting the event loop, we might be
able to make progress on other tasks, but as far as I can see, detect
and throw is probably the best option.
On Thu, Jan 14, 2016 at 8:44 PM, David Rajchenbach-Teller
wrote:
> I also think that this makes sense. Can we already sta
sed -i~ -e '/#ifdef XP_MACOSX/d' xul files
I think that we need more information on what it is that you intend to
do if we are to make a sensible suggestion.
On Mon, Feb 1, 2016 at 5:23 PM, Yonggang Luo wrote:
> How to remove #ifdef XP_MACOSX in xul files?
> _
On Tue, Feb 2, 2016 at 10:42 AM, Milan Sreckovic wrote:
> Surprisingly, perhaps, there are a lot of people using Firefox on 32-bit
> Windows. If I’m reading the data correctly, more than half. A small
> percentage of those don’t have SSE2.
Do we have any, say telemetry, that would move this f
On Wed, Feb 3, 2016 at 12:54 AM, Benjamin Smedberg
wrote:
>> Do we have any, say telemetry, that would move this from speculation
>> into numbers? Sure, numbers aren't necessarily perfect, but I'm sure
>> that they would help.
>
> Milan is quoting numbers from telemetry data. The last time I calc
On Thu, Feb 4, 2016 at 2:21 AM, Milan Sreckovic wrote:
> 99.77% of the users on all channels have SSE2 support;
> 51.7% of all users are on 32-bit Windows;
> 0.44% of all users on 32-bit Windows do not have SSE2 support.
Those numbers wouldn't justify a change to me. When we make decisions
about
I know that this is not good practice, but is there something written
down somewhere explaining why?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
e are some people who consider the fact that a dictionary
becomes outside the control of the browser to be a feature. That is
partly why WebRTC is how it is.
On Mon, Feb 15, 2016 at 10:11 AM, Cameron McCormack wrote:
> Martin Thomson:
>> I know that this is not good practice, but is t
On Mon, Feb 15, 2016 at 12:30 PM, Valentin Gosu wrote:
>> Thumbnails, or columns on the right for each selected browser with
>> median (or mean), with the best (for that site) in green, the worst in
>> red would allow eyeballing the results and finding interesting
>> differences without clicking o
On Mon, Feb 15, 2016 at 1:12 PM, Martin Thomson wrote:
> On Mon, Feb 15, 2016 at 12:30 PM, Valentin Gosu
> wrote:
>>> Thumbnails, or columns on the right for each selected browser with
>>> median (or mean), with the best (for that site) in green, the worst in
>>&g
This is great.
As I said elsewhere, I don't think that we can pref this on until bug
1252650 lands. It turns out that "gecko not running" is pretty much
the only interesting state for push.
On Thu, Mar 3, 2016 at 5:06 AM, Nicholas Alexander
wrote:
> Summary: "The Push API gives web applications
On Thu, Mar 3, 2016 at 10:45 AM, Mike Hommey wrote:
> More importantly, changing the official toolchain has implications on
> performance.
Without any real evidence for this, I'm told that GCC still produces
better (i.e., faster) output. But we could switch try builds to clang
if the time saving
On Wed, Mar 9, 2016 at 6:42 AM, Jonas Sicking wrote:
> I know there's some concern that always sending CH with all requests
> would generate too much header traffic which would be wasteful.
We could limit the feature to h2. (Which would also address the other
request, which is to limit this to
On Fri, Mar 11, 2016 at 5:56 AM, Axel Nennker wrote:
> no password generation help by the UA
I agree with MattN here, not doing this eliminates much of the
advantage of having a password manager. Or do you have a plan to rely
on sites doing that with CredentialContainer.store()? That doesn't
so
On 12 Mar 2016 7:28 PM, "Anne van Kesteren" wrote:
> It should be identical to password manager integration.
But it is not, though I suppose that a password manager might be exploited
to store state. I hope that isn't possible... (note to self, attempt this
attack)
> > In that case, credentials
Now that is a frightening observation. Is this creating a more persistent
(pernicious?) tracking mechanism?
In that case, credentials stored by a site should last no longer than
cookies. Credentials created by a user maybe can live longer.
On 12 Mar 2016 04:41, "Anne van Kesteren" wrote:
> On Fr
I don't think that there was any misunderstanding in what it is that
is being proposed, just disagreement about cost-benefit.
On Mon, Mar 14, 2016 at 8:02 PM, Mike West wrote:
> Websites use passwords today. While I agree that we can and should be
> working on something better, I don't think that
On Wed, Mar 23, 2016 at 10:59 PM, Philip Chee wrote:
> Thunderbird cannot migrate (easily). The only functionality in Devtools
> that they currently can use is the Debugger (as a remote client).
If they are alone, then maybe they might consider adoption.
__
On Wed, Mar 30, 2016 at 12:41 PM, Xidorn Quan wrote:
> I'd suggest you use https instead, it seems to work with ftp.mozilla.org :)
Indeed. Don't drop the scheme entirely either, since Firefox attempts
to use FTP, which isn't available on that server.
_
I would like to see other browsers on board before taking on these risks.
And a lot more testing.
For instance, is there a way to collect telemetry on the impact of
such a change without actually implementing it? Does restricting it
to 3rd party requests change things?
On Fri, Apr 15, 2016 at 1
On 17 Apr 2016 2:37 AM, "Haik Aftandilian" wrote:
>
> Sites might depend on a combination of https and non-https cookies and
then
> act strangely when a user returns to the site with only the https cookies.
This is also known as a security vulnerability. See
https://www.usenix.org/conference/usen
I prefer the fallible, if failed return null else return new pattern
myself also. With a little RAII, it keeps manual cleanup to a
minimum.
On Thu, Apr 21, 2016 at 8:24 PM, Nicholas Nethercote
wrote:
> - It doesn't appear to work with stack-allocated objects?
The advantage with a heap-allocated
On Fri, Apr 22, 2016 at 1:05 AM, Nicholas Nethercote
wrote:
> The third example I looked at was CycleCollectedJSRuntime. Again
> problems, specifically this line in Init():
>
> mOwningThread->SetScriptObserver(this);
Others have already said what I would have here generally, but this
example is
In NSS, we have landed bug 1183318 [1], which I expect will be part of
Firefox 48.
This disables the use of the SSLKEYLOGFILE environment variable in
optimized builds of NSS. That means all released Firefox channels
won't have this feature as it rides the trains.
This feature is sometimes used t
On Tue, Apr 26, 2016 at 4:10 PM, Xidorn Quan wrote:
> Could we probably restrict it to non-release builds (aurora and nightly)
> rather than restrict them to debug builds only? Debug builds are harder to
> get, and are slow.
That was suggested, but we decided against it in bug 1188657. I think
t
On Tue, Apr 26, 2016 at 6:08 PM, Jonas Sicking wrote:
> Limiting this to aurora builds might make the most sense here since
> that's what we're pushing as the build that developers should use.
I'm OK with that; that's why I asked here.
https://bugzilla.mozilla.org/show_bug.cgi?id=1188657
___
On Tue, May 24, 2016 at 7:29 PM, Jeff Gilbert wrote:
> What's the build-time impact of this?
The implicit question being, if this impact is non-zero, can I turn it
off? Also, does it make any sense to do this on try machines?
___
dev-platform mailing l
On Thu, Jun 23, 2016 at 3:19 AM, Anne van Kesteren wrote:
> We should just let them do their thing and do our thing elsewhere.
This seems like a reasonable plan. Unless and until someone thinks
that a course correction is feasible, or decides that it's worth
trying.
_
On Fri, Jul 1, 2016 at 9:55 AM, Robert O'Callahan wrote:
> In theory responses 301 and 308 mean "permanent redirect" so the browser
> could do that for those responses.
Those would only work for as long as the 3xx is remembered, and it
wouldn't work for /x if you have only seen /y redirect.
To g
Is now the right time to start talking about retiring checkin-needed,
or is it still heavily used?
On Sat, Jul 9, 2016 at 4:58 AM, Gregory Szorc wrote:
> On Fri, Jul 8, 2016 at 11:39 AM, Felipe G wrote:
>
>> Is there a way to make the checkin-needed flag generate a template comment
>> (like the
On Mon, Jul 11, 2016 at 2:18 PM, Xidorn Quan wrote:
> Isn't it still necessary for people who don't yet have permission to
> push?
That suggests to me that there are missing safeguards on autoland.
Otherwise we could just enable it even for those with try access.
> I also use checkin-needed for
Sounds like a good plan.
(For those who might be wondering: .request() was never exposed.)
On Wed, Aug 17, 2016 at 2:48 PM, wrote:
> Summary: It seems we prematurely shipped the .revoke() method on the
> Permissions API before it was stable or deciding if we even wanted it in the
> platform.
On Wed, Aug 17, 2016 at 5:02 PM, Anne van Kesteren wrote:
> The main problem with query as I see it is that since we haven't
> agreed on what permissions are keyed on, an application cannot really
> do anything with the answer it gets from query. E.g., communicating
> the answer with other open ta
On Wed, Aug 17, 2016 at 5:34 PM, Anne van Kesteren wrote:
> Interesting, I guess I didn't realize that covered more than just
> query(). If we ship a subset of an API it probably would help to be
> clear, indeed.
Well, it only mentioned .query() explicitly, but then said "other
parts will be impl
On Tue, Oct 11, 2016 at 12:52 PM, L. David Baron wrote:
> My initial reaction would be to worry about whether there's
> properly-incubated material here that's appropriate to charter a
> working group for, or whether this is more of a (set of?) research
> projects. W3C has an existing Interest Gr
On Thu, Oct 13, 2016 at 6:21 AM, Benjamin Francis wrote:
> Much more compelling is the member submission from EVRYTHNG which also forms
> the basis of the book, Building the Web of Things.
Yes, that is a much clearer articulation of a vision. It starts going
off the rails in a few places as it g
On Thu, Oct 13, 2016 at 11:26 AM, Tantek Çelik wrote:
> Security is the number one problem for anything "ot" (iot, wot,
> wotever),
I agree with this sentiment, but I don't think that we need to insist
that a new W3C group solve these issues. I'm very much concerned with
the question of how a ne
1 - 100 of 262 matches
Mail list logo
