On 9/30/2014 11:44 PM, Eric Shepherd wrote:
Last week the idea came up that it would be helpful to create a list on
MDN of the Mozilla projects that are on GitHub, with links to those
sites. I have two questions:
1. Do we already have such a list anywhere?
2. If you have a project (or
Hi,
Thank you!
Yes, I do care about iFrames, and I'll check out nsDocShell::LoadURI.
As for the logging, currently i'm using my own, simple infrastructure, but I
was just curious if there is something already used by the Firefox source, e.g.
I see a bunch of LOG(...) statements scattered
On 02/10/2014 00:52, Till Schneidereit wrote:
Unfortunately, it turns out that Array.prototype.contains breaks the web.
Or, the MooTools-using parts of the web, at least. So I'm preparing a
backout right now.
Can we not reach out to the MooTools people and work together unbreak
the web?
On 02/10/14 09:06, Philip Chee wrote:
On 02/10/2014 00:52, Till Schneidereit wrote:
Unfortunately, it turns out that Array.prototype.contains breaks the web.
Or, the MooTools-using parts of the web, at least. So I'm preparing a
backout right now.
Can we not reach out to the MooTools people
No I can't wait for it to happen
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Is there even a solution to that problem? Could, say,
`Array.prototype.contains` be instantiated lazily when called and only
if no `Array.prototype.contains` has been defined by web code?
On 02/10/14 10:49, James Graham wrote:
Unfortunately js libraries aren't like web browsers; you can't just
The W3C WebFonts Working Group[1] has been working on designing and
specifying a new compressed font format for the web, aiming to give
significantly smaller file sizes than the existing WOFF format (to
reduce bandwidth requirements), while remaining cheap to decode (for
low-power devices).
On 02/10/2014 17:30, David Rajchenbach-Teller wrote:
On 02/10/14 10:49, James Graham wrote:
Unfortunately js libraries aren't like web browsers; you can't just ship
a new version and upgrade all existing users in a matter of weeks.
Instead usage of the broken versions may continue for years,
On Thu, Oct 2, 2014 at 2:24 PM, Philip Chee philip.c...@gmail.com wrote:
On 02/10/2014 17:30, David Rajchenbach-Teller wrote:
On 02/10/14 10:49, James Graham wrote:
Unfortunately js libraries aren't like web browsers; you can't just ship
a new version and upgrade all existing users in a
On Wed, Oct 1, 2014 at 7:51 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:
On 2014-10-01, 1:20 PM, Till Schneidereit wrote:
That's a great point. It would be great if we can adopt
https://wiki.mozilla.org/WebAPI/ExposureGuidelines for new JS
fatures as well.
Yes, I think we
That's provided by the NSPR library we use; see
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSPR/Reference/Logging
for an in-depth explanation, or
http://bertrandbenoit.blogspot.ca/2011/09/activate-logging-for-mozilla.html
for a quick explanation of how to view the output.
All changes have been applied, as of a few moments ago.
- Mensaje original -
De: Hal Wine hw...@mozilla.com
Para: release rele...@mozilla.com, Sheriffs sheri...@mozilla.org, Ben
Kero bk...@mozilla.com, Gregory Szorc gsz...@mozilla.com
CC: Kendall Libby kli...@mozilla.com, Mark Côté
On 2014-10-02, 9:58 AM, Till Schneidereit wrote:
On Wed, Oct 1, 2014 at 7:51 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
mailto:ehsan.akhg...@gmail.com wrote:
On 2014-10-01, 1:20 PM, Till Schneidereit wrote:
That's a great point. It would be great if we can adopt
On Thu, Oct 2, 2014 at 4:51 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:
(Of course, I have no idea whether you'd be OK with just calling the
Preferences API inside the js code or if we need to invent some kind of a
way to mask that away, and just pass the necessary info into the JS engine
I don't have control over that site anymore.
On Wed, Oct 1, 2014 at 10:19 AM, Ralph Giles gi...@mozilla.com wrote:
Forked and PR submitted.
Jeff, do you still have admin access on gitmirror.mozilla.org? Can you
deploy and confirm the fix?
-r
On 2014-10-01 10:12 AM, Ralph Giles wrote:
On
On 2014-10-02 4:03 AM, Jonathan Kew wrote:
The format is primarily based on earlier TrueType compression work
(MicroType Express) by Monotype, and a new entropy coder (Brotli)
developed by Google's data compression team in Zurich.
What kind of filesize reductions do you see over ttf and
On 2/10/14 16:20, Ralph Giles wrote:
On 2014-10-02 4:03 AM, Jonathan Kew wrote:
The format is primarily based on earlier TrueType compression work
(MicroType Express) by Monotype, and a new entropy coder (Brotli)
developed by Google's data compression team in Zurich.
What kind of filesize
On Thu, Oct 2, 2014 at 4:51 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:
On 2014-10-02, 9:58 AM, Till Schneidereit wrote:
The full answer to that is actually ridiculously complicated. The part
relevant here is, though: very early on in at least some cases. Too
early to rely on
On 2014-10-02, 7:03 AM, Jonathan Kew wrote:
The W3C WebFonts Working Group[1] has been working on designing and
specifying a new compressed font format for the web, aiming to give
significantly smaller file sizes than the existing WOFF format (to
reduce bandwidth requirements), while remaining
On Thursday, October 2, 2014 9:17:38 AM UTC-7, Ehsan Akhgari wrote:
On 2014-10-02, 7:03 AM, Jonathan Kew wrote:
WOFF2 is currently supported by Chrome and Opera,[4] and the Google
webfonts service is serving WOFF2-compressed fonts to browser versions
that are known to support it.[5]
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1075985 to cover the fact
that steeplechase does not work with the new layout. This is more of an FYI.
Syd Polk
sp...@mozilla.com
+1-512-905-9904
irc: sydpolk
On Sep 30, 2014, at 23:22, Robert Strong rstr...@mozilla.com wrote:
The Mac
On 10/2/14, 4:06 AM, Philip Chee wrote:
Can we not reach out to the MooTools people and work together unbreak
the web?
Already done. Now you just have to get the several million sites using
old MooTools versions to update.
-Boris
___
dev-platform
On 2014-10-02, 1:14 AM, Xidorn Quan wrote:
On Wed, Oct 1, 2014 at 6:27 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
mailto:ehsan.akhg...@gmail.com wrote:
On 2014-10-01, 7:42 PM, L. David Baron wrote:
On Wednesday 2014-10-01 16:24 -0700, Eric Rescorla wrote:
Obviously, if
On Sep 30, 2014, at 5:36 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
On 2014-09-30, 4:29 AM, Henri Sivonen wrote:
More immediately we should make it impossible to make persistent
grants for these features on unauthenticated origins.
This I agree with when it comes to privacy-sensitive
On 2014-10-02, 2:34 PM, Richard Barnes wrote:
On Sep 30, 2014, at 5:36 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
On 2014-09-30, 4:29 AM, Henri Sivonen wrote:
More immediately we should make it impossible to make persistent
grants for these features on unauthenticated origins.
This I
Hi,
I was looking at a large number of JavaScript (strict) warnings, and
errors from the recording of |make mozmill| test run of locall-built
DEBUG BUILD of TB last several days after a refresh of C-C source tree.
The number of such has increased very much both
- due to the seemingly stricter
We should most likely assert when we have strict violations in chrome JS.
We should *definitely* assert when we have JS errors in chrome JS.
I don't see how there should be any excuse for either of these cases.
We certainly can't assert on non-browser JS errors, but we should keep our own
On 2014-10-01 12:16 PM, Ehsan Akhgari wrote:
On 2014-10-01, 11:59 AM, Ralph Giles wrote:
On 2014-10-01 7:17 AM, Mike Hoye wrote:
Having to scramble to recover from data loss - particularly around
source or bug tracking - is a miserable experience we should try to
avoid.
Perhaps
On 10/02/2014 11:59 AM, ISHIKAWA,chiaki wrote:
Hi,
I was looking at a large number of JavaScript (strict) warnings, and
errors from the recording of |make mozmill| test run of locall-built
DEBUG BUILD of TB last several days after a refresh of C-C source tree.
The number of such has
See bug 807862 - Use strict mode for all builtin JS
Note that some of those warnings are from SpiderMonkey's non-standard
extra warnings mode, not ES5 strict mode. To confuse matters, extra
warnings were called strict warnings before ES5 and are controlled by
the javascript.options.strict
On 02/10/14 12:52, Chris Peterson wrote:
SpiderMonkey already forces ES5 strict mode and extra warnings mode
for all self-hosted JS: bug 784295.
The problem is that this only generates an exception, not a test
failure, so if the error is in code that isn't depended upon (also a
problem),
On 02/10/14 11:58, Ehsan Akhgari wrote:
What data specifically? I'm fairly confident that we can make this
change no matter how many websites use geolocation from
non-authenticated origins.
I believe that usual practice before we remove something we don't like
is to provide some warning.
On 10/2/14 1:07 PM, Martin Thomson wrote:
On 02/10/14 11:58, Ehsan Akhgari wrote:
What data specifically? I'm fairly confident that we can make this
change no matter how many websites use geolocation from
non-authenticated origins.
I believe that usual practice before we remove something we
Thanks for bringing this up!
So ever since extra super awesome strict warning were turned on we indeed have
to endure longer tail logs during test runs and when running debug builds. Just
like I get the information telling me which video card my computer has for
about the 1000th time.
All in
On 2014-10-02, 4:07 PM, Martin Thomson wrote:
On 02/10/14 11:58, Ehsan Akhgari wrote:
What data specifically? I'm fairly confident that we can make this
change no matter how many websites use geolocation from
non-authenticated origins.
I believe that usual practice before we remove something
On 2014-10-02, 4:38 PM, Justin Dolske wrote:
On 10/2/14 1:07 PM, Martin Thomson wrote:
On 02/10/14 11:58, Ehsan Akhgari wrote:
What data specifically? I'm fairly confident that we can make this
change no matter how many websites use geolocation from
non-authenticated origins.
I believe that
Indeed, which is why I recommended assert, not warn.
Warnings are basically useless from a CI standpoint.
If you want to guarantee it, don't warn, assert.
-Jeff
- Original Message -
From: Martin Thomson m...@mozilla.com
To: dev-platform@lists.mozilla.org
Sent: Thursday, October 2, 2014
On 2014-10-02, 4:40 PM, Mike de Boer wrote:
Thanks for bringing this up!
So ever since extra super awesome strict warning were turned on we indeed have
to endure longer tail logs during test runs and when running debug builds. Just
like I get the information telling me which video card my
Are we going to spend the time to fix these, however?
I’d be up for that, certainly!
For context, for as long as I remember, if you kept the browser console open
and used the browser, we'd occasionally report an unhandled chrome JS errors
(for example when attempting to access properties
On Thu, Oct 2, 2014 at 9:42 AM, Jonathan Kew jfkth...@gmail.com wrote:
Or do people need to hardcode
UA versions to know what UAs support it?
I believe that's what Google Fonts currently does, though IMO a better
approach is to serve CSS that offers both WOFF2 and older (more
On 10/2/14, 4:53 PM, Jeff Gilbert wrote:
If you want to guarantee it, don't warn, assert.
Note that mochitest-plain tests will go orange on unexpected uncaught
exceptions. Not least because we added that pretty early on in their
evolution.
We're nowhere close to doing that with
42 matches
Mail list logo
