The whack-a-mole between bug 655878 and bug 604196 was the result of a lot of confusing logic in XPCWrappedNative argument conversion. I think I've got enough of a handle on things to fix bug 655878, but I'd like to make all this code simpler and more understandable while I'm at it.
*Cracks Knuckles*

r=mrbkap on the final two patches as well.
One concern that I have is that we're removing more micro-optimizations here and we don't really know how important they are. We're going to probably want to keep a close eye on chrome performance and make sure that none of these optimizations are still being used on hot paths in the DOM.

(In reply to Ms2ger from comment #7)
> https://github.com/bholley/mozilla-central/commit/
> 7d912f7b7b3e9eaf67e5cae0eb31adb3d444542c
>
> +// XPIDL decides which types to make dippers. The list of these types
> +// is given in the DIPPER_TYPE() macro in xpidl.h, and is currently
> +// limited to 4 string types.
>
> Shouldn't this point to typelib.py?
Indeed. Updated to reflect that.

For some reason this is burning on Maemo. The error says "extra ";"". The code in question is a NS_GENERIC_FACTORY_CONSTRUCTOR that has a trailing ;. None of the other instances of this have the trailing ;, so I'm going to try removing it, pushing to try, and see what happens.

The failure in question here was actually the final issue I was sorting out on this stuff. Thought to be solved, but clearly not! ;-) It was previously appearing on all try platforms (though never locally until I replicated the precise environment with which buildbot runs the test suite). I investigated it, figured out the issue, and (with khuey's help) came up with a patch:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9eb6dc0ea6b2
This patch made sense, worked in local testing, and fixed the problem on all of the platforms that completed the try run. Windows didn't complete for some reason, but I maintain that it was reasonable to assume that the problem, platform-neutral as it was previously, would be fixed there too. Poor luck, but not poor judgement. ;-)
The Maemo thing was certainly my fault. I didn't see it - my bad. I'll certainly watch out for it in the future. :-)
> since bholley's 23-changeset push> a whopping 23 changesets> a=use-try-before-crapping-23-changesets-on-the-tree-thank-you-please
Why so much negativity here? This kind of work is routinely squashed into a single patch, to the detriment of reviewer sanity, regression finding, and useful history. We know how to back out multiple changesets without resorting to O(n) techniques (Ehsan has a blog post about this). So the vitriol seems a bit uncalled for IMHO.
Regardless, we now have a bit of a problem. The open web apps team needs this stuff landed before the branch, and I don't have time this weekend to spin up a windows VM and figure out what's going on. But reality, the failure in question is in the test code (the build system for the test code, even!). This is of course stuff that should land with the refactor. But we know from running these tests on the different platforms that the refactor is fundamentally sound. So, assuming there are no objections, I don't think there's too much harm in landing the refactor minus the test code, and sorting out the test code after the branch.
So I rebased the refactor off directly onto master: https://github.com/bholley/mozilla-central/tree/refactor-notests
and pushed it to try: https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=c33f04e55afe
I'll let it do its full thing overnight. I'm not going to be at my computer until tomorrow evening, but anyone else who wants them sooner (ie, fabrice) is welcome to land the changes too. I'm attaching the exact patch set to the bug. If all goes well, just hg qimport *, hg qpush -a, hg qfinish -a, and hg push!

(In reply to Bobby Holley (:bholley) from comment #15)
> Why so much negativity here?
I'm sorry. I was tired and unduly vented the products of a bad day in your direction. I should not have done this, as it was not productive, nor fair on you. Thank you for the clarification of the try situation + the reality check :-)

(In reply to Ed Morley [:edmorley] from comment #17)
> I'm sorry. I was tired and unduly vented the products of a bad day in your
> direction. I should not have done this, as it was not productive, nor fair
> on you. Thank you for the clarification of the try situation + the reality
> check :-)
No worries. I really appreciate all the work you do sheriffing the tree, and I know that stuff can get pretty hectic sometimes. :-)
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #18)
> The line at
> http://mxr.mozilla.org/mozilla-central/source/xpcom/components/
> nsComponentManager.cpp#770 is failing. Looks like we can't handle
> "interfaces ../foo.xpt" on windows.
Oh, awesome! Thanks for looking into that. I've updated the patch to just symlink the xpt file into both directories: https://github.com/bholley/mozilla-central/commits/xpcwn_refactor
I pushed this whole thing to try again here: https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=8c30ddd8b511
Once it (all!) goes green, the whole set (including the tests) should be good to land. I can do that this evening, but in the mean time I'm attaching the patchset that can be pushed by anyone who wants to. Just follow the instructions in comment 15.
/me heads off for the day

Hm, 12 hours later and the Windows results still haven't come in. Anyone have any ideas?
Ed - what do you think about the rest of the results - are there any other failures showing up there that I should look into?

Ok, so according to the self-serve api it doesn't look like the windows tests results are coming. I kicked the above submission to build again, just in case.
This makes twice in a row where I don't get windows test results on try, but everyone else seems to. My hypothesis is that they might be miscategorized as talos rather than unit tests, meaning my '-t none' kills them somehow. So I tried a trychooser set that does everything for windows:
https://tbpl.mozilla.org/?tree=Try&rev=892f7daeab71

(In reply to Bobby Holley (:bholley) from comment #23)
> Ed - what do you think about the rest of the results - are there any other
> failures showing up there that I should look into?
The gesture is appreciated - though after my grumpiness the other day I probably don't deserve it ;-)
The windows tests have finally shown up on the original try run (presumably from the 3rd rebuild request) and look fine to me, but it's strange they hadn't twice in a row. The new try run suffered the same fate as well.
A skim of recent try pushes on TBPL shows that the windows tests seems to be triggering fine for almost all the other pushes, though I did find one other (https://tbpl.mozilla.org/?tree=Try&rev=a13f81776b22), maybe you've just been unlucky!
Either way, don't see any reason why this shouldn't land :-)
I'll ask on #build/file a bug about the win tests not being triggered.

This caused a significant perf regression on the N900s (>50% on Tp4), and we've had no android perf data for several days ... if we can't get confirmation that this didn't regress android before we branch I think this has to bounce from 9.

(In reply to Matt Brubeck (:mbrubeck) from comment #33)
> The performance regression blamed on this bug was detected on N900. There
> was no gap in the N900 data; the regression clearly took place in this
> changeset range:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=fecae145d884&tochange=f08484868187
Well, then I'm blameless, no? That was my first attempt to land, and it includes Ed's backout of my changes.

(In reply to Bobby Holley (:bholley) from comment #34)
> Well, then I'm blameless, no? That was my first attempt to land, and it
> includes Ed's backout of my changes.
Yes, you're right of course. I'll post to mozilla.dev.tree-management to start finding the real regression.