did mozilla postponed electrlolysis firefox to version 42?

2014-12-29 Thread Yaron Kahanovitch
Firefox 2015 roadmap states that e10 will be released with fireox42.
I thought that e10 will be released with firefox 36.
Does anyone knows where to get more detail information about that?

thanks

Yaron Kahanovitch.
 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Turning off Overscroll on Windows touchscreen scrolling

2014-12-29 Thread jmathies
On Sunday, December 28, 2014 7:20:25 PM UTC-6, Aaron Travis wrote:
> I've noticed that when you're scrolling a text field on a Windows touch 
> screen and you reach the end of the scroll, the entire program "pulls" in the 
> direction of the scroll and then snaps back.  Not just the text field, but 
> all of Firefox slides and then rubber bands back.  I'd like to turn this off 
> in the code.  Does anyone know where I could find this in the source code?

Right here - 

http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsWinGesture.cpp#257
http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsWinGesture.cpp#493

No prefs associated with this currently, feel free to add one if you like and 
flag me for review.

Jim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Test Informant Report - Week ending Dec 28

2014-12-29 Thread Test Informant

Test Informant report for 2014-12-28.

State of test manifests at revision 8850aa0f5332.
Using revision 8880b5632e2b as a baseline for comparisons.
Showing tests enabled or disabled between 2014-12-19 and 2014-12-28.

90% of tests across all suites and configurations are enabled.

Summary
---
marionette- ↑2↓0   - 92%
mochitest-a11y- ↑0↓0   - 99%
mochitest-browser-chrome  - ↑3↓9   - 94%
mochitest-browser-chrome-e10s - ↑0↓0   - 57%
mochitest-chrome  - ↑0↓0   - 96%
mochitest-plain   - ↑16↓18 - 92%
mochitest-plain-e10s  - ↑10↓0  - 79%
xpcshell  - ↑12↓0  - 97%

Full Report
---
http://brasstacks.mozilla.com/testreports/weekly/2014-12-28.informant-report.html


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Is anyone still using JS strict warnings?

2014-12-29 Thread Paolo Amadini
On 12/26/2014 5:59 PM, Jeff Walden wrote:
> On 12/22/2014 08:08 AM, Paolo Amadini wrote:
>> Maybe we could make available
>> an opt-in code linting solution - and these typos would become errors,
>> not warnings,
> 
> Introducing our own proprietary version of JS with these as errors

To clarify, these would be linting errors, just like it would be an
error to inconsistently indent a line by one space instead of two. An
automated tool in Continuous Integration could then tell you in advance
that your patch will be rejected if this is not fixed (so the reviewer
doesn't have to do the check or detect typos manually).

> creates a purely self-inflicted language

But I agree we may not want to enforce this particular check during code
linting, and allow a more liberal style, even for chrome code (that by
our choice has higher requirements than web page code).

If you're thinking about the usefulness of these warnings for web page
authors, my guess is that it would be quite limited, for the reasons
you mentioned.

Paolo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: XULRunner 10.0.6.esr cause CPU spike to 100%+ and network completely hangs while the UI still responsive.

2014-12-29 Thread xingzhou322
On Wednesday, November 19, 2014 10:29:35 PM UTC+8, Josh Matthews wrote:
> On 2014-11-19 3:38 AM, xingzhou...@gmail.com wrote:
> > ===
> > The problem we have:
> > ===
> > Our product leverage XULRunner 10.0.6.esr Version as embedded browser core, 
> > currently, it seems that we are encountering the problem highlighted in bug 
> > "Bug 710176 - Socket transport service thread pegs the CPU spinning to send 
> > data on a SSL socket that is blocking waiting for certificate validation to 
> > finish" within our product. This is causing our users on Mac to have a poor 
> > user experience since when the CPU Spikes to 100%+, the CPU keeps spinning 
> > while Embedded Browser couldn't open any web pages any more(no content will 
> > rendering anymore), seems like the network completely hangs while the UI 
> > still responsive.
> >
> > We have got the Sample file of our product while the CPU spikes, and in the 
> > process sample file, we found a lot of XULRunner threads(such as 
> > nsSocketTransportService, nsSSLThread, nsSSLIOLayerPoll...) are working..
> >
> > We have also using XCode's Instruments tool to look at which thread is 
> > spinning the CPU, and the results as showed below, XULRunner's 
> > nsSSLThread::requestPoll() -> nsSocketTransportService::Poll() takes much 
> > of the CPU time.. the symptom is that if XULRunner enter a potential loop 
> > between nsSSLIOLayerPoll() and nsSSLThread::requestPoll() which spinning on 
> > the CPU and starving everything else, this might leads to a complete hang 
> > of any networking, but the UI is responsive, which means that when the CPU 
> > spikes, you can still open another browser tab, but you can not loading any 
> > pages from then unless you restart the client..
> >
> > ===
> > The help that we need:
> > ===
> > We have done a great deal of research on this problem, but have not found a 
> > solidly reproducible case which also seems to be the case with Bug 71076. 
> > We are leveraging 10.0.6esr version of XULrunner and determined that the 
> > problem was addressed in version 12. However in this version a lot of 
> > changes to the network service related code were made, it is not easy for 
> > us to backport the Bug710176 patch to XULRunner10.0.6.esr since we are not 
> > the XULRunner experts.
> >
> > Specifically we are looking for the following help:
> > (1)Identification of the specific changes made to address bug 71076, plus 
> > guidance on how to backport that to 10.06esr.
> > (2)Is there a test case specifically identified which we could use to 
> > confirm the backport was successful.
> > (3)Any suggestions on further regression testing that should be done to 
> > ensure there are no unexpected side effects applying a patch to the earlier 
> > build.
> >
> >
> > Great thanks for your kindly help in advance.
> >
> 
> Maybe you can try the versions which landed on mozilla-beta (which was 
> version 11 at the time); they might be closer to the ESR code you're 
> using: https://bugzilla.mozilla.org/show_bug.cgi?id=710176#c73

Hi Josh,

Thanks for your reply.. I noticed that Mozilla Version 11 had already remove 
nsSSLThread(https://bugzilla.mozilla.org/show_bug.cgi?id=674147), and the 
710176's given patch is based on new infrastructure without nsSSLThread.. 

However XULRunner 10.0.6.esr also have the CPU spike issue, so I am wondering 
is there any fix for XULRunner 10.0.6.esr which is based on the old nsSSLThread 
implementation.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform