User Agent: Mozilla/5.0 (X11; Linux i686; rv:23.0) Gecko/20130510 Firefox/23.0 Build ID: 20130510094137 Steps to reproduce: Go to http://test-ipv6.com/ on an ipv6 connection Let it run the tests Actual results: Gave the info/warning IPv6 Connections using DNS work; but literal IP addresses in urls do not. These are rarely used on the web today. Basically http://[2001:470:1:18::114]/ip/?callback=_jqjsp fails to load in nightly. I check it in a clean profile, it gave the same error. Expected results: The above test should have passed. It works fine in the stable build.

Steps: 1. Open http://test-ipv6.com/ 2. Let the test run 3. Click the Test Run 4. Test IPv6 without DNS fails

This is broken on Android as well so All platforms are affected.

Last good nightly: 2013-05-04 First bad nightly: 2013-05-05 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=69008b1fd6eb&tochange=c8e47b184aba CC'ing the Zbarsky's as it seems that their changes may have caused this.

It's possible, but my first guess based on that pushlog would be bug 861117, actually, since that's doing various hand-processing of URI strings... Can someone who can reproduce this check whether backing that patch out helps? I don't hae an ipv6 setup, sadly. :(

bz: that bug's patch just removed an assertion and changed it to an NS_ENSURE_SUCCESS... doesn't change anything with URIs, so I'm not sure how that would break the URI parsing. Are you thinking of another bug? Or are you thinking it might be deeper in HSTS?

If it is of any value: Point me to download URLs for a series of builds for Mac, and I'll see if I can find where it goes from "working" to "not". (I'm not sure if you have an archive of the daily trunk builds or not..)

Unfortunately I'm not able to reproduce this bug. Boris, do you think you could push a build to tryserver with bug 861117 backed out so the people who can reproduce this can test?

I can take care of that.

Jason, we do have archives of daily builds; the link in comment 3 pins things down to a single day. Since this happened recently, we also have per-push builds for that time range, though. If you're willing to download and try some, take a look at <http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-macosx64/>. The dates are a bit wacky (as in, these files got copied in later or something), but I _think_ that 1367608154/ should be before the problem appeared and that 1367682106/ should be after. That's 30-some builds in between, which should ideally actually be in push order, so you should be able to do a binary search on them.

