the WDSpec
tests, a subset of Web-Platform Tests used for testing the WebDriver
specification. Testharness.js and reftests in the Web-Platform tests will
still be working as they use Marionette via another means.
Let me know if you have any questions.
David
should remove it.
Would you be able to try searching for those minutes? I know
there's been an in-person discussion (and I think it was at a
meeting at a TPAC a few yeas ago).
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://
I am not saying it should but if we have a requirement for python 3, we are
also going to have a requirement for py2 to both be available for local
development.
David
On 11 November 2017 at 14:10, Andrew Halberstadt <ahalberst...@mozilla.com>
wrote:
> On Fri, Nov 10, 2017 at 9:44 PM Da
of the
mozbase stuff is already moving to python 3 support but that still means we
need to have web servers and the actual test runners moved over too.
David
On 10 November 2017 at 23:27, Gregory Szorc <g...@mozilla.com> wrote:
> For reasons outlined at https://bugzilla.mozilla.org/
> sho
I use #developers for two things:
1. I prefer to keep my discussions in smaller topic channels, but for my
sanity I also try to keep my channel list small. There is a large set of
people whom I ping roughly once a month and can't be bothered matching
channels with. #developers is my "lowest
As a user, I would definitely love to have this.
I wanted to add something like that to about:performance, but at the
time, my impression was that we did not have sufficient platform data on
where allocations come from to provide something convincing.
Cheers,
David
On 02/11/17 15:34, Randell
On 11/03/2017 03:34 PM, Robert Helmer wrote:
> On Fri, Nov 3, 2017 at 3:25 PM, David Keeler <dkee...@mozilla.com> wrote:
>> [firefox-dev, dev-addons, and the enterprise mailing list cc'd - please
>> direct follow-up discussion to dev-platform]
>>
>> Hello All,
>
we should disallow this?)
Thanks,
David
signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
grown in the past X amount of time" or past a certain
threshold, that's the best indicator I've come up with.
I don't know what we'd do at that point -- force killing the content
process sounds severe (though possibly correct) -- or some alert similar to
the dreaded slow script one.
--
D
, and easily testable on Try. Thank you!
On Wed, Oct 25, 2017 at 5:48 PM, David Major <dma...@mozilla.com> wrote:
> I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
> 1408789.
>
> VS2017 has optimizer improvements that produce faster code. I've seen
), I'm
comfortable with that number. If it goes longer than that, I agree it makes
sense to wait for a new train.
On Thu, Oct 26, 2017 at 3:31 AM, Sylvestre Ledru <sle...@mozilla.com> wrote:
> Hello,
>
>
> On 25/10/2017 23:48, David Major wrote:
> > I'm planning to move p
Agreed, changing compilers of an already-released ESR isn't a good idea.
You could use 2017 to build ESR52 locally though, if that's what you're
asking. Our tree has supported 2017 builds for a good while, since it's the
default VS download from Microsoft and a number of Mozillians have been
I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
1408789.
VS2017 has optimizer improvements that produce faster code. I've seen 3-6%
improvement on Speedometer. There is also increased support for C++14 and
C++17 language features:
Btw, I believe that there is already support for reporting uncaught
errors and that it is blocked by the lack of test harness support.
Cheers,
David
On 18/10/17 19:37, Steve Fink wrote:
> My gut feeling is that you'd only want uncaught errors, and
> AutoJSAPI::ReportException is a better
This should be feasible.
Opening bug 1409852 for the low-level support.
On 18/10/17 22:22, Dan Mosedale wrote:
> Could we do this on a per-module opt-in basis to allow for gradual
> migration? That is to say, assuming there's enough information in the
> stack to tell where it was thrown from
On 18/10/17 14:16, Boris Zbarsky wrote:
> On 10/18/17 4:28 AM, David Teller wrote:
>> 2/ basically impossible to diagnose in the wild, because there was no
>> error message of any kind.
>
> That's odd. Was the exception caught or something? If not, it should
> have
Beta, Release, ...
My main worry, at this stage, is what we encountered when we started
flagging uncaught async errors: some module owners simply never fixed
their errors, so we had to whitelist large swaths of Firefox code,
knowing that it was misbehaving.
Cheers,
David
__
On 18/10/17 10:45, Gregory Szorc wrote:
> I agree that errors like this should have better visibility in order to
> help catch bugs.
>
> I'm not sure changing behavior of the JS VM is the proper layer to
> accomplish this. I think reporting messages from the JS console is a
> better place to
s a programmer error.
- Any TypeError is a programmer error.
I expect that this will find a number of lurking errorsy, so we may want
to migrate code progressively, using a directive, say "use strict
moz-platform" and static analysis to help encourage using this directive.
What do you think
to hear from somebody
knowledgable about the spec and our implementation before just doing
that.
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
Before I built a wall I'd ask to know
> On Fri, Oct 6, 2017 at 5:41 PM, David Major <dma...@mozilla.com> wrote:
> > I bet Google Benchmark will have what you want.
> >
> > As a first guess, maybe this?
> > https://github.com/google/benchmark/blob/master/include/
> benchmark/benchmark.h#L297
I bet Google Benchmark will have what you want.
As a first guess, maybe this?
https://github.com/google/benchmark/blob/master/include/benchmark/benchmark.h#L297
(And if godbolt says they are wrong, please send them a PR :))
On Fri, Oct 6, 2017 at 9:16 AM, Gabriele Svelto
on-secure context, and @supports would do the right thing.
So I don't think this requires any new *features* to be spec'd in
CSS (since @supports would work, and is the right thing to use),
although it probably does require a small amount of new spec prose
to explain how it works.
-David
--
턞
products don't trust any code-signing roots, so this wouldn't work as
before even without removing the now-dead code.
Cheers,
David
On 09/22/2017 01:35 AM, Onno Ekker wrote:
> Op 27-7-2017 om 07:03 schreef Andrew Swan:
>> On Wed, Jul 26, 2017 at 2:49 AM, Frank-Rainer Grahl <f...@gm
Hi Gabor, I'm interested in shutdown issues. Is there a bug # for this case?
Cheers,
D
On Thu, Sep 21, 2017 at 4:08 AM, Gabor Krizsanits
wrote:
> I guess the question is how do you define "after we've entered shutdown".
>
> For the preallocated process manager both
to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
Before I
because symbols are new, but maybe it's just something to
get used to, hard to tell.
David
[1] https://github.com/heycam/webidl/issues/54
[2] https://github.com/heycam/webidl/pull/357
[3] https://github.com/heycam/webidl/issues/419
Le vendredi 1 septembre 2017 17:01:58 UTC+2, Boris Zbarsky
:Servo (or deleting the
function, of course). Otherwise we risk taking substantial
regressions in the CSS code backing much of our user interface.
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
Be
to get this started.
David
On 31 August 2017 at 21:51, Jim Blandy <jbla...@mozilla.com> wrote:
> Sorry for the premature send. The complete message should read:
>
> The primary goals here are not related to automation and testing.
>
> - We want to migrate the Devtools consol
Do we know if the other vendors would see value in having this spec'ed
properly so that we have true interop here? Reverse engineering seems like
a "fun" project but what stops people from breaking stuff without realising?
David
On 30 August 2017 at 22:55, Michael Smith <li...@spin
ouching 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 (b) is also more likely to lead to
overly long lines that require wrapping.
-David
--
턞 L. David Baron http://dbaron.
t seems pretty
reasonable to me (although broad, but broad seems OK for an IG).
So I'm inclined to vote in support of the charter, with the
following comments:
=
There should likely be a mention of some form of interaction with
the Web Payments Working Group.
Section 6 (Patent Disclosures)
.
-
-David
On Friday 2017-08-18 10:17 -0500, Lars Bergstrom wrote:
> Thanks, Tantek! I like this response. I have not been able to reach
> google/microsoft but will inform them of this intention.
>
> To reinforce point #1, I'd add that WebVR is currently under TAG review
Hey, all cool kids have exciting Engineering Newsletters these days, so
it's high time the JavaScript Binary AST got one!
# General idea
JavaScript Binary AST is a joint project between Mozilla and Facebook to
rethink how JavaScript source code is stored/transmitted/parsed. We
expect that this
On Wednesday 2017-07-12 12:20 -0700, L. David Baron wrote:
> On Wednesday 2017-07-12 06:48 -0500, Lars Bergstrom wrote:
> > There is some contention in the WebVR community group around the submission
> > of this charter proposal, as there is currently no public s
# is showing a few
unassigned that are actually assigned (judging from the comments).
Similarly, if something IS assigned to you, but it's not actively being
worked on and you're OK with someone else doing so, please un-assign
yourself.
Thanks...
--
David Durst [:ddurst]
On Tue, Aug 8, 2017 at 9:26 AM
PSM:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core=Security%3A%20PSM
Thanks to everyone who made this possible!
Cheers,
David
* the catch is that if any thread needs to query the trust of a
certificate, that thread will block until this operation has completed.
In the worst case, we should be no s
la-central/search?q=skip-if%28browserIsRemote
although that search isn't exhaustive, and contains some tests that
we still run under some conditions.
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
I don't think that anyone deliberately set out to write the code this way.
Likely this is fallout from the mass-refactorings in bug 968520 and related
bugs. I'd recommend working with poiru and froydnj to see if there's any
automated follow-up we could do to remove/improve this pattern.
On Tue,
Node dependency trees tend to be pretty large, so I'm a little concerned
here. Has the memory footprint be measured?
Cheers,
David
On 31/07/17 19:45, Michael Cooper wrote:
> If you mean using modules from NPM in a browser add-on, the Shield client
> extension recently started
Well, at least there is the matter of feature detection, for people who
want to write code that will work in more than just Firefox.
moz-prefixing makes it clear that the feature can be absent on some
browsers.
Cheers,
David
On 26/07/17 05:55, Martin Thomson wrote:
> On Wed, Jul 26, 2017 a
Should we moz-prefix moz-specific extensions?
On 25/07/17 20:45, Jet Villegas wrote:
> Based on product plans I've heard, this sounds like the right approach. We
> should try to limit the scope of such browser-specific APIs but it's likely
> necessary in some cases (e.g., in the devtools.)
>
>
of support for
Rust-implemented webidl in m-c, which meant that roughly 50% of the code
I would be writing would have been bug-prone adapters.
Cheers,
David
On 10/07/17 12:29, Nicholas Nethercote wrote:
> Hi,
>
> Firefox now has multiple Rust components, and it's on track to get a
> bun
where add-on signing isn't
required - for builds where it is required, this API is not used at all).
Given all this, the question is do we still need this second API? Does
Thunderbird or SeaMonkey use it for any reason, or can we simplify the
code-base, reduce build size, etc.?
Cheers,
David
should
support or oppose it.
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom
As of bug 1275780, rust panic text gets reported as a MOZ_CRASH reason.
On Mon, Jul 17, 2017 at 12:42 PM, Benjamin Smedberg
wrote:
> I don't know really anything about how rust panics get reflected into
> crash-data. Who would be the right person to talk to about that?
>
On Thursday, July 13, 2017 at 1:38:18 PM UTC-7, Joe Hildebrand wrote:
> I'm responding at the top of the thread here so that I'm not singling out any
> particular response.
>
> We didn't make clear in this process how much work Mark and his team did
> ahead of the decision to gather feedback
, or if you think we should
support or oppose it.
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
Before I built a wall I'd ask to know
What I was walling in or walling out
eave-open' keyword so that it gets resolved as FIXED when the
changeset is merged from autoland or mozilla-inbound into
mozilla-central. (This is easy to forget.)
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozill
likely time for the
standardization process to also admit that it's no longer just
experimenting, but actually shipping real stuff.
-David
> I would certainly not support at this time and, depending on the
> conversations in that group and timing of the below deadline, may suggest
> that we oppose.
&g
On Wednesday 2017-07-05 20:58 -0700, Marcos Caceres wrote:
> On July 6, 2017 at 1:40:13 PM, L. David Baron (dba...@dbaron.org) wrote:
> > I've taken what you (Tantek) wrote and made minor changes to yield
> > the following Formal Objection to the Web Platform WG charter.
>
>
On Tuesday 2017-07-11 11:38 -0700, L. David Baron wrote:
> On Wednesday 2017-07-05 11:02 -0700, L. David Baron wrote:
> > On Friday 2017-05-12 15:58 -0700, L. David Baron wrote:
> > > The W3C gave advance notice that 2 new charters are under
> > > development:
> >
On Wednesday 2017-07-05 11:02 -0700, L. David Baron wrote:
> On Friday 2017-05-12 15:58 -0700, L. David Baron wrote:
> > The W3C gave advance notice that 2 new charters are under
> > development:
> >
> > https://lists.w3.org/Archives/Public/public-new-work/201
support or oppose it.
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like
On Wednesday 2017-05-24 09:30 -0400, L. David Baron wrote:
> The W3C gave advance notice that a charter is under development for
> a new working group:
>
> WebAssembly Working Group
> https://w3c.github.io/charter-drafts/webassembly.html
> https://github.com/w3c/charter
I've taken what you (Tantek) wrote and made minor changes to yield
the following Formal Objection to the Web Platform WG charter. Note
that I added DOM 4 to the list, although perhaps there was a reason
you didn't include it?
-David
We request that the charter drop all REC track specifications
On Friday 2017-05-12 15:58 -0700, L. David Baron wrote:
> The W3C gave advance notice that 2 new charters are under
> development:
>
> https://lists.w3.org/Archives/Public/public-new-work/2017May/0006.html
> (which contains brief descriptions of what has changed)
>
>
, which now
includes the SVG Integration work.
Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla
I suspect that if it's too large, we'll be okay with generating the
bytecode on the user's computer.
Cheers,
David
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
%3A31.000Z#graphs
--
David Durst [:ddurst]
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Friday 2017-05-26 11:53 -0600, Tom Tromey wrote:
> >>>>> "David" == L David Baron <dba...@dbaron.org> writes:
>
> David> I agree it would be good to have a somewhat more "proper" spec for
> David> this. In terms of process, I thin
hat more "proper" spec for
this. In terms of process, I think probably the most important
(and lowest overhead) aspect of "proper" is having the revision
history of the specification in publicly visible version control
(such as github), and a way for people to raise issues that wi
on this charter can be made in its github repository, or,
if necessary, I can make comments that should be made as statements
"from Mozilla" on the Advisory Committee mailing list.
The charter will likely be submitted to the Advisory Committee for
formal review sometime in the futur
I'm not sure if this is exactly the same as the ALLOW_COMPILER_WARNINGS
that we use for warnings-on-errors, but FWIW as of a couple of months
ago I cleaned out the last warning-allowance in our "own" code.
ALLOW_COMPILER_WARNINGS usage is now only in external libraries (I'm
counting NSS and NSPR
of that?
Also, I had the impression that Quantum DOM scheduling made JS event
loop spinning unncessary. Did I miss something?
Cheers,
David
On 5/19/17 1:38 AM, Bill McCloskey wrote:
> Hi everyone,
>
> One of the challenges of the Quantum DOM project is that we will soon have
> multiple "
Hi,
The Gecko Profiler used to be notoriously unstable on 64-bit Windows. (If
you're curious: it's mostly because the unwinding rules for Win64 require
the system libraries to do a lot of synchronization, which our stack walker
would often call in ways that could deadlock.)
Ever since the last
also:
https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback
https://developer.mozilla.org/en-US/docs/Web/API/Background_Tasks_API
I'm not sure whether it works for privileged (chrome) JS, but it
seems like it ought to...
-David
--
턞 L. David Baron
as statements "from Mozilla" on the Advisory Committee mailing
list.
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
Before I built a wall I'd ask to know
What I w
On Wednesday 2017-05-10 13:10 +0200, Emilio Cobos Álvarez wrote:
> On Tue, May 09, 2017 at 06:56:03PM -0700, L. David Baron wrote:
> > On Wednesday 2017-05-10 02:43 +0200, Emilio Cobos Álvarez wrote:
> > > The issue I have with per-type conventions is that it doesn't sca
ces. We shouldn't treat
the two style set classes differently. So it should be passed with
pointers, not references.
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
Before I built a wa
ill just write a "*" whether or not their
existing code guarantees a non-null pointer; at least that was my
experience in the early days of Gecko. Perhaps we have better code
review now... but I'm somewhat skeptical of that given that I think
we've been relying on tests more and review
Hi All,
If you are working on web exposed features could you please take a few
minutes to complete the survey. This will help us prioritize work on Web
Platform Tests which helps us with our web compatibility story.
David
-- Forwarded message --
From: <dbu...@mozilla.com>
support, comments, or
objections through Friday, May 26, 2017.
Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢
for the first time at this stage, although that's a little less true
when review is taking place against a CR rather than a PR.)
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
Before I built
the specification. (I'd note,
however, that there have been previous opportunities to make
comments, so it's somewhat bad form to bring up fundamental issues
for the first time at this stage, although that's a little less true
now that the review is taking place against a CR rather than a PR.)
-David
/2017Apr/0021.html
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like
.
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense
On Friday 2017-03-31 07:55 -0400, L. David Baron wrote:
> On Friday 2017-03-31 12:11 +0800, Tommy Kuo wrote:
> > **Summary**
> >
> > I am intent to implement the property `line-height-step`. And it would be
> > disabled behind the pref `layout.css.line-heig
that's a little less true
now that the review is taking place against a CR rather than a PR.)
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
Before I built a wall I'd ask to know
undamentally the wrong UI for bug tracking as I described in
https://dbaron.org/log/20120816-bug-system and
https://dbaron.org/log/20130129-bugzilla and as a result I don't pay
much attention to the comments in bug reports; I mainly read the
summary.
-David
--
턞 L. David Baron
I'd like to add to this a reminder that commit messages should describe
the _change_ and not the _symptom_. In other words, "Bug XYZ: Crash at
Foo::Bar" is not a good summary.
This is implied by what Boris said, but I've seen enough of these on my
pulsebot backscroll that it's worth mentioning
the same behavior, since 2014.
This sounds good to me; thanks for cleaning this up.
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
Before I built a wall I'd ask to know
What I was
That's actually a pretty easy question to answer:
https://www.w3.org/2001/tag/doc/unsanctioned-tracking/
(Unsanctioned Web Tracking, W3C TAG Finding 17 July 2015)
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.
nd Chrome already ship it.
>
> Tests: WPT
The list of disabled tests in
https://bugzilla.mozilla.org/show_bug.cgi?id=1284758
seems somewhat concerning.
> Security & Privacy Concerns: none
Well, it's implemented in C++, but we don't have a better option
right now.
-David
--
턞 L. Dav
ht
it would be preferable to put all the extra space above in this case
in order to keep the baseline matching the rhythm. (In some cases
this would require an additional multiple of the step height.) I
might be wrong about this, though; it's worth consulting designers
about what behavior is ac
ue.
>
This just strikes me that we are going to disable until they are all gone
then we have dead code in the tree and still no one to own it. Its a longer
process that could end up at the same end point.
David
___
dev-platform mailing list
dev-pl
Try using Sysinternals Process Monitor to see what files MsMpEng.exe is
reading.
On Fri, Mar 17, 2017, at 04:26 PM, Ben Kelly wrote:
> Hi all,
>
> I'm trying to configure my new windows build machine and noticed that
> builds were still somewhat slow. I did:
>
> 1) Put it in high performance
let me know. (I'm already aware of the servo bindings and will
address those)
Thanks,
David
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
problem and fix our nit problem instead
of bashing that we can't handle re-reviews because of nits.
David
On 9 March 2017 at 21:53, Mike Connor <mcon...@mozilla.com> wrote:
> (please direct followups to dev-planning, cross-posting to governance,
> firefox-dev, dev-platform)
>
>
o fail for some substantial set of important cases (such
as rebases, as you mention).
(That's a piece of interdiff from rebasing my own patch queue
earlier this week.)
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.m
not allow us to fail
forward like inbound without having to get a sheriff to land the code.
I think, and this is my next area to investigate, is the 1 bug per push
(the autoland model) could be helping with the percentage of backouts being
lower.
David
On 7 March 2017 at 21:29, Chris Peterson
e, etc.
Information about why the static state of the code is correct is
better placed in comments than the commit message, although if the
patch is large it may need to summarize, or point to particular
comments (e.g., "see the comment in Foo.h for a full description of
these new methods").
-
as I think they should, for summary views).
An old example of this that I like is this commit:
https://hg.mozilla.org/mozilla-central/rev/830111e10951
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
ario where I asked for
> more time and was denied that.
I think it's often reasonable to expect a *backout* of the cause
within less than two weeks, although perhaps not if the immediate
trigger was changes in test chunking.
-David
--
턞 L. David Baron http://dbaron.org/
as to why there is a difference.
David
On 7 March 2017 at 12:57, Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 3/7/17 6:23 AM, David Burns wrote:
>
>>- Autoland 6%.(24 backouts out of 381 pushes)
>>- Inbound 12% (30 backouts out of 251 pushes)
>>
>
>
this but when I look at https://futurama.
theautomatedtester.co.uk/ each week I have seen this result consistenly
for about a month.
David
On 7 March 2017 at 09:03, Carsten Book <cb...@mozilla.com> wrote:
> Hi Lawrence,
>
> most (i would say 95 %) of the backouts are
e WebVR standards community here?
And is your intend to support the features in 1.1 forever, or to
take them away at some point?
-David
--
턞 L. David Baron http://dbaron.org/ 턂
턢 Mozilla https://www.mozilla.org/ 턂
Befor
01/03/2017 21:47, David Lawrence wrote:
>> Today, the BMO Team changed the default bug view to the new modal
>> view that has been in development for a while.
>
> I like the fact that you can now change the Product in one step.
>
> Sadly when resolving a bug, ther
Today, the BMO Team changed the default bug view to the new modal
view that has been in development for a while. For those who would like
to use the old form, instructions on how to switch back are below in the
background information. The old form will, however, be removed one day,
so please
this questions/raise:
* the feature is not implemented yet
* other browsers vendors are reading the "intent to" emails, so there is an
opportunity for this question to be fixed in an interoperable manner
David
Le mercredi 11 janvier 2017 18:34:56 UTC+1, Boris Zbarsky a écrit :
> When add
201 - 300 of 963 matches
Mail list logo