Closed Bug 492562 Opened 16 years ago Closed 16 years ago

please QA the Fastest Firefox upload page

Categories

(www.mozilla.org :: General, defect, P1)

Product:
www.mozilla.org
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jslater, Assigned: stephend)

References

(
URL
)

Details

Attachments

(2 files)

error message
74.62 KB, image/png
Details
parental consent, ODF format
22.18 KB, application/vnd.oasis.opendocument.text
Details
Hi guys. The final component of the Fastest Firefox page is now ready for QA...please take a look. This is the page where people will actually upload their videos to us. It'll be accessed from https://www-trunk.stage.mozilla.com/en-US/firefox/fastest/. Alex Buchanan, who built the uploader, notes that the following items are still missing: 1) the uploads and log directories are locked down, IT to set these up as they would be in production, bug 491757 2) locale detection. I've written this, I'll commit it to stage after some testing QA guys, I know you're super busy right now, but is there any chance we could get this finalized by the end of the week?
I'm on it; will report back ASAP (today/tonight).
Assignee: nobody → stephen.donner
Priority: -- → P1
(In reply to comment #0) > 1) the uploads and log directories are locked down, IT to set these up as they > would be in production, bug 491757 This part is done. oremj put these behind HTTP auth, with sfx/sfx as the username/password. It's not exactly like it would be in production, because I think we'll want the logs under MoCo eyes only, but it works for stage. > 2) locale detection. I've written this, I'll commit it to stage after some > testing Still working on this. 3) email doesn't actually validate for email address form yet (foo@bar.com) but I'll put that in soon.
4) There are 8 validation errors, according to the W3C's validator. 5) My upload is still pending, but it looks like one can submit a video without agreeing to the TOS, as long as Name, Email Address, and a valid video are specific; shouldn't we do client-side checking on the checkbox's state before that submit?
(In reply to comment #3) > 4) There are 8 validation errors, according to the W3C's validator. > 5) My upload is still pending, but it looks like one can submit a video without > agreeing to the TOS, as long as Name, Email Address, and a valid video are > specific; shouldn't we do client-side checking on the checkbox's state before > that submit? hm, I test the TOS, but I'll double check. Yes, a simple client-side check sounds nice.
(In reply to comment #3) > 4) There are 8 validation errors, according to the W3C's validator. These are coming from the reCaptcha. The iframe that they use for non-JS users throws these errors. So, I can't fix these. > 5) My upload is still pending, but it looks like one can submit a video without > agreeing to the TOS, as long as Name, Email Address, and a valid video are > specific; shouldn't we do client-side checking on the checkbox's state before > that submit? r25661 implements a simple JS check to make sure the user has checked the TOS checkbox. There are a couple other issues in the queue... 1) No file type/size validation 2) Uploads don't maintain a file type/extension 3) email format validation I also checked in some simple locale detection and handling. However, we can't really test this part yet, as there are no active locales.
(In reply to comment #5) > I also checked in some simple locale detection and handling. However, we can't > really test this part yet, as there are no active locales. There won't be any active locales until we close this bug and indicate to Pascal that the page is ready for localization. What's the best way to resolve this?
(In reply to comment #6) > There won't be any active locales until we close this bug and indicate to > Pascal that the page is ready for localization. What's the best way to resolve > this? I'm not sure. I could check in a dummy locale for testing, and we could remove it before the real localization starts
(In reply to comment #7) > I'm not sure. I could check in a dummy locale for testing, and we could remove > it before the real localization starts Ok, let's give that a try. We need to get this into l10n soon...thanks!
(In reply to comment #5) > There are a couple other issues in the queue... > > 1) No file type/size validation > > 2) Uploads don't maintain a file type/extension > > 3) email format validation r25679 handles these
(In reply to comment #8) > (In reply to comment #7) > > I'm not sure. I could check in a dummy locale for testing, and we could remove > > it before the real localization starts > > Ok, let's give that a try. We need to get this into l10n soon...thanks! r25680 creates some dummy locales with placeholder strings. (test, de, es) http://fastestfox.stage.mozilla.com/?lang=test http://fastestfox.stage.mozilla.com/?lang=de http://fastestfox.stage.mozilla.com/?lang=es
A couple notes: 1) The issue I filed as bug 492878 was due to me stripping out all accept-header languages (en, en-US) that Firefox ships by default with its en-US builds -- when I added back en-US, it works; Alex checked in some changes to fix the language/locale-detect code, and I'm still testing on stage. 2) I just successfully uploaded a PDF :-(
(In reply to comment #11) > 2) I just successfully uploaded a PDF :-( https://bugzilla.mozilla.org/show_bug.cgi?id=484251#c16
Alex, what is the final live URL going to be for this upload page?
(In reply to comment #13) > Alex, what is the final live URL going to be for this upload page? Per https://bugzilla.mozilla.org/show_bug.cgi?id=484251#c18, I'm recommending that we go with http://fastestfirefox.mozilla.com.
Attached image error message —
steps to reproduce: 1.Enter any URL in the name field 2.Enter email id and try to upload a video. 3.Notice the error message expected result: -Error messages are descriptive/informative to the user. actual result: Error message says-An unknown error occurred while uploading your file. Try TODO - some backup option This user message is not very informative about what caused the error.
(In reply to comment #15) > Created an attachment (id=378260) [details] > error message > > steps to reproduce: > 1.Enter any URL in the name field > 2.Enter email id and try to upload a video. > 3.Notice the error message > > expected result: > -Error messages are descriptive/informative to the user. > > actual result: > Error message says-An unknown error occurred while uploading your file. Try > TODO - some backup option > > This user message is not very informative about what caused the error. I fixed the problem that was causing this error in r25908. Here are all the error messages. Please revise. * User left "Name" blank "Please enter your name" * User entered "Email" and it isn't in email address format "Please enter a valid email" * User left "File" blank "Please choose a file to upload" * File exceeds max size (100MB) "The file you are uploading is too big, there is a 100 MB limit" * File could not be uploaded/saved for an unknown reason "An unknown error occurred while uploading your file. Try TODO - some backup option" * User didn't check the TOS checkbox "We need you to agree to the Terms of Agreement" * Captcha was incorrect/blank "The CAPTCHA string you entered does not match"
Also,the font color of listed collections/collection authors is different in our site and clearleft's site(clearleft uses darker/royal blue)
please ignore my comment.I am an idiot.
Also, we'll need one for bad file types. Something like... * We can only accept videos in the formats wmv, mpeg, mov. Please blah > Here are all the error messages. Please revise. > > * User left "Name" blank > > "Please enter your name" > > * User entered "Email" and it isn't in email address format > > "Please enter a valid email" > > * User left "File" blank > > "Please choose a file to upload" > > * File exceeds max size (100MB) > > "The file you are uploading is too big, there is a 100 MB limit" > > * File could not be uploaded/saved for an unknown reason > > "An unknown error occurred while uploading your file. Try TODO - some backup > option" > > * User didn't check the TOS checkbox > > "We need you to agree to the Terms of Agreement" > > * Captcha was incorrect/blank > > "The CAPTCHA string you entered does not match"
Alex, thanks for bringing this up. My suggestions are below...let me know what you think. (the unknown error one was tough...am open to better ideas there, for sure) > Also, we'll need one for bad file types. Due to editing considerations we're only able to accept .wmv, .mov and .mp4 files. Please try again with a different format. > * User left "Name" blank Please enter your name and try again. > * User entered "Email" and it isn't in email address format Please enter a valid email address and try again. > * User left "File" blank Please choose a file to upload. > * File exceeds max size (100MB) Sorry, the file you're uploading exceeds our 100MB limit. Please edit your video and try again. > > * File could not be uploaded/saved for an unknown reason An unknown error occurred while uploading your file. Please review the list of upload requirements and try again. > * User didn't check the TOS checkbox Be sure to read the Terms of Agreement, then click Agree and try again. > > * Captcha was incorrect/blank The information you entered does not match. Please try again.
r25965 updates the error messages, except the Capthca. > > * Captcha was incorrect/blank > The information you entered does not match. Please try again. I think 'information' could be confused with any information on the form. Can we use 'Captcha' instead of 'information'? Re: unknown error This case shouldn't happen, and if it does, it means it's a problem that can't be diagnosed by the user. In this case, I think we should recommend that they contact someone, so we can help them get their video in (and also, the unknown error is brought to our attention)
(In reply to comment #21) > > > * Captcha was incorrect/blank > > The information you entered does not match. Please try again. > > I think 'information' could be confused with any information on the form. Can > we use 'Captcha' instead of 'information'? How about: The Captcha information you entered does not match. Please try again. > Re: unknown error > > This case shouldn't happen, and if it does, it means it's a problem that can't > be diagnosed by the user. In this case, I think we should recommend that they > contact someone, so we can help them get their video in (and also, the unknown > error is brought to our attention) Ok. What do you think the best thing to do here is? Should we set up a fastestfirefox@mozilla.com email account? My only concern is doing a bunch of customer service on this that could be really difficult...how will we be able to analyze the problem any better than the user? Apologies if I'm missing something here. Thanks!
Bug: I tried to upload the 24MB demo file on that page (http://videos.mozilla.org/sfx/MozVideoTutorial.mp4 is the direct link), and kept getting "file size too large" messages; Alex says the max file size is wrong -- it's set up right now to be only be 12MB.
r25999 should fix the MAX_FILE_SIZE HTML attribute (...which fixed the problem for me when I hacked it with firebug)
r26000, updates the captcha error string (In reply to comment #22) > Ok. What do you think the best thing to do here is? Should we set up a > fastestfirefox@mozilla.com email account? My only concern is doing a bunch of > customer service on this that could be really difficult...how will we be able > to analyze the problem any better than the user? Apologies if I'm missing > something here. Yeah, agreed. I don't want to create any extra customer service work. Basically, I want to give the user options on what to do next. 1) Try again, the best first option 2) If the user really can't get past it, how about they try posting it somewhere (like YouTube) and send a link to fastestfirefox@mozilla.com? Better still, how about putting this info in the sidebar, and show it always? In that case, we can go with your error string in comment #20
I tested Alex's changes both positively (small, correct file types, +combinations) and negatively (large, incorrect file types, +combinations), verified the fix, and haven't yet seen any regression. Going to still take a further look; will comment back if I see something.
One other little fix...this was originally discussed in the other bug (https://bugzilla.mozilla.org/show_bug.cgi?id=484251#c15), but we need to specify that .mp4 files are ok, but other .mpeg formats aren't. So, just to be clear, the official list of acceptable file types is: .mp4, .mov, .wmv.
I've tweaked the file type checking to only allow MPEG v4 (mp4), but I haven't checked this in yet. The description under the file upload input says "(.mov, .wmv, .mp4, .mpeg)" should I remove .mpeg from this?
(In reply to comment #28) > The description under the file upload input says "(.mov, .wmv, .mp4, .mpeg)" > should I remove .mpeg from this? Yes please - thanks!
r26047 disallows mpeg version < 4, and changes the text per comment #29
http://fastestfox.stage.mozilla.com/consent.php?lang=en-US refers to "the Mozilla Firefox Speed Campaign." -- shouldn't that say "the Mozilla Fastest Firefox campaign."?
(In reply to comment #31) > http://fastestfox.stage.mozilla.com/consent.php?lang=en-US refers to "the > Mozilla Firefox Speed Campaign." -- shouldn't that say "the Mozilla Fastest > Firefox campaign."? Great catch...yes, it should reference Fastest Firefox like you said.
(In reply to comment #32) > (In reply to comment #31) > > http://fastestfox.stage.mozilla.com/consent.php?lang=en-US refers to "the > > Mozilla Firefox Speed Campaign." -- shouldn't that say "the Mozilla Fastest > > Firefox campaign."? > Great catch...yes, it should reference Fastest Firefox like you said. r26095
I added two messages per John's request in email "uploads take awhile" http://fastestfox.stage.mozilla.com/#uploading "success!" http://fastestfox.stage.mozilla.com/success.php r26105
any thoughts on comment #25? Otherwise, I think we're ready.
Actually, trying to upload http://videos.mozilla.org/sfx/MozVideoTutorial.mp4 is failing, now (complaining about file type, but it's very clearly an MP4).
(In reply to comment #35) > any thoughts on comment #25? Otherwise, I think we're ready. Yeah, I'm still not sure about that. I'm not really into the idea of putting that error message in the sidebar b/c I think that will encourage people to email us about all sorts of topics...we're not really staffed to do customer service on this! I guess I'd be fine with giving that email address as part of the error message (although I'm still reluctant about it)...only thing is it could be a lot of work for us and I'm not totally clear on how we'd be able to help people. Maybe we should just ask people to upload to YouTube? That's not ideal either, of course, but I don't want to over-rotate *too* much on what's probably an edge case. Alex, what do you think? (In reply to comment #36) > Actually, trying to upload http://videos.mozilla.org/sfx/MozVideoTutorial.mp4 > is failing, now (complaining about file type, but it's very clearly an MP4). Doh! Alex, can you investigate?
Sorry for just-now noticing, but, "* Be sure to read the Terms of Agreement, then click Agree and try again." makes it seem like there's an Agree button (since it's treated as a proper noun), but we're using a checkbox, instead. Shouldn't the text read something like, "Be sure to read the Terms of Agreement, and click the checkbox to indicate your acknowledgment." (or approval, or something)?
When I upload http://www.swissnexboston.org/activities/weblog/testmovie.mov, it gets renamed as BillClinton-91b6a.mp4 (dummy name I just chose for fun); we're not maintaining neither the file-type extension nor the filename :-(
Using Opera 9.64, I see a bunch of "PLACEHOLDER" markers :-( http://screencast.com/t/W5kLKWrdmhL
(In reply to comment #37) > I guess I'd be fine with giving that email address as part of the error message > (although I'm still reluctant about it)...only thing is it could be a lot of > work for us and I'm not totally clear on how we'd be able to help people. Maybe > we should just ask people to upload to YouTube? That's not ideal either, of > course, but I don't want to over-rotate *too* much on what's probably an edge > case. Alex, what do you think? > Ok, let's leave it out. > (In reply to comment #36) > > Actually, trying to upload http://videos.mozilla.org/sfx/MozVideoTutorial.mp4 > > is failing, now (complaining about file type, but it's very clearly an MP4). > Doh! Alex, can you investigate? Yes, I'm looking into this, and comments #39 #40 (In reply to comment #38) > Shouldn't the text read something like, "Be sure to read the Terms of > Agreement, and click the checkbox to indicate your acknowledgment." (or > approval, or something)? I agree. John, want to finalize the wording for this?
(In reply to comment #38) > Sorry for just-now noticing, but, "* Be sure to read the Terms of Agreement, > then click Agree and try again." makes it seem like there's an Agree button > (since it's treated as a proper noun), but we're using a checkbox, instead. > > Shouldn't the text read something like, "Be sure to read the Terms of > Agreement, and click the checkbox to indicate your acknowledgment." (or > approval, or something)? Great catch. How about: Please read the Terms of Agreement and click the "I have read and agree" checkbox to continue with your upload.
r26363 changes the Terms of Agreement error message. I'm still working on writing a test case for the other issues.
(In reply to comment #36) > Actually, trying to upload http://videos.mozilla.org/sfx/MozVideoTutorial.mp4 > is failing, now (complaining about file type, but it's very clearly an MP4). Can you try again? I can't reproduce, and I haven't changed anything. (In reply to comment #39) > When I upload http://www.swissnexboston.org/activities/weblog/testmovie.mov, it > gets renamed as BillClinton-91b6a.mp4 (dummy name I just chose for fun); we're > not maintaining neither the file-type extension nor the filename :-( I ran the `file` command on this video, and it turns out it actually is in MPEG v4 format. [abuchanan@khan ~]$ file test_mov.stephend test_mov.stephend: ISO Media, MPEG v4 system, iTunes AAC-LC So, I think it's fine. Still looking at the Opera locale detection issue
Alex: yeah, I just tried to upload the video and it succeeded; scary that it failed once, though :-( Thanks for checking the file-type issue -- glad that Opera is the only thing we have left; sorry for the constant churn from QA on this :-(
(In reply to comment #45) > Alex: yeah, I just tried to upload the video and it succeeded; scary that it > failed once, though :-( > Thanks for checking the file-type issue -- glad that Opera is the only thing we > have left; sorry for the constant churn from QA on this :-( no problem, glad to have your help. I've figured out the Opera problem. I'm figuring out to fix it and write a test case for it now.
I've committed the fix for the Opera issue. The issue was that Opera defaults to 'en' not 'en-US'. I hadn't yet mapped en -> en-US, so it was falling back to the next language, 'de' Anyway, I've added the following mappings, 'en' => 'en-US', 'es' => 'es-ES', 'ja-jp-mac' => 'ja', 'no' => 'nb-NO', 'pt' => 'pt-PT', 'sv' => 'sv-SE' I took that from mozilla.com, so I think it's complete. If you know of one I should add, please let me know. I also added a unit test framework and a few simple tests for file type and language detection.
Awesome! I can confirm that it fixes the problem with Opera 9.64.
Thanks guys!!
A few question: 1/ The videos have urls pointing to different folders: /1/fastest-clapper.mp4 /4/fastest-clapper.ogg Is it normal that these 2 videos are not in the same folder? 2/ There is a close button on the video player that is hardcoded in English in the source javascript file which is bad: Mozilla.VideoScaler.close_text = 'Close'; [...] document.createTextNode( Mozilla.VideoScaler.close_text ) I am putting it for localization as a php variable in the file given to localizer, the javascript function using it has to be modified to use this variable and not a constant 3/ the launch date is not defined and left as a placeholder, if we don't know the launch date, we can't translate the sentence with the date in it. The only solution I see is to put it as a variable and display it in numeric form for locales like: $launch_date = strftime(___('%Y-%m-%d'), strtotime('2009-06-01')); Then instead of putting "Follow the steps below and upload by June 1, 2009." put "Follow the steps below and upload before this date: 06-01-2009" for locales. 4/ there is a commented out javascript file include in the footer, should be removed. 5/ there are placeholders for 2 future videos, so it means that there is maintenance work for localizers that will have to update the files with new video descriptions over time, when will these updates be required? I need to communicate these dates to localizers so as to pick locales that are able to do the initial localization *and* update the file when new text is added.
one more thing, there is a download block for 3.5 beta in a sidebar, by the time this page goes public, Firefox 3.5RC1 should have been already released.
mmm, my comments should probably go to bug #490697 actually...
(In reply to comment #52) > mmm, my comments should probably go to bug #490697 actually... Good comments in #50 and #51, but let's address them in bug #490697 like you said. As for this bug, it seems pretty much finished. Stephen, can we resolve it?
(In reply to comment #53) <snip> > As for this bug, it seems pretty much finished. Stephen, can we resolve it? I think there's one case left (and it seems to be a regression); here are the steps to reproduce: Fill in all required information except for the reCaptcha, attach a file, and click "Upload Your Video" -- you go through the upload process only to be rejected because "The Captcha information you entered does not match. Please try again." I'm not sure this should block, though, because there's no way for us to know what the correct reCaptcha responses are (so no way to validate user input against those correct answers). However, Alex: couldn't we just add another quick local JavaScript check to ensure the .value of the reCaptcha field isn't null or an empty string? (i.e. check to ensure that the user at least typed in _something_).
Sure, we could add an empty check. I agree uploading your file only to find out you got the Recaptcha wrong sucks. Unfortunately, async. validation doesn't exist for Recaptcha, afaik.
(In reply to comment #55) > Sure, we could add an empty check. > > I agree uploading your file only to find out you got the Recaptcha wrong sucks. > Unfortunately, async. validation doesn't exist for Recaptcha, afaik. If we can get that fixed (and verified), this bug is all good from my side; Pascal has noted a bunch of issues in bug 490697, which are being addressed there.
Are the files in http://viewvc.svn.mozilla.org/vc/projects/fastestfox/trunk/views/en-US/?pathrev=25680 the only one required ? BTW, I don't think I have access to this repo.
confirmed, I don't have access.
a couple of files really have nothing to translate, no objection to me putting the scarse strings in variables at the top like that? http://pastebin.mozilla.org/654029
Hi, Stephend, I'll work on that Recaptcha check today, should be quick. Pascal, yes, the views files with all the strings are located at, http://svn.mozilla.org/projects/fastestfox/trunk/views/ Please note, the test/ de/ and es/ dirs are placeholders for testing. They can be removed and replaced with en-US. They should NOT be used as starting points for l10n, because the views are out of date. I've filed bug 495460 to give Pascal SVN access. (In reply to comment #59) > a couple of files really have nothing to translate, no objection to me putting > the scarse strings in variables at the top like that? > > http://pastebin.mozilla.org/654029 Looks fine to me.
r26566 checks in the recaptcha check. While I was at it, I did a couple other things, * added the same empty check for name and file fields (these ones aren't user facing) * moved JS to an external file * added jquery * during file validation, check if it's empty first, then validate error and type
Fantastic, thanks Alex! Anything left to do here before we launch on Monday?
(In reply to comment #62) > Fantastic, thanks Alex! > > Anything left to do here before we launch on Monday? Yes; I have to re-test the error conditions/messaging once more, then we should be all set.
"Please fill out the attached form and fax to Fastest Firefox at 1-650-903-0875" Can you give me the number in international format ? Is it +1-650-903-0875?
<li><a href="parental-consent-fastest-firefox.doc">Parental Consent Form</a> (Word version)</li> can we have an odf version as well?
(In reply to comment #64) > "Please fill out the attached form and fax to Fastest Firefox at > 1-650-903-0875" > > Can you give me the number in international format ? Is it +1-650-903-0875? Yes, good catch. Also, Alex, can you amend the text on the consent page to read: "Please fill out the attached form and fax to Fastest Firefox at 1-650-903-0875 or email fastestfirefox@mozilla.com." (In reply to comment #65) > can we have an odf version as well? Great catch. Per an IM conversation, Pascal will be uploading this version in a bit.
No longer depends on: 492878
I put the email as a mailto link, ok for you? <p>If your video includes a child under 18, we'll need parental consent before we can use it. Please fill out the attached form and fax to Fastest Firefox at 1-650-903-0875 or email <a href="mailto:fastestfirefox@mozilla.com">fastestfirefox@mozilla.com</a></p>
(In reply to comment #68) > I put the email as a mailto link, ok for you? > > <p>If your video includes a child under 18, we'll need parental consent > before we can use it. Please fill out the attached form and fax to Fastest > Firefox at 1-650-903-0875 or email <a > href="mailto:fastestfirefox@mozilla.com">fastestfirefox@mozilla.com</a></p> Perfect, thanks. In other news, we're launching this page on Monday morning (Pacific time) so I'm bumping it up to critical. Gotta get the loose ends tied up soon.
Severity: normal → critical
I have removed the dummy es, de and test locales and added the first real locale done, ro (Romanian). I am not seeing http://fastestfox.stage.mozilla.com/?lang=ro online yet, how often is the cron job between svn and http://fastestfox.stage.mozilla.com/ ran?
I don't think there is a cron running, I committed changes 2 hours ago on svn and nothing as changed on the staging site, this should be fixed asap as I need to test the localized upload pages as they are created. Also, I am assuming that just adding a folder containing the localized template with the right locale name is enough, but if this is not enough and some settings file has to be updated, I should either have access to this file or Alex should update it as he sees locales added to SVN.
Yes, I also noticed last night that stage was not updating. I've filed bug 495616 with IT There is an active languages array which will need to be updated with new locales. I can update this as needed. I've fixed the parental consent form (added email and ODF format) just waiting on it to show on stage. Cheers
OK, stage is updating again. Consent page changes are showing up. r26650 removes test, es, de from active locales, add ro.
please add fr and nl to the array, committed in r26652 Is that ok for you guys to keep this bug open until the release to follow the addition of new locales to the site or do you prefer using another communication channel like email?
(In reply to comment #74) > Is that ok for you guys to keep this bug open until the release to follow the > addition of new locales to the site or do you prefer using another > communication channel like email? I'm fine with leaving this bug open as long as Stephen adds a comment when he thinks it's ready from a basic technical perspective. Or, maybe we should file a new bug to track the localizations? (great to see them start to roll in, btw!)
ok, closing this one. Tracker bug for localization of the project is: Bug #495632 You can also see it oin the web dashboard: http://l10n.mozilla.org/webdashboard/?project=7&task=Firefox+3.5+marketing+mini-sites
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
http://fastestfox.stage.mozilla.com/submit.php?lang=en-US The page has Mozilla Corporation, 1981 Landings Drive, Bldg. K, Mountain View, CA 94043-0801 as the current address.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #77) > http://fastestfox.stage.mozilla.com/submit.php?lang=en-US > The page has Mozilla Corporation, 1981 Landings Drive, Bldg. K, Mountain View, > CA 94043-0801 as the current address. Thanks Raymond - that's a good catch, but I just closed down the submissions in bug 500836, so I think we're ok leaving this one as is.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
verified fixed http://fastestfox.stage.mozilla.com/
Status: RESOLVED → VERIFIED
Component: www.mozilla.org/firefox → www.mozilla.org
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: