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 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 , > 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: [blink-dev] Fwd: [Bug 441414] Treerows need a way to hold richer content
2015-01-17 21:55 GMT+08:00 Philipp Kewisch : > 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: 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::Rooted 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::Handle obj, nsDOMCSSDeclaration* self, JSJitSetterCallArgs args) --- It means that the second argument is JS::Handle 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: 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::Rooted 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::Handle obj, nsDOMCSSDeclaration* self, JSJitSetterCallArgs args) --- It means that the second argument is JS::Handle 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
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
Re: JavaScript code coverage
On Mon, Jan 19, 2015 at 12:36 PM, Joshua Cranmer 🐧 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: 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 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: 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 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 -- 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 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 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