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.
o 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&am
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
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
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
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.
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
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
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)
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
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
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
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
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
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
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
Martin Thomson schrieb:
On Thu, Apr 23, 2015 at 12:33 PM, e...@mozilla.com 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
Bobby Holley schrieb:
On Tue, Apr 21, 2015 at 3:32 PM, Nick Fitzgerald nfitzger...@mozilla.com
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
Karl Dubost schrieb:
Henri,
great points, about…
Le 14 avr. 2015 à 19:29, Henri Sivonen hsivo...@hsivonen.fi 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
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
___
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
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
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 kdub...@mozilla.com 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
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
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
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
Seth Fowler schrieb:
On Dec 17, 2014, at 10:08 PM, James May m...@fowlsmurf.net 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
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 m...@fowlsmurf.net wrote:
* Is there telemetry for this?
There isn’t telemetry specifically for non-MJPEG usage of
multipart/x-mixed-replace images
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
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
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
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
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
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
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 report/not this
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
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
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,
Benjamin Smedberg schrieb:
The known-large crashes will have a signature of OOM | Large |
C++Signature. 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
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
GMT-04:00 matthew.br...@gmail.com:
On Tuesday, January 3, 2012 4:37:53 PM UTC-8, Benoit Jacob wrote:
2012/1/3 Jeff Muizelaar jmuizel...@mozilla.com:
On 2012-01-03, at 2:01 PM, Benoit Jacob wrote:
2012/1/2 Robert Kaiser ka...@kairo.at:
Jean-Marc Desperrier schrieb
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
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
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
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
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
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
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,
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
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
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
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
)
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
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
(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
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
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,
, 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
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
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
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
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
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
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
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
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
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
Philip Chee schrieb:
Doesn't SQLite come with its own set of issues? I vaguely remember the
urlclassifier code moving from SQLite to something else because of
performance issues.
Always depends on what you are using it for, just like any technology.
Robert Kaiser
Robert Relyea schrieb:
Switching to SQLite would make this a non-issue.
Is there a plan to do this? An open bug? Someone working on it?
Robert Kaiser
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo
.
If we wouldn't have caught that problem with applying proper sr, our
problem lies deeper, of course.
Robert Kaiser
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
.
Robert Kaiser
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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
Firefox work well with
the parallelization it brings.
Robert Kaiser
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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
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
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
- 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
, 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
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
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
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
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
95 matches
Mail list logo
