Closed Bug 871560 Opened 11 years ago Closed 11 years ago

Firefox nightly doesn't connect to IPv6 literal

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Version:
23 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
firefox22 --- unaffected
firefox23 + verified
firefox24 + verified

People

(Reporter: anshprat, Assigned: geekboy)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(1 file)

backout bug 861117
1.68 KB, patch
lsblakk
: approval-mozilla-aurora+
Details | Diff | Splinter Review 
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
URL: http://test-ipv6.com/
Status: UNCONFIRMED → NEW
status-firefox22: --- → unaffected
status-firefox23: --- → affected
status-firefox24: --- → affected
tracking-firefox23: --- → ?
tracking-firefox24: --- → ?
Component: Untriaged → Networking
Ever confirmed: true
Keywords: regression, regressionwindow-wanted
OS: Linux → All
Product: Firefox → Core
Hardware: x86 → All
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.  :(
Keywords: qawanted
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!
QA Contact: kbrosnan
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.
Blocks: 861117
Keywords: qawanted, regressionwindow-wanted
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?
Assignee: nobody → sstamm
Flags: needinfo?(sstamm)
[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?
Attachment #750647 - Flags: approval-mozilla-aurora?
Flags: needinfo?(sstamm) → needinfo?(lsblakk)
See if the patch for bug 633001 fixes this.
See Also: → 633001
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?
Flags: needinfo?(bsmith)
(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.
Flags: needinfo?(bsmith)
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.
Depends on: 633001
See Also: 633001 → 
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
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.
Attachment #750647 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Flags: needinfo?(lsblakk)
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.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Anshu, can you please check tomorrow's Aurora build?
sure, will do.
Keywords: verifyme
fell off my radar. Confirming that it works well since the fix in nightly.
Status: RESOLVED → VERIFIED
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.
(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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: