Re: JS-Ctype IRC Room
Is there a maillist for jsctypes? Wouldn't that be better than an irc channel? On Tue, Jan 20, 2015 at 5:39 AM, Philip Chee philip.c...@gmail.com wrote: 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JavaScript code coverage
On 01/19/2015 09:36 PM, Joshua Cranmer wrote: 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. The problem was not the solution, but the lack of motivated reply to use such API. If we had more people motivated to make use of such API to implement a code-coverage, a taint-analysis, or whatever is useful for the mission then we would probably have scheduled some time to implement such API. Indeed, everybody did their +1 would be great, but only one person mentioned that he would take action if we did so. Having an API with no users is worse than not having any API (e4x?). Some of this may due to be trying to create an overly-general design that solves all the problems™. This general design is a pragmatic approach to help people implement different variant of taint-analysis without having to implement taint analysis in SpiderMonkey. Identically for code-coverage, how much time do you want to spend at doing code-coverage vs. running code? This is part of the implementation design of the analysis. The choice of analysis is unlikely to ever become a primary focus for the JS Team, so the only way to raise its importance is to increase the user base by making an Analysis API which targets a wider audience. Is there any prospect for this sort of stuff getting done this year? AFAIK, no. Maybe some potential users will show up and mention that they are willing to get their hand dirty if we were to implement an Analysis API as discussed back in June. In which case we might be able to raise again the question about scheduling this work. -- Nicolas B. Pierron ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Extracting session cookies from Firefox
I would like to extract session cookies from a running Firefox instance. Is there are a supported mechanism to do this? Somewhat surprisingly (to users, I mean—but obviously, something like this is required if you want to do crash restarts without a supervisor process), the session cookies are written to disk, but not the SQLite cookie store. I found a way to extract them from the crash recovery files, but this feels rather dirty and brittle, so I'm looking for better options. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Extracting session cookies from Firefox
On Tue, Jan 20, 2015, at 07:22 AM, Florian Weimer wrote: I would like to extract session cookies from a running Firefox instance. Is there are a supported mechanism to do this? I don't know the definitive answer, but I strongly suspect the answer is no. We don't really have any supported APIs for communicating with a running Firefox by default. If you have control over the client configuration you may be able to use marionette-client[1], which is a Python library for communicating with Firefox using our implementation of the WebDriver protocol. This would let you execute arbitrary JavaScript in the browser context. However, Marionette is not enabled by default so you'd have to configure Firefox to enable it first. -Ted 1. http://marionette-client.readthedocs.org/en/latest/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JavaScript code coverage
On 1/20/2015 4:37 AM, Nicolas B. Pierron wrote: This general design is a pragmatic approach to help people implement different variant of taint-analysis without having to implement taint analysis in SpiderMonkey. Identically for code-coverage, how much time do you want to spend at doing code-coverage vs. running code? This is part of the implementation design of the analysis. Seeing that the code coverage runs on try already risk timing out (in --coverage -g -Owhateverweuse builds), the instrumentation costs need to be pretty low. Post-processing is already necessary to capture scripts never run, so as long as stuff is output in a recoverable manner, that's sufficient. Is there any prospect for this sort of stuff getting done this year? AFAIK, no. Maybe some potential users will show up and mention that they are willing to get their hand dirty if we were to implement an Analysis API as discussed back in June. In which case we might be able to raise again the question about scheduling this work. That's a real shame. I've been without JS code coverage since 2012 or 2013 when the PC counts was removed, and it's disappointing that Mozilla is encouraging browser development in JS but failing to provide effective tooling to support that development. -- 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
Re: Does anybody know how to modify the source code in order to log the executions of the JavaScript functions?
You can do something similar to the beginning of
mozilla::dom::CheckPermissions to get an nsPIDOMWindow*, and then call
GetDocumentURI() on it.
Thank you Ehsan. I tried to do that, but I did not afford to make that working.
Probably, because I have totally no experience with Firefox code (actually, it
is the first time I am looking at it) and I have no idea how the things are
implemented there...
So, in mozilla-central/dom/bindings/BindingUtils.cpp, there is a function:
---
bool CheckPermissions(JSContext* aCx, JSObject* aObj, const char* const
aPermissions[])
{
JS::RootedJSObject* rootedObj(aCx, aObj);
nsPIDOMWindow* window = xpc::WindowGlobalOrNull(rootedObj);
---
In every file generated by the Python script
mozilla-central/dom/bindings/Codegen.py, the function headers are a little bit
different, for example:
---
set_border_spacing(JSContext* cx, JS::HandleJSObject* obj,
nsDOMCSSDeclaration* self, JSJitSetterCallArgs args)
---
It means that the second argument is JS::HandleJSObject* instead of JSObject*
as in the previous case. I found that JS::Handle is just a const reference to
JS::Rooted, so, if I understand correctly, I should just add the following line
to mozilla-central/dom/bindings/Codegen.py:
---
cgThings.append(CGGeneric('nsPIDOMWindow* cwindow =
xpc::WindowGlobalOrNull(obj);\n'))
---
However, when I do that, an error appears:
---
error: cannot convert 'nsGlobalWindow*' to 'nsPIDOMWindow*' in initialization
---
So, I tried to use nsGlobalWindow* instead of nsPIDOMWindow*:
---
cgThings.append(CGGeneric('nsGlobalWindow* cwindow =
xpc::WindowGlobalOrNull(obj);\n'))
---
and I obtained no errors from the compiler (only warnings about the unused
variable, which is normal). However, I am not able to do anything with this
variable. If I try any of the following lines:
---
cgThings.append(CGGeneric('nsIURI* oURI = cwindow-GetDocumentURI();\n'))
cgThings.append(CGGeneric('nsPIDOMWindow* qwerty =
cwindow-GetPrivateParent();\n'))
---
I am obtaining 2 different errors:
---
error: invalid use of incomplete type 'class nsGlobalWindow' nsIURI* oURI =
cwindow-GetDocumentURI();
../../dist/include/mozilla/dom/ScriptSettings.h:21:7: error: forward
declaration of 'class nsGlobalWindow'
class nsGlobalWindow
---
Any idea what is the problem here?
Best regards,
Tomasz
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: [blink-dev] Fwd: [Bug 441414] Treerows need a way to hold richer content
2015-01-17 21:55 GMT+08:00 Philipp Kewisch mozi...@kewis.ch: On 1/16/15 7:09 PM, 罗勇刚(Yonggang Luo) wrote: Is that really the case? The current XUL tree may have some graphics optimizations, but as long as DOM nodes are re-used in lazy loading, I don't see why it couldn't be done in a library. After the fiasco with your patch I wouldn't want to burden you with this, but maybe someone should try to write a html equivalent by either re-using an existing library and adapting it for nsITreeView or writing a simple one from scratch. I'm not sure about if that's possible to do it in pure javascript without any underlying modification to the library. If that's possible, that's would be great. (Was it on purpose you replied to me personally instead of the list? Just FYI) See this for example, it kind of does what we want, but with jQuery and ajax requests to a server: http://datatables.net/release-datatables/extensions/Scroller/examples/server-side_processing.html Imagine something like that, but not using jQuery and loading from nsITreeView instead of an ajax source. It should be fairly simple to use DataTables with nsITreeView, I'm trying it right now for proof of concept. Philipp That's great, except the boring loading when scrolling. I hope it's will not show the loading when the data is in the locale computer or computed in locale computer. -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo ___ 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-20 11:42 AM, Tomasz wrote:
You can do something similar to the beginning of
mozilla::dom::CheckPermissions to get an nsPIDOMWindow*, and then call
GetDocumentURI() on it.
Thank you Ehsan. I tried to do that, but I did not afford to make that working.
Probably, because I have totally no experience with Firefox code (actually, it
is the first time I am looking at it) and I have no idea how the things are
implemented there...
So, in mozilla-central/dom/bindings/BindingUtils.cpp, there is a function:
---
bool CheckPermissions(JSContext* aCx, JSObject* aObj, const char* const
aPermissions[])
{
JS::RootedJSObject* rootedObj(aCx, aObj);
nsPIDOMWindow* window = xpc::WindowGlobalOrNull(rootedObj);
---
In every file generated by the Python script
mozilla-central/dom/bindings/Codegen.py, the function headers are a little bit
different, for example:
---
set_border_spacing(JSContext* cx, JS::HandleJSObject* obj,
nsDOMCSSDeclaration* self, JSJitSetterCallArgs args)
---
It means that the second argument is JS::HandleJSObject* instead of JSObject*
as in the previous case. I found that JS::Handle is just a const reference to
JS::Rooted, so, if I understand correctly, I should just add the following line to
mozilla-central/dom/bindings/Codegen.py:
---
cgThings.append(CGGeneric('nsPIDOMWindow* cwindow =
xpc::WindowGlobalOrNull(obj);\n'))
---
However, when I do that, an error appears:
---
error: cannot convert 'nsGlobalWindow*' to 'nsPIDOMWindow*' in initialization
---
So, I tried to use nsGlobalWindow* instead of nsPIDOMWindow*:
---
cgThings.append(CGGeneric('nsGlobalWindow* cwindow =
xpc::WindowGlobalOrNull(obj);\n'))
---
and I obtained no errors from the compiler (only warnings about the unused
variable, which is normal). However, I am not able to do anything with this
variable. If I try any of the following lines:
---
cgThings.append(CGGeneric('nsIURI* oURI = cwindow-GetDocumentURI();\n'))
cgThings.append(CGGeneric('nsPIDOMWindow* qwerty =
cwindow-GetPrivateParent();\n'))
---
I am obtaining 2 different errors:
---
error: invalid use of incomplete type 'class nsGlobalWindow' nsIURI* oURI =
cwindow-GetDocumentURI();
../../dist/include/mozilla/dom/ScriptSettings.h:21:7: error: forward
declaration of 'class nsGlobalWindow'
class nsGlobalWindow
---
Any idea what is the problem here?
You need to #include nsGlobalWindow.h in order to be able to use the
type. Look for occurrences of CGHeaders in Codegen.py to see how to add
a header #include statement to a generated bindings file.
___
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 1/20/15 11:42 AM, Tomasz wrote:
cgThings.append(CGGeneric('nsPIDOMWindow* cwindow =
xpc::WindowGlobalOrNull(obj);\n'))
Yep, that looks good.
error: cannot convert 'nsGlobalWindow*' to 'nsPIDOMWindow*' in initialization
Right, because WindowGlobalOrNull returns nsGlobalWindow*, but the
header it's declared in only forward-declares the nsGlobalWindow class,
so the fact that it inherits from nsPIDOMWindow* is not known in
translation units that don't also include nsGlobalWindow.h.
error: invalid use of incomplete type 'class nsGlobalWindow' nsIURI* oURI =
cwindow-GetDocumentURI();
Yes, this is the same issue.
What you need to do is to make sure that nsGlobalWindow.h is included in
each generated binding file. The simplest way to do that is to add the line
bindingHeaders[nsGlobalWindow.h] = True
where all the other such lines are (e.g. right after the line that sets
bindingHeaders[xpcpublic.h]).
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: JavaScript code coverage
On 1/20/15 5:34 PM, Joshua Cranmer wrote: On 1/20/2015 4:37 AM, Nicolas B. Pierron wrote: Maybe some potential users will show up and mention that they are willing to get their hand dirty if we were to implement an Analysis API as discussed back in June. In which case we might be able to raise again the question about scheduling this work. That's a real shame. I've been without JS code coverage since 2012 or 2013 when the PC counts was removed, and it's disappointing that Mozilla is encouraging browser development in JS but failing to provide effective tooling to support that development. It really sounds like the chicken-egg problem here. Wouldn't the devtools folks be interested in writing a panel that uses the API to show code coverage? Maybe this is just a matter of the respective managers getting together and committing to it? Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JavaScript code coverage
I recommend reading https://developer.mozilla.org/en-US/docs/Tools/Debugger-API or js/src/doc/Debugger/ for more information. On Tue, Jan 20, 2015 at 1:29 PM, Nick Fitzgerald nfitzger...@mozilla.com wrote: On Mon, Jan 19, 2015 at 12:36 PM, Joshua Cranmer [image: ] pidgeo...@gmail.com wrote: Getting good code coverage (line and branch coverage) ultimately requires fine-grained instrumentation (ideally bytecode-level) not presented by the current Debugger. I think you can get fine-grained enough data with the existing Debugger API by doing the following: * Adding all existing globals as debuggees: `Debugger.prototype. addAllGlobalsAsDebuggees` * Adding new globals as debuggees: have your Debugger's onNewGlobal hook to always add the new global as a debuggee. * For each `Debugger.Script` (on initialization via `Debugger.prototype.findScripts` and on new scripts in the future via the `onNewScript` hook): *** Use `Debugger.Script.prototype.getAllOffsets` to get all byte code offsets which are entry points to each line in the script *** Set a breakpoint on each of those offsets which, when hit, records that the offset's line was executed ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Migrating defaults from other browsers
On 1/19/15 4:58 AM, 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? My assumption was that we're only migrating customized prefs, since otherwise we can't tell the difference between something a user made an explicit choice about vs didn't care. But more broadly, I think we should be pretty conservative with what's migrated. A quick skim shows that we're migrating lots of stuff that seems low-value (eg browser.underline_anchors), or things that could be outright broken (eg permissions.default.image, the UI for which was removed!). So I think it's worth revisiting what prefs we migrate. Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JavaScript code coverage
On Mon, Jan 19, 2015 at 12:36 PM, Joshua Cranmer pidgeo...@gmail.com wrote: Getting good code coverage (line and branch coverage) ultimately requires fine-grained instrumentation (ideally bytecode-level) not presented by the current Debugger. I think you can get fine-grained enough data with the existing Debugger API by doing the following: * Adding all existing globals as debuggees: `Debugger.prototype. addAllGlobalsAsDebuggees` * Adding new globals as debuggees: have your Debugger's onNewGlobal hook to always add the new global as a debuggee. * For each `Debugger.Script` (on initialization via `Debugger.prototype.findScripts` and on new scripts in the future via the `onNewScript` hook): *** Use `Debugger.Script.prototype.getAllOffsets` to get all byte code offsets which are entry points to each line in the script *** Set a breakpoint on each of those offsets which, when hit, records that the offset's line was executed ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Migrating defaults from other browsers
+firefox-dev (more relevant to that list than dev-platform, IMO) I would certainly support an audit of what we're migrating, I bet a lot could be cleaned up. Gavin On Tue, Jan 20, 2015 at 2:40 PM, Justin Dolske dol...@mozilla.com wrote: On 1/19/15 4:58 AM, 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? My assumption was that we're only migrating customized prefs, since otherwise we can't tell the difference between something a user made an explicit choice about vs didn't care. But more broadly, I think we should be pretty conservative with what's migrated. A quick skim shows that we're migrating lots of stuff that seems low-value (eg browser.underline_anchors), or things that could be outright broken (eg permissions.default.image, the UI for which was removed!). So I think it's worth revisiting what prefs we migrate. Justin ___ 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
Nested scrolling behavior
Is it possible to make a container scroll before its child? Example: 2 nested divs. #out and #in. #in is inside #out. Both overflow. When scrolling (mouse wheel), #in scrolls first. Once #in reached its max scroll, #out starts scrolling. See it in action here: http://jsbin.com/puxenibotu Is there a way to make #out scroll first, then #in? Not sure how relevant this is but: - APZC is enabled - #in is actually an iframe remote='true' -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Nested scrolling behavior
On Wed, Jan 21, 2015 at 1:37 AM, Paul Rouget p...@mozilla.com wrote: Is it possible to make a container scroll before its child? Example: 2 nested divs. #out and #in. #in is inside #out. Both overflow. [...] Is there a way to make #out scroll first, then #in? Not sure how relevant this is but: - APZC is enabled - #in is actually an iframe remote='true' Yes! The addressbar in the B2G browser makes use of exactly this (with #in being the iframe of the page you're looking at, and #out being a div grouping the address bar and the iframe). It's done by setting the DOM property 'scrollgrab' [1] on #out. Note that 'scrollgrab' is implemented in APZ, and it's only enabled in chrome code and certified apps [2]. Hope that helps! Cheers, Botond [1] http://mxr.mozilla.org/mozilla-central/source/dom/webidl/HTMLElement.webidl?rev=68ec1899bb63#98 [2] http://mxr.mozilla.org/mozilla-central/source/dom/html/nsGenericHTMLElement.cpp?rev=e8981c280f7b#1713 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MemShrink Meeting - Today, 20 Jan 2015 at 2:00pm PST
The next Memshrink meeting is is brought to you by proper shutdown when IPC messages are dropped: https://bugzilla.mozilla.org/show_bug.cgi?id=1091766 The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * Prioritize unprioritized MemShrink bugs. * Discuss how we measure progress. * Discuss approaches to getting more data. Meeting details: * Tue, 20 Jan 2015, 2:00 PM PST * http://arewemeetingyet.com/Los%20Angeles/2015-01-20/14:00/MemShrink%20Meeting * Vidyo: Memshrink * Dial-in Info: - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference num 98802 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
