Re: Network Predictive Actions re-enabled on Nightly
On Fri, Jan 16, 2015 at 12:41 AM, Jonas Sicking jo...@sicking.cc wrote: FWIW, a difference in load time of 100ms is quite big. Websites like Amazon has measured significant changes in clickthrough rates when they have experimentally increased loadtime by 100ms. I believe that significant resources have been dedicated to the general problem, and for far less than that. I once had access to some numbers on this, and improvements in the small 10s of ms would easily justify the cost of a data center. I don't have specific numbers, but I believe that 3ms was considered enough cause to spend a fairly shocking amount money for a large company. 100ms is an absurdly large improvement. That said, privacy is definitely very important. But given that this has gone through privacy review by the mozilla privacy team I'll trust that this feature has been implemented with privacy in mind. The extent to which browsing history can be recovered by a passive network observer based on this feature alone is hard to say. The fact that we spray DNS requests for every a href= on a page is probably a worse leak...or, if you think about it a little more, providing of excellent k-anonymity. Good luck recovering any signal when there is that much noise. Critically, one-off or infrequent navigation events won't trigger the heuristic. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JS-Ctype IRC Room
On 20/01/2015 07:21, noitid...@gmail.com wrote: New irc room we're trying to establish. #jsctypes https://client00.chat.mibbit.com/?url=irc%3A%2F%2Firc.mozilla.org%2F%23jsctypes That's wrong. The correct link is irc://moznet/jsctypes Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Network Predictive Actions re-enabled on Nightly
On Fri, Jan 16, 2015 at 8:45 AM, Nicholas Hurley hur...@mozilla.com wrote: On Thu, Jan 15, 2015 at 9:44 PM, Patrick Cloke clo...@gmail.com wrote: I did not think you were randomly guessing, I guess I'm not convinced the browser is able to tell what the user has intentionally done. Given that the browser has access to your browsing history (assuming you aren't running in private browsing mode, in which case this feature is disabled anyway), it shouldn't be surprising that we know what the user has intentionally done. Furthermore, we don't just predict willy-nilly. This is explicitly for the case when you're visiting a site you've visited before. Say you go to load yahoo.com - based on your previous visits to yahoo.com, we will start firing off dns requests and/or tcp/tls connections that you're highly likely to need again on this load of yahoo.com. We won't, however, start firing off those requests just because you happen to have a page open with a link to yahoo.com on it. You have to click on one of those links before any predictions start. My point was that just because it is in my history, does not necessarily mean I intentionally visited it. Maybe I lent my computer to someone else or clicked on a link by mistake. (By the way, I fully understand why the assumption that if it's in the history then it was intentional was made. I'm just undecided on whether I agree with the assumption or not.) I was asking for more information about the algorithm, e.g. is there a frequency/recency component to understand how visiting a link only a few times would impact this. But as you suggested, I can read the code and take a look at it if I'm really interested. I fully understand that you're not arbitrarily opening connections, by the way. My concern is that by going to a site (yahoo.com, in your example), I'm not saying that I currently trust any of the other sites linked off there, even if I've been there before. If I trust them I'll go to them. And of course privacy is important - I wouldn't have wanted to work on this feature if I didn't think it could be done in a privacy-preserving manner, and I (along with a lot of other people) am confident that I've done that. So, here's to faster page loads without sacrificing privacy! Thanks for ensuring that this was considered before this feature was implemented! By the way, please don't try to think I'm knocking this feature at all. I'm sure you've put a lot of good work and thought into it. I'm just trying to adequately understand the privacy ramifications. Thanks (again) for replying! Patrick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
JS-Ctype IRC Room
New irc room we're trying to establish. #jsctypes https://client00.chat.mibbit.com/?url=irc%3A%2F%2Firc.mozilla.org%2F%23jsctypes A bunch of us together here who collaborate/help each other get their code working because we just like to see ctypes working. Join! Mostly cuz we need more people to help each other out :) just a couple of us in there right now ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Test Informant Report - Week ending Jan 18
Test Informant report for 2015-01-18. State of test manifests at revision 6446c26b45f9. Using revision 286e1f883fdb as a baseline for comparisons. Showing tests enabled or disabled between 2015-01-09 and 2015-01-18. 85% of tests across all suites and configurations are enabled. Summary --- marionette- ↑0↓0 - 92% mochitest-a11y- ↑0↓0 - 99% mochitest-browser-chrome - ↑344↓10 - 94% mochitest-browser-chrome-e10s - ↑58↓2 - 58% mochitest-chrome - ↑24↓0 - 96% mochitest-plain - ↑395↓19 - 84% mochitest-plain-e10s - ↑90↓4 - 79% xpcshell - ↑86↓8 - 86% Full Report --- http://brasstacks.mozilla.com/testreports/weekly/2015-01-18.informant-report.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Migrating defaults from other browsers
https://bugzilla.mozilla.org/show_bug.cgi?id=1005863 got stalled for some time, because it wasn't clear if it was OK to stop migrating font settings from Safari. I think this leads to a more general question: Is it really a good idea that our profile migrators migrate settings from other browsers when those settings have been left to the defaults of those browsers? By migrating settings that the user hasn't changed from other browsers basically outsources the decisions on what the defaults should be from us to our competitors. This might mean default fonts, but this most visibly also means Windows users ending up with an MSN home page if they just click through the installation process. (At least last I checked, which was a good while ago.) Do we *really* want to delegate decisions about the defaults to competitors like this? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Does anybody know how to modify the source code in order to log the executions of the JavaScript functions?
Hi all, I would like to modify the Firefox source code in order to log every execution of any JavaScript API function (or object method) invoked by any JavaScript code on any website together with the full URL to the file which contained the JavaScript code. For example, we have the following files, which include (among others) the following statements: * http://www.aaa.com/dir1/file1.htm var x = document.getElementById(demo); * http://www.bbb.com/dirT/file44.htm script var c = document.getElementById(myCanvas); var ctx = c.getContext(2d); ctx.fillStyle = #FF; ctx.fillRect(0,0,150,75); /script I would like to automatically log the execution of these functions as: http://www.aaa.com/dir1/file1.htm | getElementById http://www.bbb.com/dirT/file44.htm | getElementById http://www.bbb.com/dirT/file44.htm | getContext http://www.bbb.com/dirT/file44.htm | fillRect If it is possible, I would also like to separately log all the set / read properties, as: http://www.bbb.com/dirT/file44.htm | fillStyle I know that the JavaScript API functions are implemented in Firefox in 2 ways: as C++ functions or JavaScript functions. However, I do not care how the functions are internally implemented - I just want to log all the executions. Is there any easy way to do that besides adding logging statements to every single JavaScript function we want to log? Thank you for all your suggestions in advance. Best regards, Tomasz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Does anybody know how to modify the source code in order to log the executions of the JavaScript functions?
Half of the battle is modifying CGPerSignatureCall in Codegen.py - that will get you the name of the DOM implementation method being invoked and deals with both DOM methods and DOM getters/setters. Getting the owning document URL is a separate struggle. Cheers, Josh On 2015-01-19 7:57 AM, Tomasz wrote: Hi all, I would like to modify the Firefox source code in order to log every execution of any JavaScript API function (or object method) invoked by any JavaScript code on any website together with the full URL to the file which contained the JavaScript code. For example, we have the following files, which include (among others) the following statements: * http://www.aaa.com/dir1/file1.htm var x = document.getElementById(demo); * http://www.bbb.com/dirT/file44.htm script var c = document.getElementById(myCanvas); var ctx = c.getContext(2d); ctx.fillStyle = #FF; ctx.fillRect(0,0,150,75); /script I would like to automatically log the execution of these functions as: http://www.aaa.com/dir1/file1.htm | getElementById http://www.bbb.com/dirT/file44.htm | getElementById http://www.bbb.com/dirT/file44.htm | getContext http://www.bbb.com/dirT/file44.htm | fillRect If it is possible, I would also like to separately log all the set / read properties, as: http://www.bbb.com/dirT/file44.htm | fillStyle I know that the JavaScript API functions are implemented in Firefox in 2 ways: as C++ functions or JavaScript functions. However, I do not care how the functions are internally implemented - I just want to log all the executions. Is there any easy way to do that besides adding logging statements to every single JavaScript function we want to log? Thank you for all your suggestions in advance. Best regards, Tomasz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Migrating defaults from other browsers
On 19/01/2015 13:58, Henri Sivonen wrote: I think this leads to a more general question: Is it really a good idea that our profile migrators migrate settings from other browsers when those settings have been left to the defaults of those browsers? Note that we don't migrate IE prefs if they have not been changed (when we can detect that), and we don't migrate the homepage if it's the system default one as well (provided the registry information didn't change recently). The only prefs that are migrated regardless (cause there's no way to check if they are at the default value afaik) is Safaris'. I think most of the prefs we are migrating are somehow related to the user browsing habits (load tabs in background, smoothscroll, underline anchors, spell check and so on...). When we converted the migrators from cpp to js, we filterd most of the prefs out, exactly to avoid creating an unacceptable downgrade of the Firefox experience (for example we don't migrate anymore the location bar prefs cause the awesomebar _is_ better!) We could probably do better and remove some more prefs (formfill, block images and cookie behavior for example), but we didn't ignore the problem. Font prefs for example could be important to some users, for locale or visual issues, not migrating them in those cases could create more issues to the user than migrating a system font setting that is optimized to work on that system (so it's unlikely to be problematic). Keeping track of the system defaults could be expensive, someone should periodically check the default values and keep the code up-to-date. Considered I'm not even sure how often we run manual browser migration tests, that doesn't seem like something achievable. -m ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Does anybody know how to modify the source code in order to log the executions of the JavaScript functions?
Thank you very much, it works as expected. The code, which I added to the
function, is:
if setter:
cgThings.append(CGGeneric('printf(setter: ' + nativeMethodName +
'\\n);\n'))
elif getter:
cgThings.append(CGGeneric('printf(getter: ' + nativeMethodName +
'\\n);\n'))
else:
cgThings.append(CGGeneric('printf(method: ' + nativeMethodName +
'\\n);\n'))
What about the document URL? Is it also possible to print it somewhere in the
code in a way that the document URL will appear exactly before all the embedded
methods / setters / getters?
Tomasz
On Monday, January 19, 2015 at 3:29:52 PM UTC+1, Josh Matthews wrote:
Half of the battle is modifying CGPerSignatureCall in Codegen.py - that
will get you the name of the DOM implementation method being invoked and
deals with both DOM methods and DOM getters/setters. Getting the owning
document URL is a separate struggle.
Cheers,
Josh
On 2015-01-19 7:57 AM, Tomasz wrote:
Hi all,
I would like to modify the Firefox source code in order to log every
execution of any JavaScript API function (or object method) invoked by any
JavaScript code on any website together with the full URL to the file which
contained the JavaScript code.
For example, we have the following files, which include (among others) the
following statements:
* http://www.aaa.com/dir1/file1.htm
var x = document.getElementById(demo);
* http://www.bbb.com/dirT/file44.htm
script
var c = document.getElementById(myCanvas);
var ctx = c.getContext(2d);
ctx.fillStyle = #FF;
ctx.fillRect(0,0,150,75);
/script
I would like to automatically log the execution of these functions as:
http://www.aaa.com/dir1/file1.htm | getElementById
http://www.bbb.com/dirT/file44.htm | getElementById
http://www.bbb.com/dirT/file44.htm | getContext
http://www.bbb.com/dirT/file44.htm | fillRect
If it is possible, I would also like to separately log all the set / read
properties, as:
http://www.bbb.com/dirT/file44.htm | fillStyle
I know that the JavaScript API functions are implemented in Firefox in 2
ways: as C++ functions or JavaScript functions. However, I do not care how
the functions are internally implemented - I just want to log all the
executions. Is there any easy way to do that besides adding logging
statements to every single JavaScript function we want to log?
Thank you for all your suggestions in advance.
Best regards,
Tomasz
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Does anybody know how to modify the source code in order to log the executions of the JavaScript functions?
On 2015-01-19 11:33 AM, Tomasz wrote:
Thank you very much, it works as expected. The code, which I added to the
function, is:
if setter:
cgThings.append(CGGeneric('printf(setter: ' + nativeMethodName +
'\\n);\n'))
elif getter:
cgThings.append(CGGeneric('printf(getter: ' + nativeMethodName +
'\\n);\n'))
else:
cgThings.append(CGGeneric('printf(method: ' + nativeMethodName +
'\\n);\n'))
What about the document URL? Is it also possible to print it somewhere in the
code in a way that the document URL will appear exactly before all the embedded
methods / setters / getters?
You can do something similar to the beginning of
mozilla::dom::CheckPermissions to get an nsPIDOMWindow*, and then call
GetDocumentURI() on it.
On Monday, January 19, 2015 at 3:29:52 PM UTC+1, Josh Matthews wrote:
Half of the battle is modifying CGPerSignatureCall in Codegen.py - that
will get you the name of the DOM implementation method being invoked and
deals with both DOM methods and DOM getters/setters. Getting the owning
document URL is a separate struggle.
Cheers,
Josh
On 2015-01-19 7:57 AM, Tomasz wrote:
Hi all,
I would like to modify the Firefox source code in order to log every execution
of any JavaScript API function (or object method) invoked by any JavaScript
code on any website together with the full URL to the file which contained the
JavaScript code.
For example, we have the following files, which include (among others) the
following statements:
* http://www.aaa.com/dir1/file1.htm
var x = document.getElementById(demo);
* http://www.bbb.com/dirT/file44.htm
script
var c = document.getElementById(myCanvas);
var ctx = c.getContext(2d);
ctx.fillStyle = #FF;
ctx.fillRect(0,0,150,75);
/script
I would like to automatically log the execution of these functions as:
http://www.aaa.com/dir1/file1.htm | getElementById
http://www.bbb.com/dirT/file44.htm | getElementById
http://www.bbb.com/dirT/file44.htm | getContext
http://www.bbb.com/dirT/file44.htm | fillRect
If it is possible, I would also like to separately log all the set / read
properties, as:
http://www.bbb.com/dirT/file44.htm | fillStyle
I know that the JavaScript API functions are implemented in Firefox in 2 ways:
as C++ functions or JavaScript functions. However, I do not care how the
functions are internally implemented - I just want to log all the executions.
Is there any easy way to do that besides adding logging statements to every
single JavaScript function we want to log?
Thank you for all your suggestions in advance.
Best regards,
Tomasz
___
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
JavaScript code coverage
Hi, you may know me as the guy who produces the code coverage results occasionally: http://www.tjhsst.edu/~jcranmer/m-ccov/. One persistent failure of producing code coverage is the inability to record code coverage in half of our codebase, the half that is written in JavaScript. There are several existing JS code coverage solutions, but all of them would fail to work for a few broad reasons: 1. Mozilla aggressively uses ES6 (and some non-standard) features in its codebase, and code coverage infrastructure at best lags. Of the half dozen tools I looked at, only 2 mentioned any support for ES6 (and one using an ES6-to-ES5 translator, which is unsettling). 2. Importing the coverage database, updating it, and reporting it is fraught with peril, because we have at least 6 different scopes which require at least 3 different mechanisms: JS modules, chrome windows, content windows, workers, JS shell, xpcshell. Some of our code will be run in multiple scopes (https://dxr.mozilla.org/comm-central/source/mozilla/toolkit/components/osfile/osfile.jsm can run in both JS modules and chrome workers). 3. Getting a static list of all of our JS code is extremely non-trivial, since JS can also crop up in non-JS files like XBL files or HTML files. 4. Our scripts sometimes share the same global, sometimes they don't. In contrast, the target environments of web browsers and node.js always use one or the other. If you can't tell from my list of points, I'm highly skeptical that any instrumentation-based approach will work. However, since we use the same JS engine for all of our code, if code coverage support is added to SpiderMonkey, than it is a relatively easy step to add support for JS code coverage to my periodic code coverage runs. Getting good code coverage (line and branch coverage) ultimately requires fine-grained instrumentation (ideally bytecode-level) not presented by the current Debugger. I've seen people bring up supporting this sort of stuff in the past, which usually tends to generate a flurry of +1 this would be wonderful! but ultimately everything peters out before anything gets done. Some of this may due to be trying to create an overly-general design that solves all the problems™. Is there any prospect for this sort of stuff getting done this year? -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
