or follow along.
>
As I said before, this approach is, IMO, much too complicated; splitting
the reusable parts of Servo into their own repositories, as we have done
before, would be a much simpler solution.
However, as it seems the decision has already been made quietly long
ago, I don't see
of the implementation:
<https://hg.mozilla.org/integration/mozilla-inbound/rev/ddfcb1823adc>
Security & Privacy Concerns: none
(Please direct any further questions to Mats, who implemented the API.)
HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.m
isband this WG and
move any remaining useful work to the WHATWG.
HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
gt;
> In order to be compliant the spec, it's time to get rid of this.
> Any objection?
>
... and we will stop dispatching the clone event.
This is https://bugzilla.mozilla.org/show_bug.cgi?id=790919
Really great to finally see it gone!
Ms2ger
ll be shared with other vendors (and
Servo)?
Thanks
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
nsition from MXR to its more modern equivalent, DXR (
> https://dxr.mozilla.org), instead of bringing MXR back online.
I wish the years of complaining about MXR had led to an equally useful
replacement for it by now.
Sad to see it go.
Ms2ger
___
dev-p
a reflector when JS code needs it.
> the memory management arrangements of the two
> engines are fundamentally different and, therefore, the same WebIDL
> bindings won't work.
... but your conclusion remains correct.
HTH
Ms2ger
___
dev-plat
w about Edge?
Should we implement an unprefixed version as well?
> Preference behind which this will be implemented:
> layout.css.prefixes.webkit
Should this have a more specific pref?
Thanks
Ms2ger
___
dev-platform mailing list
dev-platform@lists
gt; rust-encoding UTF-8 and UTF-16 converters.
I agree that it is useful to have code looking like the spec in the
general case. However, if we were to get to the point where that was
the only argument against unifying your proposed library and
rust-unicode, I think we should
and maybe Aurora for now.
> I don't remember what the current conventional wisdom about
> prefixing is, but I would be open to shipping with a prefix if
> people thought that would ease pain in the eventual transition.
No. Nonononononononono.
Ms2ger
-B
ature/5743723954569216
>
Do we have tests in web-platform-tests that show our implementation is
interoperable with Blink?
I believe there was a capitalization issue with this feature; has it
been solved and the solution implemented everywhere?
Thanks
Ms2ger
-BEGIN PGP SIGNATURE-
iQEcBA
geSmoothingEnabled
>
>
>
> Blink and WebKit unprefixed awhile ago, too:
> https://code.google.com/p/chromium/issues/detail?id=277199
> https://bugs.webkit.org/show_bug.cgi?id=147803
Do we have a test suite that shows our implementation is interoperable
with
s)
Strongly in favour for all the reasons you mentioned.
Thanks
Ms2ger
-BEGIN PGP SIGNATURE-
iQEcBAEBAgAGBQJWKftoAAoJEOXgvIL+s8n2ALEH/3quXXrs7lAn1qiWjdj0nfTE
r6qbmHHUL1OlfkipeFLy+vjLmI2g5ep/aKlAfYBILowaQgzFlXUiTBiz1+Yz2ChD
1UzCHOGKxcPLNYVpgEu5snBjdWhPk1DJZk5DMt390V2ldU4LVfF0f9FvIsXW6n2G
o bring up fundamental issues
> for the first time at this stage.)
>
> (Sorry, should have sent these out a bit sooner.)
Does this mean that the W3C is claiming that the features in these
forks have interoperable implementations, and should we point out what
utter nonsense suc
C WICG, but given the state of the
> world, us shipping this with or without a spec can hardly cause any
> more harm.
Please submit tests to web-platform-tests and create a pull request to
the HTML standard.
Thanks
Ms2ger
-BEGIN PGP SIGNATURE-
iQEcBAEBAgAGBQJWJN+pAAoJEOXgvIL
oes not seem to support the claim that they intend to ship
this feature. No intent-to-ship is mentioned, and it appears the
intent-to-implement has not been sent.
Have other browser vendors provided any implementation feedback?
Thanks
Ms2ger
-BEGIN PGP SIGNATURE-
iQEcBAEBAgAGBQJV+9MXAAoJEOXg
errible idea. (Even if we're
the only Member raising a formal objection, I suspect Mike(TM) Smith
would be happy to amplify the message internally.)
OTOH, maybe we should just move the remaining useful specs in WebApps
to WHATWG; that'd solve the issue once and for all.
HTH
Ms2ger
-BEGIN P
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/26/2015 03:36 PM, Ehsan Akhgari wrote:
Hmm, I see. Have you considered the implications of making the
alias falsey in conditions, similar to document.all?
No. No. Nononononono.
Ms2ger
-BEGIN PGP SIGNATURE
.
HTH
Ms2ger
-BEGIN PGP SIGNATURE-
iQEcBAEBAgAGBQJVrh8gAAoJEOXgvIL+s8n2OG0H/ioMX2t9p01ngpsKhmsX5yAC
rNvBAf+yhkT6AanCXmXvdnvUbYXjo2zgSQmxPrhRkLWIYQHTjQN4guMoc1v5HljW
JE2Aa5xT5tbKPQ2p/6smwQZyBWZxa7OwapefzrtRBXILyqOFeTG4qqgnd7Hvw1Nx
N9G0e+JgiQjpvZLA3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/01/2015 01:35 AM, James Graham wrote:
Web-platform-tests are now running in debug builds on try only.
\o/
Thanks for getting this up and running!
Ms2ger
-BEGIN PGP SIGNATURE-
iQEcBAEBAgAGBQJVk5APAAoJEOXgvIL+s8n2yrQH
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/22/2015 05:51 AM, J. Ryan Stinnett wrote:
On Sched, it appears the Servo session is scheduled for Friday, 1 -
3 PM, is that now the correct date and time?
That's correct.
HTH
Ms2ger
-BEGIN PGP SIGNATURE
this is the
webperf wg), and keep it out of release builds at least until it's
been discussed there.
Ms2ger
-BEGIN PGP SIGNATURE-
iQEcBAEBAgAGBQJVXf7hAAoJEOXgvIL+s8n2ON4H/joOtkdA6pAqsEJmFZebZmZH
CND5saMByYUx78y9eH81PWFVzthDqPAcQJ1aowkLjn6PoWQ2wzvIXs1dF4zzBwyu
UjXeFPyGr+DNL9R+r6m4VEO0w8pA
without 100% confidence? Here's the guidance from the Wiki:
without 100% doesn't mean with 10%, which is what it feel like
nowadays. Tryserver time is machine time; inbound bustage is people
time, and the latter is much more expensive.
Ms2ger
-BEGIN PGP SIGNATURE
for is().
Thanks to everyone who helped bring this home!
Ms2ger
-BEGIN PGP SIGNATURE-
iQEcBAEBAgAGBQJVLhlwAAoJEOXgvIL+s8n27TEH/RTBfCQmN0dwDzzRGPsYT9ya
ztmFfpJq2NKe85YX9XnO+yLha9Lvc2V83J4SHRC0PpJgKEfgR3DAswCDnX+MOD3e
7PfXqkY6ceVhrrPz1b0TxWWCnVvW9OyjlxhAjH7k8K96T0uBvcrB3q0AKFLC4aXH
://bugzilla.mozilla.org/show_bug.cgi?id=1124608
Link to standard:
https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#h-event-modifier-initializers
What are other browsers planning to do? Do we have any tests in wpt
that could show interop?
- --
Thanks
Ms2ger
-BEGIN PGP
that have been suggested, yes. (I've heard
suggestions for async innerHTML too, but I don't think that was in the
context of Servo.)
Either way, while some people have been dreaming about such APIs,
we're not actually working on any, or planning to start working on them.
HTH
Ms2ger
-BEGIN PGP
the web-platform tests
(https://github.com/w3c/web-platform-tests/tree/master/subresource-integrity)?
Do we run them in automation? Do we intend to extend
the tests to a level where we can be confident about interoperability
with other browsers?
Thanks
Ms2ger
-BEGIN PGP SIGNATURE
://bugzilla.mozilla.org/show_bug.cgi?id=666414,
https://bugzilla.mozilla.org/show_bug.cgi?id=710473.
HTH
Ms2ger
-BEGIN PGP SIGNATURE-
iQEcBAEBAgAGBQJUmR8xAAoJEOXgvIL+s8n2OlcH/Am6t8XxPCvZj3w/VWbPbhF8
wQRqfnWvdHwB/neOxaTzcyMWL1siQfQIHTmDjOKmbKtD6tETyybuYiWba6YmRjFQ
52URtbQkh5zRS6VawRyNEiMc3ea6gnj
the new paths, see:
https://gist.github.com/poiru/b266b75473a8d9f71d33
Did we not coordinate this with the sheriffs at all? This needs to
be merged to all trees as soon as possible to keep the merge pain
down.
Philor merged to m-c and fx-team, fwiw.
HTH
Ms2ger
-BEGIN PGP SIGNATURE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/14/2014 02:09 AM, Kyle Huey wrote:
The simplest way to break the installer down is by the files in
it.
e.g. http://khuey.pastebin.mozilla.org/6781501
For future reference:
mozilla@KHUEY-19294 /c/dev/scratch $ wget
://gitmirror.mozilla.org/ should be our project
directory.
Looks like the instructions to add repos are on intranet; why?
Ms2ger
-BEGIN PGP SIGNATURE-
iQEcBAEBAgAGBQJULCydAAoJEOXgvIL+s8n2+0MIAJKuWFkVTXpNwdirhBY+P/Zj
4yE8U3SAwzYoG+rTWpqozUeGQDhtDKlxM9VsKyRDdVKR+co2O+Eno1yhJjYDp0EI
to retract them at worst, I believe the answers
that make the most sense are
* Regarding the HTML5 specification, my organization: abstains from
this review.
* My organization: does not expect to produce or use products or
content addressed by this specification
HTH
Ms2ger
-BEGIN PGP SIGNATURE
methods.
Ms2ger
-BEGIN PGP SIGNATURE-
iQEcBAEBAgAGBQJUEVzEAAoJEOXgvIL+s8n2YWYH/i9h3e3GvQ9dPrYYg72F/mdD
BXdyHiyKarz4dSI8H0UJHwDhCtBKi92AskHhCeT3l4KX4h7pX87144LYNYiZ9qzv
rMXDFvf5Oo8M4uaEPo82z1M2OW6jADuFCfs4SeK+1aqW5DLRRMlYiGfop4yeGp+g
m81ciytaLr08ro6+K+HgIP/zCo5KLtvp54kGLRg0EMqWnNE4SxG8Nrvm
identified as needing external access.
I don't think anyone is in agreement with this, actually. The
suggestion was to use a manifest annotation *instead of* the
unnecessary directory structure.
HTH
Ms2ger
-BEGIN PGP SIGNATURE-
iQEcBAEBAgAGBQJT7QmWAAoJEOXgvIL+s8n2sQYIAJFNcZul6cQjWQ6oMGTpfDta
sensible approach to
achieve that goal would be to adopt the testharness.js methods, which
are also more consistently named, have better behaviour for the
shorter-name methods, and are documented more clearly.
HTH
Ms2ger
___
dev-platform mailing list
) {
throw new Error(This need to be a non-negative whole number);
}
Well, it adds up. :) Even now I can replace the fifth condition with
!Number.isFinite(num).
One could use if ((num | 0) !== num) { ... }. That should be
equivalent for 32-bit unsigned integers.
HTH
Ms2ger
On 04/15/2014 11:08 PM, Joshua Dover wrote:
as this current specification is not on a standards track
(and will probably not be compatible with what we have now).
That sounds like a clear no to me.
HTH
Ms2ger
___
dev-platform mailing list
dev
, forgot to mention, sorry. Hoped it's obvious from looking into the
IDL file.
Why do you take this as two differences?
netwerk vs network
HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev
reviewers.
HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
the NS_ENSURE_* macros have been
effectively deprecated.
HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
-contributor readability.
Personally this doesn't bother me much (although aCx will always be
painful compared to cx as two no-cap letters, I'm sure), but others
are much more bothered.
Based on the discussion in #jsapi yesterday, I'm not sure that most JS
hackers is necessarily accurate.
HTH
Ms2ger
from WebKit
HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
:
| nsIScriptSecurityManager* ssm = nsContentUtils::GetSecurityManager();
| rv = ssm-GetSimpleCodebasePrincipal(originURI,
|
getter_AddRefs(providedPrincipal);
| if (NS_WARN_IF(NS_FAILED(rv))) {
HTH
Ms2ger
___
dev-platform mailing list
dev-platform
the bug should be fixed?
As was mentioned before, very much the former.
HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
of our CVS repositories, of which I
think none are in active development.
It's the source of truth for pre-mercurial Gecko history; I find myself
having to use it surprisingly often.
HTH
Ms2ger
___
dev-platform mailing list
dev-platform
.
The etherpad was at https://etherpad.mozilla.org/commonissues. Since
it's been out of the topic since last March, though, I don't think
anything there is particularly common still.
HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
, this could cause more bustage when changes that built locally turn
out not to have enough includes; on the other, it might be better than
having to fix up a dozen unrelated files whenever you add a new one.
Thoughts?
Ms2ger
___
dev-platform mailing list
dev
/?c=mozilla%23contents=30+Sep+2013e=30+Sep+2013#c137495
HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
, the issue is that makeURI(makeURI(str).spec).spec !=
makeURI(str).spec.
HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
changed since.)
* Would you want to additionally consider using something like JS-Lint
for our codebase?
I don't want to derail this thread, but AIUI, JSLint enforces Douglas
Crockford's style, which is not necessarily something anyone else wants
to use.
HTH
Ms2ger
[1] http
starting.
Test jobs are kicked off before 'make check' starts.
HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
to put them further away.
HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
-Inbound.
(And, worse, that might actually be wasting the time of many others
by increasing wait times on Try.)
To be honest, at this point, it feels like using Try too rarely is a
bigger problem than using it too often.
Ms2ger
___
dev-platform mailing
tests in preference to mochitests when possible, and I'd
hate the preference to change to be in favor of mochitests, because
xpcshell tests are much more convenient (and faster) to write and
run.
Kyle already answered this.
HTH
Ms2ger
___
dev-platform
, the fact that a test fails intermittently in Gecko doesn't
necessarily imply that it will also fail intermittently in other
browsers; these failures often point to actual Gecko bugs, rather than
test issues.
HTH
Ms2ger
___
dev-platform mailing list
dev
On 08/16/2012 06:21 PM, Ehsan Akhgari wrote:
On 12-08-16 11:34 AM, Ms2ger wrote:
On 08/16/2012 05:10 PM, Ehsan Akhgari wrote:
I think this is generally a good idea. I have a few questions before
jumping in to agree though.
1. Is the current testharness.js API the documentation
56 matches
Mail list logo
