Re: The e10s throbber
On 07/04/2015 23:41, Robert O'Callahan wrote: On Wed, Apr 8, 2015 at 6:27 AM, Gavin Sharp ga...@gavinsharp.com wrote: We don't have telemetry yet. I've done some measurements and haven't found any cases where tab switching consistently takes longer in e10s. However, it's certainly possible that it does on average. Either way, it's hard to investigate until we can reproduce the problem. I see the spinner far too frequently. e10s tab switching is definitely far worse than non-e10s for me. I can reproduce it fairly consistently, though the STR seem to require loading my normal many-tab session and frequent heavy use, so it's hard to reduce to something easily replicable. How can I usefully debug this? Install the Gecko Profiler extension if you haven't already, and profile your tab switching. Is there any advantage in doing this over using the builtin devtools browser toolbox's profiling tools? I thought they used the same APIs and just visualized differently? ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The e10s throbber
Yes they are built on the same SPS profiler backend. However, the gecko profiler addon will do things the builtin devtools can't, like open a shell and call `atos` to symbolicate C++ function addresses. See https://bugzilla.mozilla.org/show_bug.cgi?id=1132529 for some context. For the time being, I would recommend using the gecko profiler addon for debugging chrome and platform performance issues. On Wed, Apr 8, 2015 at 1:59 AM, Gijs Kruitbosch gijskruitbo...@gmail.com wrote: On 07/04/2015 23:41, Robert O'Callahan wrote: On Wed, Apr 8, 2015 at 6:27 AM, Gavin Sharp ga...@gavinsharp.com wrote: We don't have telemetry yet. I've done some measurements and haven't found any cases where tab switching consistently takes longer in e10s. However, it's certainly possible that it does on average. Either way, it's hard to investigate until we can reproduce the problem. I see the spinner far too frequently. e10s tab switching is definitely far worse than non-e10s for me. I can reproduce it fairly consistently, though the STR seem to require loading my normal many-tab session and frequent heavy use, so it's hard to reduce to something easily replicable. How can I usefully debug this? Install the Gecko Profiler extension if you haven't already, and profile your tab switching. Is there any advantage in doing this over using the builtin devtools browser toolbox's profiling tools? I thought they used the same APIs and just visualized differently? ~ Gijs ___ 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
Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?
I sometimes ask users to test a try build to verify that the build fixes their problem. This is an important tool, especially when the problem is hard to reproduce or when the definition of “fix” is a bit nebulous (as it sometimes is in performance-related bugs). However, I don’t want to run the risk of causing users to lose data when they test these builds! That’s especially true in light of the fact that we sometimes make backwards incompatible changes to on-disk data structures between releases (like the recent IndexedDB changes), which could result in users being stuck on Nightly if they experiment with a try build. We do have instructions available for changing profiles, and for backing up and restoring your profile, which would mitigate this issue to an extent: https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data?redirectlocale=en-USredirectslug=Profiles https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data?redirectlocale=en-USredirectslug=Profiles In my opinion, though, these instructions are *way* too complex for less-technical users. Making a mistake when following these instructions could result in data loss in some cases, as well, which is exactly what I’m trying to prevent. And even for more experienced users, backing up and restoring a profile or switching profiles manually is tedious as implemented today. I think one way we could reduce the burden on users would be to just make try builds default to a different profile than channel builds. Can we do this? Any better ideas? - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?
On 2015-04-08 3:08 PM, Seth Fowler wrote: Can we do this? Any better ideas? I filed 1013371 a while back asking for something not quite identical that might meet your needs. Automatically create clean profiles when -P specifies nonexistent profile. - mhoye https://bugzilla.mozilla.org/show_bug.cgi?id=1013371 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?
On Wednesday 2015-04-08 12:08 -0700, Seth Fowler wrote: I think one way we could reduce the burden on users would be to just make try builds default to a different profile than channel builds. Is there a simple patch one could push to change this default, and just include on any try pushes where you need this behavior? I'm a little nervous about making try builds differ from other trees, since that just increases the risk of bustage (or bugs in testing) that shows up in one place but not the other. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: IndexedDB transactions are no longer durable by default, and other changes
2. The the schema version for all databases has changed, so once you open a database on trunk builds and it upgrades you will not be able to open that same database in an aurora/beta/release build. Have we considered issuing a warning saying that after upgrading the profile, it will not be compatible with older versions? Cheers, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: IndexedDB transactions are no longer durable by default, and other changes
On Wed, Apr 8, 2015 at 2:30 PM, Botond Ballo bba...@mozilla.com wrote: Have we considered issuing a warning saying that after upgrading the profile, it will not be compatible with older versions? I would really like to have something like this. WebIDE makes use of IndexedDB today, and it seems to trigger uncatchable errors in some cases when an older client is used with newer profile (see WebIDE bug 1117129), so it's hard to handle at the application level today. Some people (at least at Mozilla) move their profiles between up and down versions regularly, so we should at least look for a way to offer a nice warning. - Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: IndexedDB transactions are no longer durable by default, and other changes
This is a good idea. On 08/04/15 21:30, Botond Ballo wrote: 2. The the schema version for all databases has changed, so once you open a database on trunk builds and it upgrades you will not be able to open that same database in an aurora/beta/release build. Have we considered issuing a warning saying that after upgrading the profile, it will not be compatible with older versions? Cheers, Botond ___ 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: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?
I think you can get this fairly easily by just changing one of the values (Vendor or Name) in build/application.ini such that a different profile folder is used. Gavin On Wed, Apr 8, 2015 at 12:28 PM, L. David Baron dba...@dbaron.org wrote: On Wednesday 2015-04-08 12:08 -0700, Seth Fowler wrote: I think one way we could reduce the burden on users would be to just make try builds default to a different profile than channel builds. Is there a simple patch one could push to change this default, and just include on any try pushes where you need this behavior? I'm a little nervous about making try builds differ from other trees, since that just increases the risk of bustage (or bugs in testing) that shows up in one place but not the other. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) ___ 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: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?
There is also an old, unmaintained GUI for managing profiles: https://developer.mozilla.org/en-US/docs/Profile_Manager It still works, although there are a few bugs. It may be an improvement over command-line arguments for less technical users. Jonathan On Wed, Apr 8, 2015 at 12:49 PM, Gavin Sharp ga...@gavinsharp.com wrote: I think you can get this fairly easily by just changing one of the values (Vendor or Name) in build/application.ini such that a different profile folder is used. Gavin On Wed, Apr 8, 2015 at 12:28 PM, L. David Baron dba...@dbaron.org wrote: On Wednesday 2015-04-08 12:08 -0700, Seth Fowler wrote: I think one way we could reduce the burden on users would be to just make try builds default to a different profile than channel builds. Is there a simple patch one could push to change this default, and just include on any try pushes where you need this behavior? I'm a little nervous about making try builds differ from other trees, since that just increases the risk of bustage (or bugs in testing) that shows up in one place but not the other. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) ___ 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?
+1000 I am constantly killing my profile by downgrading it when I need to test something on Firefox Stable. Switching between Chrome releases couldnt be easier but even as a Firefox Dev switching between profiles when testing a different version is a nightmare, I cant imagine how unfriendly it is for typical web developers. On 8 April 2015 at 20:52, Jonathan Griffin jgrif...@mozilla.com wrote: There is also an old, unmaintained GUI for managing profiles: https://developer.mozilla.org/en-US/docs/Profile_Manager It still works, although there are a few bugs. It may be an improvement over command-line arguments for less technical users. Jonathan On Wed, Apr 8, 2015 at 12:49 PM, Gavin Sharp ga...@gavinsharp.com wrote: I think you can get this fairly easily by just changing one of the values (Vendor or Name) in build/application.ini such that a different profile folder is used. Gavin On Wed, Apr 8, 2015 at 12:28 PM, L. David Baron dba...@dbaron.org wrote: On Wednesday 2015-04-08 12:08 -0700, Seth Fowler wrote: I think one way we could reduce the burden on users would be to just make try builds default to a different profile than channel builds. Is there a simple patch one could push to change this default, and just include on any try pushes where you need this behavior? I'm a little nervous about making try builds differ from other trees, since that just increases the risk of bustage (or bugs in testing) that shows up in one place but not the other. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) ___ 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 ___ 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
Intent to Implement and Ship: UI Events (formerly DOM Level 3 Events) EventModifierInit
EventModifierInit is a dictionary to initialize modifier state at creating untrusted event. This allows to initialize AltGraph, CapsLock, Fn, FnLock, Hyper, NumLock, OS, ScrollLock, Super, Symbol and SymboleLock state of creating events and it has been no way to initialize them. Currently, we don't support Super and Hyper modifier state yet. Therefore, we don't support modifierSuper and modifierHyper in this time. Bug to implement: Support D3E EventModifierInit https://bugzilla.mozilla.org/show_bug.cgi?id=1124608 Link to standard: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#h-event-modifier-initializers -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Is MOZ_SHARK still used?
On 4/6/15 8:11 AM, Eric Shepherd (Sheppy) wrote: Is it worth talking to someone from the TenFourFox project (http://www.floodgap.com/software/tenfourfox/) to see if they have an opinion on this? They may be using Shark still for their debugging and testing processes. I responded in the bug, but I mostly use it for profiling entire processes rather than the specific profiling *control* the Shark code facilitates. If it turned out to be a big deal, it could always be added back in our local changesets since there's really not that many sections. Cameron Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
W3C Proposed Recommendation: HTML5 Web Messaging
W3C recently published the following proposed recommendation (the stage before W3C's final stage, Recommendation): HTML5 Web Messaging http://www.w3.org/TR/webmessaging/ There's a call for review to W3C member companies (of which Mozilla is one) open until Tuesday, May 5. If there are comments you think Mozilla should send as part of the review, or if you think Mozilla should voice support or opposition to the specification, please say so in this thread. (I'd note, however, that there have been many previous opportunities to make comments, so it's somewhat bad form to bring up fundamental issues for the first time at this stage.) This is a specification that's the W3C version of a piece of the WHATWG HTML specification. It appears (from looking at code) to be something we implement, although I'm not sure if there are differences between the W3C and WHATWG versions, and I don't know anything about the status of our implementation. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?
My concern with an approach like this is that it’s opt-in, and developers may not necessarily keep this issue in mind every time they offer a build for someone to try. I’ve seen other developers suggest that users experiment with try builds, but I’m not sure how widespread it is. Probably suggesting that users try to reproduce the problem on Nightly is much more widespread, and is subject to the same problems. How can we reduce users’ risk of data loss in these scenarios, even if a developer doesn’t remember to go out of their way to protect them? Maybe changing the default profile is the wrong approach, especially since it doesn’t cover the Nightly case. Maybe instead we need to be doing something like automatically backing up the user’s profile every time they switch builds, and keeping the last N backups. We’d then need to provide some extremely easy UI in Firefox itself (and not some external tool) to restore from one of these backups. Possibly just even adding easy UI to Firefox itself to both backup and restore your profile would eliminate the need for the automatic backups, although I still vastly prefer the automatic backup idea as it reduces the need for developers to remind users to backup their profile. - Seth On Apr 8, 2015, at 12:49 PM, Gavin Sharp ga...@gavinsharp.com wrote: I think you can get this fairly easily by just changing one of the values (Vendor or Name) in build/application.ini such that a different profile folder is used. Gavin On Wed, Apr 8, 2015 at 12:28 PM, L. David Baron dba...@dbaron.org wrote: On Wednesday 2015-04-08 12:08 -0700, Seth Fowler wrote: I think one way we could reduce the burden on users would be to just make try builds default to a different profile than channel builds. Is there a simple patch one could push to change this default, and just include on any try pushes where you need this behavior? I'm a little nervous about making try builds differ from other trees, since that just increases the risk of bustage (or bugs in testing) that shows up in one place but not the other. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) ___ 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: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?
On Wed, Apr 8, 2015 at 4:06 PM, Mike Hommey m...@glandium.org wrote: On Wed, Apr 08, 2015 at 12:08:27PM -0700, Seth Fowler wrote: I sometimes ask users to test a try build to verify that the build fixes their problem. This is an important tool, especially when the problem is hard to reproduce or when the definition of “fix” is a bit nebulous (as it sometimes is in performance-related bugs). However, I don’t want to run the risk of causing users to lose data when they test these builds! That’s especially true in light of the fact that we sometimes make backwards incompatible changes to on-disk data structures between releases (like the recent IndexedDB changes), which could result in users being stuck on Nightly if they experiment with a try build. It seems to me *this* is the actual problem that needs solving. Switching between esr-release-beta-aurora-nightly is *very* common. If running nightly screws up profiles for older versions, that's a serious problem imho. Really? Presumably not every forward DB migration can be reverted without some data loss in theory, and and in my limited practice, handling DB downgrades is pretty damn hard. Is there an expectation that Release - Nightly - Release will work? Preserve data? Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?
On 09/04/15 15:39, Seth Fowler wrote: Sounds like yet another reason to build support and UI for this stuff directly into the browser. On that note, Bram from UX has some ideas about what it could look like: https://wiki.mozilla.org/Security/Contextual_Identity_Project/User_Profiles Francois ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?
On Apr 8, 2015, at 8:37 PM, Nicholas Alexander nalexan...@mozilla.com wrote: It's quite important for Firefox for Android that try builds look and behave exactly like Nightly builds. On Android, it's not really possible to move/copy/duplicate profiles, and it's rocket science to do it across products (Release, Beta, ..., Nightly, custom). So we need to preserve try builds installing over-top of Nightly builds and vice-versa. And we accept that some migrations are one-way -- nature of the testing beast, I think. So whatever we do needs to be Desktop only, or otherwise account for Fennec. Sounds like yet another reason to build support and UI for this stuff directly into the browser. - Seth ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
HTTP/1.1 Multiplexing
I wrote a very simple addition to HTTP/1.1 in which I plan to draft as a RFC soon, which allows multiplexing, prevents HOL blocking, and allows server pushing in HTTP/1.1. HPack could also be incorporated, via negotiation. The idea? A request begins by adding a header: X-Req-ID, set to a connection-unique value. The server responded with an exact copy of this ID, and a X-Req-Target header which specifies the location of the response(for server pushing mostly). The server sets the X-Req-ID = push/based-id for pushed responses. In doing so, we do away with the standard in-order processing one-response-per-request model. Furthermore, A server may send many 206 Partial Contents for Transfer-Encoding: chunked responses, and must not send any in the initial response denoting a transfer. The request headers for pushed responses are equal to the response they are coming from, with any caching data removed. It is planned to allow the client to push more caching info for pushed information. Example: GET / HTTP/1.1 Host: 127.0.0.1 If-None-Modifed: random etag X-Req-ID: 1 HTTP/1.1 200 OK X-Req-ID: 1 X-Req-Target: / Content-Length: 1024 ...1024 bytes of data... HTTP/1.1 200 OK X-Req-ID: push/1 X-Req-Target: /logo.png Content-Length: 65535 Content-Type: image/png ...65kb... I have a slightly less refined implementation which uses a static -PUSH- X-Req-ID available @ www.avuna.org or https://github.com/JavaProphet/Avuna-HTTPD for source code. The to-do list comprises at the moment of a efficient system for specific more complex push caching, to avoid re-pushing already known data. One possible system is to allow multiple ETag/Last-Modified or other cache-related header fields in the initial request. Ex. If-None-Modified: /=blah /logo.png=blah2 Another is to use a 'master-etag/last-modified' that assumes the pushed content is there. (But what if some updates?) A HPack negotiation is planned, perhaps after the server acknowledges that the connection is extended, it will encode with HPack instead of standard. Also X-HPACK: hpack binary perhaps to allow legacy processing to be more efficient? I would like to see some form of this support by Firefox to allow further testing and development. Not only is it not as complicated as HTTP/2, but it has theoretically much faster potential without all the nasty protocol negotiation and upgrading, as well as the virtualized stream overhead, which seems to be unnecessary. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?
Hi Seth, others, On Wed, Apr 8, 2015 at 12:08 PM, Seth Fowler s...@mozilla.com wrote: I sometimes ask users to test a try build to verify that the build fixes their problem. This is an important tool, especially when the problem is hard to reproduce or when the definition of “fix” is a bit nebulous (as it sometimes is in performance-related bugs). However, I don’t want to run the risk of causing users to lose data when they test these builds! That’s especially true in light of the fact that we sometimes make backwards incompatible changes to on-disk data structures between releases (like the recent IndexedDB changes), which could result in users being stuck on Nightly if they experiment with a try build. It's quite important for Firefox for Android that try builds look and behave exactly like Nightly builds. On Android, it's not really possible to move/copy/duplicate profiles, and it's rocket science to do it across products (Release, Beta, ..., Nightly, custom). So we need to preserve try builds installing over-top of Nightly builds and vice-versa. And we accept that some migrations are one-way -- nature of the testing beast, I think. So whatever we do needs to be Desktop only, or otherwise account for Fennec. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?
On Thu, Apr 9, 2015 at 9:00 AM, Gavin Sharp ga...@gavinsharp.com wrote: I think that's overthinking it - I doubt Seth was intending to distribute these builds widely or frequently. A few leftover profile files won't hurt anyone :) It wouldn't be distributed widely, but could be frequently if it becomes a common practice. And for people who are obsessive about cleanliness, it could be a serious problem. - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: Identity provider proxy for WebRTC
As of 2015-04-15 I intend to turn identity for WebRTC on by default. It has been developed behind the media.peerconnection.identity.enabled preference. Firefox will be the first to implement this; I have only informal promises from Google to implement once we ship. This feature is the mutual authentication mechanism for WebRTC [1]. It enables peer-to-peer media communications that are confidential, even from the site that you are visiting. We don't currently have UX [2] for this, so enabling the feature is largely intended to enable experimentation. This is feature will be needed for Firefox Hello. This feature was previously discussed in this intent to implement thread: https://groups.google.com/d/msg/mozilla.dev.platform/QiF18J4vccA/rDclGYmFPBEJ. [1] https://w3c.github.io/webrtc-pc/ (see also https://github.com/w3c/webrtc-pc/pull/178) [2] https://bugzilla.mozilla.org/show_bug.cgi?id=942372 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Identity provider proxy for WebRTC
My bad, here's the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1152538 On Wed, Apr 8, 2015 at 2:11 PM, Martin Thomson m...@mozilla.com wrote: As of 2015-04-15 I intend to turn identity for WebRTC on by default. It has been developed behind the media.peerconnection.identity.enabled preference. Firefox will be the first to implement this; I have only informal promises from Google to implement once we ship. This feature is the mutual authentication mechanism for WebRTC [1]. It enables peer-to-peer media communications that are confidential, even from the site that you are visiting. We don't currently have UX [2] for this, so enabling the feature is largely intended to enable experimentation. This is feature will be needed for Firefox Hello. This feature was previously discussed in this intent to implement thread: https://groups.google.com/d/msg/mozilla.dev.platform/QiF18J4vccA/rDclGYmFPBEJ. [1] https://w3c.github.io/webrtc-pc/ (see also https://github.com/w3c/webrtc-pc/pull/178) [2] https://bugzilla.mozilla.org/show_bug.cgi?id=942372 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?
On Thu, Apr 09, 2015 at 08:48:32AM +1200, Xidorn Quan wrote: On Thu, Apr 9, 2015 at 7:49 AM, Gavin Sharp ga...@gavinsharp.com wrote: I think you can get this fairly easily by just changing one of the values (Vendor or Name) in build/application.ini such that a different profile folder is used. If I were a user who wants to test the build, I don't want to see this, as the new profile folder is useless after testing the build, but it is hard to locate and clean. The profile manager has UI to remove profiles and the files associated with them. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?
I think that's overthinking it - I doubt Seth was intending to distribute these builds widely or frequently. A few leftover profile files won't hurt anyone :) Gavin On Apr 8, 2015, at 1:48 PM, Xidorn Quan quanxunz...@gmail.com wrote: On Thu, Apr 9, 2015 at 7:49 AM, Gavin Sharp ga...@gavinsharp.com wrote: I think you can get this fairly easily by just changing one of the values (Vendor or Name) in build/application.ini such that a different profile folder is used. If I were a user who wants to test the build, I don't want to see this, as the new profile folder is useless after testing the build, but it is hard to locate and clean. Since try build are usually placed in a user folder which doesn't require any privilege to write in, I'd suggest we create the profile in the program directory directly. Probably we can add a bit of code before reading profile, and wrap it with a #ifdef, then anyone wants this could just switch it on. - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?
On Wed, Apr 08, 2015 at 12:08:27PM -0700, Seth Fowler wrote: I sometimes ask users to test a try build to verify that the build fixes their problem. This is an important tool, especially when the problem is hard to reproduce or when the definition of “fix” is a bit nebulous (as it sometimes is in performance-related bugs). However, I don’t want to run the risk of causing users to lose data when they test these builds! That’s especially true in light of the fact that we sometimes make backwards incompatible changes to on-disk data structures between releases (like the recent IndexedDB changes), which could result in users being stuck on Nightly if they experiment with a try build. It seems to me *this* is the actual problem that needs solving. Switching between esr-release-beta-aurora-nightly is *very* common. If running nightly screws up profiles for older versions, that's a serious problem imho. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
