Summary: https://github.com/whatwg/dom/issues/911 proposes to add signal
property to AddEventListenerOptions
const ac = new AbortController();
target.addEventListener('fooEvent', (e) => { ... }, { signal: ac.signal } );
so that one can easily remove the event listener when AbortController is
abo
FWIW, apparently the UI is in the devtools profiler UI, not in the profiler
addon.
https://profiler.firefox.com/ still tells users to install the addon from there.
I was told that one can get the button similar to the addon by enabling
devtools.performance.popup.enabled boolean pref and then usi
On 10/24/19 9:17 AM, Marcos Caceres wrote:
On Thursday, October 24, 2019 at 6:46:08 AM UTC+11, Christopher Manchester
wrote:
As announced in this week's project call, sccache-dist schedulers have been
deployed to mozilla offices, and those with hardware available can enroll
servers based on the
Hi all,
during the past year, while optimizing page load by changing how various tasks
within Gecko are scheduled,
intermittently failing tests have often caused trouble and required fixes to
them or occasionally
disabling them. Now with Fission we are seeing even more issues and we will do
pa
On 10/3/19 1:18 AM, Andrew McCreight wrote:
On Wed, Oct 2, 2019 at 2:35 PM Geoff Lankow wrote:
Hi all, I need some advice.
I'm trying to enable Mochitest on debug builds of Thunderbird. It works
fine, except for the leak check, which finds a number of leaked windows
and docshells. Obviously w
And as with other data structures, be careful with modifications when using
range-based for.
We had plenty of crash issue with nsTArray + range-based for when we started to
use it.
-Olli
On 10/2/19 1:15 PM, Simon Giesecke wrote:
Hi,
I recently [1] added STL-style iterators and begin/cbegin/
Hi all,
during the past year, while optimizing page load by changing how various tasks
within Gecko are scheduled,
intermittently failing tests have often caused trouble and required fixes to
them or occasionally
disabling them. Now with Fission we are seeing even more issues and we will do
pa
Summary: queueMicrotask exposes the platform primitive to queue microtasks.
Without the API, web pages have used hacks around MutationObserver or Promise.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1480236
Link to standard:
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.ht
Hi all,
looks like I didn't send email about, IMO, rather useful environment variable
[1]:
MOZ_ALLOW_DOWNGRADE does the same thing as --allow-downgrade passed to firefox,
bypasses the profile downgrade protection.
(At least I need to bypass that all the time when testing various local and/or
n
Hi all,
I'm trying to disable document.createEvent("TouchEvent"), document.createTouch*
and ontouch* event handlers on desktop in
order to follow what has been done in other browsers.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1412485
The issue is that some web pages use those features to
On 09/20/2018 04:21 PM, Mike Hommey wrote:
On Thu, Sep 20, 2018 at 12:18:49PM +0300, smaug wrote:
On 09/19/2018 08:34 PM, Nicholas Alexander wrote:
2.
Making the main browser window be an HTML document with (mostly) HTML
DOM elements instead of a XUL document with (mostly) XUL DOM
On 09/19/2018 08:34 PM, Nicholas Alexander wrote:
2.
Making the main browser window be an HTML document with (mostly) HTML
DOM elements instead of a XUL document with (mostly) XUL DOM elements.
It is still mystery to me how the performance can be anywhere close to XUL when
starting br
On 09/05/2018 06:40 AM, Kris Maglione wrote:
On Tue, Sep 04, 2018 at 07:37:28PM +0200, Dão Gottwald wrote:
This may have been discussed before since it's kind of an obvious question:
Was there a conscious decision not to post phabricator review comments to
bugzilla? It's a somewhat significant
On 08/30/2018 11:21 AM, Henri Sivonen wrote:
We have the following that a pattern in our code base:
1) SetCapacity(newCapacity) is called on an XPCOM string.
2) A pointer obtained from BeginWriting() is used for writing more
than Length() but no more than newCapacity code units to the XPCOM
On 08/15/2018 06:06 PM, darin.hens...@gmail.com wrote:
On Wednesday, August 15, 2018 at 5:56:06 AM UTC-5, smaug wrote:
On 08/15/2018 01:54 PM, smaug wrote:
On 08/14/2018 09:43 PM, darin wrote:
When it ships in version 63 will shadowdom and webcomponent be shipped disabled
or enabled by
Hi all,
I think it is good to let people know that some of the review requests in
Phabricator don't show up in Bugzilla.
https://bugzilla.mozilla.org/show_bug.cgi?id=1482110
So, if some review seems to take too much time, better to ping the requestee.
-Olli
sk breaking web sites, but there isn't too much
we can do other than trying to ship.
David
On 10 August 2018 at 15:49, smaug wrote:
I'm planning to keep Shadow DOM and Custom Elements turned on on
beta/release builds.
Target release is Firefox 63.
prefs are dom.webcomponents.c
I'm planning to keep Shadow DOM and Custom Elements turned on on beta/release
builds.
Target release is Firefox 63.
prefs are dom.webcomponents.customelements.enabled and
dom.webcomponents.shadowdom.enabled.
Custom elements has been enabled in Nightly since January and Shadow DOM since
late Ma
On 07/12/2018 11:08 PM, Randell Jesup wrote:
I do hope that the 100 process figures scenario that was given is a worse case
scenario though...
It's not. Worst case is a LOT worse.
Shutting down threads/threadpools when not needed or off an idle timer
is a Good thing. There may be some perf
On 06/29/2018 05:58 PM, Boris Zbarsky wrote:
On 6/29/18 10:30 AM, Nathan Froyd wrote:
Given the language-required qualification for
`enum class` and a more Rust-alike syntax, I would feel comfortable
with saying CamelCase `enum class` is the way to go.
For what it's worth, I agree. The point
On 06/20/2018 04:14 PM, Andrea Marchesini wrote:
Summary: The Clear-Site-Data header allows a secure origin to send a header
requesting the deletion of its own browsing data.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1268889
Link to standard: https://w3c.github.io/webappsec-clear-site-
On 04/27/2018 12:14 AM, Ben Kelly wrote:
Hi all,
I just pushed another helper class that I thought others might find useful.
CopyableErrorResult is a specialized form of ErrorResult. Its intended to
allow slightly more rich error values to be passed through things like ipdl
structure and MozPr
On 04/25/2018 08:38 PM, Bobby Holley wrote:
On Wed, Apr 25, 2018 at 10:21 AM, Ted Mielczarek wrote:
On Wed, Apr 25, 2018, at 12:32 PM, Jeff Muizelaar wrote:
At minimum we should make --enable-profiling build with rust-opt.
This sounds reasonable, although the quirk is that we default
--enab
On 04/24/2018 09:25 AM, Andreas Tolfsen wrote:
Also sprach Bobby Holley:
For reasons outlined in bug 1450827, the DOM peers have decided to
deprecate support for JS-implemented WebIDL APIs. This means that
new additions of |JSImplementation="foo"| are no longer permitted.
Out of curiosity, a
Hi all,
just some random notes about Phabricator.
I've been reviewing now a bunch of patches in Phabricator and the initial
feeling from
reviewer's point of view is that it is ok. Not great, but ok.
MozReview's interdiff, when it works, is easier to use or at least to discover
than Phabricator
On 03/19/2018 09:30 PM, Kris Maglione wrote:
On Mon, Mar 19, 2018 at 08:49:10PM +0200, Henri Sivonen wrote:
It appears that currently we allow atomicizing invalid UTF-16 string,
which are impossible to look up by UTF-8 key and we don't allow
atomicizing invalid UTF-8.
I need to change some thin
On 02/09/2018 10:39 PM, James Graham wrote:
On 09/02/2018 19:59, Josh Bowman-Matthews wrote:
On 2/9/18 1:26 PM, James Graham wrote:
* One bug per PR we downstream, filed in a component determined by the files
changed in the PR.
What does this mean exactly? What is the desired outcome of thes
On 01/16/2018 11:41 PM, Mike Hommey wrote:
On Tue, Jan 16, 2018 at 10:02:12AM -0800, Ralph Giles wrote:
On Tue, Jan 16, 2018 at 7:51 AM, Jean-Yves Avenard
wrote:
But I would be interested in knowing how long that same Lenovo P710 takes
to compile *today*….
On my Lenovo P710 (2x2x6 core Xeo
On 01/04/2018 12:30 AM, Ben Kelly wrote:
On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto wrote:
So after validating my approach in that bug (which is almost ready) I've
thought that it might be time to give the observer service the same
treatment. First of all we'd have a list of topics (I've
Great work on wpt!
On 12/15/2017 05:38 PM, James Graham wrote:
Following the summary of what we achieved in wpt in the last year, I'd
like to solicit input from the gecko community to inform the
priorities of various pieces of wpt work for the next year.
In order to maximise the compatibility b
time since the end
of last year to push this forward by providing a correct microtask
scheduling (Thanks Olli(:smaug) for the major work of the new scheduling
patch) and fixing the test failures in our implementation discovered by the
scheduling change.
Good news is that we have all WPT gre
On 11/28/2017 06:33 AM, Boris Zbarsky wrote:
On 11/27/17 7:45 PM, Eric Rescorla wrote:
As for the lifetime question, can you elaborate on the scenario you are
concerned about.
Olli may have a different concern, but I'm thinking something like this:
for (auto foo : myFoos) {
foo->bar();
t cringe back from
it. Sure, prove it out. But we really don't need more moz-specific
constructs. We should choose our deviations carefully.
On Mon, Nov 27, 2017 at 3:24 AM, smaug wrote:
On 11/27/2017 01:05 PM, Nicolas B. Pierron wrote:
On 11/26/2017 12:45 AM, smaug wrote:
On 11/24/2017
This is basically an after the fact notification that
we're in progress of implementing Shadow DOM again, this time v1[1].
While doing this, the v0 implementation, which was never exposed to the web,
will be removed.
v1 is luckily way simpler, so this all should simplify various bits in DOM.
FF6
On 11/27/2017 02:20 PM, smaug wrote:
This is basically an after the fact notification that
we're in progress of implementing Shadow DOM again, this time v1[1].
While doing this, the v0 implementation, which was never exposed to the web,
will be removed.
v1 is luckily way simpler, so thi
On 11/27/2017 01:05 PM, Nicolas B. Pierron wrote:
On 11/26/2017 12:45 AM, smaug wrote:
On 11/24/2017 06:35 PM, Eric Rescorla wrote:
On Thu, Nov 23, 2017 at 4:00 PM, smaug wrote:
On 11/23/2017 11:54 PM, Botond Ballo wrote:
I think it makes sense to hide a 'new' call in a Make
On 11/24/2017 06:35 PM, Eric Rescorla wrote:
On Thu, Nov 23, 2017 at 4:00 PM, smaug wrote:
On 11/23/2017 11:54 PM, Botond Ballo wrote:
I think it makes sense to hide a 'new' call in a Make* function when
you're writing an abstraction that handles allocation *and*
de
On 11/23/2017 11:54 PM, Botond Ballo wrote:
I think it makes sense to hide a 'new' call in a Make* function when
you're writing an abstraction that handles allocation *and*
deallocation.
So MakeUnique makes sense, because UniquePtr takes ownership of the
allocated object, and will deallocate it
On 11/17/2017 12:55 AM, Chung-Sheng Fu wrote:
Content Security Policy suggests Security Policy Violation DOM Events [1].
In case any of the directives within a policy are violated, such a
SecurityPolicyViolationEvent is generated and sent out to a reporting
endpoint associated with the policy. We
On 11/02/2017 09:58 PM, Kris Maglione wrote:
Related: I've been thinking for a long time that we need better tools for
tracking what sites/usage patterns are responsible for the time we spend in
CC (and possibly GC, but I think that tends to be less of a problem).
I've noticed, in particular, t
On 11/02/2017 10:01 PM, Kris Maglione wrote:
On Thu, Nov 02, 2017 at 05:37:30PM +0200, smaug wrote:
This has been an issue forever, and there aren't really good tools on any
browser, as far as
I know, for web devs to debug their leaks.
Internally we do have useful data (CC and GC graph
This has been an issue forever, and there aren't really good tools on any
browser, as far as
I know, for web devs to debug their leaks.
Internally we do have useful data (CC and GC graphs and such), but would need
quite some ux skills to design some good
UI to deal with leaks. Also, the data to
judgment would
hurt the quality of the code.
+1
On Mon, Oct 30, 2017 at 8:03 AM, smaug wrote:
On 10/30/2017 04:52 PM, Simon Sapin wrote:
On 30/10/17 15:05, smaug wrote:
And let's be careful with the new C++ features, pretty please. We
managed to not be careful when we started to use aut
On 10/30/2017 04:52 PM, Simon Sapin wrote:
On 30/10/17 15:05, smaug wrote:
And let's be careful with the new C++ features, pretty please. We
managed to not be careful when we started to use auto, or ranged-for
or lambdas. I'd prefer to not fix more security critical bugs or
memory
And let's be careful with the new C++ features, pretty please.
We managed to not be careful when we started to use auto, or ranged-for or
lambdas.
I'd prefer to not fix more security critical bugs or memory leaks just because
of fancy hip and cool
language features ;)
-Olli
On 10/30/2017 05
On 10/21/2017 01:14 PM, Philipp Kewisch wrote:
On 10/20/17 7:47 PM, Dave Townsend wrote:
For some time now we've been talking about moving away from XUL and XBL.
The browser architecture team has been hard at work figuring out how to go
about doing that and we're ready to share the first of our
On 10/21/2017 11:45 PM, Yura Zenevich wrote:
I would also like to bring to the team's attention another force worth
being on the radar (in terms of "forces on the system") - accessibility.
One theme that seems to consistently happen with re-writes such as the ones
from xul to React is regressions
Sounds very reasonable.
(Hoping the r=documentation flag won't be misused ;))
On 10/19/2017 04:37 PM, Andreas Tolfsen wrote:
Some time ago there was a discussion on dev-builds@ regarding
the state of our in-tree source code documentation. The main
focus was that MDN, moving forward, will main
On 10/18/2017 08:08 AM, Jet Villegas wrote:
SGTM. BTW, bug 143038 was filed 16 years ago. Is that a bugzilla record for
oldest fixed bug?
whoohoo, didn't realize it was that old.
One day I'll start reading the bugs I review ;)
That is, do I owe you another steak? :-)
On Wed, Oct 18, 2017
On 10/11/2017 09:55 PM, Andreas Tolfsen wrote:
+tools-marionette
Also sprach Chris Cooper:
Many of the build peers have long review queues.
Is having a long review queue the actual issue? Isn't (too) high throughput
at least equally bad issue. Does the new setup somehow try to ensure
reviews
On 05/23/2014 04:29 AM, Anthony Jones wrote:
Some of you may remember the discussion on clang-format and the `mach
clang-format` command. What we have in place right now is very temporary
but it is functional enough to give it a try. I have not put the effort
into upstreaming my changes. Dependin
are quickly
going to hit a point where "I don't feel like learning Rust" is not
going to cut it anymore.
Indeed.
On Tue, Jul 11, 2017 at 4:37 PM, smaug wrote:
How is the performance when crossing Rust <-> C++ boundary? We need to make
everything faster, not slower.
If
Hi all,
recently in couple of bugs there has been requests to add Gecko specific APIs
for extensions.
It isn't clear to me why, and even less clear to me is what the plan is there.
I thought WebExtensions should work in several browsers, but the more we add
Gecko specific APIs, the less likely
On 07/12/2017 04:20 PM, Ben Kelly wrote:
On Tue, Jul 11, 2017 at 11:49 PM, Martin Thomson wrote:
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 exi
On 07/11/2017 04:27 PM, Ben Kelly wrote:
On Tue, Jul 11, 2017 at 4:57 AM, Nicholas Nethercote
wrote:
On Tue, Jul 11, 2017 at 11:15 AM, Bobby Holley
wrote:
If I were the owner of that module I would consider implementing a policy
something like the following:
"When a person writes a new c
On 07/10/2017 01:29 PM, Nicholas Nethercote wrote:
Hi,
Firefox now has multiple Rust components, and it's on track to get a bunch
more. See https://wiki.mozilla.org/Oxidation for details.
I think this is an excellent trend, and I've been thinking about how to
accelerate it. Here's a provocative
On 07/10/2017 09:04 PM, zbranie...@mozilla.com wrote:
One more thought. There's a project that fitzgen told me about that aims to
allow for components to communicate between JS and Rust using Streams.
If we could get to the point where instead of WebIDL/XPIDL we could just plug
streams between
On 07/10/2017 01:29 PM, Nicholas Nethercote wrote:
Hi,
Firefox now has multiple Rust components, and it's on track to get a bunch
more. See https://wiki.mozilla.org/Oxidation for details.
I think this is an excellent trend, and I've been thinking about how to
accelerate it. Here's a provocative
On 07/04/2017 04:47 PM, Dexter wrote:
Hi everyone!
Could you tell me please, how I can clearly convert char (&name)[N] to
nsACString?
I tried this:
char* cname = new char[N];
memcpy(cname, &name, N);
nsAutoString strName;
strName.AssignWithConversion(cname, N);
I can't find out how to get ns
On 06/27/2017 12:12 AM, Armen Zambrano Gasparnian wrote:
Asking around, looking on dxr or MDN did not yield something easily.
I don't want to have to use Marionette in this specific automation context.
Thanks in advance,
Armen
Do you mean fullscreen in chrome level, or running web pages in f
On 06/16/2017 02:32 AM, Jim Porter wrote:
On 6/15/17 4:12 PM, Kartikaya Gupta wrote:
Not quite. For e10s, mouse events are sent across the process boundary
using the PBrowser ipdl protocol. On the parent side they go into
EventStateManager::DispatchCrossProcessEvent [1] which picks up the
TabPar
On 05/18/2017 09:25 PM, Domenic Denicola wrote:
On Thursday, May 18, 2017 at 4:34:37 AM UTC-4, smaug wrote:
FWIW, I just yesterday suggested in #whatwg that the platform should have
something like IdlePromise or AsyncPromise.
And there is the related spec bug
https://github.com/whatwg/html
FWIW, I just yesterday suggested in #whatwg that the platform should have
something like IdlePromise or AsyncPromise.
And there is the related spec bug
https://github.com/whatwg/html/issues/512#issuecomment-171498578
On 05/18/2017 04:22 AM, Mark Hammond wrote:
Given our recent performance pus
On 05/09/2017 04:52 PM, smaug wrote:
On 05/09/2017 01:55 PM, Mike Hommey wrote:
On Tue, May 09, 2017 at 01:31:33PM +0300, Henri Sivonen wrote:
On Tue, May 9, 2017 at 12:58 PM, Emilio Cobos Álvarez wrote:
I think references help to encode that a bit more in the type system,
and help reasoning
On 05/09/2017 01:55 PM, Mike Hommey wrote:
On Tue, May 09, 2017 at 01:31:33PM +0300, Henri Sivonen wrote:
On Tue, May 9, 2017 at 12:58 PM, Emilio Cobos Álvarez wrote:
I think references help to encode that a bit more in the type system,
and help reasoning about the code without having to look
On 04/25/2017 04:38 PM, Ehsan Akhgari wrote:
On 04/24/2017 06:04 PM, Martin Thomson wrote:
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 rest
On 04/25/2017 08:20 PM, Boris Zbarsky wrote:
On 4/25/17 1:07 PM, Alexander Surkov wrote:
I bet there's always room for improvements, and I hope this was a counterpoint
for the example only, not for the bug organization approach.
Sort of.
It was a counterpoint to "just check the bug; all the
On 04/20/2017 05:15 AM, Bevis Tseng wrote:
A soft reminder of using AbstractThread::GetCurrent()/MainThread()
after some design change for Quantum-DOM.
If this message/callback is to be handled on *the main thread of the
content process*, please use the replacement called AbstractMainThreadFor
On 04/18/2017 04:24 PM, Ehsan Akhgari wrote:
On 2017-04-18 12:30 AM, Mike Hommey wrote:
I've yet to see that to happen. What is crucial is fast way to browse
through the blame in time. So commit messages should be short and
descriptive. Telling what and why. (I very often need to go back to CVS
On 04/18/2017 03:12 AM, gsquel...@mozilla.com wrote:
On Tuesday, April 18, 2017 at 11:58:11 AM UTC+12, smaug wrote:
On 04/18/2017 02:36 AM, Gregory Szorc wrote:
On Mon, Apr 17, 2017 at 4:10 PM, smaug wrote:
On 04/17/2017 06:16 PM, Boris Zbarsky wrote:
A quick reminder to patch authors and
On 04/18/2017 02:36 AM, Gregory Szorc wrote:
On Mon, Apr 17, 2017 at 4:10 PM, smaug wrote:
On 04/17/2017 06:16 PM, Boris Zbarsky wrote:
A quick reminder to patch authors and reviewers.
Changesets should have commit messages. The commit message should
describe not just the "what&qu
On 04/17/2017 06:16 PM, Boris Zbarsky wrote:
A quick reminder to patch authors and reviewers.
Changesets should have commit messages. The commit message should describe not just the
"what" of the change but also the "why". This is especially
true in cases when the "what" is obvious from the d
On 04/05/2017 07:34 PM, Tom Ritter wrote:
On Tue, Apr 4, 2017 at 10:29 PM, wrote:
Security & Privacy Concerns: none
It looks like this exposes pointerType, which reveals whether the user
is using a mouse, pen, or touch input.
Note, that is already available through old moz-prefixed API (w
A bit off topic
On 03/13/2017 04:37 PM, David Burns wrote:
Regarding burden on reviewers, the comments in this thread just highlight
how broken our current process is by having to flag individual people for
reviews. This leads to the a handful of people doing 50%+ of reviews on the
code.
Unfor
On 03/10/2017 12:43 AM, Ben Kelly wrote:
On Thu, Mar 9, 2017 at 5:35 PM, Mike Hommey wrote:
On Thu, Mar 09, 2017 at 02:46:53PM -0500, Ehsan Akhgari wrote:
I review a large number of patches on a typical day, and usually I have
to
spend a fair amount of time to just understand what the patch
On 03/10/2017 12:59 AM, Bobby Holley wrote:
At a high level, I think the goals here are good.
However, the tooling here needs to be top-notch for this to work, and the
standard approach of flipping on an MVP and dealing with the rest in
followup bugs isn't going to be acceptable for something so
On 03/12/2017 10:40 PM, Ehsan Akhgari wrote:
On 2017-03-11 9:23 AM, smaug via governance wrote:
On 03/11/2017 08:23 AM, Nicholas Nethercote wrote:
On Sat, Mar 11, 2017 at 2:23 PM, smaug via governance <
governa...@lists.mozilla.org> wrote:
I'd be ok to do a quick r+ if interdiff
On 03/11/2017 08:23 AM, Nicholas Nethercote wrote:
On Sat, Mar 11, 2017 at 2:23 PM, smaug via governance <
governa...@lists.mozilla.org> wrote:
I'd be ok to do a quick r+ if interdiff was working well.
Depending on the relative timezones of the reviewer and reviewee, that
could de
On 03/07/2017 05:29 AM, Ben Kelly wrote:
On Mon, Mar 6, 2017 at 5:42 PM, Nicholas Nethercote
wrote:
On Tue, Mar 7, 2017 at 9:22 AM, Ben Kelly wrote:
These measurements are for full content processes. Many of the processes
in the above do not need all the chrome script we load in content pr
every DOM change
Definitely use cache
* every page load
This happens rarely, so probably doesn't matter
etc.
I wonder, if everybody uses Add*VarCache, doesn't it cause another performance
problem when a pref is changed?
On 2017/02/22 20:18, smaug wrote:
Hi,
Preferences::GetBool
ation matches the one you
requested a cache for. So if you have prefs "blah.foo" and
"blah.foo.bar", changing blah.foo.bar will write garbage into your cache for
blah.foo.
https://bugzilla.mozilla.org/show_bug.cgi?id=1208744
~ Gijs
On 22/02/2017 11:18, smaug wrote:
Hi,
Prefe
Hi,
Preferences::GetBool is a slow hashtable lookup and has been showing up in
performance profiles in many places.
Please use Preferences::AddBoolVarCache. Same with other pref types.
Or if the pref needs to be read just once, store the value in some static
variable or so.
-Olli
___
On 02/21/2017 07:03 AM, Brian Birtles wrote:
As of Firefox 54, I intend to turn on, by default, the code that makes
Event.timeStamp a DOMHighResTimeStamp. This makes this member a double
whose value is the number of milliseconds since the time origin.
This has been developed behind the dom.event
On 02/18/2017 07:08 PM, Eric Rescorla wrote:
I'd also note that if we're not going to use "this is what we have done
historically"
as a guide, then it seems like much bigger changes are on the table and we
would probably be better off adopting some other well-defined coding
standard
wholesale (e
On 02/16/2017 07:24 PM, Henri Sivonen wrote:
It seems that we already have MFBT code that has lower case methods
begin/end/cbegin/cend, etc., for compatibility with C++ standard
library iteration:
https://dxr.mozilla.org/mozilla-central/source/mfbt/ReverseIterator.h#136
I guess these methods sho
On 02/16/2017 08:05 PM, smaug wrote:
On 02/16/2017 07:24 PM, Henri Sivonen wrote:
It seems that we already have MFBT code that has lower case methods
begin/end/cbegin/cend, etc., for compatibility with C++ standard
library iteration:
https://dxr.mozilla.org/mozilla-central/source/mfbt
On 02/15/2017 12:41 AM, Botond Ballo wrote:
But yes, don't implement probes as JS event listener when the event is some
rather commonly dispatched.
Same applies to observer service observers etc.
In bug 1238137, I added a SCROLL_INPUT_METHODS telemetry ping in
autoscrollLoop. Is that also inapp
On 02/12/2017 08:52 PM, Jared Wein wrote:
The original email looks to be related to:
https://bugzilla.mozilla.org/show_bug.cgi?id=1338891
and
https://bugzilla.mozilla.org/show_bug.cgi?id=1338902
though I agree that the message could have been explained a little better.
Sorry about that. I tho
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Ryan
On Wed, Jan 18, 2017 at 12:50 AM, smaug wrote:
On 01/18/2017 08:28 AM, smaug wrote:
On 01/17/2017 10:51 PM, J. Ryan Stinnett wrote:
On Mon, Jan 16, 2017 at 3:08 PM, smaug wrote:
On 01/16/2017 10:43 PM, Dave Townsend wrote:
One of the things I've been investigating since movi
So we'll get support for object too in FF53, not only array?
On 01/17/2017 07:11 PM, Andrea Marchesini wrote:
Summary: URLSearchParams constructor is changed in the latest URL spec.
Now it's possible to create URLSearchParams objects starting from a string,
an array and from an object.
Bugs:
ht
On 01/18/2017 08:28 AM, smaug wrote:
On 01/17/2017 10:51 PM, J. Ryan Stinnett wrote:
On Mon, Jan 16, 2017 at 3:08 PM, smaug wrote:
On 01/16/2017 10:43 PM, Dave Townsend wrote:
One of the things I've been investigating since moving back to the desktop
team is how we can remove XUL fro
On 01/17/2017 10:51 PM, J. Ryan Stinnett wrote:
On Mon, Jan 16, 2017 at 3:08 PM, smaug wrote:
On 01/16/2017 10:43 PM, Dave Townsend wrote:
One of the things I've been investigating since moving back to the desktop
team is how we can remove XUL from the application as much as possible
On 01/17/2017 12:05 AM, Dave Townsend wrote:
Trees! I knew I was forgetting something, thank you. Yeah those are things
we're going to need some sane replacements for.
AS far as XBL goes, while I suspect it works from HTML documents I think we
want to be phasing out use of XBL too for pretty muc
On 01/16/2017 10:43 PM, Dave Townsend wrote:
One of the things I've been investigating since moving back to the desktop
team is how we can remove XUL from the application as much as possible. The
benefits for doing this are varied, some obvious examples:
* XUL is a proprietary standard and we ba
On 01/07/2017 02:55 AM, Andrea Marchesini wrote:
Today we had a meeting about the next steps for NetworkInformation API.
The results of this meeting are:
1. we want to keep what we have in m-c. It means NetworkInformation enabled
on fennec, main-thread and workers. It stays disabled on desktop.
On 01/05/2017 06:00 PM, Jet Villegas wrote:
Spec: https://drafts.css-houdini.org/css-paint-api/
Summary: The CSS Paint API is the first of several Web Rendering proposals
from the CSS Houdini Task Force. The CSS Paint API allows Web authors to
define and register a custom Paint method to be exec
On 12/20/2016 03:46 PM, Jan de Mooij wrote:
Hi all,
A few weeks ago we added mozilla::Result to MFBT [0][1]. I was asked
to inform dev-platform about this, so here's a quick overview.
mozilla::Result is based on Rust's Result type [2]. It contains
either a success value of type V or an error val
On 12/22/2016 08:14 PM, Bobby Holley wrote:
We've had this debate several times already, culminating in the attempt to
ban NS_ENSURE_* macros. It didn't work.
This is a bit different. One of the most common NS_ENSURE_ macros is SUCCESS
variant which explicitly has the
return value.
MOZ_TRY doe
On 12/16/2016 10:36 AM, Masayuki Nakano wrote:
Due to the end of B2G platform, I'd like to remove mozbrowserbeforekeydown,
mozbrowserbeforekeyup, mozbrowserafterkeydown and mozbrowserafterkeyup
events and its event classes.
They were implemented by bug 989198 [1] for allowing embedded browser e
1 - 100 of 277 matches
Mail list logo
