Closed Bug 543805 Opened 15 years ago Closed 14 years ago

FTP list parse error when list returns twice space between date and file name

Categories

(Core Graveyard :: Networking: FTP, defect)

Product:
Core Graveyard
Component:
Networking: FTP
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking2.0 betaN+, blocking1.9.2 -, status1.9.2 wanted, status1.9.1 unaffected)

Status:
VERIFIED FIXED
Milestone:
mozilla2.0b10
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+
blocking1.9.2 --- -
status1.9.2 --- wanted
status1.9.1 --- unaffected

People

(Reporter: lperico, Assigned: michal)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [softblocker][fx4-fixed-bugday])

Attachments

(1 file, 2 obsolete files)

patch v2 - fixed dates
6.29 KB, patch
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 One space are added at the start of every file or directory. Apparently at the wu FTP server Reproducible: Always Steps to Reproduce: 1. go to ftp://ftp.software.ibm.com/ or ftp.lotus.com 2. click on a file or a directory 3. Actual Results: a %20 url are opened
I see more problems on the first site. Most or at least a lot of links give an error: 550 / cloud: No such file or directory. Is this what you mean?
Version: unspecified → 3.6 Branch
Core > Networking: FTP will be the right place in any case.
Component: General → Networking: FTP
Product: Firefox → Core
QA Contact: general → networking.ftp
Version: 3.6 Branch → Trunk
blocking1.9.2: --- → ?
ftp> ls 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. total 208 drwxr-sr-x 13 102004493 201 4096 Apr 18 2008 4700 -rw-r--r-- 1 102004493 201 6981 Dec 20 1995 TRADEMARKS.TXT drwxr-sr-x 14 102004493 201 4096 Oct 20 2008 aix drwxr-sr-x 17 102004493 201 4096 Mar 4 2009 annualreport drwxr-sr-x 8 102004493 202 4096 Oct 31 2008 as400 drwxr-sr-x 2 0 201 256 Nov 2 09:00 bin drwxr-sr-x 3 102004493 202 256 Jun 8 2009 cloud drwxr-sr-x 4 102004493 202 256 Apr 22 2003 common drwxr-sr-x 19 102004493 202 4096 Jan 25 23:30 demos drwxr-sr-x 2 0 201 256 Oct 26 14:13 dev drwxr-xr-x 8 102004493 201 256 Mar 7 2006 devices drwxr-sr-x 10 102004493 201 256 Apr 23 2008 education drwxr-sr-x 4 102004493 201 256 May 6 2004 eserver drwxr-xr-x 2 102004493 201 4096 Sep 25 2007 fiximages lrwxrwxrwx 1 102004493 1 14 Sep 25 16:01 ftp -> software/lotus drwxr-sr-x 4 102004493 201 256 Dec 6 2002 hardware drwxr-sr-x 2 102004493 201 256 Oct 22 1997 ims drwxr-xr-x 2 102004493 201 256 Mar 24 2004 indexes drwxr-sr-x 4 102004493 202 256 Feb 16 2009 industries drwxr-sr-x 6 102004493 201 4096 Dec 17 22:02 infomgmt drwxr-sr-x 6 102004493 202 4096 Sep 24 13:30 itsolutions drwxr-sr-x 3 102004493 202 256 Mar 23 2006 jp drwxr-sr-x 3 102004493 202 256 Dec 19 2007 la drwxr-sr-x 2 0 201 256 Oct 26 14:13 lib drwxr-sr-x 11 102004493 201 4096 Aug 7 2007 linux drwxr-xr-x 2 102004493 1 256 Sep 8 08:06 lost+found drwxr-sr-x 5 102004493 201 256 Nov 29 2001 networking drwxr-sr-x 6 102004493 202 256 Dec 18 11:48 partnerworld drwxr-sr-x 2 102004493 201 256 Jul 17 2006 pc drwxr-sr-x 15 102004493 202 4096 Jul 17 2008 podcasts drwxr-sr-x 23 102004493 201 4096 Nov 13 2008 printers drwxr-sr-x 4 102004493 202 4096 Jul 26 2006 procurement drwxr-sr-x 7 102004493 201 256 Mar 9 2004 ps lrwxrwxrwx 1 102004493 1 14 Sep 25 16:01 pub -> software/lotus drwxr-sr-x 19 102004493 201 4096 Jul 22 1999 publications -rw-r--r-- 1 102004493 201 47 May 29 2007 robots.txt drwxr-sr-x 21 102004493 201 4096 Aug 20 2002 rs6000 drwxr-sr-x 38 102004493 201 4096 Apr 28 2008 s390 drwxr-sr-x 3 102004493 202 256 Dec 8 06:25 sales drwxr-sr-x 4 102004493 202 256 Oct 11 2006 servers drwxr-sr-x 6 102004493 201 256 Sep 24 14:08 services drwxr-sr-x 13 102004493 201 4096 Apr 10 2008 sns drwxr-sr-x 268 102004493 201 16384 Feb 1 09:20 software drwxr-sr-x 9 102004493 201 4096 Apr 8 2009 solutions drwxr-sr-x 83 102004493 202 4096 Jan 4 13:36 storage drwxr-sr-x 25 102004493 202 4096 Mar 12 2009 systems drwxr-sr-x 3 102004493 202 256 Feb 5 2009 virtualworlds 226 Transfer complete. ftp> cd aix 250-Please read the file README_AIX 250- it was last modified on Fri Jul 26 08:09:01 1996 - 4935 days ago 250 CWD command successful. ftp> system 215 UNIX Type: L8 LIST data has twice space beteen date and name...
confirm on latest trunk of Mac OS X.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: FTP list parse error → FTP list parse error when list returns twice space between date and file name
@Ria Klaassen (triage) The problem seem the same(In reply to comment #1) > I see more problems on the first site. Most or at least a lot of links give an > error: 550 / cloud: No such file or directory. > > Is this what you mean? Yes the server seem the same. Apparently the parsing code have some problem it will add a space at the begin of the file or directory name. "/ cloud" instead "/cloud" i.e.
(In reply to comment #3) > drwxr-sr-x 8 102004493 202 4096 Oct 31 2008 | as400 > drwxr-sr-x 2 0 201 256 Nov 2 09:00 |bin ^----- Seem the directory separated in a fixed size column or use one space after the column > ftp> ls > 200 PORT command successful. > 150 Opening ASCII mode data connection for /bin/ls. > total 208 > drwxr-sr-x 13 102004493 201 4096 Apr 18 2008 4700 > -rw-r--r-- 1 102004493 201 6981 Dec 20 1995 TRADEMARKS.TXT > drwxr-sr-x 14 102004493 201 4096 Oct 20 2008 aix > drwxr-sr-x 17 102004493 201 4096 Mar 4 2009 annualreport > drwxr-sr-x 8 102004493 202 4096 Oct 31 2008 as400 > drwxr-sr-x 2 0 201 256 Nov 2 09:00 bin > drwxr-sr-x 3 102004493 202 256 Jun 8 2009 cloud > drwxr-sr-x 4 102004493 202 256 Apr 22 2003 common > drwxr-sr-x 19 102004493 202 4096 Jan 25 23:30 demos > drwxr-sr-x 2 0 201 256 Oct 26 14:13 dev > drwxr-xr-x 8 102004493 201 256 Mar 7 2006 devices > drwxr-sr-x 10 102004493 201 256 Apr 23 2008 education > drwxr-sr-x 4 102004493 201 256 May 6 2004 eserver > drwxr-xr-x 2 102004493 201 4096 Sep 25 2007 fiximages > lrwxrwxrwx 1 102004493 1 14 Sep 25 16:01 ftp -> software/lotus > drwxr-sr-x 4 102004493 201 256 Dec 6 2002 hardware > drwxr-sr-x 2 102004493 201 256 Oct 22 1997 ims > drwxr-xr-x 2 102004493 201 256 Mar 24 2004 indexes > drwxr-sr-x 4 102004493 202 256 Feb 16 2009 industries > drwxr-sr-x 6 102004493 201 4096 Dec 17 22:02 infomgmt > drwxr-sr-x 6 102004493 202 4096 Sep 24 13:30 itsolutions > drwxr-sr-x 3 102004493 202 256 Mar 23 2006 jp > drwxr-sr-x 3 102004493 202 256 Dec 19 2007 la > drwxr-sr-x 2 0 201 256 Oct 26 14:13 lib > drwxr-sr-x 11 102004493 201 4096 Aug 7 2007 linux > drwxr-xr-x 2 102004493 1 256 Sep 8 08:06 lost+found > drwxr-sr-x 5 102004493 201 256 Nov 29 2001 networking > drwxr-sr-x 6 102004493 202 256 Dec 18 11:48 partnerworld > drwxr-sr-x 2 102004493 201 256 Jul 17 2006 pc > drwxr-sr-x 15 102004493 202 4096 Jul 17 2008 podcasts > drwxr-sr-x 23 102004493 201 4096 Nov 13 2008 printers > drwxr-sr-x 4 102004493 202 4096 Jul 26 2006 procurement > drwxr-sr-x 7 102004493 201 256 Mar 9 2004 ps > lrwxrwxrwx 1 102004493 1 14 Sep 25 16:01 pub -> software/lotus > drwxr-sr-x 19 102004493 201 4096 Jul 22 1999 publications > -rw-r--r-- 1 102004493 201 47 May 29 2007 robots.txt > drwxr-sr-x 21 102004493 201 4096 Aug 20 2002 rs6000 > drwxr-sr-x 38 102004493 201 4096 Apr 28 2008 s390 > drwxr-sr-x 3 102004493 202 256 Dec 8 06:25 sales > drwxr-sr-x 4 102004493 202 256 Oct 11 2006 servers > drwxr-sr-x 6 102004493 201 256 Sep 24 14:08 services > drwxr-sr-x 13 102004493 201 4096 Apr 10 2008 sns > drwxr-sr-x 268 102004493 201 16384 Feb 1 09:20 software > drwxr-sr-x 9 102004493 201 4096 Apr 8 2009 solutions > drwxr-sr-x 83 102004493 202 4096 Jan 4 13:36 storage > drwxr-sr-x 25 102004493 202 4096 Mar 12 2009 systems > drwxr-sr-x 3 102004493 202 256 Feb 5 2009 virtualworlds > 226 Transfer complete. > ftp> cd aix > 250-Please read the file README_AIX > 250- it was last modified on Fri Jul 26 08:09:01 1996 - 4935 days ago > 250 CWD command successful. > ftp> system > 215 UNIX Type: L8 > > LIST data has twice space beteen date and name...
This does not affect 1.9.1 -- when did it regress?
Keywords: regression, regressionwindow-wanted
It would be good to know what is causing this - a server side configuation, maybe? Doesn't happen on ftp://ftp.mozilla.org for example ...
blocking1.9.2: ? → needed
Looks like a consequence of us fixing bug 484684. Their listing is incorrect (includes the space), and we used to strip them, but we now don't. That leaves a few options, I think: 1) Back out that bug and WONTFIX it 2) WONTFIX this bug (broken server listing) 3) Try to come up with some sort of heuristic? 1) or 2) are probably the best options, though which would be best depends on the number of sites affected by each. Would also be worth investigating how other FTP clients deal with this, I guess.
Oh, looks like there's already a special case for "old Hellsoft" servers. Perhaps that needs to be extended?
Keywords: regressionwindow-wanted
Assignee: nobody → michal.novotny
Apparently it isn't true that there is always 1 space between filename and previous token (http://hg.mozilla.org/mozilla-central/annotate/46484930f4f3/netwerk/streamconv/converters/ParseFTPList.cpp#l1202). In this case I don't see a way how to find a correct start of the filename while parsing the listing. I've looked at few anonymous wu-2.6.2 FTP servers that I've found and no other server gave me such wrong output. We could theoretically fix it not in FTP parser but in FTP protocol so, that if RETR or LIST command fails we remove leading space (if present) from last component of the path and try again. But although this would fix this problem, it would have other side effects. Since I haven't found other affected FTP server I would prefer to WONTFIX this bug (and possibly give a notice to IBM that their FTP servers return incompatible listing).
Interestingly, this path will kill IE 6 every time: ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoolbox/RPMS/ppc/ I thought it was a unique way of handling the issue.
@bzilla99, do you really want to compare Firefox 3.6 to 9-year old IE6? Both IE7 and IE8 handle the wu ftp server output correctly unlike Firefox 3.6 which has the %20 bug. Firefox 3.5 worked fine. Many instances of the problem can be seen here: ftp://www.redbooks.ibm.com/redbooks/
(In reply to comment #15) > Both IE7 and IE8 handle the wu ftp server output correctly unlike Firefox 3.6 > which has the %20 bug. Firefox 3.5 worked fine. OK, but I'll bet that IE7 and IE8 can't handle filenames with leading spaces correctly... > Many instances of the problem can be seen here: > ftp://www.redbooks.ibm.com/redbooks/ It seems that only output of IBM's wu FTP servers is broken. Do you know any other site that is affected?
I avoid IE like the plague. I use Firefox on windows and mac exclusively. I was just curious how an old version of IE handled it. It was ironic (?) to see it crashed and burned. Yes, the bug appeared in 3.6 - I often use the browser to drill down into a site and get an ftp path so I can use wget to retrieve the file from a terminal window. It isn't too hard to take the extra space out once the path is pasted elsewhere, but it's a bit annoying. I think wu-ftp is fairly pervasive, so I'd like to see this fixed.
blocking2.0: --- → -
Any idea if this is going to be fixed - and if so - when?
Any idea if this is going to be fixed - and if so - when?
blocking2.0: - → ?
(In reply to comment #17) > I think wu-ftp is fairly pervasive, so I'd like to see this fixed. So far, we've seen this problem only on IBM's servers. This isn't generic wu-ftp problem. Fixing this bug means reverting the patch from bug #484684. I think we don't want to do that unless somebody shows that the problem is widely spread.
(In reply to comment #21) > So far, we've seen this problem only on IBM's servers. This isn't generic > wu-ftp problem. Agreed. > Fixing this bug means reverting the patch from bug #484684. I respectfully disagree! You said yourself that it's not a generic wu-ftpd bug. Reverting the change would break ALL servers, including plain wu-ftpd. Either IBM fixes their servers (which would be my personal preference) or an IBM-specific (not all servers, or even all wu-ftpd servers!) workaround could be added. But please make sure such a workaround (if added) is applied ONLY to IBM servers to avoid breaking others.
This problem affects any FTP server running the AIX operating system, whether at IBM or anywhere else. So it is a generic problem that cannot be resolved by simply having IBM modify its own servers, or by making a special exception for ibm.com ftp servers. The issue is the output from the Unix ls command, which varies in different flavors of Unix. I have built a test case at [ftp://ftp.uic.edu/test] which contains the following files (this output is from ls on a linemode ftp client) -rw-r--r-- 1 0 49 May 4 20:19 nodup.file -rw-r--r-- 1 0 15 May 4 20:09 test.blankfile -rw-r--r-- 1 0 15 Apr 1 2008 test2.blankfile -rw-r--r-- 1 0 15 May 4 20:09 nodup.file -rw-r--r-- 1 0 15 May 4 20:09 test.file -rw-r--r-- 1 0 15 Apr 1 2008 test2.file Note that this differs from the output of ls on linux. In AIX the blank space is after the year, whereas on linux it is before the year. I deliberately created the first three files with blank spaces as the first character of the file name. Then I used touch to alter the dates on some of them, so that the year would appear in place of the time. I also deliberately created a pair of two files "nodup.file" and " nodup.file" just to see what happens. Firefox 3.6: All of the files created in 2010 could be displayed correctly, and none of the files created in 2008 could be displayed, regardless of whether the file names had leading blanks or not. This is broken behavior. Firefox prior to the patch from bug 484684, also IE8: None of the files with leading blanks in their name could be displayed. There were two separate entries for "nodup.file", but clicking on the entry for " nodup.file" displayed the contents of "nodup.file" instead. This is also broken behavior which the patch from Bug #484684 attempted to fix, except that it created other problems. Correct parsing of the output from ls would be: Assume that the date in ls command output is always exactly 12 characters long, even if the 12th character is a blank. The 13th character after the start of the date will always be a blank. The 14th character after the start of the date is the beginning of the file name - and it could possibly be a blank space character which is part of the file/directory name. This parsing method, of always assuming that the date stamp is exactly 12 characters long, followed by exactly 1 blank space, followed by the file name, would be compatible with all FTP servers, and would also accommodate filenames with leading blank space characters. I will leave my AIX testcase up for you to try against possible fixes.
(In reply to comment #23) > Firefox 3.6: All of the files created in 2010 could be displayed correctly, and > none of the files created in 2008 could be displayed, regardless of whether the > file names had leading blanks or not. This is broken behavior. > Roger, I like your theory - but if you have a look at the following site: ftp://ftp.software.ibm.com/ps/products/imageplus/fixes/IWPMv2.3fp2/ You will see that while all the 2010 files handle as expected and most of the others do not that there are also a couple of 2009 files that are handled correctly in Firefox 3.6 - specifically the 2 with a date of December 15 2009 - although it sounds to me like your suggested resolution will work for any file date
The man page for the Unix ls command states: "If the time of last modification is greater than six months ago, the time field is shown in the format month date year where as files modified within six months the time field is shown as month date time format." This bug does not occur with files younger than 6 months, because the time is shown instead of the year, and FTP clients (including Firefox 3.6) already know how to calculate the year correctly by following the 6-month rule. It's May 7, 2010 as I type, so a file last touched after November 7, 2009 will not exhibit this bug, whereas a file last touched before November 7, 2009 will exhibit it. If the date is parsed as always being exactly 12 characters, possibly including a trailing blank after the year, it will always be parsed correctly when connecting to any FTP server, even if there are filenames that start with a blank space character. BTW I reported the bug about IE8 not handling filenames that start with a blank space character to Microsoft, and they seem perplexed by it too. I haven't tried any other browsers to see how they behave on my test directory.
(In reply to comment #25) > The man page for the Unix ls command states: "If the time of last modification > is greater than six months ago, the time field is shown in the format month > date year where as files modified within six months the time field is shown as > month date time format." > > This bug does not occur with files younger than 6 months, because the time is > shown instead of the year, and FTP clients (including Firefox 3.6) already know > how to calculate the year correctly by following the 6-month rule. It's May 7, > 2010 as I type, so a file last touched after November 7, 2009 will not exhibit > this bug, whereas a file last touched before November 7, 2009 will exhibit it. > > If the date is parsed as always being exactly 12 characters, possibly including > a trailing blank after the year, it will always be parsed correctly when > connecting to any FTP server, even if there are filenames that start with a > blank space character. > > BTW I reported the bug about IE8 not handling filenames that start with a blank > space character to Microsoft, and they seem perplexed by it too. I haven't > tried any other browsers to see how they behave on my test directory. So now that Roger has so clearly identified the problem and also how to resolve so that FF 3.6 should in my opinion work correctly with any FTP server with files of any date - what are the chances of getting this fixed?
Not blocking per comment 21.
blocking2.0: ? → -
As more and more users update their Firefox browsers to v3.6, we are getting an increasing number of complaints from users of our AIX-based ftp server that they cannot use it. It is complicated to explain the intricacies of this age-based bug to them. Although we generally recommend that people at the University use Firefox for everything, about all we can tell them is to switch from Firefox to IE or Safari, which is much easier than trying to get them to regress back to an earlier version of Firefox. We have tested Firefox 4 beta and found that this bug still exists at that level. It's been a while since I explained here the exact nature of the problem with all AIX-based ftp servers, and suggested a fix that will not interfere with any other types of ftp servers or with files/directories that begin with a blank space character. This is becoming a widespread problem for us. When can we expect this to be fixed?
Renominating per comment 23, since this affects more servers than was thought at the time of comment 21, and since we do not in fact have to back the fix out. That said, Roger, this is a very low priority compared to the other things on Michal's plate. Your best bet for getting this fixed is probably to post a patch....
blocking2.0: - → ?
Blocking. Michal, can you look at this in the next couple of weeks?
blocking2.0: ? → beta5+
We don't need this for beta5, but moving to betaN.
blocking2.0: beta5+ → betaN+
Attached patch fix (obsolete) — — Splinter Review
Attachment #483359 - Flags: review?(doug.turner)
Seems like problem is resolved in 3.6.11 - thanks to all involved
Comment on attachment 483359 [details] [diff] [review] fix sorry for the delay michal, and sorry for punting to jason. ooc, has ParseFTPList ever been updated outside of mozilla? maybe there are other fixes that we should grab.
Attachment #483359 - Flags: review?(doug.turner) → review?(jduell.mcbugs)
Whiteboard: softblocker
Comment on attachment 483359 [details] [diff] [review] fix Honza says he can help offload Jason a bit by doing this review.
Attachment #483359 - Flags: review?(jduell.mcbugs) → review?(honzab.moz)
Whiteboard: softblocker → [softblocker]
This is just an update to the test. Files that has May 4 as the date are parsed as May 4th 2010, which is logical. I changed the date to Jan 1 that should let the parse always return the current year. Please apply over your patch.
Comment on attachment 483359 [details] [diff] [review] fix r=honzab with the test fixed.
Attachment #483359 - Flags: review?(honzab.moz) → review+
Attachment #483359 - Attachment is obsolete: true
Attachment #503238 - Attachment is obsolete: true
Keywords: checkin-needed
Landed. http://hg.mozilla.org/mozilla-central/rev/b623418ab1de
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Keywords: checkin-needed
Target Milestone: --- → mozilla2.0b10
Does this patch apply to the 1.9.2 branch as well, or will we need a new one?
(In reply to comment #33) > Seems like problem is resolved in 3.6.11 - thanks to all involved (In reply to comment #40) > Does this patch apply to the 1.9.2 branch as well, or will we need a new one? Could NOT reproduce with recent 1.9.2 branch builds: 3.6.14rc1 MacOSX 10.6, 3.6.14rc AIX 5.1, 3.6.13 on W2K3 Server and a Minefield 4.0b10 MacOSX 10.6 and SeaMonkey 2.0.12 on Win Vista are all showing all files in the dir "ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoolbox/RPMS/ppc/python/" correctly. This dir contains old and files newer the 6 months. A "ls -l" from my AIX buildhost shows a little different listing format: ftp> ls -l 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. total 131576 -rw-rw-r-- 1 102004493 201 1652349 Apr 16 2001 python-1.5.2-8.aix4.3 .ppc.rpm -rw-rw-r-- 1 102004493 201 4102464 Jun 28 2001 python-2.1-1.aix4.3.p pc.rpm -rw-rw-r-- 1 102004493 201 4118414 Oct 10 2001 python-2.1.1-1.aix4.3 .ppc.rpm -rw-rw-r-- 1 102004493 201 3687396 Feb 17 2002 python-2.2-3.aix4.3.p pc.rpm -rw-rw-r-- 1 102004493 201 3692060 Feb 18 2003 python-2.2-4.aix4.3.p pc.rpm -rw-rw-r-- 1 102004493 201 3697237 Feb 23 2005 python-2.2-5.aix5.1.p pc.rpm -rw-rw-r-- 1 102004493 201 4460884 Sep 12 2005 python-2.3.4-2.aix5.1 .ppc.rpm -rw-rw-r-- 1 102004493 201 4471844 Jul 24 2008 python-2.3.4-4.aix5.3 .ppc.rpm -rw-rw-r-- 1 102004493 201 7684595 Dec 22 06:02 python-2.6.2-1.aix5.3 .ppc.rpm -rw-rw-r-- 1 102004493 201 853061 Apr 16 2001 python-devel-1.5.2-8. aix4.3.ppc.rpm -rw-rw-r-- 1 102004493 201 515244 Jun 28 2001 python-devel-2.1-1.ai x4.3.ppc.rpm ... So the padding blank is before the year, I'm using en_US 8859-1 locale on my AIX buildhost. Seems 1.9.2 is fixed or unaffected.
FTP site can be browsed ok with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10) Gecko/20100101 Firefox/4.0b10 ID:20110121161358
Whiteboard: [softblocker] → [softblocker][fx
Status: RESOLVED → VERIFIED
Whiteboard: [softblocker][fx → [softblocker][fx4-fixed-bugday]
blocking1.9.2: needed → -
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: