Bug 560975

Regenerated the patch

ok, let's play safe and only do this for WebGl.

still need to know what's your graphics card! If it's Intel and doesn't have GL drivers on Windows, then your issue is a dupe of the fact that we need to use ANGLE in your case (known issue).

This patch relaxes them so we only block when the feature is really blocked or not available.

indeed our feature tests were too strict in that "not recommended" ended up blocking.

Either, "webgl not recommended" status must not disabled webgl, or at least some recent graphic cards must have "webgl available" status.

Every Intel card as been declared as "Webgl not recommended", so webgl is not enabled.

It seems to be linked to bug 594874 fix.

What is the graphics card in the machine that can't run WebGL demos?

Perhaps this is hardware related?

I tested this on my HP TouchSmart tx2 laptop which runs Windows 7 and that machine loads the sites such as https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/demos/google/particles/index.html fine.

Seen while running Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; rv:2.0b3) Gecko/20100805 Firefox/4.0b3. I tried in 32 bit mode and the same thing happens. STR: 1. Enable WebGL with the about:config pref 2. Load the site in the URL, or one of the demos from http://www.ambiera.com/copperlicht/demos.html Expected: it would work as it does using Windows XP and Vista using the same build Actual: I get an error saying that "This demo requires a WebGL-enabled browser" I have seen Bug 560975 and I do not have those prefs set in about:config since I am using a new profile.

ASSIGNED → RESOLVED

It doesn't look like nsIUserCertPicker is used anymore, so the interface and its implementation can be removed. As far as I can tell, that's the only user of nsICertPickDialogs, so I think the interface, its implementation, and associated xul/js/l10n strings/etc. can also be removed.

It doesn't look like nsIUserCertPicker is used anymore, so the interface and its implementation can be removed. As far as I can tell, that's the only user of nsICertPickDialogs, so I think the interface, its implementation, and associated xul/js/l10n strings/etc. can also be removed.

Remove nsIUserCertPicker, nsICertPickDialogs and associated code from mozilla-central.

Alternatively, if someone working on c-c code would like to reimplement the code in a cleaner fashion (the current code suffers from basically the same issues as the client auth code as pointed out in Bug 307081), then I can wait for that work to finish first.

I will look into moving this code to c-c, but if that fails, I will just remove the code from m-c.

Maybe we can move it to c-c and remove it from m-c.

Unfortunately this might still be in use in c-c

It's not, and it is essential for configuring S/MIME signing or encryption

Pushed: http://hg.mozilla.org/mozilla-central/rev/b8664f450508

Not a useful killswitch since MathML has shipped for some time now.

http://hg.mozilla.org/mozilla-central/rev/da5a3ef843f8

This patch adds label() to handle this.

insBranch() can return NULL if a conditional branch is optimized so that its condition never succeeds. jstracer.cpp doesn't account for this, it just calls branch->setTarget(label). This hasn't mattered up until now, but with bug 600127 doing a better job of optimizing guard/branch conditions, it does matter.

Testcases have been landed by virtue of being marked in-testsuite+ -> VERIFIED as well.

http://hg.mozilla.org/tracemonkey/rev/9ce0b72525ba

Slow push thisv on CALLXMLNAME checks to make sure we're not pushing a call object onto the stack, sets |this| to NULL.

(function() { function::a(eval("false"), true); function a({}) {} })() asserts js debug shell on JM changeset 89b775191b9d without -m nor -j at Assertion failure: IsSaneThisObject(vp[1].toObject()), at ../jsinterp.cpp:4734

Don't reset other axis' scroll position during APZ drag. r=kats

These are the changes asked for in your previous review. They got pushed to try but they got lost somewhere along the way.

I recall applying all these changes but perhaps they never got qref into the final patch.

I don't think this patch fixes anything that would cause a crash, those were fixed in the first patch.

BTW, you know you can get gcc to generate these warnings without such hackery, right?

This fixes all of the -Wformat-extra-args warnings and all of the -Wformat-security warnings except the ones in fsmcnf.c and fsmdef.c which are caused by the format parameter being the return of another function (get_debug_string). I chose not to address those since that would entail getting replacing all of the get_debug_string calls with literals.

reopening since this is [leave-open]

This should fix all of the -Wformat warnings, but not the -Wformat-extra-args or -Wformat-security ones.

