Shortening Crash Signatures: Dropping Argument Lists
Hi everyone,
Crash signatures derived from the function on the stack are how we group
("bucket") crashes as belonging to a certain issue or bug. They should
be precise enough to identify this "bucket" but also short enough so we
can handle it as a denominator in lists and when talking about those
issues. For some time, we have seen that our signatures are very
long-winded and contain parts that make it sometimes even harder to
bucket correctly. To fix that, we set out to shorten our crash signatures.
We already completed a first step of this effort in June: After we found
that templates in signatures were often fluctuating wildly in crashes
that belonged to the same bug, all parts of crash
signatures were replaced by just .
That made a signature like this (from bug 1045509, the [@ …] are our
customary delimiters for signatures, not really part of the signature
itself though):
[@ nsTArray_basensTArray_CopyWithMemutils>::UsesAutoArrayBuffer() |
nsTArray_ImplnsTArrayFallibleAllocator>::SizeOfExcludingThis(unsigned int (*)(void
const*)) ]
be shortended to:
[@ nsTArray_base::UsesAutoArrayBuffer() |
nsTArray_Impl::SizeOfExcludingThis(unsigned int (*)(void const*)) ]
Which is definitely somewhat better to read and put in tables like
topcrash reports, etc. - and we found it did not munge bugs together
into the same signature more than previously, at least to our knowledge.
But we found out we can go even further: Different argument lists of
functions (mostly due to overloading) did as far as I remember not help
us distinguish any bugs in the >4 years I have been working with crashes
- but patches changing types of arguments or adding one to a function
often made us lose the connection between a bug and the signature.
Therefore, we are removing argument lists from the signatures.
The signature listed above will turn out as:
[@ nsTArray_base::UsesAutoArrayBuffer |
nsTArray_Impl::SizeOfExcludingThis ]
Today, we have run a script on Bugzilla (see bug 1178094) to update all
affected bugs to add the new shortened signature to the Crash Signatures
field without sending a ton of bugmail.
We have tested in the last weeks that Socorro crash-stats can create the
new shortened signatures fine on their staging setup and that generation
of the special "shutdownhang | …" signatures for browser processes that
did take more than 60s to shut down and "OOM | …" for out-of-memory
crashes do still work in all cases where they worked before.
As all preparation has been done, we will flip the switch on production
Socorro crash-stats in the next days, and then those shortened
signatures will be created everywhere.
Note that this will impede some stats that are comparing signatures
across days, even though we will see to reprocess some crashes to make
the watershed be at a UTC day delimiter so that as few stats as possible
are disturbed by the change.
Please let me know of any issues with those changes (as well as any
other questions about or issues with crash analysis), and thanks to
Lars, Byron (glob) and others who helped with those changes!
Thanks,
KaiRo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Shortening Crash Signatures: Dropping Argument Lists
Boris Zbarsky schrieb: On 10/13/15 2:11 PM, Robert Kaiser wrote: Please let me know of any issues with those changes (as well as any other questions about or issues with crash analysis), and thanks to Lars, Byron (glob) and others who helped with those changes! Just to make sure, crash-stats will still have the full crash stack with the arguments and whatnot, right? It's just the signature linked to bugzilla that's changing? Yes, the stack frames themselves still contain the full template and argument strings, all that changes is the signatures - which are used in topcrash reports and all other reports based on signature-based buckets. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Merging comm-central into mozilla-central
Jonas Sicking schrieb: Would it be possible to create a thunderbird build system which simply takes the output of a firefox build and grabs the files that it needs, and builds the additions that thunderbird needs. Generally speaking, libraries don't worry about having a build system which enables building all downstream products. It's the responsibility of downstream products to trigger the build system of libraries. Yes, but our platform is not built in a way to really be able to act as an outside library to Thunderbird (or SeaMonkey). The idea to get it there was around years ago, under different names (the last of them being XULRunner) and it failed. So what we have is "you need to build all the platform code if you want to build Thunderbird, and you need to compile your Thunderbird-specific code into libxul even". And I think that's the reason where this view you bring up there doesn't apply to what we have. Maybe, some years down the road, when Firefox and Thunderbird UI are all standard HTML, this will be all different, but until then, lives are much easier when all this lives into a common repository. The goal of putting seamonkey and thunderbird in separate trees has always been to make firefox development easier, not harder. That should include the build system. That was the idea, yes. In reality, we have found out that this made it harder, especially for the build system, and we are continuing to waste a lot of developer time because making sure that the build system at least stays usable to Thunderbird (and SeaMonkey) is slowing efforts down to make our build system modern and give it all kinds of optimizations like caching, dependency-awareness and whatnot that will improve development speed for all platform and Firefox developers. As the on-paper-owner of the comm-central build system, I would heavily appreciate this merge (and killing off "my" module and the repository I created way back). KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Merging comm-central into mozilla-central
Jonas Sicking schrieb: I definitely think that some aspects of Firefox development has gotten easier thanks to the split. I'd like to see which. I don't see much that has gotten easier *because of the split*. I see a lot that has gotten easier because we change platform and Firefox (mostly) without caring if we break Thunderbird or SeaMonkey - and I think that isn't necessarily related with where the code actually lives. I see where the code lives as a technical issue and how much or if we care to break those products when changing code as a policy issue. And I don't think that the proposal here is to change policy there. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Merging comm-central into mozilla-central
Edmund Wong schrieb: As for the long term plans, I'll wait for one of the SeaMonkey council members to comment on that; but I believe we are determined to maintain the SeaMonkey code. I'll weigh in as a SeaMonkey Council member - even though I mostly watch what's going on while Edmund is actually one of the people doing a ton of work there. ;-) From all I see and hear, those people active in the SeaMonkey project are committed to maintaining it for the foreseeable future. You never know what happens years down the road, of course, and this is a small group of people. But then, from its inception, this was a pretty small group, and the project has survived for 10 years now (founded in March 2005, 1.0 release in January 2006). The project has been having build infrastructure issues in recent months, but I hear things are somewhat improving - and actually, this merge would probably make quite a few things easier, as more of the same tooling could be used that Firefox uses (for example, all the custom buildbot tooling I wrote up years ago for handling c-c is a major PITA up to this day). KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Merging comm-central into mozilla-central
Jonas Sicking schrieb: Everyone acknowledges that there's currently friction due to the way that collaboration with thunderbird is done. The question is, do we fix that friction by making collaboration easier, or do we fix it by reducing collaboration. I think the only way to "fix the friction by reducing collaboration" is to say that you are actively trying to kill Thunderbird and make their life as hard as possible. Is that what you are trying to say? Otherwise, if we acknowledge that they can and should live, we need to see that we fix the friction by making collaboration easier. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Date, time, week, month and datetime attributes in the in Firefox
Carlos Valim Coragem schrieb: I asked this same question on channel #mozilla-br on IRC, a mozillian gave me this link: https://bugzilla.mozilla.org/show_bug.cgi?id=1069609 - the bug was opened on 09-18-2014, the last comment was day 07-24-2015, wondering if there was any progress on that. https://bugzilla.mozilla.org/show_bug.cgi?id=825294 is actually the bug for this. Fun thing is that IIRC this is in HTML5 because of Mozilla's "Web Forms 2.0" specification proposed earlier - and we never implemented it so far... KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Date, time, week, month and datetime attributes in the in Firefox
Jonas Sicking schrieb: The main blocker, IMO, is that unless web authors can style these controls to integrate well with the look and feel of the rest of their website, they won't be interested in using these controls. I'm not sure. I mean, isn't decently styleable and people still use it a lot. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improving blame in Mercurial
Gregory Szorc schrieb: If you have ideas for making the blame/annotate functionality better, please capture them at https://www.mercurial-scm.org/wiki/BlamePlan or let me know by replying to this message. Your feedback will be used to drive what improvements Mercurial makes. I really liked a lot about the blame implementation that bonsai had, unfortunately we don't have a running copy any more AFAIK so it's hard to take a look at it. For one thing instead of showing author and changeset (or version in CVS) for every line, it grouped subsequent lines changed at once together and showed that information only once for them. For the other, when you moved your mouse over that author/changeset "blame" info, it didn't just show a tooltip but a full-fledged HTML box where e.g. bug numbers in the checkin comments could be linked and you could call up that link (in a new tab probably) right away and directly go to read the bug that changed this code. Those two features would be great to see in hg blame/annotate as well. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Crash signature change: signatures now include abort messages
For one thing, the signature facet is more helpful to look at signatures: Abort&_facets=signature&_columns=date&_columns=signature&_columns=abort_message#facet-signature ;-) Hmm, I'm somewhat nervous about the fact that there is no signature that appears twice in this stage dataset. I think the part in [] is a process ID or something like that, which probably was added later than we made this spec, and which throws off this generation. I think we'll need to adjust this algorithm. Benjamin, what do you think? KaiRo Adrian Gaudebert schrieb: Thanks Benjamin! Here's a search that shows what those new signatures look like on stage: https://crash-stats.allizom.org/search/?product=Firefox&signature=%5EAbort&_facets=abort_message&_columns=date&_columns=signature&_columns=abort_message Please let me know if that seems good or not before we push this change to prod. :) Cheers, Adrian On Thu, Apr 7, 2016 at 3:27 AM, Bobby Holley wrote: On Wed, Apr 6, 2016 at 2:34 PM, Benjamin Smedberg wrote: No, it does not catch MOZ_RELEASE_ASSERT, because that doesn't call NS_DebugBreak and that is what does the AbortMessage annotation[1]. NS_RUNTIMEABORT is the recommended way to reliably crash if you're in XPCOM-y code. That's unfortunate, because according to MXR (and anecdotally) almost everyone uses MOZ_CRASH. ___ Stability mailing list stabil...@mozilla.org https://mail.mozilla.org/listinfo/stability ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Crash signature change: signatures now include abort messages
Sorry, that "look at the signatures" link should have been https://crash-stats.allizom.org/search/?product=Firefox&signature=%5EAbort&_facets=signature&_columns=date&_columns=signature&_columns=abort_message#facet-signature I propose that before we add it to the signature, we remove /^\[.+\] ###!!! ABORT: / from the abort message, I'm putting this in the bug as well, we should discuss the details of what we do in there, I guess. KaiRo Robert Kaiser schrieb: For one thing, the signature facet is more helpful to look at signatures: Abort&_facets=signature&_columns=date&_columns=signature&_columns=abort_message#facet-signature ;-) Hmm, I'm somewhat nervous about the fact that there is no signature that appears twice in this stage dataset. I think the part in [] is a process ID or something like that, which probably was added later than we made this spec, and which throws off this generation. I think we'll need to adjust this algorithm. Benjamin, what do you think? KaiRo Adrian Gaudebert schrieb: Thanks Benjamin! Here's a search that shows what those new signatures look like on stage: https://crash-stats.allizom.org/search/?product=Firefox&signature=%5EAbort&_facets=abort_message&_columns=date&_columns=signature&_columns=abort_message Please let me know if that seems good or not before we push this change to prod. :) Cheers, Adrian On Thu, Apr 7, 2016 at 3:27 AM, Bobby Holley wrote: On Wed, Apr 6, 2016 at 2:34 PM, Benjamin Smedberg wrote: No, it does not catch MOZ_RELEASE_ASSERT, because that doesn't call NS_DebugBreak and that is what does the AbortMessage annotation[1]. NS_RUNTIMEABORT is the recommended way to reliably crash if you're in XPCOM-y code. That's unfortunate, because according to MXR (and anecdotally) almost everyone uses MOZ_CRASH. ___ Stability mailing list stabil...@mozilla.org https://mail.mozilla.org/listinfo/stability ___ Stability mailing list stabil...@mozilla.org https://mail.mozilla.org/listinfo/stability ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Please keep an eye out for new plugin crashes
FWIW, no crashes listed in this query after a week of having this on Nightly. KaiRo Benjamin Smedberg schrieb: In today's nightly I landed a patch in bug 1252152 which will crash a plugin-container process more aggressively if a plugin instance is torn down while its code is on the stack. Please keep an eye out for new plugin crashes that you're seeing. In crash-stats, this should show up with an abort message of "Destroying plugin instance on the stack.". I'll be monitoring this crash-stats search to see if this shows up at all: https://crash-stats.mozilla.com/search/?abort_message=destroying&_facets=signature&_facets=abort_message&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-abort_message --BDS ___ Stability mailing list stabil...@mozilla.org https://mail.mozilla.org/listinfo/stability ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: improving access to telemetry data
Benjamin Smedberg schrieb: Because the raw crash files do not include new metadata fields, this has led to weird engineering practices like shoving interesting metadata into the freeform app notes field, and then parsing that data back out later. I'm worried about perpetuating this kind of behavior, which is hard on the database and leads to very arcane queries in many cases. I agree and ideas on that are coming along slowly but surely, but let's not do the Socorro discussion here, let's stick with Telemetry in this thread. ;-) I agree with bjacob that there should be a few ways of getting public access to data - e.g. he likes the CSV files much better than he would direct DB access, while I'm pretty happy with the latter on Socorro. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: improving access to telemetry data(Help Wanted)
Taras Glek schrieb: I doubt people actually want to build own dashboards. I suspect this is mainly a need because of deficiencies in the current dashboard. I disagree. I think people will want to integrate Telemetry data in dashboards that connect data from different sources, and not just Telemetry. That might be combinations with FHR data, with crash data, or even other things. I for example would love to have stability-related data from all those sources be trimmed down by a dashboard to digestible "this channel looks good/bad" values. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
Jason Smith schrieb: *Ideas for what products we should remove* And how the XXX should users of those products file new bugs then? Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
Anthony Ricaud schrieb: I'd suggest renaming Core here. Web developers don't understand what Core is. They might know Gecko though. Does it make sense to rename Core to Gecko? Probably only if we split off anything that Servo doesn't replace into yet another "Core" product. Yes, Gecko is only part of what's in there. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Replacing gcc 4.5 as the default Linux compiler?
Mike Hommey schrieb: 4.8 is IMHO too young to even consider testing. Though its feature set seems to be quite helpful for us: http://lwn.net/Articles/543570/ Makes me think that we should at least experiment with it to make sure are issues we have with it will be fixed in a .1 or so and we'll be able to use that. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Replacing gcc 4.5 as the default Linux compiler?
Gabriele Svelto schrieb: On 05/04/2013 01:49, Robert Kaiser wrote: Though its feature set seems to be quite helpful for us: http://lwn.net/Articles/543570/ Makes me think that we should at least experiment with it to make sure are issues we have with it will be fixed in a .1 or so and we'll be able to use that. I've got a build of gcc-4.8.0 on Linux along with all the previous major versions which I often use for testing. I'm trying a full build now; is there any specific test that would be worth doing? A full run of the unit tests maybe? Or even some performance testing on a relevant benchmark? I think all of that would be interesting. Not sure how to see results from the Graphite or PRE changes mentioned in that article. Also not sure what the DWARF changes actually mean for us. In terms of perf, what would be interesting would be gcc 4.5 vs. 4.8 with the same options we use to compile Linux Nightly builds. But I'm just guessing there. People like e.g. Mike Hommey probably know more on what would be interesting there. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Forcing alphabetical order in moz.build files
Gregory Szorc schrieb: Theoretically, yes. And I do empathize with the desire to have them alphabetical. As Ms2ger notes, we probably cannot have that for *DIRS, though. I know at least one case where this is crucial, and that's Mac packaging. I added a comment for that a long time ago in SeaMonkey that is now in http://mxr.mozilla.org/comm-central/source/suite/moz.build#32 but the same is true for Firefox and others. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using a pre-processing flag to auto-disable features in later Beta versions
Lukas Blakk schrieb: * Releng automation to switch/edit mozconfigs for earlier betas to check for this flag I think it would be good if we wouldn't have to rely on releng there, as this again introduces the factor of someone possibly forgetting to do this. Ideally this should be fully automated, or at least depend on something obvious that many eyes can check easily (which something buried in several platform-dependent mozconfigs probably isn't). Also, I think that people building themselves from the beta repo (or, say, Linux distros), should ideally get the same feature set that our builds do, so it would be good if this flag was triggered by something in the actual source. Maybe we should have a simple file in the source trigger this flag (just like the simple files with versions trigger RELEASE_BUILD) and have an automated script that checks daily how long it has been since the last uplift and sends an email warning to relman or so if the value of that file doesn't match our expectation. Having someone do a minimal checkin there around the middle of every beta cycle doesn't sound too bad, and the warning would ensure that happens. Also, if we'd miss it, we notice that a beta that should not have "early beta" functionality actually does, and the checkin can be done and will persist for the rest of this train. It would be even better if we could completely automatically detect if some state of the source is "early beta" or not, but I don't know how that would be possible from the source alone. (The current date itself isn't good as a distinction as someone could go back and try to bisect commits and re-build to find a regression, just to be confused, as the regression might have been caused or fixed by turning that flag - another reason why it should be in the source repo.) Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using a pre-processing flag to auto-disable features in later Beta versions
Daniel Holbert schrieb:
Would this mean that Beta-channel users would see some features appear
on release-day, and then disappear a couple weeks later, and then those
same features (plus maybe some new ones) would suddenly reappear on the
next release day, and then potentially disappear again? (etc)
Nothing would be day-wise here. Those things would on for for the first
half of the beta cycle and off for the second (or very similar), so
those users would alternate between the state every few weeks, not on a
daily or even single-weekly basis.
We once said that we wanted roughly 1:10:100:1000 ratios between the
channels, but what we have is roughly 1:1.2:25:1000 when counting only
the most-current versions on every channels (when counting the full
channels I think we're somewhere in the range of 1:2:40:1500 for desktop
- for Android we're something like 1:2:60:1100).
This means in practice that
1) Aurora is way too small to really see the impact of a lot of
problems, e.g. in web compat, as it basically doesn't really have a
wider impact in terms of users/testers than what Nightly has (the
channel is still good for localizing and stabilizing in general, just
not much for getting feedback "from the wild"), and
2) Beta is even too small to see how stability and edge-cases apply to
the general public.
Point 1 leads to what we are discussing here: We need to use the first
few weeks of Beta to get wider-impact testing of our code and some
feedback "from the wild".
Point 2 leads to us needing to stop ("0% throttle") updates on release
after we reach 10-20 million users, review stability and testing data
from the first few days, and often enough do point-releases to fix up
stability issues or regressions (like the recent issues with proxies or
remote profiles).
So, for the short term, I think those two outcomes (early-beta-flag and
throttling) are the right thing to do here as we need to get that
testing in time. For the longer run we IMHO need to think again about
how we can get more people on the Aurora and even Beta channels so that
we can get more of that testing earlier and spare us the complications
in early-beta or even early-release phases.
Robert Kaiser
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Storage in Gecko
Gregory Szorc schrieb: Perhaps this should be advertised more, especially to the add-on community. Looking at about:config of my main profile, about 2/3 of my preferences are user set. There are hundreds of preferences apparently being used for key-value storage by add-ons (not to pick on one, but HTTPS Everywhere has a few hundred prefs). FWIW, we had a pretty high-ranking topcrash in https://bugzilla.mozilla.org/show_bug.cgi?id=836263 where an add-on stored strings up to at least 128MB in prefs, and Nightly now limits prefs to 1MB max, and that add-on switched to indexedDB instead. This should happen more, for sure. I'd think that anything larger than a few KB probably doesn't belong in a pref. We couldn't easily set that limit mentioned above as low as we'd like because up to now we had no limit at all and some add-ons definitely store large stuff in prefs. Given that we probably read prefs in startup and before we can do anything useful with the launched Firefox, I wonder how much of a perf problem those large prefs tend to be, actually. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OS.File and shutdown
Felipe Gomes schrieb: What prompted the question is that I'm working on a conversion from SQLite storage to a JSON file. OS.File.writeAtomic provides a good guarantee of data consistency against crashes etc, and I'm now looking how to guarantee a proper full flush of the data to disk during shutdown. Just make sure you do (lazily but still) also flush that data out to disk every now and then during normal operation. For one thing, people leave Firefox running for hours, days and even weeks and if they run into a crash, they shouldn't lose state over such long periods, and for the other, we want shutdown to be fast and the ideal situation is that you already have written everything when the shutdown request comes and you don't need to care. ;-) Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Storage in Gecko
David Rajchenbach-Teller schrieb: I'd even go as far as limiting it to 16kb. (possibly with a transition phase during which going above 16kb only prints warnings) I think most of us agree, but the problem is that apparently a number of add-ons rely on large prefs atm, so right now we did set to 1MB. Adding a warning for everything over 10KB or 16KB or something and targeting to move the limit down to that at some point would surely be a good idea, and I'd be happy about someone filing a bug and patch about this. For now, the important thing was to prohibit the case that caused crashes, but we surely can do better and reduce that kind of "prefs mis-use" in favor of indexedDB, etc. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
Gavin Sharp schrieb: This has exposed some e10s crashes that previously weren't exposed on desktop. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=899758 to track them - please hang any other such crashes off that bug. If you're working in a component that has e10s-related crashes, please fix them :) Note that all those crashes I have seen so far are actually crashes of the browser process, not "just" a content process, i.e. those crashes take down the whole browser! KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
Mark Hammond schrieb: We ask the docShell to not allow plugins or media So that means that for any page with a video or a big Flash/Java thing on it, I would get a completely wrong thumbnail? That's unfortunate. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
Justin Lebar schrieb: It's a lot better than the page a) playing audio, b) spinning your cpu, or a) pwning you. True. Still, if this is a problem (there /are/ a lot of websites which are just one big flash object), I wonder if we could detect it. Yes, I worry about those pages that are one big Flash object, or about pages which have a video as the centerpiece or such. We also get worse thumbnails than before on pages that are basically just a big login screen when you aren't actually logged in. It's pretty hard to figure out the right thing to do in cases like that, I guess (esp. on the "well, but private info can't be shown" front). Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
Asa Dotzler schrieb: We should evaluate, possibly through telemetry or FHR, how many users are seeing the e10s thumbnails and if that number is high, I think we'll want to change the criteria for when we go to the e10s thumbnails. I saw a bug in a recent triage that said we are (or have been) overwriting thumbnails created before with less useful background thumbnails. That might be just a real bug, though. :) Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nsIDownloadManager replaced by Downloads.jsm
Paolo Amadini schrieb: The Downloads back-end will not call any method of nsIDownloadManagerUI anymore So I cannot implement an alternative download manager any more? Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Detection of unlabeled UTF-8
Zack Weinberg schrieb: It is possible to distinguish UTF-8 from most legacy encodings heuristically with high reliability, and I'd like to suggest that we ought to do so, independent of locale. I would very much agree with doing that. UTF-8 is what is being suggested everywhere as the encoding to go with, and as we should be able to detect it easily enough, we should do it and switch to it when we find it. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting the current release version
Robert Helmer schrieb: Thanks for the shout-out - releases-api exposes the metadata that's only available on ftp.m.o (this is something we need for Socorro so we decided to split this out into it's own service). Ideally this would come from a better source, but FTP is as "official" as we can get at the moment for things like getting the buildid for the latest nightly, that sort of thing. Also note that this only know what builds have been *generated* and not what has been *released* to users, which will only happen after QA signs off those generated builds. If you want what has been released, product-details is the place to go. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Detection of unlabeled UTF-8
Henri Sivonen schrieb: Considering what Aryeh said earlier in this thread, do you have a suggestion how to do that so that > [...] Hmm, do we have to treat the whole document as a consistent charset? Could we instead, if we don't know the charset, look at every rendered-as-text node/attribute in the DOM tree and run some kind of charset detection on it? May be a dumb idea but might avoid the problem on the parsing level. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implementing Pepper since Google is dropping NPAPI for good
Johnathan Nightingale schrieb: Benjamin blogged with what's actually happening: https://blog.mozilla.org/futurereleases/2013/09/24/plugin-activation-in-firefox/ Hmm, I would have expected that to appear on Planet Mozilla Projects, but I don't see it there... Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: HWA and OMTC on Linux
Nicholas Cameron schrieb: Our goal is (basically) to be OMTC everywhere I have been using OMTC on Linux for a while (with both prefs on, actually) and with the exception of https://bugzilla.mozilla.org/show_bug.cgi?id=934250 everything works really fine (but then, I'm on the newest kernel/driver and Xorg versions and am using the open Intel drivers). 3) For nightly users, we initialise X for multiple threads in any case so that e10s works. Ah, so that is the reason why OMTC is now always on for me, no matter if I use the env var or not. That said, I thought we are targeting to get e10s enabled at some point anyhow, so maybe we should just take this hit and be done with it. 4) We do not want (non-nightly) users who do not use OMTC to pay the cost of multi-threaded X. As said above, I wonder if we actually should do that and be done with it. 5) We would love to spend time making OMTC OpenGL on Linux work perfectly, but it is not a priority for the graphics team due to the low number of users. We always hope to get community involvment here, but it has been patchy in the past. Maybe we need to communicate better that we need help there? KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [RFC] Should we persist dynamically generated iframes?
David Rajchenbach-Teller schrieb: Or we could not save dynamic iframes that are not visible. It sounds to me personally like this would be the most sensible option. Do we know what, if anything, would break with this on the real web? Do we have any e.g. telemetry data for how often those are used at all (i.e. worst case of how much could be broken)? Or on what "important" sites this is used in a way that would have a user-recognizable impact there? Also, do we know what the strategy of other browsers' session restore functionality is there? KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How to reduce the time m-i is closed?
Nicholas Nethercote schrieb: It also assumes that we can backout stuff to fix the problem; we tried that to some extent with the first OOM closure -- it is the standard response to test failure, of course -- but it didn't work. Yes, in the case of those OOM issues that caused this closure, they are probably just a symptom of a larger problem. We've been having a step-by-step rise of OOM issues over quite some time now, most intensely seen as an increase of crashes with empty dumps. I alerted to that in bug 837835 but we couldn't track down a decent regression range (we mostly know in which 6-week cycle we had regressions, we can do some assumptions to narrow things a bit further down on trunk, but not nearly well enough to get to candidate checkins). Because of that, this has been lingering without any real tries to fix things, and from what I saw in data, things did even get worse recently - and that's talking of the release channel, so whatever might have increased troubles on trunk around this closure is even on top of that. As in a lot of cases we're seeing, there's apparently too little memory available for Windows to even create a minidump, we have pretty little info about those issues - but we do have our additional annotations we send along with the crash report, and those gives us some info that AFAIK gives us the assumption that in many cases we're running out of virtual memory space but not necessarily of physical memory. As I'm told, that can for example happen with VM fragmentation as well as bugs causing a mapping of the same physical page over and over into virtual memory. We're not sure if that's all on our code or if system code or (graphics?) driver code exposes issues to us there. From what I know, bsmedberg and dmajor are looking into those issues more closely, both now that we had the tree closure problem and also because it has been a lingering stability issue for months. I'm sure any help in those efforts is appreciated as those are tough issues, and it might be multiple problems that all contribute a share to the overall issue. Making us more efficient on memory sounds like a worthwhile goal overall anyhow (even though the bullet of running out of VM space can be dodged by switching to Win64 and/or e10s giving us multiple processes that all have their 32bit virtual memory space, but not sure if those should or will be our primary solutions). I think in other cases, where a clear cause to the tree-closing issues is easy to assess, a backout-based process can work better, but with those OOM issues there's not a clear patch or patch set to point to. IMHO, we should work on the overall issue cluster of OOM, though. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How to reduce the time m-i is closed?
Philip Chee schrieb: I thought that there was a plan to pre-allocate on startup some memory for the minidump/crash reporter? For one thing, I'm not sure how far that went, for the other, we are calling a Windows function to generate the minidump and I'm not sure if we can reserve the memory it needs reasonably beforehand. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reacting more strongly to low-memory situations in Firefox 25
Benjamin Smedberg schrieb: On 11/25/13 8:15 PM, Bas Schouten wrote: I'm a little confused, when I force OOM my firefox build on 64-bit windows it -definitely- goes down before it reaches more than 3GB of working set. Am I missing something here? I think so. I did not mention working set at all. I am merely calculating whether users are running win64 or win32, based on whether they have 4G of total VM size (win64) or 2G/3G (win32). Wouldn't a Win64 Nightly get more than 4G VM size? KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reacting more strongly to low-memory situations in Firefox 25
Jeff Gilbert schrieb: A 64-bit build would, but we "don't ship" those. A win64 machine running a 32-bit program can have 4GB of VM, though. OK, just wanted to make sure. Benjamin looked at 25.0 release data, AFAIK, so that's of course only 32bit, but if we look at Nightly data, I think a significant part of those users is actually on the 64bit Nightlies we provide, so we could get some limited comparison out of that limited data. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [RFC] Cleaning up sessionstore.js
David Rajchenbach-Teller schrieb: As part of bug 943352 & followup, we are considering automatically cleanup some of the contents of sessionstore.js. Just for my understanding (I have commented to users with huge, e.g. ~100MB sessionstore.js in bugs as well), I thought we were working on a rewrite of session store anyhow that would not kepp info of all tabs in one file? I think I have heard that we'd need to do this because of e10s anyhow at some point, and that it also would help our startup if we didn't need to load all session store data for all tabs at once but could do it per tab when they are actually restored/loaded. Now I fully agree with trying to not store things we probably should not keep anyhow, I just wonder if it might make sense to take into account where session store is going. Of course, I might be completely mistaken with what I thought I heard there, so please correct me if I'm wrong. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Plug-in feature not available in the web platform. Alternatives?
fma spew schrieb: Summarizing. 1) WebCrypto does not initially plan support for making end-user certificates available. 2) Our use case, currently implemented as a NPAPI plug-in, needs Mozilla to continue supporting NPAPI until WebCrypto makes end-user certficates available. You forgot: 3) Mozilla doesn't plan to abandon NPAPI any time soon, in fact Benkamin Smedberg, who is in charge of the engineering around plugins and therefore around NPAPI, said "for desktop Firefox, NPAPI is likely to be around for the predictable future (three years?)" - even if it will be behind a click-to-activate mechanism (that also allows users to activate a specific plugin for the long run). You're well-advised to try and move as much of your code away from NPAPI as possible, but NPAPI is not in danger of going away for you in desktop Firefox. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On closing old bugs
Lawrence Mandel schrieb: I would assert that if a bug hasn't been fixed in 10 years it probably isn't important enough to spend time on now. You see what kind of reactions that brings up? ;-) I have tried something like that years ago in the SeaMonkey project, and after a lot of discussion went to mass-move all non-enhancement bugs from before the current SeaMonkey project was started to a RESOLVED status (EXPIRED was available to mass-changes back then, so I used that). This was followed by quite some stir-up even though it had been discussed extensively on the SeaMonkey lists, and it surely did cost me a lot of time to deal with - but the vast majority of those bugs stayed closed. If its net worth was positive probably depends on your point of view. The question really is how disturbing a ton of open bugs are in our work. If we see them as some kind of Kanban cards in our agile process on the lowest level (which is something that feels somewhat fitting to me), then they surely clog up the "not started" column quite a bit unless you filter them out in some way, I understand that. If you apply a filter in some form, they disappear in the sea of "not up for consideration" bugs that aren't up on the board. Then the question becomes of how easy or hard it is to find those in the sea that are worth to go up on the board, and how much work it is worth to reduce the overall size of that sea to make that easier. Out of my experience described above, I'm still not sure of that myself, but maybe it gives you one point of reference in the thought process. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?
Tetsuharu OHZEKI schrieb: I propose that we should disable "autoplay" feature of HTMLMediaElement on mobile. I personally have not yet seen any arguments that would really apply for making things different between mobile and desktop in your discussion, and I think we should not make functionality different between form factors or products when there is no good reason to make them different. IMHO, what's named "Firefox" should work the same everywhere unless there is a really good reason why a different variant should behave differently (and there surely are often good reasons, but I haven't noticed those in this discussion yet - nobody says I won't often use my laptop in public or my mobile devices in private). That said, I think we should think about how we can enable more user control of such features. If I open media tabs in the background, I probably don't want them to autoplay at all. And then, there are situations on all my devices where I may want autoplay and situations where I may not. How could we give the user control over autoplay in an intuitive and easy way? Is there a good way to do that on mobile form factors as well? KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should we disable "autoplay" feature of HTMLMediaElement on mobile?
Henri Sivonen schrieb: If autoplay is disabled by default, Web authors will take counter-measures and start playback from JavaScript. However, if autoplay is honored by default but the user can turn in off as a pref, it could be that Web authors won't bother to take counter-measures. It probably should be a visual pref somewhere, but I agree that the default should be to enable autoplay on foreground tabs. On background tabs, I think all media should be click-to-play by default though, if possible - both for not needlessly waste power (which might be just as precious on a laptop than a mobile device, the lines are blurry anyhow) and for not surprising people (or making multiple tbas that one opens in the background all run autostarted media elements at the same time, creating a big jumble on the speakers). KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Toolkit sub-module Preferred Reviewers who are not Toolkit Peers
Dave Townsend schrieb: Ideally you would have talked to the Toolkit module owner (i.e. me) before adding a new chunk of code to it but Toolkit has basically become the wild-west of modules and I'm not sure what purpose an owner is meant to have at this point. The Submodule page is probably hopelessly out of date at this point and I don't know if trying to save it is the right thing to do. Given that toolkit is pretty central to Firefox (as well as Thunderbird and SeaMonkey, probably also XULRunner-based applications), your post makes me pretty scared as a member of the module ownership group. What should we do there? KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Tagging legitimate main thread I/O
Brian Smith schrieb: David's explanation is mostly correct for Firefox (but see below). However, for Thunderbird that warning occurs because Thunderbird is blocking the main thread waiting for network I/O (and disk I/O). Thunderbird should be fixed so that it stops doing network I/O on the main thread. Then this warning will go away. MailNews (in Thunderbird and SeaMonkey) does a lot of main-thread stuff, I/O and otherwise, that it should not do, from what I see/feel when using it. I fear though that there are too little resources to work on this and fix it, that project is a bit understaffed, both in terms of paid and volunteer developers. That said, I'm sure they're happy about contributions! Even after insanity::pkix lands Hrm, doesn't "insanity" sound a bit strange and possibly untrustworthy for a security-related thing? KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [e10s] Changes to the browser.tabs.remote preference in desktop Firefox
Bill McCloskey schrieb: I just wanted to make a quick announcement about preference changes for out-of-process tabs. Bug 960783, which landed recently, added a "New OOP Window" menu option to open a new window with out-of-process tabs. Right now this option is only enabled on Macs because it requires OMTC, but it will move to other platforms as they get OMTC. It's also restricted to nightly. Hrm, we just recently added an annotation to crashes that states if the e10s pref is on or not, sounds like you just completely obsoleted this. Has the annotation be changed so we can still determine if a crash of the main process happened with e10s involved? KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New necko cache?
Jason Duell schrieb: Is there something specific you're wondering about? Neil is the code module owner for SeaMonkey, I guess that might be where he's coming from with the question - he probably wants to make sure it still works in the future... ;-) KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Including Adobe CMaps
Boris Zbarsky schrieb: On 2/26/14 3:58 PM, Wesley Hardman wrote: Personally, I would prefer to have it already available. We have several deployment targets with different tradeoffs. Broadly speaking: Phones: expensive data, limited storage. Want to not use up the storage, so download lazily. Esp. on phones I would expect to have *very* expensive and slow download (as many Firefox OS users do from what I'm told) so it's actually there that I would say we cannot download in most cases, esp. as we want installed apps to work the same on all devices. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Too many system compartments at start-up
Nicholas Nethercote schrieb: Hi, At start-up, with a new profile, Firefox creates more than 230 system compartments. This is about 90 more than a year ago, and it's part of the reason why Firefox uses almost twice as much physical memory at start-up than it did two years ago. Hrm, reading your list sounds like the main culprits are modules and also bindings that all get their own compartment. I somewhat hazily seem to remember that we had an issue like that on FxOS as well and some kind of hack to merge modules into a single compartment was done, and the real solution being called out back then as doing "zones" or something where all those system things wouldn't get actual separate compartments? Did that not work out? It sounds bad that using modules and bindings would have a large overhead. :( KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Spring cleaning: Reducing Number & Footprint of HG Repos
Taras Glek schrieb: *User Repos* TLDR: I would like to make user repos read-only by April 30th. When that happens, I will stop running any custom crash reports and dashboards that the stability program depends on, at least until further notice. I do not want to run a non-Mozilla-hosted repo for Mozilla work stuff. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Desktop QA: Bugzilla tags/keywords
The Firefox desktop team is heavily relying on bugs being marked in some way to know if we need to verify them or perform some other action on them. For that, our QA drivers for example triage the bugs fixed in every development cycle and mark them "verifyme" or [qa-]. I've also seen [qa+] float around, and nowadays the whiteboard tags are even sometimes in the normal whiteboard and sometimes in the newly created QA whiteboard field. For bugs we need to investigate, the "qawanted" keyword is also in use to get our attention. I wonder if it's really a good idea to have this mixed bag of whiteboards and keywords floating around or if we should consolidate that, for example to using keywords for everything ([qa-] could be replaced by a new "noverify" or similar keyword). I think the Bugzilla DB is better at queries for keywords than whiteboard tags, as keywords are structured, also it's harder to mistype them, so I personally prefer them over whiteboard tags for cases like this. What's your opinion on that? (Please post discussion items on dev-quality, I'll post to the other lists as well when we reach a conclusion.) Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Recommendations on source control and code review
Karl Tomlinson schrieb: Joshua Cranmer 🐧. writes: On 4/13/2014 4:42 PM, Robert O'Callahan wrote: Honestly, I think we're already pretty close to most of those recommendations, most of the time. Some experienced Mozillians are breaking up their large changes well, but some are not. And many less experienced contributors are learning. That's a good step. IMHO, often another good step is to mostly separate every patch to its own bug (I know there are cases where it might not makes sense, but often it does) so that individual chunks can be accounted for separately in reviews, checkins, work-done reports, maybe even verifications. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Oculus VR support & somehwat-non-free code in the tree
Rob Manson schrieb: I know I'm lobbing in from the sidelines on what is essentially a licensing debate internal to Mozilla...but wouldn't any VR implementation like Vlad described be best done as an extension of existing open web standards where possible. Excellent points, I really think that should be discussed! [...] we just use the open source oculus-bridge app [...] Does that maybe already have the code we need, and even on an openly licensed form? But once you guys have finished your licensing discussion I think it would also be great to have the discussion about using/extending existing open web standards rather than re-inventing some just for VR. That sounds like a very good proposal. Not sure in which list that is best discussed. Here? dev-webapi? KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Oculus VR support & somehwat-non-free code in the tree
Benoit Jacob schrieb: In this respect, more innovation is not necessarily better, and in fact, the cost of innovating in the wrong direction could be particularly high for the Web compared to other platforms. But innovation is part of our mission (yes, the very short statement of it that must guide everything we're doing). So is openness, though. So we have a case here where two of those part of the core mission seem to be in conflict. IMHO, we cannot sacrifice any part of the mission even in the name of another one of them. They need to go together. That said, we should push all of them as far as we can without sacrificing the others. In this case, it sounds to me like we are talking about very little code, and any API we create should also be mostly agnostic of the specific implementation. I think trying to get re-licensing first and if that doesn't work, going for an alternative, actually open implementation is probably the way to go here. That said, I absolutely think we should be a player in this field, and probably in others that concern innovation on the Web (IoT anyone?). KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WebGL 2.0
Dan Glastonbury schrieb: /Summary/: Bring more power of GPU to browsers by exposing OpenGL ES 3 features in WebGL 2.0 We currently have (almost) no documentation on MDN for WebGL 1, do we intend to put concerted work into docs along with bringing up WebGL 2? KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Time to revive the "require SSE2" discussion
When you want to whole stability group to get a message, please send to stability@m.o ;-) That said, IMHO, the API, esp. the "SuperSearch" part of it, should be just as good or even better than the CSV stuff you're doing, as you should be able to more directly get a lot of what you need out of there. AFAIK you were pointed to that for B2G stuff already anyhow (as the CSVs only contain Firefox and Firefox for Android). KaiRo Benoit Jacob schrieb: Wonderful, thanks Matthew! @Stability-team: ^^^ see the value of public crashdata CSV files in action! Thanks! Benoit 2014-05-08 20:42 GMT-04:00 : On Tuesday, January 3, 2012 4:37:53 PM UTC-8, Benoit Jacob wrote: 2012/1/3 Jeff Muizelaar : On 2012-01-03, at 2:01 PM, Benoit Jacob wrote: 2012/1/2 Robert Kaiser : Jean-Marc Desperrier schrieb: According to https://bugzilla.mozilla.org/show_bug.cgi?id=594160#c6 , the Raw Dump tab on crash-stats.mozilla.com shows the needed information, you need to sort out from the info on the second line CPU maker, family, model, and stepping information whether SSE2 is there or not (With a little search, I can find that info again, bug 593117 gives a formula that's correct for most of the cases). https://crash-analysis.mozilla.com/crash_analysis/ holds *-pub-crashdata.csv.gz files that have that info from all Firefox desktop/mobile crashes on a given day, you should be able to analyze that for this info - with a bias, of course, as it's only people having crashes that you see there. No idea if the less biased telemetry samples have that info as well. On yesterday's crash data, assuming that AuthenticAMD\ family\ [1-6][^0-9] is the proper way to identify these old AMD CPUs (I didn't check that very well), I get these results: The measurement I have used in the past was: CPUs have sse2 if: if vendor == AuthenticAMD and family >= 15 if vendor == GenuineIntel and family >= 15 or (family == 6 and (model == 9 or model > 11)) if vendor == CentaurHauls and family >= 6 and model >= 10 Thanks. AMD and Intel CPUs amount to 296362 crashes: bjacob@cahouette:~$ egrep AuthenticAMD\|GenuineIntel 20120102-pub-crashdata.csv | wc -l 296362 Counting SSE2-capable CPUs: bjacob@cahouette:~$ egrep GenuineIntel\ family\ 1[5-9] 20120102-pub-crashdata.csv | wc -l 58490 bjacob@cahouette:~$ egrep GenuineIntel\ family\ [2-9][0-9] 20120102-pub-crashdata.csv | wc -l 0 bjacob@cahouette:~$ egrep GenuineIntel\ family\ 6\ model\ 9 20120102-pub-crashdata.csv | wc -l 792 bjacob@cahouette:~$ egrep GenuineIntel\ family\ 6\ model\ 1[2-9] 20120102-pub-crashdata.csv | wc -l 52473 bjacob@cahouette:~$ egrep GenuineIntel\ family\ 6\ model\ [2-9][0-9] 20120102-pub-crashdata.csv | wc -l 103655 bjacob@cahouette:~$ egrep AuthenticAMD\ family\ 1[5-9] 20120102-pub-crashdata.csv | wc -l 59463 bjacob@cahouette:~$ egrep AuthenticAMD\ family\ [2-9][0-9] 20120102-pub-crashdata.csv | wc -l 8120 Total SSE2 capable CPUs: 58490 + 792 + 52473 + 103655 + 59463 + 8120 = 282993 1 - 282993 / 296362 = 0.045 So the proportion of non-SSE2-capable CPUs among crash reports is 4.5 %. Just for the record, I coded this analysis up here: https://gist.github.com/matthew-brett/9cb5274f7451a3eb8fc0 SSE2 apparently now at about one percent: 20120102-pub-crashdata.csv.gz: 4.53 20120401-pub-crashdata.csv.gz: 4.24 20120701-pub-crashdata.csv.gz: 2.77 20121001-pub-crashdata.csv.gz: 2.83 20130101-pub-crashdata.csv.gz: 2.66 20130401-pub-crashdata.csv.gz: 2.59 20130701-pub-crashdata.csv.gz: 2.20 20131001-pub-crashdata.csv.gz: 1.92 20140101-pub-crashdata.csv.gz: 1.86 20140401-pub-crashdata.csv.gz: 1.12 Cheers, Matthew ___ 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: Google announces Chrome builds for Win64
jmor...@mozilla.com schrieb: Launching 64 bit first may be a stability bandaid for users who have 64 bit and adequate memory. I would want to see decently founded comparative stats from a wide variety of systems before claiming that. bsmedberg and others have done some analysis that looks to me like our OOM crashes (which are the largest group of stability issues nowadays) are pretty split between cases where we run out of physical memory and where we run out of VM space. Now, 64bit gives us more VM space but probably also uses more physical memory, so we could run out of physical memory even faster, even though we should not run out of VM space. Also, given that every process has its own VM space, e10s will help the VM space issues anyhow, so I wonder how much impact on stability we'll have with 64bit anyhow after that. It's also security boost for 64 bit users. Could someone please explain why you and Google claim 64bit to be more secure? This is a new argument to me and I wonder what's behind it. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
New crash signatures for out-of-memory crashes: "OOM | ..."
Benjamin Smedberg schrieb: The known-large crashes will have a signature of "OOM | Large | ". The engineering action for these crashes should typically be to make the call site use a fallible allocator instead of an infallible allocator. Crashkill will track and file the most common versions of these as part of crashkill. I filed (or reworded existing bugs) for those that had 100 or more crashes with such a signature yesterday in Firefox 30. Here's a list: https://bugzilla.mozilla.org/buglist.cgi?short_desc=Large%20OOM%20in&short_desc_type=substring&resolution=--- I hope we can tackle those for future releases! :) Also, in case you see some "OOM | unknown" with CrashAtUnhandleableOOM in there, don't file them at this point, the JS team is working on getting the size annotation in place in https://bugzilla.mozilla.org/show_bug.cgi?id=1026545 KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
What are the most important new APIs to document in Q3/Q4?
Benoit Jacob schrieb: Not expressing any opinion on whether WebGL should be prioritized, but recently I had to teach some WebGL and, not being fully satisfied with existing tutorials, I made a code-only "tutorial" made of 12 increasingly involved WebGL examples, http://bjacob.github.io/webgl-tutorial/ and I would be happy to work a bit with someone to turn it into proper documentation. Awesome, and it doesn't use any magic external matrix library like our current tutorial does. ;-) That said, IMHO, we should at least / also have a reference of all JS functions on the GL context (shader language probably would go too far), when I did my work on getting a not-so-complicated WebGL project up, I had to turn to MSDN for the reference... Oh, and webglcontextlost/webglcontextrestored should probably be mentioned as anyone doing a longer-running WebGL-using web app might run into this and wonder why their GL stuff went away. But I'm getting too far for this thread. Suffice to say, I think WebGL should be in the set, not surprising as I filed https://bugzilla.mozilla.org/show_bug.cgi?id=986498 ;-) I also think that Service Workers should be a priority to have ASAP as people are longing to replace appCache but this replacement will be distinctively more complex (and can do way more exiting stuff), so we should have good docs on "what to do if you 'just' want a well-working local cache for your app files" (with example code) and other use prime cases of Service Workers. For Web Activities, I wonder how fast those might come to the wider web, but for FxOS they're tremendously important. One area we may want to dig into doc-wise is Web Components, but I'm not sure when we will be supporting those natively. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rethinking the crash experience
David Rajchenbach-Teller schrieb: 5. Upon the next restart, display a bottom doorhanger on all windows "Firefox or an add-on encountered a problem [a few seconds ago / on July 4rd, 2014] and recovered. If you wish, Firefox can report it automatically so that we can fix the bug ." This would probably eliminate most comments we get on crash reports. Even if a good number of those are not helpful now, a significant part of them is, I don't want to lose that part. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rethinking the crash experience
Justin Dolske schrieb: 3) E10S will already need something vaguely like this That's a completely different subject, esp. as we already have an in-content crash reporter UI for plugin crashes. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rethinking the crash experience
Tobias Besemer schrieb: Sorry, maybe a little bit OT ... ;-) Would it be possible to report back to Mozilla "hanging scripts" ??? I'd love to have something reporting fatal JS error and hanging scripts but that would be something pretty different from what the current crash reporter does as the current stuff is dependent on a minidump from binary code. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rethinking the crash experience
Most probably would not type a comment when they're not immediately prompted for it. We could do an experiment around it, but I'd be surprised if anything else comes out of it. I for myself probably wouldn't type a comment myself in >90% of the cases when that was required, and I know how helpful those comments can be. KaiRo David Rajchenbach-Teller schrieb: Interesting point. What's the profile of users who write comments on crash reports? Would they click on a button "add comments"? On 08/07/14 21:33, Honza Bambas wrote: This would probably eliminate most comments we get on crash reports. Even if a good number of those are not helpful now, a significant part of them is, I don't want to lose that part. +1 KaiRo ___ 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: Continued support for ESR
Lukas Blakk schrieb: * plan a marketing push around the existence of ESR (update docs, revamp the org web page, promote the channel externally) Let's please make sure we stay clear in that we do not want end users on this channel and do not give any direct support to them but any support for those releases goes through the enterprise list and the people who do the mass deployments. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to autocomplete code affecting Thunderbird
Paolo Amadini schrieb: On 8/30/2014 2:18 PM, Philip Chee wrote: SeaMonkey uses Form History: http://hg.mozilla.org/mozilla-central/rev/f69c9019e0b0 Thanks for the reference! I'll keep in mind that these Form History interfaces are used by SeaMonkey as well. I think that any application doing web form will probably use them. Isn't Fennec using them as well? KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
Jonathan Kew schrieb: But the model for webfonts is explicitly *not* to have a single URL that may be delivered in any of several formats, but rather to offer several distinct resources with different URLs, and let the browser decide which of them to request. So the "negotiation" is handled within the browser Right. And if I remember correctly, we also just invented the element for HTML5 to do the same for images as it's actually *better* in many regards to the dilemma we have with all the Accept: negotiation. Or am I wrong there? KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Breakdown of Firefox full installer
Mike Hommey schrieb: Note a significant amount of the omni.ja and browser/omni.ja data is used for jsloader/jssubloader data: 4744949 and 1560499 bytes from those files are that. These jsloader/jssubloader data are there for startup benefits on Firefox first run (if the data wasn't there, it would be generated on the first run and stored in the user profile). This was added a while ago, and we've been wondering if the js parser speed had been improved enough for those to now be useless for a while. It seems to me there's a lot to gain in download size from stripping those if we can confirm they are not helping in a significant way anymore. Who wants to check? Also, if we can't get decent startup without them, why do we need to download those pieces and not generate them with the installer in some fashion? KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Breakdown of Firefox full installer
Mike Hommey schrieb: The only way to generate them is to run firefox. Well, there are other ways, but I don't think adding parts of the js engine and gecko to the installer is really a great idea. Could the installer run the Firefox binary in some mode that would just generate those files and then exit? KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: e10s is now enabled by default for Nightly!
Marco Bonardo schrieb: I'm forcing myself to use it for everyday work, but I completely dropped forceRTL and Flash (I must admit I'm not missing it) to make it usable. The Flash/Plugins stuff *should* have been fixed, but probably needs testing. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: multipart/x-mixed-replace images will soon be restricted to MJPEG
Seth Fowler schrieb: On Dec 17, 2014, at 10:08 PM, James May wrote: * Is there telemetry for this? There isn’t telemetry specifically for non-MJPEG usage of multipart/x-mixed-replace images. Given that I’ve never seen them used outside of our test suite, I don’t think we need telemetry to make this particular decision, although generally it’s a good idea. Letting the change ride the trains, and making sure that it’s easy to back out if a problem is found, should suffice. IMHO, "I haven't seen" is a weak argument. When we remove features that are exposed to the web in some form, it's always a good idea to gather some telemetry first so that we know what the actual impact will probably be (there is some bias to the Telemetry audience already, of course). Let's see that we have data instead of assumptions and do not run into surprises. People have been known to do crazy things in some corners of the web. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: multipart/x-mixed-replace images will soon be restricted to MJPEG
L. David Baron schrieb: On Friday 2015-01-02 14:23 +0100, Robert Kaiser wrote: Seth Fowler schrieb: On Dec 17, 2014, at 10:08 PM, James May wrote: * Is there telemetry for this? There isn’t telemetry specifically for non-MJPEG usage of multipart/x-mixed-replace images. Given that I’ve never seen them used outside of our test suite, I don’t think we need telemetry to make this particular decision, although generally it’s a good idea. Letting the change ride the trains, and making sure that it’s easy to back out if a problem is found, should suffice. IMHO, "I haven't seen" is a weak argument. When we remove features that are exposed to the web in some form, it's always a good idea to gather some telemetry first so that we know what the actual impact will probably be (there is some bias to the Telemetry audience already, of course). Let's see that we have data instead of assumptions and do not run into surprises. People have been known to do crazy things in some corners of the web. I don't think that' necessary for features that aren't supported across other browser engines, which I believe is the case here. We have been burned by removing Gecko-only features in JS land, that's why even that reasoning is dangerous in general. For this specific case everything might be fine, I don't dispute that, but we shouldn't do removals of web-exposed features without good data in general. Can we at least have a very small telemetry probe along with this specific removal (can be removed in the next train again), so we can get at least some data from beta users if there are cases encountered of those features we remove? I'd have guessed we all, including Seth, would be happier if we have data confirmation of us doing the right thing here. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Permission UI
Anne van Kesteren schrieb: I'd like to ask that we start investigating how to best present these to the user, including their persistence and implications. Note that one idea that I had about 5 years back is implemented by default in SeaMonkey as "Data Manager" and available as a Firefox add-on under https://addons.mozilla.org/en-US/firefox/addon/data-manager/ (code is available at https://hg.mozilla.org/users/kairo_kairo.at/dataman/ at the moment). While this approach might not be perfect and I haven't had time or energy to do any maintenance on the code, it's there and one idea on how a rather powerful management UI can be done. That said, it might be overwhelming for a normal user (and it has some bugs as well as room for improvement). KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Ship: 3rd Party Install Tracking
Mark Finkle schrieb: and maybe we should use it for the FHR persistent ID since it's the same across installs and profile-resets I think it's a *very* bad idea privacy-wise to use the same ID across different data collection services as that opens up all the scary cross-system-user-tracking scenarios that we warn people of in other cases. Out of that same reason, I think everything that wants a per-install-ID should have a separate one that is independent of any other per-install-ID for any other data collection mechanism. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
Boris Zbarsky schrieb: On 4/14/15 3:28 AM, Anne van Kesteren wrote: On Tue, Apr 14, 2015 at 4:10 AM, Karl Dubost wrote: 1. You do not need to register a domain name to have a Web site (IP address) Name one site you visit regularly that doesn't have a domain name. My router's configuration UI. Here "regularly" is probably once a month or so. And even then, you can get certificates for public IP addresses. It's not a public IP address. We do need a solution for this space, which I expect includes the various embedded devices people are bringing up; I expect those are behind firewalls more often than on the publicly routable internet. Definitely. Right now, esp. those router configs and similar web interfaces to devices are in a very bad state - either they run unencrypted (most of them) or they can only go with self-signed certs with mostly-bogus domain descriptors, which is pretty bad as well, or the user needs to create a cert and install it into the device, which is too much hassle for the vast majority of people. Are there any good proposals on how to make those decently secure and keep them easy to use? KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
vic schrieb: I would view this proposal favorably if 1) you didn't try to force people to adopt the One True Way and 2) the CA situation was fixed. Please define of what alternatives to what you call the "One True Way" are acceptable to you and still secure to access, and also what specific issues with the CA system you would want/need to see fixed. It's hard to discuss improvements when you are low on specifics. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
northrupthebandg...@gmail.com schrieb: That whole article is just additional shovelfuls of bovine manure slopped onto the existing heap. Please refrain from language like that in lists like this if you want to be taken seriously. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
Yoav Weiss schrieb: IMO, limiting new features to HTTPS only, when there's no real security reason behind it will only end up limiting feature adoption. It directly "punishing" developers and adds friction to using new features, but only influence business in a very indirect manner. That's my concern as well, I think we need to think very hard about what reasons people have to still not use TLS and how we can help them to do so. Let's Encrypt will be one step easing the solution to one class of reasons, but there's more. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
northrupthebandg...@gmail.com schrieb: On Monday, April 13, 2015 at 8:26:59 PM UTC-7, ipar...@gmail.com wrote: * Less scary warnings about self-signed certificates (i.e. treat HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do with HTTPS+selfsigned now); the fact that self-signed HTTPS is treated as less secure than HTTP is - to put this as politely and gently as possible - a pile of bovine manure I am against this. Both are insecure and should be treated as such. How is your browser supposed to know that gmail.com is intended to serve a self-signed cert? It's not, and it cannot possibly know it in the general case. Thus it must be treated as insecure. Except that one is encrypted, and the other is not. *By logical measure*, the one that is encrypted but unauthenticated is more secure than the one that is neither encrypted nor authenticated, and the fact that virtually every HTTPS-supporting browser assumes the precise opposite is mind-boggling. Right, the transport is encrypted, but it's completely unverified that you are accessing the actual machine you wanted to reach (i.e. there is no domain verification, which is what you need a 3rd-party system for, the CA system being the usual one in the TLS/web realm). You could just as much be connected to a MitM with that encrypted transport. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP
Karl Dubost schrieb: Henri, great points, about… Le 14 avr. 2015 à 19:29, Henri Sivonen a écrit : Currently, the UI designation for http is neutral while the UI designation for mixed content is undesirable. I think we should make the UI designation of plain http undesirable once x% the sites that users encounter on a daily basis are https. What about changing the color of the grey world icon for http into something which is more telling. An icon that would mean "eavesdropping possible". but yes UI should be part of the work. I believe we could think about potentially starting with only marking HTTP that contains any script as insecure. There's much less danger of evesdropping or other stuff on completely static HTML+CSS that doesn't contain any scripts or iframes or somesuch. Of course, we'd need to get some data to find out if completely static/passive sites vs. those with scripts etc. make any significant difference in terms of how many sites are affected. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
Bobby Holley schrieb: On Tue, Apr 21, 2015 at 3:32 PM, Nick Fitzgerald wrote: And this can surely be done via private channels, without public shaming and the potential negatives people have listed elsewhere in the thread, right? How, exactly?I want the ability to see where I match up against my peers. Names are important here, and anonymization does a disservice to my interpretation of the data. Seeing names on try score of people I know are doing similar kinds of work is very helpful to gauge my relative usage. Also, this data is already public as the whole pushlog is. IMHO it would be against all standards of the Mozilla project to create summaries of public data and then hide those. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Tiles Design Questions (was Re: Improving trust and transparency for Suggested Tiles)
Martin Thomson schrieb: On Thu, Apr 23, 2015 at 12:33 PM, wrote: Do you have suggestions on where each of the 4 topics I posted should be discussed? In a meeting, where a small number of participants are well-prepared. So you mean in a place where Mozilla's greatest asset, our community, is excluded? I for one disagree with that sentiment. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Voting in BMO
Philipp Kewisch schrieb: I could live without this feature if the number of people on CC gives some indication of how wanted a feature may be. Well, I tend to CC myself to thing I seriously do not want to change but really want to be informed about when they actually get done. I wouldn't use votes for that. ;-) KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Voting in BMO
Mark Côté schrieb: * Change bug tagging to something like "favouriting" (or a word with less contentious spelling ;). Rework the UI to provide an obvious way to both favourite a bug and to see your favourites list. I actually think that "tagging" is an established way to call such a feature, but we could have a "like" or "want" tag or so that's easy to add, and the whole tagging UI needs a whole lot of rework (it's really cumbersome to use - and I am using it quite a bit). KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New requirement for tier 1 platforms: working assertion stacks
Ehsan Akhgari schrieb: Is someone signing up to do the work to keep the working on all tier 1 platforms now? I know it's not a platform, but does JIT conflict with this? Ion JIT stack are not walkable in any way that the stackwalker understands... (Actually, I do not know of any way to even detect if a crash is in the Ion JIT - in Baseline JIT, stacks are walkable by frame pointers and the first frame that actually make sense is something like "EnterBaseline" which ends up as the crash signature). KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Collecting web platform features implementation status
Ehsan Akhgari schrieb: I think we need to have a way to signal that we are not going to implement a specific feature in addition to those categories (without delving into the specific example here, but yes this is one of those features.) That sends a useful signal to other browser vendors and web developers. I know that for us, it would be hugely helpful to know if vendor X is actively planning to not implement a certain feature when weighing the pros and cons of working on something. I can imagine the same would be useful for other vendors, and it would be nice if we did that. I agree, but I think we should have a wording that says something like "opposed to implementation" or similar and not "we will not implement", as we have seen in the past that things we didn't want to be implemented (that way) did actually pick up steam elsewhere and we ended up still implementing it - both for things that are not in line with our philosophy of the web, like EME, and for things where we had competing proposals (which we thought were the better way to go), like WebAudio. KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Porting B2G to a HTC Desire HD
doomsplayer schrieb: I'm also seeking a way to port FirefoxOS to my Galaxy Nexus AFAIK there's instructions on how to compile B2G for the Galaxy Nexus up on MDC. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Verification Culture
Jason Smith schrieb: Note - I still think it's useful for a QA driver to look through a set of bugs fixed for a certain Firefox release, it's just the process would be re-purposed for flagging a bug for needing more extensive testing for X purpose (e.g. web compatibility). I think QA should do some exploratory testing of major new features as time allows, but just verifying existing test cases that often are running automatically anyhow isn't a good use of time, I guess. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Increase in mozilla-inbound bustage due to people not using Try
Gregory Szorc schrieb: On 8/15/12 11:10 PM, Mike Hommey wrote: What is interesting is that the corresponding times are in the order of seconds on linux and osx. We're just hitting the fact that windows sucks at I/O. That is an over-generalization. I/O on Windows itself does not suck. I/O on Windows sucks when you are using the POSIX APIs instead of the Win32 ones. From all I heard so far, the truth is in the middle of your and Mike's position. I/O on Windows sucks, but it sucks even more when you are using POSIX APIs on top of it. An interesting data point is that the Wine team found out that running tests involving file/disk I/O are significantly slower on native Windows than on Wine-on-Linux on the same hardware. This implies that Windows I/O really sucks already by itself (and I know from my own experience how painful it is even with native Windows applications to delete larger trees, even more so when they are VMs, which we have eliminated from out build pools nowadays, though). Emulating POSIX upon that already slow I/O makes it even worse, though. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed policy change: reusability of tests by other browsers
Chris Hofmann schrieb: Yeah, this is not for the other browser vendors or users, but is mostly a benefit for web developers that want to count on certain behaviors to work across browsers effectively and reliably every release of every browser. And as web developers write websites for users, this is for users. And as we want to serve the web and users, it's a benefit for us. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: LinuxGL widget backend for Mozilla
Ehsan Akhgari schrieb: I suggest that the best place to develop this would be on mozilla-central, especially since most of the work involved would probably not be part of the build of any Tier 1 platform. I agree on the m-c part, but given that a lot of the Linux world is looking at maybe getting rid of X completely and using Wayland as the main graphics output base layer, and Wayland being all about OpenGL, some of this work may even have tier-1 impact in the longer run. :) Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moving Away from Makefile's
Gregory Szorc schrieb: We could go the route of GYP and shoehorn conditionals into a static document (JSON) [3]. JSON is a good format for data for the most part, but IMHO we *really* want comments in those files, and unfortunately JSON doesn't have those and therefore probably must be thrown out of the equation. :( Actually, I know a format that allows everything we need: Makefile! :p Seriously, this is hard, and needing to parse even more files to build doesn't sound faster and cleaner, but rather slower and more complex, esp. given that basic file I/O is often costly (from watching my CPU usage, a lot of the build time is spent in I/O wait when using spinning disks - SSDs improve that hugely). Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: STR Needed Keyword?
Andre Klapper schrieb: * needURLs (used once so far, maybe pretty new?) We're removed that one from the bug when we paste in URLs from crash stats, so that's why it's always only on very few or no bugs. * crashreportid I wonder why we have that at all, never saw it actually being used - and I work in the stability group. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moving Away from Makefile's
Gregory Szorc schrieb: * "if" is "ifneq (,$(foo))" or even "ifneq (,$(strip $(foo)))" in case some extra whitespace snuck in there. One thing that was hoped we could achieve with pymake was to possibly switch to it everywhere at some time and then be able to replace those ugly conditionals with just python ones. We definitely should go for nicer conditionals with all this. :) Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Adding hardware tokens to UA string
Mike Hommey schrieb: On Tue, Sep 18, 2012 at 01:17:16PM +0300, Henri Sivonen wrote: (Remember Web sites in the 1990s that blocked access from browsers that the authors hadn't tested. Those were not cool.) Such sites still exist, and they still aren't cool. Right, just nowadays Firefox is usually tested browser that they let in. Once you browser without the "Firefox" token in a UA string (e.g. try using SeaMonkey with the "pretend to be Firefox" pref turned off), you see that those practices are still around. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Adding hardware tokens to UA string
Jonas Sicking schrieb: For Firefox OS, we are getting requests from partners to add tokens to the UA string which identify the hardware device on which Firefox OS is running. I think using the UA is surely the wrong place for this. If we allow the models that want to be achieved with this at all (and there are good arguments in this thread against it), I think this should be something exposed from the navigator object in JS only (e.g. navigator.manufacturer=ZTE, navigator.vendor=Vivo, navigator.devicename=foobar or similar). Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: UA Override List Policy
Gervase Markham schrieb: Does this strike the right balance? I think it does. This looks like a good way to go forward for me. And yes, IMGO, we can have very short timeouts on #2 for sites we already know about, and esp. in the time before we finish up the first release and are still able to remove a pref before actually shipping. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Flash Player freezes XULRunner
James Newell schrieb: Am I right to assume from https://bugzilla.mozilla.org/show_bug.cgi?id=778858 that the OOP setting is enabled by default now? I manually added the setting from the previously mentioned bug just in case and saw no change in behaviour. I didn't even see the plugin container process get created. Maybe it is crashing out before that? We might actually not be allowing for Flash to run at all when it's not OOP, maybe that's the problem. Adobe has not testing in-process Flash at all for quite some time, and we recently made some changes that should force it always to be OOP in Firefox, those might not interact well with XULRunner not setting OOP to be on by default (disclaimer: that's my guess, I don't know the actual code). Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XULRunner on OS X, Why is not supported?
richardson.balca...@gmail.com schrieb: I believe my question is, if Mozilla is taking out their app development platform not 'XUL' per se. How would they promote "openness, innovation and opportunity on the web", only by giving us the opportunity of doing so in extensions on a browser? What's the strategy? Is not clear where is this going? XUL was always only a transitional technology as the project discovered in 1998 that what they would really want to do, using HTML as the technology to build UI, was not there yet. Nowadays we are getting closer and closer to being there, and developing Firefox OS and the needed APIs for all kinds of apps there is one further step on this way. We sincerely hope that HTML and friends can obsolete XUL in the next few years. If you try to use our technology for a new project today, I'd urge you to try to get as far as possible with HTML, and try to work with us to bring those pieces to HTML stack that it cannot do today but XUL can. Not everything will be feasible in the same way on the web, but we want web apps to become as powerful as native apps in the long run. And in the mean time, you can use XULRunner underneath your HTML app and fill in the gaps with XUL/XPCOM technology, until we're able to fill them with HTML and actual web APIs. Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Not shipping prefixed APIs on the release channel
Joe Drew schrieb: On 2012-11-06 8:31 AM, Henri Sivonen wrote: Therefore, I propose that we adopt the following policy: 1) APIs that are not ready for use by Web developers shall not be shipped on the release channel (unless preffed off). 2) APIs that are shipped on the release channel shall be shipped without a prefix. I am broadly in support of this, but I have a specific concern: Firefox OS will (or could) require experimental APIs that aren't fully baked simply because of time constraints. I don't think we should hamstring the features possible in FxOS to simply stabilize an API. I would, however, be in favour of the result of s/release channel/release channel on desktop/g. I think we should have a pref that just turns on/off all the prefixed technologies, and ship with that on in the experimental channels and off on release (I'd say that beta is up for discussion, I'd lean towards off on beta as we treat beta as RC and want testing there to match release as much as possible so we don't get surprises when shipping). This way, we can just ship B2G with that pref on as long as we require that (I hope it will get stable enough at some point so we can apply the same principles we're using elsewhere). Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
