Steps to reproduce problem: 1. Start a debug build 2. Turn off keyword.enabled 3. Try to load :// Actual result: ###!!! ASSERTION: buffer incorrectly sized: 'a.Length() == headLen', file nsTSubstringTuple.cpp, line 78 What's happening here is that nsDefaultURIFixup strips off the bogus :// and attempts to prefix http:// in its place. It does this using uriString.Assign(NS_LITERAL_CSTRING("http://") + uriString); We create a substring tuple from "http://" and [R]uriString, and decide that [L]uriString doesn't depend on it, so that we can write to it in place. So we adjust [L]uriString's length, and then try to copy [R]uriString and "http://". Of course since [L]uriString and [R]uriString are the same thing, we've just changed [R]uriString's length which is why we get confused as to what to copy.
We actually copy "http://" to uriString, and then uriString to uriString.
Created attachment 362914 [details] [diff] [review] Somewhat contrived test case This test fails with our current code.
Created attachment 362917 [details] [diff] [review] Confident patch Passes the test :-)
Pushed changeset 6c0ff682551d to mozilla-central. Actually I pushed it yesterday. See bug 478732 for the gory details.
would we not want this on the 1.9.2 branch if it's good for the 1.9.1 branch?
It landed before 1.9.2 branched.
Comment on attachment 362917 [details] [diff] [review] Confident patch a=beltzner for 184.108.40.206
Pushed changeset 9a06693cdbb4 to releases/mozilla-1.9.1