I'm going to take this bug and start with a patch that resolves the -Wformat warnings. After that we can tackle the -Wformat-security and -Wformat-extra-args

I would propose that the first step is to run debugging all the way up to 9, run a text call, and then fix the first message that causes a segfault. Repeat as necessary.

Looking at this list I see a bunch that could cause crashes in the future.

Compiling the SIPCC code with log macros expanded directly to printf() yields approximately 300 formatting-related warnings. Most of these are benign, but some could be problematic. This bug represents an audit task to examine and fix (or suppress) these warnings.

I don't suppose we can rip out the protection around resolve hooks now, can we?

Looks great. The new code is a little longer but the strange loops in the old code were far from obvious.

Object and Function initialization are intricately intertwined. To initialize Object, you need Function to be initialized for the function properties on Object.prototype and Object. But to initialize Function, you need Object.prototype for Function.prototype's [[Prototype]]! Since the two are so intricately interdependent, their bootstrapping should be one-off and not use functionality that thinks that these things have already been bootstrapped -- they should do it from scratch.

Update linux64-qr test jobs on central and integration branches. r=dustin,catlee

Based on an estimated 23h of additional test load per push, about 3200 pushes on inbound/autoland per month = 73,600h. We pay about $0.02/hr, so that's about an extra $1500 per month, which is fine.

r? to dustin for the actual config file changes, r? to catlee for the fact that this will increase load on AWS and that we're ok with doing this. I talked with Milan about this yesterday and he said to flag you for review on this.

Lately we've had a number of cases where after a merge from m-c to graphics we end up with permafail or high-frequency intermittent failures on QR tests. These take time to bisect and is not a reliable process because of the potential intermittency. Avoid this is one reason I want to start running the QR reftests on autoland/inbound and make them tier-1, so that anything that regresses them gets detected earlier and backed out. Also eventually we're going to want this anyway because we'd like to stop working on the graphics branch and move to working directly on central. Turning on the tests on central/integration branches is a necessary prerequisite for this. The downside to doing this, of course, is we'll need more machine time. Right now all we want to enable are linux64 tests which I hear is the cheapest to scale up. If we can use SETA to further reduce the number of times it runs that's fine by me, as long as the sheriffs have the ability to backfill and bisect as needed.

This does not happen for 1 week. https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1347860&startday=2017-03-13&endday=2017-03-24&tree=all Bug 1347836 should already fix this bug.

Bug 1347836 handled this issue and has already landed into m-c few hours ago, let's seek if Bug 1347836 solves this crash.

It might be better to return already_AddRefed<>.

Image is locked only within GetCurrentImage().

It seems like a regression of Bug 1345403.

From the source, returned pointer of HTMLMediaElement::GetCurrentImage() seems not safe.

From the source, returned pointer of HTMLMediaElement::GetCurrentImage() seems not safe.

I kicked off a build and it succeeded.

Download gtk3 for periodic update script

Set the env for periodic file update jobs.

Here's the job output from these changes running in dry-run mode (-n) in staging. The script returns 2 in dry-run mode if there are updates which is why it's marked as failed.

We inherit the env so we can make use of TOOLTOOL_CACHE.

xpcshell requires gtk3 now, so we download it via tooltool and then set the LD_LIBRARY_PATH.

I mucked around with this on a dev slave and managed to get it working. Since we only need xpcshell and not a fully functional browser context, I was able to download the gtk3 tarball via tooltool and then get the periodic_update script working by setting the LD_LIBRARY_PATH.

Any ideas who might be able to assist in getting this security process unbroken?

Well, it's probably going to be me.

The environment running this job obviously doesn't have gtk3 installed.

Looks like GTK3 fallout? http://people.mozilla.org/~coop/hsts_failures/central-failure-july25.log INFO: Generating new HSTS preload list... INFO: Running "LD_LIBRARY_PATH=. ./xpcshell /builds/slave/m-cen-l64-periodicupdate-00000/getHSTSPreloadList.js /builds/slave/m-cen-l64-periodicupdate-00000/" ./xpcshell: error while loading shared libraries: libcairo-gobject.so.2: cannot open shared object file: No such file or directory

need more work on Windows

unsigned long and uint32_t are interchangeable

Why did you drop <uint32_t>?

Add the types for nameSetters and make the code more robust.