(In reply to Kevin Brosnan [:kbrosnan] from comment #8) > I can take care of that. Thanks!

Win32, Linux64, OSX 64, and Android builds requested at https://tbpl.mozilla.org/?tree=Try&rev=384a973f24ac

Boris, thanks for the help in comment #7. I've tested the Mac builds; and can confirm that things *did* work, and *did* break. GOOD: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-macosx64/1367617664/ BAD: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-macosx64/1367617849/ According to firebug, the query for http://[2001:470:1:18::114]:80/ip/?callback=? never even happened. Just doesn't show up in the "Network" tab of firebug. Nothing in the console, either. I was hoping to see an error message. In fact, if I open a new window (with the about:home page shown); and go put the http://[2001:470:1:18::114]:80/ip/?callback=? address in the bar and hit enter, the about:home page comes back up. The URL field is just blank. Hope this helps..

Backout worked. Sid is on the hook for causing this.

That also matches the pushlog from the builds Jason tested, which is http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=bfe5c0296c3b&tochange=000ed86d069f Sid, I assume that the IPv6 cases used to trigger that assert and now we just fail them altogether or something.

We should really have ipv6 tests...

Sid can you get this backout landed on central and nominated for Aurora uplift today so we can unthrottle the first Aurora 23 updates tomorrow to go out without this bug?

[Approval Request Comment] Bug caused by (feature/regressing bug #): bug 861117 caused this bug User impact if declined: breakage of loading URLs that have IPV6 literals Testing completed (on m-c, etc.): landed backout on m-c Risk to taking this patch (and alternatives if risky): risk is minimal, potentially malformed URIs may interact with STS in a funny way (but not likely at all) String or IDL/UUID changes made by this patch: none Lukas: what kind of commit message should I use on this backout?

See if the patch for bug 633001 fixes this.

Now that we've backed out the patch in 861117, do you mean we should see if this problem goes away without that backout and after applying 633001?

(In reply to Sid Stamm [:geekboy or :sstamm] from comment #19) > Now that we've backed out the patch in 861117, do you mean we should see if > this problem goes away without that backout and after applying 633001? Yes, exactly.

Broken: http://hg.mozilla.org/mozilla-central/rev/b30552dbb013 Works: http://hg.mozilla.org/mozilla-central/rev/630974b4fa14 + bug 633001 Both commits don't contain the backout, so it looks like the patch for bug 633001 fixes the issue.

I'm happy to test (dual stack) a mac tinderbox build if someone points me a specific build.

I have no mac environment. Please test. without the patch: https://tbpl.mozilla.org/?tree=Try&rev=f83301ecc4d2 with the patch: https://tbpl.mozilla.org/?tree=Try&rev=2c18ff5a2942

Here are built files. without the patch: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/VYV03354@nifty.ne.jp-f83301ecc4d2/try-macosx64/ with the patch: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/VYV03354@nifty.ne.jp-2c18ff5a2942/try-macosx64/

Masatoshi-san, without the patch: fails the IPv6 literal connection test. with the patch: succeeds in the IPv6 literal connection test.

Thank you. So we can backout the backout once bug 633001 has been fixed.

Comment on attachment 750647 [details] [diff] [review] backout bug 861117 Approving for uplift to Aurora so we don't ship broken ipv6 for a wider audience. Sid, I don't see why this public bug summary can't be the commit comment "Backout of bug 861117 to resolve bug 871560 Firefox nightly doesn't connect to IPv6 literal". This will need to land on central as well, you can re-land later when bug 633001 is fixed.

Already backed out on m-c. https://hg.mozilla.org/mozilla-central/rev/55e790d0ff02

Looking good on today's nightly + ydays's as well.

This has been noted in the Aurora 23 release notes: http://www.mozilla.org/en-US/firefox/23.0a2/auroranotes/ If you would like to make any changes or have questions/concerns please contact me directly.

Will remove from known issues in auroranotes.

Anshu, can you please check tomorrow's Aurora build?

sure, will do.

fell off my radar. Confirming that it works well since the fix in nightly.

Anshu, can you please also test with the latest Aurora[1] and the latest Beta[2]? 1. http://aurora.mozilla.org 2. http://beta.mozilla.org

Weirdly I ran into a different issue when trying to use aurora and beta on fedora 19 64 bit. Nightly and UX Nightly work fine in the same environment. [anshup@aero Downloads]$ ./firefox24/firefox XPCOMGlueLoad error for file /home/anshup/Downloads/firefox24/libxul.so: libdbus-glib-1.so.2: cannot open shared object file: No such file or directory Couldn't load XPCOM. [anshup@aero Downloads]$ ./firefox230b9/firefox XPCOMGlueLoad error for file /home/anshup/Downloads/firefox230b9/libxul.so: libdbus-glib-1.so.2: cannot open shared object file: No such file or directory Couldn't load XPCOM. Should I file a separate bug for these?

went back and realised that aurora build is 32 bit. Where is the 64 bit build for that? Same for beta I guess?

Ignore the last two comments :! Got 64 bit builds from ftp and confirmed this is working fine in both beta (23.0b9) and aurora (24.0a2) fine.

Verified fixed based on comment 39.

(In reply to Brian Smith (:briansmith, :bsmith; NEEDINFO? for response) from comment #20) > (In reply to Sid Stamm [:geekboy or :sstamm] from comment #19) > > Now that we've backed out the patch in 861117, do you mean we should see if > > this problem goes away without that backout and after applying 633001? > > Yes, exactly. Tracking this in the original bug 861117.