On 12/6/17 3:22 PM, Nico Grunbaum wrote:
It is in nightly now, and we intend to ship these interfaces in 59.
Chrome shipped a partial implementation[3] of getContributingSources()
in 59. Edge has partial support[4] for getContributingSources().
OK. Neither of those ships
On 12/6/17 12:19 AM, Nico Grunbaum wrote:
We intend to ship these interfaces in 59, and they are on nightly now.
Tracking: https://bugzilla.mozilla.org/show_bug.cgi?id=1363667
[1] https://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver
[2]
On 11/29/17 12:42 PM, Emilio Cobos Álvarez wrote:
Another thing we could try to do if plain unshipping fails would be to
just hide the regex matching function, which IIUC would prevent the
security issue too. But hiding it behind a pref on non-release for now
sounds good.
Boris, would you also
On 11/29/17 11:53 AM, Emilio Cobos Álvarez wrote:
Let me know if there's any concern on doing this.
@-moz-document url-prefix() {
/* rules go here */
}
at least used to be a somewhat common way to have "Firefox-only" rules
on web pages.
On 11/28/17 10:28 PM, Jeff Gilbert wrote:
const auto& foo = getFoo();
foo->bar(); // foo is always safe here
Sadly not true. Some counterexamples:
Foo* getFoo() {
return mFoo; // Hey, this is the common case!
}
const RefPtr& getFoo() {
return mFoo; // Can be nulled out by the
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();
}
where bar() can run arbitrary script.
On 11/20/17 12:26 PM, Gijs Kruitbosch wrote:
I don't see the "events" view in the current debugger in 57/58/59
anymore, but perhaps I'm not looking in the right place.
Oh, right, it's not implemented in the new debugger yet... I keep
forgetting that I have the new debugger disabled for
On 11/20/17 6:28 AM, Gijs Kruitbosch wrote:
Devtools' inspector lets you see which DOM nodes have event listeners
attached to them. It would be neat if they could provide the same
support in the debugger for instances of EventTarget (or any "subclasses").
Hmm. So there are at least three
Summary: Make it possible for web pages to do |new EventTarget|, and
more importantly to create EventTarget subclasses like |class MyThing
extends EventTarget| that can then have DOM events dispatched on them in
the normal way, have event listeners registered with all the features
browsers
I just landed a change [1] to use the MOZ_NO_OSX_EVENT_TAPS environment
variable instead of the MOZ_DEBUG environment variable to disable event
taps on Mac.
If you aren't setting MOZ_DEBUG in your environment, you don't need to
do anything.
If you _are_ setting it, to work around bug
On 11/15/17 10:00 AM, Henri Sivonen wrote:
the notion
of there still existing out-of-tree XPCOM callers but them being dark
matter code search-wise worries me.
Yes, I agree. We should make sure any such callers are indexed by some
dxr or searchfox instance. And I don't mean an instance per
On 11/15/17 9:12 AM, Henri Sivonen wrote:
How many Mozilla-signed special extensions are there? Does an analog
of https://dxr.mozilla.org/addons/ exist for searching their code?
That wouldn't have helped in this case. The addon was not using
nsIJSON. The addon was messing up a non-addon
On 11/3/17 3:00 PM, Jonathan Kingston wrote:
Which specific issues?
The API in the specification is promise ready by using the permissions API,
is behind a permission prompt and requires a secure context.
Does that address the privacy concerns we had with device APIs before?
-Boris
On 11/7/17 4:13 PM, Sophana "Soap" Aik wrote:
Nothing is worse than hearing IT picked or chose hardware that nobody
actually wanted or will use.
If I could interject with a comment about the hardware we pick...
The last desktop I was shipped came with a 512 GB drive. One of our
srcdirs is
On 10/4/17 10:32 AM, Jan Keromnes wrote:
We've already disabled this "no defects" comment, and are currently
deploying the fix to production, so the bot should stop sending them soon.
It looks like the "no defects" comment is back? See
https://bugzilla.mozilla.org/show_bug.cgi?id=1149250#c30
On 11/3/17 5:00 PM, Stefan Höhn wrote:
I didn't intent to start any offensive questioning
Stefan,
I wasn't attacking you; I'm sorry it came across that way...
Having said, is there an official way in Firefox to use the Magnetometer?
Not yet.
-Boris
On 11/2/17 12:54 PM, hoehn6...@gmail.com wrote:
note: Chrome 63 does support it in it early version already
I should note that this is slightly misleading. According to
https://groups.google.com/a/chromium.org/forum/?utm_medium=email_source=footer#!msg/blink-dev/2zPZt3watBk/M4qcI8wlBwAJ
On 11/2/17 12:54 PM, hoehn6...@gmail.com wrote:
The W3C defined a generic sensor API for browsers which also allows to support
sensors like the Magnetometer. The spec can be found here:
https://www.w3.org/TR/generic-sensor/
This isn't a spec, nor did the W3C "define" it. This is a working
On 10/31/17 3:21 PM, Gregory Szorc wrote:
It is "wrong" for the set of "people performing profiling."
Just to be clear, that set is "everyone".
Now the set of "people performing profiling on builds they create
themselves" is a separate question
-Boris
On 10/30/17 10:52 AM, Simon Sapin wrote:
How do new language features lead to security bugs?
By making unsafe behaviors easier or more tempting.
For example:
[&]() { /* stuff */ }
is a huge footgun in a language without a borrow checker. You _could_
still do something like that before
On 10/27/17 12:33 PM, Steve Fink wrote:
Within Spidermonkey, our rule is to never #include windows.h
directly, but always via jswin.h
Ah, I thought I'd seen this sort of thing somewhere; I had recalled a
header that you could include to under "all the bad windows.h stuff"...
This approach
On 10/26/17 2:51 PM, Jeff Muizelaar wrote:
What's the use case for a
--enable-optimize, opt-level=1 build?
Fwiw, I ended up doing a fair amount of my work recently in a
"--enable-optimize, --disable-debug, --enable-rust-debug" build, for the
following reasons:
1) I was modifying Rust
On 10/25/17 12:41 PM, Andrew Overholt wrote:
Is there precedent for doing what a user intended which would be contrary
to what the site is attempting?
The first problem is this: How do you know the user wasn't intending
what the site is attempting?
In the case that prompted my question,
On 10/25/17 2:50 PM, Emilio Cobos Álvarez wrote:
From mozilla-central I've been using ./mach cargo check gkrust, and I
certainly expect it to keep working.
Ah, excellent.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 10/25/17 1:34 PM, Gregory Szorc wrote:
Also, due to ongoing work around Rust integration in the build system, it
is dangerous to rely on manual `cargo` invocations to compile Rust because
bypassing the build system (not using `mach build`) may not use the same
set of RUSTFLAGS that direct
On 10/23/17 10:30 AM, Jeff Muizelaar wrote:
For the curious among us, what made nsIURI not thread safe in the first place?
There were several aspects to this:
1) Constructing a URI object. This needed a protocol handler, which
could be implemented in JS by extensions. With XPCOM
Naveed,
Thank you for continuing work on performance!
New profiles that require analysis should be assigned to relevant domain
experts.
Do we have a plan for _generating_ profiles, or at least incentivizing
generation thereof? This is a large part of what the Quantum Flow
effort was
On 10/18/17 2:37 PM, Steve Fink wrote:
Is there any way to detect if a finalized Promise swallowed an exception
without "handling" it in some way or other, even if very heuristically?
We used to have such a way. It requires doing things during
finalization, which is not great.
But we can
On 10/18/17 11:54 AM, David Teller wrote:
Mmmh... I was looking at setPendingException at
http://searchfox.org/mozilla-central/source/js/src/jscntxtinlines.h#435
That will allow you to hook all exceptions, sure, including ones caught
by try/catch.
My idea would be to do it even on caught
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 shown up in the browser console, at least
I have one proposal. Could we
On 10/17/17 8:12 PM, Myk Melez wrote:
Shouldn't the code rather move to comm-central if it's specific to
mailnews?
That would be fine too, yes.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 10/17/17 5:47 AM, Shih-Chiang Chien wrote:
I intent to remove all the code that handling BinHex decoding, i.e.
nsBinHex.cpp, from mozilla-central if no other project is using it.
The code was originally added for mailnews. See
https://bugzilla.mozilla.org/show_bug.cgi?id=81352
Please
On 10/10/17 1:11 PM, Jeff Griffiths wrote:
This is highly dependent on screen size.
It's dependent on window size. And I was just pointing out that the
post I was replying to assumes that "12 or fewer tabs" means "not
scrolling", whereas we have no obvious data to that effect.
That is, we
On 10/8/17 8:22 PM, Matt Woodrow wrote:
We're planning to land into mozilla-central in the next week or two, and
then enable it by default for Nightly within a week or two of that.
This is awesome news. Big thanks to everyone who worked on this!
-Boris
On 10/3/17 5:18 PM, Boris Zbarsky wrote:
So just to make sure I understand the change (and this is a theoretical
point, because I haven't had a chance to try the change yet)...
OK, now I have had a chance to try it.
When set to the new 50px default, I see 1 letter of title or less (less
On 10/6/17 9:52 AM, Nicolas B. Pierron wrote:
I will add that 91% of the session on release have 12 or fewer tabs, and
thus would not be concerned at all by these changes.
Do we actually know that?
As I said upthread, at the 100px tab width my tabs start to scroll when
adding the 9th tab.
On 10/6/17 5:00 AM, Henri Sivonen wrote:
If we don't have one, how should one be written so that it works in
GCC, clang and MSVC?
Are you OK with it being restricted to a single thread? If so, would
something like this work?
mutable void* taint;
void* black_box(void* foo) {
taint =
On 10/4/17 10:32 AM, Jan Keromnes wrote:
We've already disabled this "no defects" comment, and are currently
deploying the fix to production, so the bot should stop sending them soon.
Great, thank you!
No need to apologize, by the way. Bugmail noise happens; thank you for
moving on it
On 10/4/17 3:17 AM, Jan Keromnes wrote:
Please report any bugs with the bot here: https://bit.ly/2y9N9Vx
Not sure this is a bug, but...
I got bugmail today from this bug saying that a patch (not mine; just a
bug I was cced on) didn't have any problems. Can we consider having the
bot add
On 10/2/17 9:50 PM, Kris Maglione wrote:
For the pretty simple micro-benchmark below, here are the in-document
and out-of-document numbers for three runs without the subject principal:
Sorry, I should have been clearer: I meant numbers for "inserted into
the document" and "not inserted into
On 10/3/17 7:15 PM, Matthew N. wrote:
For those of you who don't know, when the "devtools.chrome.enabled" pref is
true the Web Developer > Browser Content Toolbox opens a toolbox targeting
the content process that the selected tab is loaded in.
Matt,
Do you know whether this starts a new
On 10/3/17 4:36 PM, Jeff Griffiths wrote:
2. it sets the default value of the tab to 50, previously this value
was hard-coded at 100.
Jeff,
So just to make sure I understand the change (and this is a theoretical
point, because I haven't had a chance to try the change yet)... Right
now, the
On 10/2/17 5:35 PM, Kris Maglione wrote:
So far it doesn't look like there's any significant difference on any
talos test from adding [NeedsCallerPrincipal] to
setAttribute/setAttributeNS/Attr.value,
OK. That's a minimum bar, obviously, but I would still like us to
measure what the
On 10/2/17 12:03 PM, Daniel Veditz wrote:
Fair enough. Could we propose improvements to the APIs that would make
them more usable? For example an object argument to createElement() that
contained attribute/value pairs?
This has definitely been proposed before. Worth checking with Anne to
On 10/2/17 10:50 AM, Daniel Veditz wrote:
As long as direct DOM manipulation works, and is easier
than overwriting (or removing) the page's CSP, can't we just encourage
people to use that mechanism?
The fact is, direct DOM manipulation with no parser involved is really
annoying to use.
On 9/30/17 12:19 AM, Kris Maglione wrote:
I still haven't settled on the details, but I it will probably have to
involve capturing the caller principal from SetAttr hooks. Which would
involve either changing that machinery to pass along a JS context when
invoked by a scripted caller, or using
On 9/29/17 3:32 PM, Kris Maglione wrote:
For instance, the following should all capture the
caller principal for the `src` URL at call time:
document.write(`http://example.com/favicon.ico;>`);
div.innerHTML = `http://example.com/favicon.ico;>`;
img.setAttribute("src",
On 9/25/17 11:45 AM, L. David Baron wrote:
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.
Well, it would need spec
On 9/25/17 9:01 AM, Anne van Kesteren wrote:
It does not seem hard to come up with solutions to those problems, if
we're actually committed to going down this path.
If we are, yes. We need to decide whether we are...
(E.g., just like globals have isSecureContext,
there could be a media
On 9/25/17 3:18 AM, Anne van Kesteren wrote:
But it would also be good if we could all communicate this on behalf
of Mozilla without caveats. E.g., Chrome might ship worklets soon and
being able to object to that happening (specification-wise) on
insecure contexts on behalf of Mozilla would be
On 9/4/17 4:51 AM, Anne van Kesteren wrote:
Also, do we need this for Promise, Map, Set, etc., or just IDL-defined objects?
For the moment, just the latter, I think, in that we have no one who is
trying to do if for the former...
-Boris
___
On 9/22/17 1:31 PM, Eric Rahm wrote:
The problem is these were never a null string, they're a voided empty
string.
Sure. In the DOM usage, it's "a string that will convert to JS null
when converting to 'DOMString?'", and not anything about the string
itself being null.
Arguably that API
On 9/22/17 2:41 AM, Nicholas Nethercote wrote:
This probably won't affect most people, because void strings are a niche
feature.
Not in the DOM. They're used anytime you see "DOMString?" in webidl.
http://searchfox.org/mozilla-central/search?q=DOMString%3F=webidl
shows several hundred hits.
On 9/20/17 3:18 PM, Mike Conley wrote:
it appears to be possible to have a non-visible but
active DocShell (despite the documentation [4]).
The documentation is kinda wrong. A simple example of an active but
non-visible docshell is a display:none iframe in the currently selected tab.
I
On 9/15/17 10:08 PM, Steve Fink wrote:
I've never used it, but it already has pretty much exactly this. Look at
--save, --preset, and --list-presets under ./mach help try syntax
Ah, I see. Alright, I'll give this a shot.
-Boris
___
dev-platform
On 9/15/17 6:30 PM, Gregory Szorc wrote:
we'd like to require the use of `mach try` for Try
submissions.
So just to be clear, instead of being able to "hg push -f try" will one
now need to do "./mach try syntax ." and put in the actual syntax
string on every single try push?
The reason
On 9/15/17 9:58 AM, David Bruant wrote:
Maybe @@toStringTag will end up not working well enough for your need anyway.
Not least because its use is kinda ugly, no?
But another solution could be to define a chromeonly symbol for the brand.
obj[Symbol.brand] === 'HTMLEmbedElement'
On 9/15/17 6:35 AM, Henri Sivonen wrote:
I'm assuming that anonymous frames count towards the
limit and a display: table-cell that doesn't belong to a table ends up
creating 5 frames. Correct?
Yes for both. It creates a table, table-row-group, table-row,
table-cell, and a block inside the
On 9/14/17 5:47 PM, Kris Maglione wrote:
Could we make it non-enumerable and add a counter to the window binding
resolve hook?
We could. Note that it would also trigger on sets of "window.content"
or on "var content" and so forth, though... Not clear how useful the
resulting data would be,
On 9/14/17 5:33 PM, Ehsan Akhgari wrote:
I think either of these two ideas would be good, but I think unshipping
in 57 is premature without having an understanding of how much the Web
depends on this for UA sniffing.
OK. Do you have any suggestions on how we could gain that understanding?
We
On 9/12/17 5:04 PM, Emilio Cobos Álvarez wrote:
I've noticed that this may be used pretty easily for UA detection.
Right, that and use in Gecko-only codepaths are the main concerns
I considered adding a usecounter, but as you noted it would be affected
by window enumeration.
We could
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=864845
window.content is a Gecko-specific thing that basically acts like
window.top in untrusted code. In chrome it returns the currently
selected tab, effectively.
I would like to unship window.content for 57; no one else implements it.
On 9/12/17 5:57 AM, Geoff wrote:
What they got instead was: undefined.
I actually can't think of a way this could happen...
This surely must mean that indexedDB.open is failing but not throwing an
exception.
Failing in what sense?
There _is_ a concept of "uncatchable exception" in Gecko,
On 9/11/17 10:08 AM, Henri Sivonen wrote:
What kind of style would have the maximum stack frame size? Is
display: table-cell enough to trigger the worst case?
I suspect that display:table-cell is the worst case, but at only about
70% confidence.
That said, I can't think of a worse case
On 9/11/17 7:41 AM, Henri Sivonen wrote:
Frame construction runs recursive algorithms along the depth of the
DOM tree.
It's not just frame construction. Recursive algorithms are all over the
place in layout and DOM code.
Frame construction may be a long pole here in terms of crashes due to
On 9/6/17 7:47 PM, Bobby Holley wrote:
Andrew became a peer in May, and Kris become a peer a few minutes ago.
Excellent. Congrats to them both!
And I do mean congrats, not condolences. ;)
-Boris
___
dev-platform mailing list
On 9/3/17 1:04 PM, Kris Maglione wrote:
The first layout flush here is happening when we focus an
autofocus form field.
That's longstanding https://bugzilla.mozilla.org/show_bug.cgi?id=1155812
and https://bugzilla.mozilla.org/show_bug.cgi?id=712130
-Boris
On 9/2/17 8:43 AM, Dustin Mitchell wrote:
The flashes (just saw another a moment ago) are on github.com.
On which exact page(s), if I might ask? For reproducing this sort of
thing details matter, so if you know what exact URL you saw it on that
would be very helpful.
-Boris
On 9/1/17 10:15 AM, Dustin Mitchell wrote:
I can narrow that bisection down to two sets: [test-pilot] and [].
So test-pilot is causing the flash of unstyled content in your case? I
assume this is the addon at https://testpilot.firefox.com/ ?
What pages are you seeing the flash of unstyled
On 9/1/17 4:54 PM, Kris Maglione wrote:
The other
potential issue is that the `instanceof Ci.nsIDOM...` checks tend to
appear in places like JSMs, where we don't have direct access to
constructors for DOM interfaces by default.
Right, if we used one of the things that use constructors, we'd
On 9/1/17 1:06 PM, Kris Maglione wrote:
if (ChromeUtils.getClassName(element) == "HTMLEmbedElement")
Ah, that works. Though I think spidermonkey wants to maybe get rid of
classnames and on the flip side it's not clear whether
HTMLEmbedElement.prototype will end up with the same
On 8/31/17 3:00 PM, Michael Froman wrote:
If I disable Ghostery, it no long appears to happen for me. YMMV.
Michael,
Thank you. So with Ghostery installed, I managed to reproduce a flash
of unstyled content when doing a force-reload of
https://github.com/servo/servo
That's because
Now that we control all the code that can attempt to touch
Components.interfaces.nsIDOM*, we can try to get rid of these interfaces
and their corresponding bloat.
The main issue is that we have consumers that use these for testing what
sort of object we have, like so:
if (obj instanceof
On 9/1/17 7:02 AM, Gervase Markham wrote:
Restarting with no extensions causes my browser to feel a whole lot
faster (I'd love to know why that is, but that's a separate issue!)
Worth trying to bisect on the extensions to figure this out...
but I can't reproduce the FOUC in a few minutes of
On 8/31/17 3:27 PM, Jet Villegas wrote:
FWIW, reverting the fix for bug 1283302 (fixed in FF53) fixes this issue.
Before that fix, we would wait up to 250ms before painting
To be clear, this is 250ms _after_ the layout-starting I described in my
previous post.
The general point remains: if
On 8/31/17 1:24 PM, Gervase Markham wrote:
Have we changed the timeout recently regarding how long Firefox waits
for a stylesheet before rendering the page?
We do not have such a timeout at all. Our wait is fairly deterministic.
We start layout as soon as:
A) Script requests layout
On 8/14/17 8:52 AM, Enrico Weigelt, metux IT consult wrote:
I wonder what exactly the CID's (*_CID defines) are for. IIRC, the
classes are looked up via their contract-IDs (*_CONTRACTID defines),
but I haven't seen anything that actually uses the CIDs.
The actual process is that when you
On 8/28/17 3:28 AM, Erxin Shang wrote:
I'm trying to build a release version Firefox. But after the build there seems
still a little bit different compare to the official build. Such as the
official build doesn't contain the folder chrome/, components/, gmp-fake/ etc
in the root of Firefox
On 8/16/17 6:56 AM, Enrico Weigelt, metux IT consult wrote:
I'd assume that do_CreateInstance() returns the object w/ refcnt=1.
Yes. It returns it as an already_AddRefed<> struct.
The assignment to nsCOMPtr should increase refcount. Correct ?
No, because nsCOMPtr knows not to increase the
On 8/9/17 1:43 PM, Daniel Veditz wrote:
What do web pages do if they want to reflect a pretty URL into their page?
Cry, basically.
This is the fundamental reason I was opposed to this behavior change,
but apparently no other browsers care about this issue and we were
getting compat
On 8/9/17 1:55 PM, Henri Sivonen wrote:
I'm thinking of introducing a C++-implemented XPCOM object that the
JS-implemented XPCOM object can hold a reference to and that has a C++
destructor that does what I want.
Does that mean your action doesn't depend on which exact JS object got
On 8/8/17 6:40 PM, Blake Kaplan wrote:
What part of the current set-up is rocket science?
Debugging pageload. Especially pageload with no session history.
In multi, there's
definitely a problem figuring out which process is the active one (though
tooltips when hovering over tabs can help).
On 8/8/17 5:12 PM, jma...@mozilla.com wrote:
In bug 1386689, we have turned them off. There was some surprise in doing this
and some valid concerns expressed in comments in the bug.
Indeed. Given how often non-e10s mode needs to get used for debugging,
it's a little concerning to see the
On 8/7/17 11:17 PM, Kris Maglione wrote:
There isn't. Not as such, anyway. By the end of the week, legacy
extensions that aren't specially signed will be disabled by default.
That fits what I want. That being a notification to nightly users that
says "These are now officially unsupported; if
On 8/7/17 6:17 PM, Nicholas Nethercote wrote:
Is there going to be a clear point in time when legacy extensions stop
working in Nightly?
I was under the impression that there is, and I strongly feel there
should be.
-Boris
___
dev-platform mailing
On 8/7/17 1:05 PM, Kris Maglione wrote:
So what is the state of things at the moment? Should we just turn off
old-style addons on nightly? If not, then we should probably stop
breaking them until we _do_ turn them off.
I don't think so. Extension authors know the score here.
OK, I thought
On 6/14/17 9:02 AM, Benjamin Smedberg wrote:
Given that old-style addons are going away for 57, if it's possible to
delay addon-breaking IDL changes by one release until 57 that's probably
the easiest way to deal with this. We're already causing the addon
community a lot of churn.
I'd like to
On 8/7/17 11:28 AM, Enrico Weigelt, metux IT consult wrote:
hmm, then what are the partial interfaces actually for ?
They're for use in specifications that want to add things to an existing
interface. They're a specification device, basically.
I had the impression that distributing
On 8/6/17 3:56 PM, Enrico Weigelt, metux IT consult wrote:
is there a way to use the partial interfaces for build-time
configurable features ?
Not without #ifdef.
Can I move that stuff to a separate webidl file, which is only
added in dom/webidl/moz.build when wakelocks enabled ?
(so no
On 8/2/17 11:18 AM, Nathan Froyd wrote:
In particular, the API of Sequence<> is constrained because it
inherits from FallibleTArray, which *only* exposes fallible
operations.
We should consider just fixing this.
The history here is that FallibleTArray and InfallibleTArray used to
bake the
On 7/23/17 9:58 PM, Enrico Weigelt, metux IT consult wrote:
what's the difference between idl and webidl ?
Brief summary. IDL:
1) Generates xptcall information for xpconnect to allow calling from JS
and into JS (via synthetic vtables).
2) Generates headers that declare pure virtuals.
3)
On 7/21/17 9:44 AM, nmago wrote:
Yes, I needed nsACString copy of data to use it as nsACString argument for
other function.
Assuming "cname" is a char[N] or char*, you should be able to do:
nsCString str(cname, N);
This will make a copy of the first N bytes of cname and add a
On 7/18/17 11:56 PM, Tom Ritter wrote:
Sorry I got the pref name wrong; it's svg.disabled from
https://bugzilla.mozilla.org/show_bug.cgi?id=1216893
Ah.
So as you note, this pref, when set, makes it so you can't even create
an SVGImageElement instance. And then of course you can't pass one
On 7/18/17 11:21 PM, Tom Ritter wrote:
This will respect the 'svg.in-content.enabled' pref, correct?
Respect in what sense?
What this will do is that _if_ you have an and you drawImage
it to a canvas, that will work, assuming the was loaded.
I don't think the pref you mention prevents
Summary: allow passing to canvas createPattern and drawImage.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1382027
Spec:
https://html.spec.whatwg.org/multipage/canvas.html#htmlorsvgimageelement
and https://html.spec.whatwg.org/multipage/canvas.html#canvasimagesource
Platform coverage:
On 7/14/17 1:31 AM, Jim Blandy wrote:
But keeping all the comments in one thread is a mixed blessing, too
Absolutely.
I guess what I'm saying is we should try to have some guidelines for
when it's appropriate to take the discussion back to the bug instead of
continuing it in the review...
On 7/13/17 9:04 PM, Mark Côté wrote:
It is also what newer systems
do today (e.g. GitHub and the full Phabricator suite)
I should note that with GitHub what this means is that you get
discussion on the PR that should have gone in the issue, with the result
that people following the issue
On 7/12/17 11:54 AM, Byron Jones wrote:
or uploading patches directly to bugzilla.
But still rewriting existing links (including from the mirrored review
comment comments, so it's clear which diff the review comments applied
to), right?
-Boris
On 7/5/17 5:41 AM, nmago wrote:
char* cname = new char[N];
memcpy(cname, , N);
nsACString strName(cname, N, 0);
This copies the data twice, and leaks it once, as far as I can tell.
What, exactly, are you trying to accomplish? For example, do you need
an nsACString that has a copy of your
On 6/23/17 8:39 AM, Carsten Book wrote:
We got a lot of Feedback thats its not easy to find out who is on
"sheriffduty". We will take steps (like adding |sheriffduty tag to irc
names etc)
For what it's worth, searching IRC names is a bit of a pain. Can we
just throw the current sheriff nick
201 - 300 of 952 matches
Mail list logo
