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]
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]
a=beltzner for 220.127.116.11
Pushed changeset 9a06693cdbb4 to releases/mozilla-1.9.1