Support for 32bit on OS X and testing infrastructure
As I have read [1] that Google will drop support for 32bit mode of Chrome with the upcoming 39 release in November. I wonder what our support plans for 32bit mode on OS X look like. Is it something we want to keep, to allow e.g. users of Chrome, who cannot run a 64bit version of Chrome, to switch over to Firefox? Or is it something we would like to follow? I just wonder because of bugs like 960509, which went unnoticed for a while. Do we actually have test coverage of the 32bit version via TBPL, or not at all? How stable are we? Would we be able to catch regressions in the case of no tests are running for this mode? Via bug 967055 there is at least the question to enable Mozmill tests for the 32bit binary. Before I want to continue with it, I would like to have some feedback here first. Thanks, Henrik [1] http://googleappsupdates.blogspot.de/2014/09/google-chrome-64-bit-for-mac-and-windows.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
RE: Support for 32bit on OS X and testing infrastructure
Regarding dropping support, Silverlight on Mac does not support 64 bit and we run it using 32 bit. So at the very least we will need html5 for sites like Netflix before we can drop 32 bit support on OS X. Robert -Original Message- From: dev-platform [mailto:dev-platform- bounces+rstrong=mozilla@lists.mozilla.org] On Behalf Of Henrik Skupin Sent: Friday, September 19, 2014 3:36 AM To: dev-platform@lists.mozilla.org Subject: Support for 32bit on OS X and testing infrastructure As I have read [1] that Google will drop support for 32bit mode of Chrome with the upcoming 39 release in November. I wonder what our support plans for 32bit mode on OS X look like. Is it something we want to keep, to allow e.g. users of Chrome, who cannot run a 64bit version of Chrome, to switch over to Firefox? Or is it something we would like to follow? I just wonder because of bugs like 960509, which went unnoticed for a while. Do we actually have test coverage of the 32bit version via TBPL, or not at all? How stable are we? Would we be able to catch regressions in the case of no tests are running for this mode? Via bug 967055 there is at least the question to enable Mozmill tests for the 32bit binary. Before I want to continue with it, I would like to have some feedback here first. Thanks, Henrik [1] http://googleappsupdates.blogspot.de/2014/09/google-chrome-64-bit-for- mac-and-windows.html ___ 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
W3C Proposed Recommendation: HTML5
W3C recently published the following proposed recommendation (the stage before W3C's final stage, Recommendation): http://www.w3.org/TR/html5/ HTML5 There's a call for review to W3C member companies (of which Mozilla is one) open until October 14. This specification is largely based on a snapshot of the WHATWG's HTML specification, written by Ian Hickson. If there are comments you think Mozilla should send as part of the review, or if you think Mozilla should voice support or opposition to the specification, please say so in this thread. (I'd note, however, that there have been many previous opportunities to make comments, so it's somewhat bad form to bring up fundamental issues for the first time at this stage.) One of the open issues being raised in this review is the status of the spec's normative reference to the URL specification. The specification currently references http://www.w3.org/TR/url/ ; it might be possible for us to suggest that it instead reference either http://url.spec.whatwg.org/ or https://whatwg.org/specs/url/2014-07-30/ (although if we did so, it would probably be best for somebody to raise the issue elsewhere in addition to it just being part of our review). I expect the finalization of this specification at W3C to be a big event, compared to other specifications. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: ES6 lexical temporal dead zone has landed on central
On 09/18/2014 04:18 PM, Kent James wrote:
Substituting var for let does not result in code that behaves identically to
previous code, so I can't see why that would be proposed.
The proposal would be to perform the substitution only for let at body level
of a function. (And for global let -- which requires its own semantic changes,
see bug 589199, that are in progress but not complete yet.) So this:
let s = valid;
{ let s = invalid;}
dump(s);
would be converted to this:
var s = valid;
{ let s = invalid;}
dump(s);
with no semantic change.
This substitution is absolutely not a good idea in the long run. In the short
run, for a release or two...maybe. But that's a vry hesitant maybe. I'm
leery of introducing these deviations into the language, such that people write
code expecting the standard semantics and are surprised to find the code
doesn't work as expected in other contexts. How should addons that inject code
into pages behave, for that code? Is this something that an addon author could
easily predict? I could well imagine it working either way. I'd really rather
not go down this path if we can help it.
Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: HTML5
On 9/19/14, 8:23 PM, L. David Baron wrote: W3C recently published the following proposed recommendation (the stage before W3C's final stage, Recommendation): The biggest issue I have with this is exiting CR without anything resembling a comprehensive enough test suite to ensure anything like interop on some of the core hard pieces (they left out the navigation algorithm, smart, but still have the bogus WindowProxy spec in this supposed PR, for example). My second biggest issue is that I don't have a concrete proposal for addressing this the first issue. Maybe it all doesn't matter too much as long as implementors keep reading the whatwg spec instead. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
