On Wed, May 25, 2016 at 9:45 PM, Nicholas Nethercote
wrote:
> On Wed, May 25, 2016 at 6:58 AM, Lawrence Mandel wrote:
>> "Crashes are caused by defects"
>>
>> Reading this I think it implies defects in Firefox. This is not always the
>> case. Crashes are also the result of interactions with third
About:
> Additionally it would be great to see information on handling OOMs (large
> and small) as those are our top crashers, and if anything I think project
> uptime should be focusing on mitigating them. Fixing null derefs for a few
> hundred users is nice, but fixing OOMs for tens of thousands
Here is a selection of docs that we've written over the years. Many are
incomplete.
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Crash_reporting
https://developer.mozilla.org/en-US/docs/Crash_Data_Analysis
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_a_minidump
There's some information I've learned about reading crash reports, which is
obvious now but wasn't when I was an intern many years ago, that isn't
really covered by these.
Here's my workflow when looking at crashes:
- Windows tells you if the exception occurred during a write or read. Look
at the
Awesome. Using the VisualStudio project file makes me significantly more
productive, so I recommend everyone on Windows use it for debugging, learning
about, and editing code.
The experience is significantly better if you install the Visual Assist plugin
by Whole Tomato Software:
http://www.who
What will the behaviour be for users on unsupported MacOSX versions?
It sounds like existing users won't get updated to a non-supported version.
What about users to try to install Firefox on an unsupported MacOS version?
Will the installer show some sort of notification/dialog box saying that th
Users won't get updated to an unsupported version and they will be notified
that their system is no longer supported. The notification includes an url
to a page for additional information.
I'm not familiar with the Mac installer but since it is just a dmg I don't
know if there is much that can be
By design, dmg's don't do anything. There's no installer, just a
container with the executable ready to run. Nils reported in the other
thread that we just crash at launch time on 10.6, which is
unfortunate. I'd hoped Apple would show a 'not supported on this
version' dialog. We could including a w
A google search on restricting the Mac version produced
LSMinimumSystemVersion and I found the following:
http://mxr.mozilla.org/mozilla-central/source/browser/app/macbuild/Contents/Info.plist.in#208
I don't have a Mac so I can't check what the behavior is.
Robert
On Thu, May 26, 2016 at 3:02 P
Existing users should not be upgraded.
The Mozilla website will use UA versions to redirect users on these
versions to a SUMO page.
If a user does end up downloading and attempting to the DMG, the minimum
version is set in the app bundle and MacOS will show a warning saying that
this application
On Thursday 2016-05-26 15:21 -0700, Robert Strong wrote:
> A google search on restricting the Mac version produced
> LSMinimumSystemVersion and I found the following:
>
> http://mxr.mozilla.org/mozilla-central/source/browser/app/macbuild/Contents/Info.plist.in#208
>
> I don't have a Mac so I can'
On Tue, May 24, 2016 at 11:22 PM, Wei-Cheng Pan wrote:
> This is great!
>
> Just few questions:
>
> Can we debug firefox in the IDE during mochitest?
>
> i.e.: ./mach mochitest --debugger=devenv
>
I think we'll need some magic in the mach commands to make this work the
way you want it to. Please
[CC mobile-firefox-dev and dev-fxos for notes below.]
Bug 1246743 (Mac libc++ support) and bug 1273934 (Android libc++
support for local development builds) have landed on mozilla-central.
This change means that all of our Tier-1 platforms now have a
more-or-less conformant C++11 standard library.
On Thu, May 26, 2016 at 09:50:56PM -0400, Nathan Froyd wrote:
> This change also means that any non-Tier-1 platforms (FxOS, for
> instance) that don't provide a C++11 standard library will probably
> break in very short order as various code is removed from the tree.
When do we actively remove sup
On 05/14/2016 06:58 AM, Philip Chee wrote:
> Given the "two different implementations rule" is there any suitable
> alternative to ICU? I mean besides rolling our own.
No, or at least not something cross-platform. It's probably possible to do
something using Windows APIs, that would only be ship
*Summary*: HTMLMediaElement::seekToNextFrame() is an experimental feature
which enables JS developers to access video frames one-by-one without going
through the real-time playback. Internally, this feature could could be
used to writ media tests.
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?i
On Fri, May 27, 2016 at 12:49 PM, Tzu-Hao Kuo wrote:
>
> *Preference behind which this will be implemented*: media.seekToNextFrame
>
I guess it'd be better to call it "media.seekToNextFrame.enabled".
- Xidorn
___
dev-platform mailing list
dev-platform
On Thu, May 26, 2016 at 3:37 PM, L. David Baron wrote:
> There's a screenshot in:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1255588#c8 (and #c9)
> (which is the bug that made the necessary changes for the Mac OS X
> support change in Firefox 49).
Ah, that's great. Thanks!
-r
_
18 matches
Mail list logo
