Re: Session Restore (sessionstore)
Am Samstag, 28. Juni 2014 18:39:12 UTC+2 schrieb David Rajchenbach-Teller: > I don't follow what you have in mind. Assuming that you suggest we move > to sqlite, you seem to be suggesting that we should considerably > increase the amount of I/O. Or do I misunderstand what you say? At first it was just a comment to the bug you mentioned ... about "Journaled Storage" ... and the example there with bookmarks backup ... and that I don't think that this is necessary for this ... So if we have to first to talk about a other storage solution ... about a "Journaled Storage" ... we have to talk maybe first for what it is needed ... if really for a backup of the bookmarks/places ... ??? Other topic for that ??? And if the SQLite writes just the changing tab(s), it should be less I/O then writing all the time the complete JSON, or ??? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Are you interested in doing dynamic analysis of JS code?
> We're considering building a JavaScript API for dynamic analysis of JS code. I'd love to add dynamic JS analysis to DXR's quiver. Static JS analysis is coming in early fall, and my intern Marcell is hard at work wringing what he can out of pointer analysis. Of course, that sort of thing is necessarily fuzzy in such a dynamic language, so we'd welcome the information a dynamic pass would add. Being able to, say, record the property sets of objects thrown around during automated tests would boost our confidence about the type signatures of functions (such as they are) and make our query results more useful. Being able to find where undefineds or NaNs pop out of running code would make it easier to spotlight ones which are spurious. We'd love to have the hooks! -- Erik Rose DXR Lead ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Are you interested in doing dynamic analysis of JS code?
On 6/25/14, 8:15 AM, Jason Orendorff wrote: We're considering building a JavaScript API for dynamic analysis of JS code. Here's the sort of thing you could do with it: - Gather code coverage information (useful for testing/release mgmt?) - Trace all object mutation and method calls (useful for devtools?) - Record/replay of JS execution (useful for devtools?) - Implement taint analysis (useful for the security team or devtools?) - Detect when a mathematical operation returns NaN (useful for game developers?) Note that the API would not directly offer all these features. Instead, it would offer some powerful but mind-boggling way of instrumenting all JS code. It would be up to you, the user, to configure the instrumentation, get useful data out of it, and display or analyze it. There would be some overhead when you turn this on; we don't know how much yet. We would present a detailed example of how to use the proposed API, but we are so early in the process that we're not even sure what it would look like. There are several possibilities. We need to know how to prioritize this work. We need to know what kind of API we should build. So we're looking for early adopters. If that's you, please speak up and tell us how you'd like to instrument JS code. FWIW, I just remembered that Honza and the Firebug folks have been asking for something like this for a while, and they can't completely remove dependency on the old debugger API until there is a replacement. https://bugzilla.mozilla.org/show_bug.cgi?id=797876 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rendering meeting, June 30th, 2:30pm PDT
No agenda items at this point. No rendering meeting today. -- - Milan On Jun 24, 2014, at 10:49 , Milan Sreckovic wrote: > The Rendering meeting is about all things Gfx, Image, Layout, and Media. > It takes place every second Monday, at 2:30pm PDT - if we have an agenda. > > The next meeting is scheduled for Monday, June 30th at 2:30 PM US/Pacific. > > Please send me any agenda items you may have. If we have none by the end of > the week, we will cancel the meeting. > -- > - Milan > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Guidelines for naming preferences?
On Mon, Jun 30, 2014 at 12:24 AM, Masayuki Nakano wrote: > One is not in UI but shown in the list of about:config. The other is not in > both UI and about:config. I.g., there is a checking the pref value code but > not included in all.js and other similar files. > > I think that the former is important for some minority users. Yes, they must > be minority but their reason to use Firefox must be the customizability by > this kind of hidden prefs. And such minority users who can customize > about:config may help their friends and family to use our product. > Therefore, I believe this is important for keeping market share. I disagree pretty strongly. There's always a judgement call involved, and it's possible for some cases to be exceptional, but as a general guideline we shouldn't be adding prefs to about:config "for power users", because the long-term costs to adding them has shown to be quite significant even in seemingly trivial cases. As Benjamin notes, an add-on is a much better way to suggest people customize these things, and writing an add-on that sets a pref is trivial. Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Guidelines for naming preferences?
On 2014/06/30 22:51, Masayuki Nakano wrote: Hi, I wrote a draft of the guideline in MDN roughly. I hope a lot of developers discuss the rules and improve this draft! Oops, the draft is here. Sorry for the spam. https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Preferences Thanks in advance. On 2014/06/30 16:24, Masayuki Nakano wrote: Thank you for the reply, but sorry for the delay. On 2014/06/20 23:25, Benjamin Smedberg wrote: On 6/19/2014 10:00 PM, Masayuki Nakano wrote: When I work on some bugs, I need to add a new option for a pref switchable behavior, e.g., if we need to add a new option to a feature and the new one isn't enabled in default settings, it's better to add new pref for the additional option in some cases. Here are the reasons we should be adding prefs: A. We actually want to expose the option in the preference UI (needs UX review) B. To enable release drivers to turn it off easily if there is a problem found C. a feature is experimental and we want to limit it to certain channels while it is stabilized D. To enable other internal usage: e.g. A/B testing via telemetry experiments I believe that we should not be adding hidden prefs just because a small minority of people might want a feature, but we've decided not to expose it in the browser preferences. Those kinds of choices should be made by installing Firefox extensions. In particular, using an extension instead of a hidden pref setting means that we will see the non-default choice in various metrics like about:support, telemetry/FHR, and that Firefox safe mode reverts the setting in case of problems. In any case, this probably doesn't have much to do with naming ;-) There are two hidden prefs. One is not in UI but shown in the list of about:config. The other is not in both UI and about:config. I.g., there is a checking the pref value code but not included in all.js and other similar files. I think that the former is important for some minority users. Yes, they must be minority but their reason to use Firefox must be the customizability by this kind of hidden prefs. And such minority users who can customize about:config may help their friends and family to use our product. Therefore, I believe this is important for keeping market share. The latter should be used for developing or automated tests. And also, should be used as far as possible. Why? Flat names seem quite reasonable. The reason is for the runtime cost of observing brunches as I mentioned below. nsXPLookAndFeel observes every pref. For doing that, it observes *all* prefs under |ui.|. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#430 And the observer uses 3 loops for retrieving the pref cache from the arrays. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#388 If somebody changes a pref under |ui.| at runtime, every change causes running this expensive method. How expensive? Pref changes at runtime are in quite unusual after startup, and I don't think we should necessarily optimize for this case. Although, I don't measure it actually. But if somebody adds a pref under |ui.| and it may be updated from UI, it may cause short hangup at changing it. This is really bad UX and automated tests must not be able to detect this problem. For example, some metrics/colors which can be retrieved with LookAndFeel class can be override by hidden prefs. The most hidden prefs are named as |ui.| or |ui.|. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#26 # Anyway, if it's allowed, we should rename the pref names referred from nxXPLookAndFeel even though customized users will need to set them again. Do we need this code at all? This sounds like the kind of code that would be better to remove entirely. At least I really need this because these prefs can emulate other environments on each environment. E.g., on Windows, we can test Mac OS X style scrollbar. This is very important to work on around XUL. # FYI: These prefs are not listed in about:config. -- Masayuki Nakano Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Guidelines for naming preferences?
Hi, I wrote a draft of the guideline in MDN roughly. I hope a lot of developers discuss the rules and improve this draft! Thanks in advance. On 2014/06/30 16:24, Masayuki Nakano wrote: Thank you for the reply, but sorry for the delay. On 2014/06/20 23:25, Benjamin Smedberg wrote: On 6/19/2014 10:00 PM, Masayuki Nakano wrote: When I work on some bugs, I need to add a new option for a pref switchable behavior, e.g., if we need to add a new option to a feature and the new one isn't enabled in default settings, it's better to add new pref for the additional option in some cases. Here are the reasons we should be adding prefs: A. We actually want to expose the option in the preference UI (needs UX review) B. To enable release drivers to turn it off easily if there is a problem found C. a feature is experimental and we want to limit it to certain channels while it is stabilized D. To enable other internal usage: e.g. A/B testing via telemetry experiments I believe that we should not be adding hidden prefs just because a small minority of people might want a feature, but we've decided not to expose it in the browser preferences. Those kinds of choices should be made by installing Firefox extensions. In particular, using an extension instead of a hidden pref setting means that we will see the non-default choice in various metrics like about:support, telemetry/FHR, and that Firefox safe mode reverts the setting in case of problems. In any case, this probably doesn't have much to do with naming ;-) There are two hidden prefs. One is not in UI but shown in the list of about:config. The other is not in both UI and about:config. I.g., there is a checking the pref value code but not included in all.js and other similar files. I think that the former is important for some minority users. Yes, they must be minority but their reason to use Firefox must be the customizability by this kind of hidden prefs. And such minority users who can customize about:config may help their friends and family to use our product. Therefore, I believe this is important for keeping market share. The latter should be used for developing or automated tests. And also, should be used as far as possible. Why? Flat names seem quite reasonable. The reason is for the runtime cost of observing brunches as I mentioned below. nsXPLookAndFeel observes every pref. For doing that, it observes *all* prefs under |ui.|. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#430 And the observer uses 3 loops for retrieving the pref cache from the arrays. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#388 If somebody changes a pref under |ui.| at runtime, every change causes running this expensive method. How expensive? Pref changes at runtime are in quite unusual after startup, and I don't think we should necessarily optimize for this case. Although, I don't measure it actually. But if somebody adds a pref under |ui.| and it may be updated from UI, it may cause short hangup at changing it. This is really bad UX and automated tests must not be able to detect this problem. For example, some metrics/colors which can be retrieved with LookAndFeel class can be override by hidden prefs. The most hidden prefs are named as |ui.| or |ui.|. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#26 # Anyway, if it's allowed, we should rename the pref names referred from nxXPLookAndFeel even though customized users will need to set them again. Do we need this code at all? This sounds like the kind of code that would be better to remove entirely. At least I really need this because these prefs can emulate other environments on each environment. E.g., on Windows, we can test Mac OS X style scrollbar. This is very important to work on around XUL. # FYI: These prefs are not listed in about:config. -- Masayuki Nakano Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
Suppressing the contextmenu is extremely user-hostile (for some users). There is a reason I always run with dom.event.contextmenu.enabled set to false. If anything alters the existing context menu, make sure there is a pref to disable it. Even the disclosure chevron would be annoying to me. On 2014-06-29 00:30, Ian Hickson wrote: > On Sat, 28 Jun 2014, Dale Harvey wrote: >> >> Application developers have the ability to specify additional menuitems for >> contextmenus via >> http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus >> however they are currently shown in addition to the default items, we are >> looking to implement an optional attribute that allows authors to disable >> the default context menu items so only the applications items are shown. >> This is primarily targeted for Firefox OS, I believe Jonas will be looking >> to add it to the official spec. >> >> The name / value of the attribute is under discussion >> >> >> >> >> >> looks like the most likely candidate. > > This has been suggested many times, but the reason it's not part of the > standard is that it's user-hostile. > > I would recommend that instead of letting the author prevent the user from > getting to the user's browser's commands, the browser instead simply hide > the browser commands behind a disclosure chevron, as in this example: > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#dom-contextmenu > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Guidelines for naming preferences?
Thank you for the reply, but sorry for the delay. On 2014/06/20 23:25, Benjamin Smedberg wrote: On 6/19/2014 10:00 PM, Masayuki Nakano wrote: When I work on some bugs, I need to add a new option for a pref switchable behavior, e.g., if we need to add a new option to a feature and the new one isn't enabled in default settings, it's better to add new pref for the additional option in some cases. Here are the reasons we should be adding prefs: A. We actually want to expose the option in the preference UI (needs UX review) B. To enable release drivers to turn it off easily if there is a problem found C. a feature is experimental and we want to limit it to certain channels while it is stabilized D. To enable other internal usage: e.g. A/B testing via telemetry experiments I believe that we should not be adding hidden prefs just because a small minority of people might want a feature, but we've decided not to expose it in the browser preferences. Those kinds of choices should be made by installing Firefox extensions. In particular, using an extension instead of a hidden pref setting means that we will see the non-default choice in various metrics like about:support, telemetry/FHR, and that Firefox safe mode reverts the setting in case of problems. In any case, this probably doesn't have much to do with naming ;-) There are two hidden prefs. One is not in UI but shown in the list of about:config. The other is not in both UI and about:config. I.g., there is a checking the pref value code but not included in all.js and other similar files. I think that the former is important for some minority users. Yes, they must be minority but their reason to use Firefox must be the customizability by this kind of hidden prefs. And such minority users who can customize about:config may help their friends and family to use our product. Therefore, I believe this is important for keeping market share. The latter should be used for developing or automated tests. And also, should be used as far as possible. Why? Flat names seem quite reasonable. The reason is for the runtime cost of observing brunches as I mentioned below. nsXPLookAndFeel observes every pref. For doing that, it observes *all* prefs under |ui.|. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#430 And the observer uses 3 loops for retrieving the pref cache from the arrays. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#388 If somebody changes a pref under |ui.| at runtime, every change causes running this expensive method. How expensive? Pref changes at runtime are in quite unusual after startup, and I don't think we should necessarily optimize for this case. Although, I don't measure it actually. But if somebody adds a pref under |ui.| and it may be updated from UI, it may cause short hangup at changing it. This is really bad UX and automated tests must not be able to detect this problem. For example, some metrics/colors which can be retrieved with LookAndFeel class can be override by hidden prefs. The most hidden prefs are named as |ui.| or |ui.|. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#26 # Anyway, if it's allowed, we should rename the pref names referred from nxXPLookAndFeel even though customized users will need to set them again. Do we need this code at all? This sounds like the kind of code that would be better to remove entirely. At least I really need this because these prefs can emulate other environments on each environment. E.g., on Windows, we can test Mac OS X style scrollbar. This is very important to work on around XUL. # FYI: These prefs are not listed in about:config. -- Masayuki Nakano Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
