On 7/18/18 5:18 PM, Botond Ballo wrote:
My reading of the proposal is that that's an extension mechanism for
the program to be able to override handling of standard URI schemes,
or invent new ones (such as for serving a page from a string in the
C++ program's memory), but if e.g. the program
On 7/13/18 5:22 PM, gsquel...@mozilla.com wrote:
E.g., could I instrument one class, so that every allocation would be tracked
automatically, and I'd get nice stats at the end?
You mean apart from just having a memory reporter for it?
Including wasted space because of larger allocation
On 7/23/18 7:36 PM, Tanushree Podder wrote:
Secure contexts: Yes
I'm not sure what this line means here. The spec does not restrict this
API to secure contexts, right? Do we plan to thus restrict it in our
implementation?
I just filed https://github.com/WICG/visual-viewport/issues/56 on
On 7/18/18 12:45 PM, Botond Ballo wrote:
A recent proposal along these lines is for a standard embedding
facility called "web_view", inspired by existing embedding APIs like
Android's WebView:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1108r0.html
Botond,
Thank you for
On 7/24/18 3:34 AM, Hiroyuki Ikezoe wrote:
Secure contexts: Yes
Why?
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 7/24/18 4:22 AM, Michael de Boer wrote:
About the desktop perspective: is pinch-to-zoom a completely separate thing
from full-page-zoom as can be controlled right now with Ctrl+ and Ctrl- using
the
keyboard?
Yes. As a simple example, full-page-zoom does relayout (e.g. can change
where
On 8/29/18 10:32 AM, Ted Mielczarek wrote:
so it's possible that there are things here that are artifacts of our tup build
implementation.
Worth keeping in mind, thank you. Would that possibly account for the
exactly-the-same 99:44 rebuild times for a number of files?
Reading through this
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=820891
Summary: In other browsers, and arguably per spec as far as cssom-view
specs things, various geometry APIs on tables should report values for
the table wrapper, not the table itself, because they are defined to
work on the "first" box
On 7/10/18 11:47 AM, James Graham wrote:
Are there web-platform-tests covering this behaviour (both the part we
are changing and the part we aren't)?
I added some tests in bug 820891. See the three
testing/web-platform/tests/css/cssom-view/table-*-props.html tests.
There was also a tiny
On 7/10/18 10:59 PM, L. David Baron wrote:
The changes relative to the previous charter are:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2016%2F07%2Fwebperf=https%3A%2F%2Fwww.w3.org%2F2018%2F07%2Fwebperf-charter
It looks like the new charter proposes to merge navigation
On 7/11/18 5:42 AM, David Bruant wrote:
I've seen this information of 100 content processes in a couple places but
i haven't been able to find the rationale for it. How was the 100 number
picked?
I believe this is based on telemetry for number of distinct sites
involved in browsing sessions.
On 3/8/18 11:29 PM, Boris Zbarsky wrote:
I expect there is, but it wasn't super-obvious low-hanging fruit.
Sorry, I should have been clearer: there wasn't super-obvious
low-hanging fruit in the getter/setter/method bits. At least the parts
of it I poked at.
There might also be low-hanging
On 3/8/18 8:04 PM, Mike Hommey wrote:
Last time I looked at bindings, I was horrified to see all the various
strings that all look the same except between bindings for field and
class names.
So for what it's worth, I tried measuring this recently. When measuring
with "size" on Mac, if I just
On 3/14/18 7:03 AM, Gijs Kruitbosch wrote:
Unfortunately, our web feed implementation is pretty unused.
Not least because it's not discoverable, ever since we removed the
"there is a feed link on this page" icon, right?
(I don't disagree with any of what you said; I just think that the feed
On 4/5/18 1:11 PM, Ben Kelly wrote:
1. Make sure you set the nsIGlobalObject owner by passing it to the DETH
constructor or by calling BindToOwner().
Can we just enforce that by:
1) Removing the no-arg constructor from DETH.
2) Making the arg-taking constructors MOZ_ASSERT that the arg is
In https://bugzilla.mozilla.org/show_bug.cgi?id=1451929 I plan to remove
DOMCursor. It seems to be completely unused, and probably has been
since b2g code was removed.
The interface object _is_ exposed to the web, which is why I'm sending
this intent... There could in theory be sites using
On 4/10/18 4:03 AM, Gijs Kruitbosch wrote:
I looked at the patch briefly, and I'm a bit confused about the state of
The DOM bit is exposed, but we don't actually send pings.
Yes, this sucks in terms of detecting whether ping is supported...
-Boris
On 4/13/18 9:37 AM, Emilio Cobos Álvarez wrote:
Would people agree to use:
, mIsRootDefined { false }
Instead of:
, mIsRootDefined{ false }
So my take is that we should not use braced initializer syntax in
constructor initializer lists. The reason for that is that it makes it
much
On 4/13/18 9:40 AM, Alex Gaynor wrote:
I don't have an opinion on the style change itself, but I'm a very strong
+1 on just picking one and making sure clang-format enforces it.
We need to fix clang-format to not produce output like
On 4/18/18 3:27 PM, Kris Maglione wrote:
Legacy. The blocklist service is ancient, and has some C++ consumers.
The JS-only parts wound up getting glommed onto the XPIDL interface over
time. I'd already suggested we fix that before I realized it was the
cause of this problem.
OK. In that
On 4/18/18 1:54 PM, Gijs Kruitbosch wrote:
Err, so it seems a side-effect of this (which wasn't very obvious to me
when this was posted) is that it's now no longer possible to change a
..idl file for a JS component in an artifact build and have it "work".
So to be clear, this is a case in
Building on Nika's awesome work in bug 1444991, I just landed some
patches to remove nsIDOMEvent (bug 1455052). xpidl should now use
"webidl Event"; C++ should use "mozilla::dom::Event".
Please do not use Ci.nsIDOMEvent in JS code. I have fixed the m-c uses
I found.
If you need Event in a
On 4/18/18 11:19 PM, Nika Layzell wrote:
This allows us to avoid using nsISupports to pass WebIDL objects which
don't have corresponding XPIDL interfaces through XPIDL defined methods.
This is awesome.
In particular, it means we can pass WebIDL things through XPIDL without
adding weird "QI
On 4/23/18 3:50 AM, Andrea Marchesini wrote:
I introduced a deprecated message in bug 1334564, the 7th, February 2017.
When we have this data, it's worth mentioning what telemetry shows for
such a deprecation message.
I just checked and out of about 5.8 billion pageloads on Beta 60, about
On 4/19/18 3:53 PM, Gijs Kruitbosch wrote:
If I understand correctly, with these changes I could now just use
Promise instead.
Not yet, as Andrew said. This just makes things declared as "interface
Something { ... }" in .webidl files work. Promise is not one of those
things.
That said, I
On 4/25/18 8:12 AM, James Graham wrote:
If there is general agreement about restricting the feature to secure contexts
There is not. Given the discussion in the spec issue, I fully expect
Chrome to ship it in all contexts.
-Boris
___
dev-platform
I have just landed changes on inbound that restrict WebIDL
QueryInterface [1] and the Components object [2] to system scopes.
There are two caveats:
1) The Components bit is not fully enforced by the security
infrastructure yet, but those patches are coming in the next day or so. [3].
2)
On 3/26/18 3:16 AM, Emilio Cobos Álvarez wrote:
However other engines have shipped this unprefixed for a long time with
the same semantics that we implement
https://bugzilla.mozilla.org/show_bug.cgi?id=509958#c14 claims the
semantics are not actually quite the same. Have we done some testing
On 3/26/18 1:55 PM, Boris Zbarsky wrote:
I have just landed changes on inbound that restrict WebIDL
QueryInterface [1] and the Components object [2] to system scopes.
Oh, I meant to mention: in particular there is no longer a Components
available in XBL bindings attached to non-system
On 3/27/18 12:56 PM, Brian Grinstead wrote:
Wouldn't keeping it for file:// require us to maintain the infrastructure, or is there something that makes it worse in the whitelisted domain case?
It's a question of what guarantees we offer for XUL working.
Keeping it for file:// requires keeping
(I tried to send this to dev-platform@lists.mozilla.org, but tha's not
coming through for some reason There is parallel discussion in
firefox-dev if people want to try to track both.)
Background: We currently have various provisions for "remote XUL",
wherein a hostname is whitelisted to:
Background: We currently have various provisions for "remote XUL",
wherein a hostname is whitelisted to:
1) Allow parsing XUL coming from that hostname (not normally alllowed
for the web).
2) Allow access to XPConnect-wrapped objects, assuming someone hands
out such an object.
3) Run
On 3/27/18 11:49 AM, Alex Gaynor wrote:
What was the original intended use case for remote XUL, powerful origins
controlled by Mozilla, or enabling developers to build their own
powerful origins?
The latter. In particular, it was used for intranet apps.
Note that the remote XUL origins are
On 3/27/18 1:02 PM, Eric Shepherd wrote:
Yes, that's true. My thinking is that a first step could be to change
it so it had to be enabled using Policy Engine, and have an ESR release
with that
So presumably targeting 60? The timing is a bit tight...
Note that as things stand the only way
On 3/27/18 11:50 AM, Nicholas Alexander wrote:
- some of the details of "likely to break remote XUL consumers"? Which
consumers are these -- internal? External?
This is referring to my proposed XPConnect/Components changes, right?
External. We have no internal consumers of remote XUL
On 3/26/18 1:48 AM, Henri Sivonen wrote:
Rationale: Say what you mean when the language has vocabulary to do so.
Amen. I'd be happy with char32_t for scalar values.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 3/27/18 11:50 AM, Eric Shepherd (Sheppy) wrote:
The one potential exception: would it make sense to allow it to be
enabled (with it disabled by default) on copies of Firefox set up with
Policy Engine, to allow those users the option?
That would require maintaining the remote XUL
On 3/26/18 6:29 PM, Myk Melez wrote:
Do any of those bits of C++ code depend on a particular feature of
XPCOM
They depend on the dynamic casting provided by QueryInterface.
That said, they could in many cases switch to other methods of dynamic
casting that are more limited...
or do they
On 3/23/18 8:25 AM, Valentin Gosu wrote:
I would like to announce that with the landing of bug 1447194, all nsIURI
implementations in Gecko are now threadsafe, as well as immutable.
Valentin,
Thank you very much for doing this! Just the safety guarantees from URI
immutability are a huge
On 3/27/18 12:39 PM, Alex Gaynor wrote:
Do we have any telemetry on whether people actually use it?
I don't believe we do.
Are there any reasons to want to keep it around, besides backwards
compatibility?
Ease of writing tests and debugging XUL stuff (hence the thought to
maybe keep it
On 3/21/18 10:02 AM, tom...@gmail.com wrote:
I also don't see any arguments why this *needs* to be opt-out?
The point is to gather data on how this behaves in the wild. If the
study is opt-in, then you have to try to figure out what part of the
effect you're seeing (if any) is just
On 3/21/18 10:53 AM, tom...@gmail.com wrote:
On Wednesday, March 21, 2018 at 3:30:48 PM UTC+1, Boris Zbarsky wrote:
The point is to gather data on how this behaves in the wild. If the
study is opt-in, then you have to try to figure out what part of the
effect you're seeing (if any) is just
On 3/19/18 1:08 PM, Selena Deckelmann wrote:
There's a lot of thinking that went into the agreement we have with
Cloudflare to enable this experiment in a way that respects user privacy.
I would like us to be very clear that there are two separate things here:
1) Is this behavior good for
On 2/27/18 5:28 PM, Manish Goregaokar wrote:
You can already achieve this behavior with `rowspan=`
Only if you can guarantee that this number is in fact larger than the
number of rows in your rowgroup, yes?
And even then, is it exactly equivalent?
and we should encourage developers to
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 of the "e" prefix is to
highlight that you
On 10/11/18 11:43 AM, Andrew Osmond wrote:
We are facing a growing number of webcompat reports against our Gecko-derived
Android offerings, where web developers assume Android and/or mobile
implies support for WebP.
In the past, I believe we objected to adding WebP for various reasons.
Do we
On 10/11/18 4:22 PM, Philip Jägenstedt wrote:
https://gist.github.com/foolip/a77c88e62aa3cfc461c2879f3e5d4855 is a
list of tests that fail in Firefox Nightly, but pass in stable
versions of Chrome, Edge and Safari.
Or more precisely have some sub-test that has that property, right?
Thank you
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1498357 to track
these failures.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 10/12/18 1:56 PM, Brian Grinstead wrote:
Summary: Motion is a key component of modern web design, and is the
premier...
Fire. The premier fire so we can have fire and motion [1].
Or maybe it's just a dumpster fire? ;)
The proposed change looks great to me.
-Boris
[1]
On 10/18/18 10:45 AM, Jon Coppeard wrote:
DevTools bug: I don't know whether there is DevTools work to do here or not..
I can think of several devtools things that would be nice to have:
1) A log of which modules got loaded (and when?)
2) Ability to break in a module once it gets loaded but
On 10/19/18 8:42 AM, Philip Jägenstedt wrote:
That's a bit odd, the is in the markup and would be
when running manually or under automation. Are you sure that explains
the difference?
Yes. I filed https://github.com/web-platform-tests/wpt/issues/13625
-Boris
On 10/13/18 3:27 AM, Philip Jägenstedt wrote:
Fiddling with these rules can reveal lots
more potential issues, and if you like I could provide reports on that too.
I would be pretty interested in that, yes. In particular, a report
where there is 1 "not PASS and not FAIL" and 3 "PASS" would
On 11/2/18 11:32 AM, Kartikaya Gupta wrote:
Those of you working in Windows-only Rust and C++ code will probably
be happy to hear that as of today searchfox is indexing the
Windows-only bits of our codebase as well.
This is awesome. Thank you!
-Boris
On 11/15/18 9:52 AM, Ehsan Akhgari wrote:
The idea is to use Feature Policy in report-only mode
There is no report-only mode in the Feature Policy spec, nor in our
implementation. See the note at the end of
https://wicg.github.io/feature-policy/#reporting
So I'm back to my question: is
On 11/7/18 11:15 AM, Andrew Osmond wrote:
This is simply a
new method for JS on image elements, so it should be unavailable.
Script can run in sandboxed iframes, depending on sandboxing flags.
It sounds like this feature is enabled by default in sandboxed iframes,
as long as script is
On 11/13/18 4:33 AM, Andrea Marchesini wrote:
I decided to implement this API, because it is required in the
web-platform-tests for FeaturePolicy.
Is it needed for any other reason? If not, this seems like a bug in the
tests: they should not be coupling the two specs together.
-Boris
On 10/3/18 5:21 AM, James Graham wrote:
Commits to mozilla repos aren't involved
Right, that's what I was assuming.
So the net effect of all this is that bug fixes won't appear on the
dashboard until the first upstream wpt commit after they are present in
a nightly release.
Right.
I
On 10/2/18 1:38 PM, James Graham wrote:
Experimental (i.e. nightly/dev) builds of Firefox and Chrome are run on
Linux using Taskcluster after each commit to web-platform-tests.
Would a commit to Firefox that fixes some tests and just touches wpt
.ini files to mark those tests as passing
On 9/29/18 11:31 AM, tom...@gmail.com wrote:
Our modern roadmap is almost entirely driven by paying customers, and no
customers have expressed interest in this.
Are we a paying customer?
-Boris
___
dev-platform mailing list
On 9/24/18 4:04 AM, Henri Sivonen wrote:
How important is --enable-shared-js? I gather its use case is making
builds faster for SpiderMonkey developers.
My use case for it is to be able to use the "exclude samples from
library X" or "collapse library X" tools in profilers (like Instruments)
On 9/24/18 8:43 AM, James Graham wrote:
Thanks to great work by Outreachy intern Ahilya Sinha (:Cactusmachete)
[1], the in-tree wpt MANIFEST.json files are no longer used and will
soon be removed.
That's great news. :)
Invoking `mach wpt` will now cause a recent wpt manifest to be
On 1/14/19 4:28 AM, Henri Sivonen wrote:
This is now an "intent to ship". The feature landed in the spec, in
WPT and in Gecko (targeting 66 release).
Where do other browsers stand on this feature, do you know?
-Boris
___
dev-platform mailing list
On 1/14/19 12:58 PM, Mats Palmgren wrote:
Link to standard:
https://drafts.csswg.org/css-logical/#propdef-padding-inline
Two quick questions on the spec:
1) 'padding-block-start' is defined as:
Value: <‘padding-top’>
while 'padding-block' is defined as:
Value: <‘padding-left’>{1,2}
On 1/14/19 9:09 PM, fantasai wrote:
I have no idea why I did that. Fixed.
Thank you!
Yes, the spec reflects general consensus, and has been explicitly cleared
for shipping by the CSSWG (as of several years). See issue at the bottom
of the intro:
https://www.w3.org/TR/css-logical-1/#intro
Summary: When matching CSS attribute selectors against HTML, some
attribute names lead to case-sensitive value matching, while others use
ASCII-case-insensitive matching. The proposed feature adds an 's' flag
on attribute selectors that forces case-sensitive matching, just like
the existing
On 11/29/18 11:40 AM, Ehsan Akhgari wrote:
Yes, that is true sadly. But to be fair here, old mq patches that do not
apply due to age are already beyond saving with any kind of automated
tooling, and they require manual work to get them applied first. :-/
Sure.
That's not true.
On 11/29/18 11:40 AM, Ehsan Akhgari wrote:
Yes, that is true sadly. But to be fair here, old mq patches that do not
apply due to age are already beyond saving with any kind of automated
tooling, and they require manual work to get them applied first. :-/
Sure.
That's not true.
On 11/29/18 7:38 AM, Sylvestre Ledru wrote:
This extension will automatically rebase the local changes to avoid
conflicts.
Sylvestre,
Will it also update mq patches, or just in-repo commits?
-Boris
___
dev-platform mailing list
On 11/29/18 11:12 AM, Ehsan Akhgari wrote:
* Pull from a pre-reformat of the tree, run ./mach bootstrap to install
hg-formatsource.
* Do a one-time translation of your mq queue to a set of commits.
* Pull from hg.mozilla.org to pick up the reformat commit.
* Do a one-time translation
On 11/21/18 2:22 PM, Daniel Veditz wrote:
"opener" doesn't exist
It does in WebKit's proposed changes and in our implementation of them.
You'd specify a target
name other than "_blank" to indicate it's a context you care about
This seems backwards. What matters is whether the context
On 11/24/18 6:35 AM, susa...@gmail.com wrote:
It is strange to hear "we are misserable impotent at ALSA" from Mozilla devs...
Well, anyway, 2 years after your decision - how is feeling each time alsa-only
user courses you? Enjoy!
I'm sorry to have to say this, but the post above fails to
On 11/19/18 5:07 PM, john.biel...@googlemail.com wrote:
WWW-Authenticate: X-MobileMe-AuthToken realm="Newcastle", Basic
realm="Newcastle"
I expect this would work if you sent it as:
WWW-Authenticate: X-MobileMe-AuthToken realm="Newcastle"
WWW-Authenticate: Basic realm="Newcastle"
Yes, per
On 11/21/18 11:50 PM, Ehsan Akhgari wrote:
Would it be OK if the answer to that question be "use window.open()"?
Can one do noreferrer with window.open()?
Also, if your thing doing the navigation is a , not , then
window.open is pretty hard to use for that. Then again, target="_blank"> is
On 11/22/18 1:06 AM, Ehsan Akhgari wrote:
Can one do noreferrer with window.open()?
Yes, by passing 'noopener' in the features argument:
https://html.spec.whatwg.org/multipage/window-object.html#apis-for-creating-and-navigating-browsing-contexts-by-name:disowned-its-opener
But we're trying
On 11/15/18 4:17 PM, Andrea Marchesini wrote:
I think we should implement this API for these reasons:
OK. I guess we should keep an eye on the privacy implications, but
otherwise probably fine to go ahead.
-Boris
___
dev-platform mailing list
On 11/20/18 8:55 AM, Honza Bambas wrote:
because comma can be contained in a single header value
(against what the spec says). We can't correctly separate the headers
by commas, potentially even opening security holes if we do that blindly.
Do we know what other UAs do here?
-Boris
On 11/20/18 9:19 AM, Anne van Kesteren wrote:
Similar, e.g., https://bugs.chromium.org/p/chromium/issues/detail?id=872772.
Doesn't seem like a high priority for anyone to fix.
Well... If:
1) All the browsers agree here (do they?)
2) There are concerns that there may be sites depending on the
On 1/10/19 6:15 PM, Kyle Machulis wrote:
- Removal of [noscript] methods in interfaces in favor of direct calls via
Cast() where possible.
This seems generally reasonably, though I'd like to put in a bit of a
vote for the pattern I recently used for
nsIPrincipal::IsSystemPrincipal, which
On 9/14/18 1:58 PM, Andrea Marchesini wrote:
DevTools bug: No devtools support.
Seems like devtools might be useful for answering questions like "what
is the feature policy for this page and why?" given the complexity of
feature policy determination (headers, inheritance from parents, etc).
On 9/17/18 3:25 PM, Jeff Gilbert wrote:
I would be excited for something between MOZ_ASSERT and MOZ_CRASH
Note that we already have MOZ_DIAGNOSTIC_ASSERT in between those. We
should perhaps be using it a bit more.
-Boris
___
dev-platform mailing
On 1/28/19 7:51 AM, edusubscr...@gmail.com wrote:
Building was successful.
I'm really surprised the static assert at
https://searchfox.org/mozilla-central/rev/4faab2f1b697827b93e16cb798b22b197e5235c9/dom/bindings/FakeString.h#146-147
did not trigger, given the changes you described...
On 3/25/19 4:22 AM, violet.bugrep...@gmail.com wrote:
In the test, I want to make sure the object is indeed a wrapped one. Is there a
reliable way to write JavaScript code to achieve this?
Are you trying to write a JS shell test or a browser test?
-Boris
On 3/25/19 11:22 AM, violet.bugrep...@gmail.com wrote:
I think it should be a browser test, because I need to call IndexedDB.
OK, makes sense.
In that case, the simplest option is to pick a browser test that
involves Xray wrappers and modify it so you have an Xray to an
ArrayBufferView.
On 4/5/19 10:20 AM, Kartikaya Gupta wrote:
If we can drop that then we can remove a bunch of complexity
and code paths.
Are we talking about just dropping linux32 _tests_, or dropping linux32
_support_?
Because if we're keeping support, and linux32 is the only non-APZ
confiration, then not
On 4/5/19 9:35 AM, jma...@mozilla.com wrote:
As our next ESR is upcoming, I would like to turn off linux32 on Firefox 69 and
let it ride the trains and stay on 68 ESR. This will allow builds/tests to be
supported with security updates into 2021.
The only thing I've used the linux32 tests
On 4/1/19 2:36 PM, Brian Grinstead wrote:
When you run the command it will create a file with the appropriate
boilerplate and add it to the manifest file (chrome.ini, mochitest.ini,
browser.ini depending on the type).
Brian, thank you for putting this together!
I have one concern with the
Summary: historically in Gecko document.open created a new global and
new session history entry (unless "replace" was passed). We also stored
the written data in a "wyciwyg" cache entry so it could participate
meaningfully in session history. I plan to change these behaviors and
simplify the
Summary: We plan to place multiple globals in a single compartment to
reduce the memory overhead due to cross-compartment wrappers and the
performance overhead of traversing those wrappers. Globals will be
placed in the same compartment if: (1) they are same-origin (ignoring
document.domain)
On 2/21/19 3:44 PM, Kyle Machulis wrote:
and Pdf.js is still shipping as a stream handler for the
time being.
Note that there are a bunch of issues with that (e.g. around
window.print()), which we were hoping fake plugins would solve. If that
plan has been abandoned, it might be worth
On 3/7/19 7:31 PM, Ehsan Akhgari wrote:
*web-platform-tests*: This is an intervention which different engines do
not agree on yet. Creating a web-platform-test for it would be very simple
but it will be failing in the engines that do not agree with the
intervention. I'm not sure what the
On 3/7/19 6:14 PM, rekt...@gmail.com wrote:
Is there any way to feature detect support for import() syntax?
In Firefox, yes, as far as I can tell:
try {
new Function("import('')");
// supported
} catch (e) {
// not supported
}
-Boris
On 3/7/19 10:27 PM, Martin Thomson wrote:
Is there a way that doesn't rely on eval or eval-like mechanisms?
I suspect the only detectable thing here (and Jon might wake up tomorrow
and tell me I'm wrong!) is that import('stuff') is a syntax error
without the support but is not a syntax error
On 1/29/19 4:37 AM, Nanday Dan wrote:
I added the variable to FakeString. But still application crashes.
Sure, unless you also fixed the Rust interop issue.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 1/30/19 10:19 AM, Ehsan Akhgari wrote:
What tool do you use which has difficulty showing function names in diffs
right now? It seems to work fine for me both in git and hgweb...
"hg diff" and "git diff" both fail at this over here when there is a /*
comment */ before the function name.
On 4/9/19 10:37 AM, Brian Grinstead wrote:
I'll think some more about if there’s a way to limit the risk of losing test
coverage.
One simple thing is to restrict the change to
On 4/11/19 3:07 AM, Haik Aftandilian wrote:
With notarization, Nightly channel builds will not be debuggable unless the
system is booted with system integrity protection (SIP)[1] disabled.
Do you know whether sampling via Activity Monitor's "Sample Process"
option or via Instruments will
On 6/7/19 8:47 AM, Andrea Marchesini wrote:
Summary: implement and ship 3 new methods to read Blob contents:
blob.text(), blob.arrayBuffer() and blob.stream().
Looks good to me.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 6/14/19 7:02 AM, Henri Sivonen wrote:
Thanks for the removal. Do we have enterprise Web developer-facing
documentation on 1) how TLS client cert enrollment should work now or
2) if there is no in-browser client cert enrollment path anymore, what
concretely should be used instead?
For what
On 6/14/19 6:23 AM, violet wrote:
Preference behind which this will be implemented:
layout.css.overflow-logical.enabled
Thank you.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 6/10/19 4:07 PM, Valentin Gosu wrote:
which means nsIURI
can now be safely used and created on any thread via NS_NewURI.
That's awesome news!
and if you want to add any other special scheme to Gecko you should do so in
NS_NewURI in
nsNetUtil.cpp
Here "special" is in the sense of
801 - 900 of 952 matches
Mail list logo
