Re: proposal: replace talos with inline tests
On Tue, Mar 5, 2013 at 11:47 AM, Dave Mandelin wrote: > > It appears that there a few areas that are only covered by Talos for now, > though. I think in that category we have warm startup time via Ts, and basic > layout performance via Tp. I'm not sure about memory, because we do seem to > detect increases via Talos, but we also have AWSY, and I don't know whether > AWSY obviates Talos memory measurements or not. Talos memory measurements aren't very good because it cycles through multiple sites in a single tab. So it sometimes catches start-up memory consumption regressions (Firefox Health Report was a recent case) but it doesn't get much beyond that. In comparison, AWSY cycles through 100 sites with 30 tabs open at once, which is a much better reflection of typical browsing. It also does multiple measurements -- start-up, after loading the tabs, after closing the tabs, etc. It's worth pointing out that AWSY is sort of built on top of Talos -- its 100 sites are taken from the Talos Tp5 set. The good thing about this page set is that they're stored entirely locally. The downside is that all the external stuff in the pages (e.g. Facebook "Like" buttons, Google Ad stuff, Twitter feeds) isn't present, so it's a not particularly realistic representation of those pages; in particular, the amount of JS present is much less than real pages have. (https://bugzilla.mozilla.org/show_bug.cgi?id=679940#c31 is an example of the effect of this in action.) Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firing events at the window vs. firing them at the chrome event handler
On 03/04/2013 08:20 PM, Boris Zbarsky wrote: On 3/4/13 1:08 PM, Zack Weinberg wrote: It only needs to be certain of seeing the event despite anything content can do, In that case, a capturing handler on the chrome event listener will work fine. -Boris or capturing or bubbling event listener in system event group. http://mxr.mozilla.org/mozilla-central/source/content/events/public/nsIEventListenerService.idl#72 Listeners in system event group are called after the default group, but stop*Propagation is per group. Listeners added by content js are only in the default group. -Olli ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: proposal: replace talos with inline tests
Writing a lot of performance tests creates the problem that those tests will take a long time to run. The nature of performance tests is that each test must run for a relatively long time to get meaningful results. Therefore I doubt writing lots of different performance tests can scale. (Maybe we can find ways to eliminate noise in very short tests, but that might be research.) Well we learn as we write more tests what works and what doesnβt. A factor like length of run is something we learn about over time as we experiment. My whole point here to provide an easy way for devs to experiment. We currently do not have something like this available. What the tests run on and how they integrate into our existing testing infrastructure is an engineering problem we can solve. One other thing to keep in mind if we're going to start doing performance tests differently is https://bugzilla.mozilla.org/show_bug.cgi?id=846166. Basically Chris suggests using eideticker for performance tests a lot more. Eideticker is interesting, but it's also not pliable. We'd love to have eideticker tests running for metro but the odds of that happening anytime soon are slim due to the overhead of getting it set up. I imagine making changes or adding tests is probably not very easy either. Something like eideticker is great as a research project or something that is owned by a special team that augments it over time and produces data sets we can use. But I seriously doubt devs on m-c will ever be able to spend a few hours writing and then checking in an eideticker test. Jim ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XMLHttpRequest for REST/PUT request to GoogleCalendar -- discloses login/PW to console
On Monday, March 4, 2013 9:34:17 PM UTC, gNeandr wrote: > Maybe it was my fault to use .responseType="" because the description > for XHR has that and ="text" as string type. While that is correct, XMLHttpRequest will exhibit its legacy behavior of also making responseXML available if you use "". So using "" is not recommended. I suppose I should clarify that in the specification at some point. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On 3/4/2013 6:10 PM, Bobby Holley wrote:
Q: Will this break websites?
A: Some, probably. Telemetry indicates that a bit under 10% of users
encounter at least one reference to Components during their browsing
session. Approximately half of these appear to be simple accesses of the
object itself and not any of its properties, which probably indicates
bachelor-frog browser detection of the form |if (window.Components) { /*
Firefox */ }|. The other half appears to be access to
Components.interfaces, which probably indicates that the page is pulling
DOM constants off XPCOM interfaces instead of the DOM constructor (i.e.
Components.interfaces.nsIXMLHttpRequest.HEADERS_RECEIVED instead of
XMLHttpRequest.HEADERS_RECEIVED).
Is there a particular reason we aren't just making these cases continue
to work? I understand that we don't want to expose the *current*
Components object for a bunch of compelling reasons. But couldn't we
have a new object with specific compatibility behaviors so that existing
sites which use Components for detection or for specific interface
consts to continue to work?
e.g. nsIDOMComponentsShim -> interfaces -> nsIXMLHttpRequest. list of consts
If we can do simple things to keep web compat, we should.
--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: proposal: replace talos with inline tests
- Original Message - > Talos memory measurements aren't very good because it cycles through > multiple sites in a single tab. So it sometimes catches start-up > memory consumption regressions (Firefox Health Report was a recent > case) but it doesn't get much beyond that. Another problem with the Talos memory tests, in comparison to AWSY, is that Talos opens and closes pages very rapidly, while AWSY proceeds at a more stately pace. This is very important for a memory test, because most of our GC and CC heuristics are time based. The drawback of this is that each test takes hours to run, though it is mostly just sitting around, so many test runs can be done at once on the same machine. > > In comparison, AWSY cycles through 100 sites with 30 tabs open at > once, which is a much better reflection of typical browsing. It also > does multiple measurements -- start-up, after loading the tabs, after > closing the tabs, etc. > > It's worth pointing out that AWSY is sort of built on top of Talos -- > its 100 sites are taken from the Talos Tp5 set. The good thing about > this page set is that they're stored entirely locally. The downside > is that all the external stuff in the pages (e.g. Facebook "Like" > buttons, Google Ad stuff, Twitter feeds) isn't present, so it's a not > particularly realistic representation of those pages; in particular, > the amount of JS present is much less than real pages have. > (https://bugzilla.mozilla.org/show_bug.cgi?id=679940#c31 is an > example > of the effect of this in action.) > > Nick > ___ > 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: Turning off window.Components for the web
On Tue, Mar 5, 2013 at 6:16 AM, Benjamin Smedberg wrote:
> On 3/4/2013 6:10 PM, Bobby Holley wrote:
>
>> Q: Will this break websites?
>> A: Some, probably. Telemetry indicates that a bit under 10% of users
>> encounter at least one reference to Components during their browsing
>> session. Approximately half of these appear to be simple accesses of the
>> object itself and not any of its properties, which probably indicates
>> bachelor-frog browser detection of the form |if (window.Components) { /*
>> Firefox */ }|. The other half appears to be access to
>> Components.interfaces, which probably indicates that the page is pulling
>> DOM constants off XPCOM interfaces instead of the DOM constructor (i.e.
>> Components.interfaces.**nsIXMLHttpRequest.HEADERS_**RECEIVED instead of
>> XMLHttpRequest.HEADERS_**RECEIVED).
>>
> Is there a particular reason we aren't just making these cases continue to
> work? I understand that we don't want to expose the *current* Components
> object for a bunch of compelling reasons. But couldn't we have a new object
> with specific compatibility behaviors so that existing sites which use
> Components for detection or for specific interface consts to continue to
> work?
>
> e.g. nsIDOMComponentsShim -> interfaces -> nsIXMLHttpRequest. list of
> consts
>
Defining an empty "window.Components" property to appease browser
detection wouldn't be that hard, but it makes things confusing, and has the
cost of perpetuating non-standard behavior on the web. This in turn makes
it more difficult to build a new interoperable implementation like Servo.
In my opinion, we should treat any such hacks as stop-gap measures, rather
than permanent ones. For example, when I removed enablePrivilege, the
MathJax library broke because of the disappearance of the |window.netscape|
object. They were embarrassed and fixed their code, and I landed and empty
|netscape| object for compatibility while the update makes its way around
the web. But I still plan to remove it eventually. So while it's possible
that we may need to do something like this, I only want to do it after
lighting a fire under developers to fix their stuff. We have no idea how
many sites and what kind of sites we're dealing with, and won't unless we
land this and let people file bugs.
Defining a shim for interface constants is significantly more complicated.
While possible, it represents a fair amount of engineering effort that I'd
like to avoid, and forces us to maintain nsIDOMFoo interfaces that would
otherwise go away with the WebIDL transition. We may yet have to do
something like this, but it's a high bar.
bholley
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On 3/5/13 12:01 PM, Bobby Holley wrote: They were embarrassed and fixed their code They weren't embarrassed and didn't fix their code. And since we relanded "netscape" they don't really have incentive to... Of course now their sniffing relies on at least three separate things all of which we want to remove. :( Defining a shim for interface constants is significantly more complicated. While possible, it represents a fair amount of engineering effort that I'd like to avoid, and forces us to maintain nsIDOMFoo interfaces that would otherwise go away with the WebIDL transition. Peter has suggested making Components.interfaces.nsIXMLHttpRequest == window.XMLHttpRequest, for what it's worth. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On Tue, Mar 5, 2013 at 9:11 AM, Boris Zbarsky wrote: > On 3/5/13 12:01 PM, Bobby Holley wrote: > >> They were embarrassed and fixed their code >> > > They weren't embarrassed and didn't fix their code. And since we relanded > "netscape" they don't really have incentive to... > Well, I interpreted bug 791526 comment 14 as some degree of embarrassment. But I admittedly didn't follow up to see if they actually fixed it. Looks like they didn't. :-( ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On 3/5/2013 12:11 PM, Boris Zbarsky wrote:
Peter has suggested making Components.interfaces.nsIXMLHttpRequest ==
window.XMLHttpRequest, for what it's worth.
Yes. I think this shim could be implemented entirely in JS:
window.Components = { interfaces: { nsIXMLHttpRequest:
window.XMLHttpRequest } };
with a bit of additional getters-spamming console.warn if we really wanted.
--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
Which channel(s) does the 10% number come from? Our past experience has shown that users on our Release channel examine a much broader portion of the old web/intranets that can be using this kind of thing than our Beta population, and Beta in turn much more than Aurora. I definitely think that we should have some backwards compat shim in place for quite some time and evangelize heavily in the mean time, and hopefully one day we will be able to completely remove those shims... :/ Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MemShrink meeting: Today March 5, 2013 @ 2:00pm PST
Today's MemShrink meeting will be brought to you by this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=689623 The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * Discuss Images Memory Usage * Prioritize unprioritized MemShrink bugs. * Discuss how we measure progress. * Discuss approaches to getting more data. Meeting details: * Tue, March 5, 2013, 2:00 PM PDT * PB&J, Mountain View office, 3rd floor. * 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 95346 -- Jet ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On Tue, Mar 5, 2013 at 10:13 AM, Ehsan Akhgari wrote: > Which channel(s) does the 10% number come from? Release WINNT. Nightly population appears to be closer to 6%, about 2/3rds of which are accesses to Ci. > I definitely think that we should have some backwards compat shim in place > for quite some time and evangelize heavily in the mean time, and hopefully > one day we will be able to completely remove those shims... :/ > I don't really have faith in our ability to "evangelize heavily" on this issue (outside of what we've already done) without flipping the switch. This is why I want to ship it, figure out which sites are broken, and only put in shims if we encounter breakage that can't be easily fixed by telling the relevant web authors to fix their site. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On 3/5/13 1:43 PM, Bobby Holley wrote: On Tue, Mar 5, 2013 at 10:13 AM, Ehsan Akhgari wrote: Which channel(s) does the 10% number come from? Release WINNT. Nightly population appears to be closer to 6%, about 2/3rds of which are accesses to Ci. Just to make sure I understand Does this include content-attached XBL? Or is this guaranteed to be actual web page scripts? I don't really have faith in our ability to "evangelize heavily" on this issue (outside of what we've already done) without flipping the switch. This is why I want to ship it, figure out which sites are broken, and only put in shims if we encounter breakage that can't be easily fixed by telling the relevant web authors to fix their site. Is shipping it on nightly+aurora but flipping off on beta+release for a cycle or two an option? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On Tue, Mar 5, 2013 at 10:46 AM, Boris Zbarsky wrote: > On 3/5/13 1:43 PM, Bobby Holley wrote: > Just to make sure I understand Does this include content-attached > XBL? Or is this guaranteed to be actual web page scripts? It does not include XBL - we specifically check for that in the telemetry code. Is shipping it on nightly+aurora but flipping off on beta+release for a > cycle or two an option? > It would take some fiddling, but I could the appropriate machinery to do that, sure. I'd still like to avoid doing it, but it's probably worth having the infrastructure in place. I'll file a bug. bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On Mar 5, 2013, at 1:43 PM, Bobby Holley wrote: >> I definitely think that we should have some backwards compat shim in place >> for quite some time and evangelize heavily in the mean time, and hopefully >> one day we will be able to completely remove those shims... :/ > > I don't really have faith in our ability to "evangelize heavily" on this > issue (outside of what we've already done) without flipping the switch. > This is why I want to ship it, figure out which sites are broken, and only > put in shims if we encounter breakage that can't be easily fixed by telling > the relevant web authors to fix their site. Our market research tells us that most people on the web have Firefox installed - so the fight on desktop isn't over users, per se, it's over usage. I believe (intuition, not data) that busted sites are very much a thing that pushes those users to launch another browser. Each time they do, there's some <100% chance that we get them back. I know that the precautionary principle can be paralytic but, in the absence of a significant win, I agree with Ehsan and Benjamin here that I'd much rather shim this than "see what breaks." J --- Johnathan Nightingale VP Firefox Engineering @johnath ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On Tue, Mar 5, 2013 at 11:08 AM, Johnathan Nightingale wrote: > Our market research tells us that most people on the web have Firefox > installed - so the fight on desktop isn't over users, per se, it's over > usage. I believe (intuition, not data) that busted sites are very much a > thing that pushes those users to launch another browser. > This makes sense in terms of |if (Components)| browser detection. But if a site is grabbing interface constants off of nsIDOMFoo interfaces, it seems very unlikely that said site would work in another browser. The other problem with shimming in interface constants is that we don't know which interfaces to do it for (though we can take an educated guess and do it for XHR and a few others). That being said, if we don't mind just guessing about the interfaces to shim, Benjamin's suggestion sounds easy enough if there's a place we can put it. Is there some global JS file somewhere that gets injected into every content scope? If so, I'd be fine to stick something like what he suggested in there. bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On Tue, Mar 5, 2013 at 10:43 AM, Bobby Holley wrote: > I don't really have faith in our ability to "evangelize heavily" on this > issue (outside of what we've already done) without flipping the switch. > This is why I want to ship it, figure out which sites are broken, and only > put in shims if we encounter breakage that can't be easily fixed by telling > the relevant web authors to fix their site. "Figuring out what sites are broken" on the release channel is a very costly process (largely in the form of frustrating our users). I don't think it's the right tradeoff in this particular case. Getting rid of web-exposed "Components" isn't a goal in and of itself, so we don't need to optimize for doing it quickly at the cost of user frustration. Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On Tue, Mar 5, 2013 at 11:33 AM, Bobby Holley wrote: > This makes sense in terms of |if (Components)| browser detection. But if a > site is grabbing interface constants off of nsIDOMFoo interfaces, it seems > very unlikely that said site would work in another browser. The other > problem with shimming in interface constants is that we don't know which > interfaces to do it for (though we can take an educated guess and do it for > XHR and a few others). > You're clearly not jaded enough if you don't expect websites to do totally non-standard things that have standard equivalents based on UA sniffing/browser detection ;-) - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On Tuesday 2013-03-05 11:36 -0800, Gavin Sharp wrote: > On Tue, Mar 5, 2013 at 10:43 AM, Bobby Holley wrote: > > I don't really have faith in our ability to "evangelize heavily" on this > > issue (outside of what we've already done) without flipping the switch. > > This is why I want to ship it, figure out which sites are broken, and only > > put in shims if we encounter breakage that can't be easily fixed by telling > > the relevant web authors to fix their site. > > "Figuring out what sites are broken" on the release channel is a very > costly process (largely in the form of frustrating our users). I don't > think it's the right tradeoff in this particular case. Getting rid of > web-exposed "Components" isn't a goal in and of itself, so we don't > need to optimize for doing it quickly at the cost of user frustration. That said, making different implementations of the Web platform (i.e., different browsers) converge so that authors can rely on standard behavior is a goal. The pieces of that that we have control over are adding and removing things from our own implementations, influencing other implementations through standards processes, and influencing other implementations in other ways. That said, it seems like it may be worth pushing on the cases we know about before shipping to a beta/release audience. It also might be worth removing Components from nightly/aurora sooner rather than later. -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla http://www.mozilla.org/ π ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On Tue, Mar 5, 2013 at 11:33 AM, Bobby Holley wrote:
> This makes sense in terms of |if (Components)| browser detection. But if a
> site is grabbing interface constants off of nsIDOMFoo interfaces, it seems
> very unlikely that said site would work in another browser.
This line of reasoning can be dangerous, given the presence of
browser-specific code (e.g. if (firefox) { /* use Ci! */ }). But we're
in "estimates of likelihood of bustage based on intuition" territory,
which can make it difficult to have a productive debate. I imagine
we'll get better data about the potential for bustage impact once this
gets onto Aurora and/or Beta, but prior experience with this kind of
thing has shown that those channels often aren't sufficient for
detecting high-impact web compat changes, so we need to be careful...
Gavin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On 2013-03-05 1:58 PM, Bobby Holley wrote: Is shipping it on nightly+aurora but flipping off on beta+release for a cycle or two an option? It would take some fiddling, but I could the appropriate machinery to do that, sure. I'd still like to avoid doing it, but it's probably worth having the infrastructure in place. I'll file a bug. I think doing this behind a MOZ_RELEASE pref makes sense any way since we do need a disaster recovery method whenever this ships on the Release channel, and having a pref which can be toggled by an add-on hotfix is the ideal way to do that. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On Tue, Mar 5, 2013 at 11:42 AM, L. David Baron wrote: > That said, making different implementations of the Web platform > (i.e., different browsers) converge so that authors can rely on > standard behavior is a goal. The pieces of that that we have > control over are adding and removing things from our own > implementations, influencing other implementations through standards > processes, and influencing other implementations in other ways. Agreed. These discussions always boil down to how you value that goal compared to the goal of not causing user issues, and different people have different perspectives. From my perspective, the current state of things (having Components be web-exposed) is far from ideal, but also not having a negative enough impact on platform-convergence goals to merit causing much user frustration. So I'd rather we stay closer to the "slow (understandably frustrating), slog of evangelism and maintaining compat shims" end of the spectrum than the opposite "full steam ahead, bustage be damned" end. Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
debugging spurious unfocus events on popup menus
Hi, In the course of debugging my patches for bug 715376, I've run across a peculiar bug that I lack the platform knowledge to explain. In this test: http://mxr.mozilla.org/mozilla-central/source/browser/base/content/test/browser_save_link-perwindowpb.js#25 a context menu is triggered on a link. In failing tests, logs show that the synthesized mouse click happens and is then followed (immediately or shortly thereafter) by a focus out event on the window. That focus out triggers this code: http://mxr.mozilla.org/mozilla-central/source/widget/gtk2/nsWindow.cpp#2838 which, through various twists and turns, makes the menu disappear before the popupshown event handler is run. The disappearance of the menu makes code in browser.xul unhappy (gContextMenu winds up |null|) and the test hangs. (Changing the handler to catch popupshowing makes the hangs go away, but that doesn't seem like what we want to test...) The issue happens infrequently on my Linux machine (debug and opt) and repeatedly on Try. I do not see what my modifications have to do with when focus events are triggered (and why the rogue focus event is only triggered occasionally). These logs: http://people.mozilla.com/~nfroyd/win-page-queues-log (successful run) http://people.mozilla.com/~nfroyd/lose-page-queues-log (unsuccessful run) contain information about events dispatched to the event queue (sans timer events) and various other bits of information (notably LOG and LOGFOCUS messages from nsWindow.cpp). The areas of interest start around line 992 for win-page-queues-log and line 981 for lose-page-queues-log, where the mouse click event is dispatched. The events run before and after the mouse click seem to be the same, so I'm at a loss to understand how the behavior diverges. Can anybody provide hints about where I should be looking to prevent these focus events from screwing up the tests? Thanks, -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On Wed, Mar 6, 2013 at 8:54 AM, Gavin Sharp wrote:
> This line of reasoning can be dangerous, given the presence of
> browser-specific code (e.g. if (firefox) { /* use Ci! */ }). But we're
> in "estimates of likelihood of bustage based on intuition" territory,
> which can make it difficult to have a productive debate. I imagine
> we'll get better data about the potential for bustage impact once this
> gets onto Aurora and/or Beta, but prior experience with this kind of
> thing has shown that those channels often aren't sufficient for
> detecting high-impact web compat changes, so we need to be careful...
>
Bustage detection rate isn't just a function of the user populations on
each channel; it's also a function of time. Six months of testing on beta
is better than six weeks. I don't know how much better but I'd like to!
Letting changes like this progress to beta and then stay there for several
releases might be a good idea, and if we get some experience with it we
might be able to estimate the value of different lengths of time.
Rob
--
Wrfhf pnyyrq gurz gbtrgure naq fnvq, βLbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
β whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.β [Znggurj 20:25-28]
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On 06/03/13 11:55, Robert O'Callahan wrote: > On Wed, Mar 6, 2013 at 8:54 AM, Gavin Sharp wrote: > Bustage detection rate isn't just a function of the user populations on > each channel; it's also a function of time. Six months of testing on beta > is better than six weeks. I don't know how much better but I'd like to! > Letting changes like this progress to beta and then stay there for several > releases might be a good idea, and if we get some experience with it we > might be able to estimate the value of different lengths of time. > > Rob My observation is that discussions about obsoleting things seem to follow a certain pattern: 1. Someone proposes that feature X needs to be obsoleted. Usually for the right reasons. 2. The usual suspects chime in about the cost and ask for it to not be obsoleted. 3. More often than not the conclusion is to continue supporting the feature. So while there is value in obsoleting things it is usually considered to be too expensive. There is value in obsoleting things. It is a good thing to do because it allows both us and the web platform to move past outdated (or poor) design decisions. We should take this opportunity to consider the bigger picture of how we can be more systematic about obsoleting things. We can also do things that will reduce the cost of obsoleting things. Some ideas for an obsolescence plan are: * Obsolete the feature for n cycles on nightly before progressing * Stage the obsolescence: - Console warnings - Banner warning (at the top of the site) - Feature removal * Warnings could link to a page with a full explanation of the obsolescence including rationale and recommendations There may be other paths that we can follow to reduce the cost of obsolescence. If we are systematic about it then we can put the right infrastructure in place to take the hassle out of cranking through such a process. Anthony ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Supporting the Windows Certificate Store
On Wednesday, January 9, 2013 9:17:12 AM UTC-8, joshu...@gmail.com wrote: > I know that there are probably well thought out reasons that this isn't a > features already...BUT! Lot's of US Government users can't use Firefox > because it doesn't use the Windows certificate store. > > > > Would anyone be totally opposed to adding this feature and having it enabled > via group policy? That would allow some IT shops to roll it out with their > preferred smart card middleware...like ActivClient. > > > > Thoughts? I would be very much in favor of adding this feature. We are getting ready to remove Firefox and restrict its use across our 5000 PCs because it is such a righteous PITA to add our internal CA certificates to Firefox remotely and we don't want to deal with the flood of inevitable user calls "I don't know what to choose, this security certificate stuff scares me." "Why am I getting prompted for internal websites?" "Don't you IT guys know how to do certs?" "Do I have to accept it, or do I install it?" I read the articles for certutil and I have to ask, "what idiot came up with that as the only method???" Seriously, not being able to do it easily through Group Policy or some other centralized method is a GIGANTIC FAIL. If you want enterprises to take you seriously, take us and our needs seriously. Otherwise whatever point Mozilla is trying to make is being lost and you will never be installed again in our shop. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
