On Tue, Apr 26, 2016 at 02:27:31PM +0800, Xidorn Quan wrote:
> On Tue, Apr 26, 2016 at 2:17 PM, Martin Thomson wrote:
>
> > 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 de
On Tue, Apr 26, 2016 at 2:17 PM, Martin Thomson wrote:
> 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.
>
>
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
I can realize that this might open some holes, but it is also a useful
function for developers to investigate how their connection goes. (I
thought about this kind of function yesterday, but I wasn't aware it has
been already available.)
Could we probably restrict it to non-release builds (aurora
I'd also love to take this opportunity to remind everyone, especially
our newer contributors and developers, to be sure to add the
"dev-doc-needed" keyword to the appropriate bugs for any changes which
should include updates to documentation on MDN.
See
https://developer.mozilla.org/en-US/docs/Moz
On 4/26/16 1:02 AM, Mike Hommey wrote:
Shouldn't we just kind of repurpose the superreviewers, update the list,
and keep it fresh?
I think that would be pretty reasonable, yes.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
http
On 2016-04-26 1:02 PM, Mike Hommey wrote:
> On Mon, Apr 25, 2016 at 10:52:02PM -0400, Boris Zbarsky wrote:
>> On 4/25/16 10:34 PM, Mike Hommey wrote:
>>> Don't we already have that with superreviewers?
>>
>> Kinda, sorta.
>>
>>> (How outdated is that list, btw?)
>>
>> Quite. If we're talking about
On Mon, Apr 25, 2016 at 10:52:02PM -0400, Boris Zbarsky wrote:
> On 4/25/16 10:34 PM, Mike Hommey wrote:
> >Don't we already have that with superreviewers?
>
> Kinda, sorta.
>
> >(How outdated is that list, btw?)
>
> Quite. If we're talking about
> https://www.mozilla.org/en-US/about/governance
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 4/25/16 10:34 PM, Mike Hommey wrote:
Don't we already have that with superreviewers?
Kinda, sorta.
(How outdated is that list, btw?)
Quite. If we're talking about
https://www.mozilla.org/en-US/about/governance/policies/reviewers/ then
of the 30 people on the list, I would say:
* 10
On 4/25/16 10:31 PM, Domenic Denicola wrote:
On Monday, April 25, 2016 at 2:09:07 PM UTC-4, Boris Zbarsky wrote:
1) This is not feature-detectible, as far as I can see. So it's not
clear to me that sites will know they can use this, short of relying on
browser sniffing.
If you implement DOMT
On Tue, Apr 26, 2016 at 10:31:06AM +0800, Ehsan Akhgari wrote:
> On 2016-04-25 10:58 PM, Boris Zbarsky wrote:
> > That said, note that a bunch of the items above lie somewhat out of a
> > specific module, so it's not clear to me that we want intent-to-ship OKs
> > to be module-specific.
>
> Yeah,
On Monday, April 25, 2016 at 2:09:07 PM UTC-4, Boris Zbarsky wrote:
> 1) This is not feature-detectible, as far as I can see. So it's not
> clear to me that sites will know they can use this, short of relying on
> browser sniffing.
If you implement DOMTokenList.prototype.supports, it should be
On 2016-04-25 10:58 PM, Boris Zbarsky wrote:
> That said, note that a bunch of the items above lie somewhat out of a
> specific module, so it's not clear to me that we want intent-to-ship OKs
> to be module-specific.
Yeah, a bunch of stuff definitely crosses multiple module boundaries, so
I think
Sometime later this week Task will become Runnable too.
- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Tuesday, April 26, 2016 at 3:39:53 AM UTC+10, Botond Ballo wrote:
> That's why we have explicit operator bool() in C++11. That only allows
Indeed. explicit operator was implied.
Here is an example of definition:
https://dxr.mozilla.org/mozilla-central/source/dom/media/MediaData.h#201
I used to be the module owner of our coding conventions, but I believe that
duty has now fallen on Nathan Froyd with the establishment of the new
module covering c++ idioms and usage, noted in this governance thread:
https://groups.google.com/forum/#!searchin/mozilla.governance/froyd/mozilla.govern
On 2016-04-25 2:41 PM, a...@imgland.xyz wrote:
I am a developer who has experimented with Firefox tweaking before and
I would be intrested in running a "proof-of-concept" branch or fork of
Firefox with the latest features added before any sort of review to
see how they play out in a normal brow
On 4/25/16 2:57 PM, Tanvi Vyas wrote:
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1267339
I think you meant to link to bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1222516 here.
Er... right you are. Too many identical-looking tabs. ;)
-Boris
__
Very cool! Thanks for implementing.
On 4/25/16 11:09 AM, Boris Zbarsky wrote:
Summary: The idea is to be able to write
Go
there
and not have "someone-I-don't-trust" be able to get hold of your
window via window.opener.
This is already possible with rel="noreferrer", but that also preve
I am a developer who has experimented with Firefox tweaking before and I would be intrested in running a "proof-of-concept" branch or fork of Firefox with the latest features added before any sort of review to see how they play out in a normal browser. I would like to have everybody's thoughts on t
Summary: The idea is to be able to write
Go
there
and not have "someone-I-don't-trust" be able to get hold of your window
via window.opener.
This is already possible with rel="noreferrer", but that also prevents
sending a referrer, which is undesirable in cases like search engine
result
Here is a change I made when investigating `ScriptSource`s outliving their
`JSRuntime` because of `ScriptSourceObject`s being considered reachable
after the final DESTROY_RUNTIME collection, and therefore not having their
finalizer run, which would have freed the leaking `ScriptSource`s. I am
itera
On Mon, Apr 25, 2016 at 1:06 PM, Jim Blandy wrote:
> On Mon, Apr 25, 2016 at 4:03 AM, Jean-Yves Avenard
> wrote:
>
>> I don't know how popular this method would be, nor if people would be
>> shocked by providing a operator bool() but here it is :)
>>
>>
> Usually, the people most shocked by provi
Could you show a sample patch that uses this?
On Mon, Apr 25, 2016 at 10:19 AM, Nick Fitzgerald
wrote:
> Hi everyone!
>
> Friendly PSA: sometimes you're debugging a "leak" where the GC considers
> something reachable and therefore won't collect it, and this happens at an
> inopportune time for u
Hi everyone!
Friendly PSA: sometimes you're debugging a "leak" where the GC considers
something reachable and therefore won't collect it, and this happens at an
inopportune time for using the devtools memory panel (eg right before a
DESTROY_RUNTIME collection), so you can't use the nice GUI for vi
On Mon, Apr 25, 2016 at 4:03 AM, Jean-Yves Avenard
wrote:
> I don't know how popular this method would be, nor if people would be
> shocked by providing a operator bool() but here it is :)
>
>
Usually, the people most shocked by providing an operator bool() are those
who find the type silently pa
I support this as a web designer
25.04.2016, 15:10, "Philipp Kewisch" :
> Hi Anne,
>
> thanks for the update! I'm looking forward to seeing web components
> work, I think they will be very helpful for future web and html based
> application development.
>
> Philipp
> __
2016年4月26日火曜日 0時50分46秒 UTC+9 Till Schneidereit:
> On Mon, Apr 25, 2016 at 8:41 AM, oonuma ryouyu
> wrote:
>
> > I think this is not bug.
> > Or normally firefox memorized breakpoints before restart?
> >
>
> You're right: breakpoints aren't remembered across restarts, so that part
> isn't a bug.
On Mon, Apr 25, 2016 at 8:41 AM, oonuma ryouyu
wrote:
> I think this is not bug.
> Or normally firefox memorized breakpoints before restart?
>
You're right: breakpoints aren't remembered across restarts, so that part
isn't a bug. The breakpoint being ignored, however, is a bug. Have you made
sur
2016年4月26日火曜日 0時02分02秒 UTC+9 Brian Grinstead:
> (moving over to the developer tools list)
>
> Thanks for reporting this - I’ve heard about a couple of issues similar to
> this lately, but haven’t been able to reproduce it myself so another data
> point is great. Do you see the problem both with
(moving over to the developer tools list)
Thanks for reporting this - I’ve heard about a couple of issues similar to this
lately, but haven’t been able to reproduce it myself so another data point is
great. Do you see the problem both with and without e10s enabled? Also, does
it happen on a c
On 4/25/16 1:47 AM, Jet Villegas wrote:
The "Intent to Implement" should help some of the concerns and allow for
comments. "Intent to Ship" usually means (at least for Platform Rendering)
that we'll be removing the #ifndef RELEASE flags and enabling preferences.
That is, by the time the "Intent t
Hi Anne,
thanks for the update! I'm looking forward to seeing web components
work, I think they will be very helpful for future web and html based
application development.
Philipp
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://list
hello!
I am trying to debugging on browserToolBox.
I open browserToolBox and open debugger and setting breakpoint, but don't stop.
because set statement was passed.
Then I restart firefox, but it was not memorize breakpoint.
Thanks for help.
___
dev-p
Ryan VanderMeulen
writes:
> Treeherder makes it easy to do this - just hit the little circle with an X
> icon on the right hand side adjacent to the "XX% - Y in progress" text
> along the top bar of the push. You will be prompted whether you really want
> to cancel all jobs on the push. Just hit
Hello,
I would like to view (capture) the data sent by a client web browser (firefox
45.0.2, ubuntu OS), to any visited website, when following about:config
settings are done.
I would like to view (capture) this data - with default setting as well as
after changing the settings (user set)
bea
You aren't clear on what level you want to capture the data. The gold
standard to see exactly what is communicated would be wireshark. When https
is used (hopefully all the time) it can automatically decode the traces if
you provide the key material -
https://developer.mozilla.org/en-US/docs/Mozill
Hi everyone,
Here's the list of new issues found and filed by the Desktop Release QA
team last week, *April 18th - April 22nd* (week 16).
Additional details on the team's priorities last week, as well as the
plans for the current week are available at:
https://public.etherpad-mozilla.org
On Thursday, April 21, 2016 at 11:15:10 AM UTC+10, Nicholas Nethercote wrote:
> The only disadvantage I can see is that it looks a bit strange at first. But
> if
> we started using it that objection would quickly go away.
>
> I have some example patches that show what this code pattern looks like
For info, the following devtools bug has received some discussion related
to an "in-page" shapes editor:
https://bugzilla.mozilla.org/show_bug.cgi?id=1242029
On Thu, Apr 21, 2016 at 3:08 AM, Jonathan Watt wrote:
> Summary:
>
> Currently clip-path clipping requires a reference to an SVG
>el
Hello,
I would like to view (capture) the data sent by a client web browser
(firefox 45.0.2, ubuntu OS), to any visited website, when following
about:config settings are done.
I would like to view (capture) this data - with default setting as well as
after changing the settings (user set)
beacon
42 matches
Mail list logo
