Closed Bug 689790 Opened 13 years ago Closed 13 years ago

[Join Mozilla]: Test new donation page: 9/27/11

Categories

(Websites :: donate.mozilla.org, defect)

Product:
Websites
Component:
donate.mozilla.org
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bsimon, Assigned: mozwebqa)

References

Details

We are launching a new donation campaign, asking folks to attend the Mozilla Festival or make a donation to Mozilla if they cannot make it. The festival page has already been reviewed, but the new "can't attend" page needs to be looked at. It's built off of an existing Blue State Digital donation page (Mozilla Foundation's Payment processor -- it's based on a previously tested page), and needs QA: https://donate.mozilla.org/page/contribute/help-mozilla-build-a-better-web-no-attend

Please note that BSD does not have a staging environment, so the page itself is live.
Possible to take a look at this today or tomorrow? We're hoping to launch tomorrow.

Thanks!
(In reply to Ben Simon from comment #1)
> Possible to take a look at this today or tomorrow? We're hoping to launch
> tomorrow.
> 
> Thanks!

We're testing this today, and will update as soon as we're finished (with results).
Assignee: nobody → mozwebqa
OS: Mac OS X → All
Hardware: x86 → All
How come it depends on the new bug? Isn't that for a very different page?
(In reply to Ben Simon from comment #3)
> How come it depends on the new bug? Isn't that for a very different page?

You asked us to test https://donate.mozilla.org/page/contribute/help-mozilla-build-a-better-web-no-attend, and that page is where I end up.  I'm sorry, to which "very different page" are you referring?

Here's a screencast: http://screencast.com/t/dDWZZoX5, in case that helps.
Are we now resolved, b/c of the traffic on the other bug? 

My confusion was b/c the url you reported in bug 690421 was here: https://donate.mozilla.org/page/contribute#act-3, while the url we're pointing people to is here: https://donate.mozilla.org/page/contribute/help-mozilla-build-a-better-web-no-attend

The screencast doesn't actually get to where the problem occurs (stops once the error appears), but it seems like we're now good?

Thanks!
Some small things I noticed:
When entering a very large number: Error message "Amount must be a number" although it is a number, just a very high one.

Also, ZIP code takes letters also, does not bail out with an error message.
(In reply to Tobias Markus (:Tobbi) [tmarkus@mozilla.com] from comment #7)
> Also, the site does not validate. Validation results:
> http://validator.w3.org/check?uri=https%3A%2F%2Fdonate.mozilla.
> org%2Fpage%2Fcde%2FContribution%2FCharge%23act-
> 3&charset=%28detect+automatically%29&doctype=Inline&group=0

BSD pages don't validate; known, but thanks for testing that.
When entering an @ in the ZIP Postal code field, you get two error messages that are the same:
http://screencast.com/t/yDpkSdHPHRD1 (ZIP/Postal code and "Not a valid ZIP/Postal Code)
URL: https://donate.mozilla.org/page/contr...
If I put the following string in the credit card number field: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 00000000000000000000000000 I do not get an error message that the credit card number is invalid.

See screenshot http://screencast.com/t/IpBS0kY6FMS (values in the background)
(In reply to Tobias Markus (:Tobbi) [tmarkus@mozilla.com] from comment #9)
> When entering an @ in the ZIP Postal code field, you get two error messages
> that are the same:
> http://screencast.com/t/yDpkSdHPHRD1 (ZIP/Postal code and "Not a valid
> ZIP/Postal Code)

Disregard that. It does, after submission.
(In reply to Tobias Markus (:Tobbi) [tmarkus@mozilla.com] from comment #9)
> When entering an @ in the ZIP Postal code field, you get two error messages
> that are the same:
> http://screencast.com/t/yDpkSdHPHRD1 (ZIP/Postal code and "Not a valid
> ZIP/Postal Code)

Disregard that. It does, after submission.
You're able to put a $ sign in each text field, which passes, apparently. Can we exclude certain characters from the field that are not going to appear in any context?
Ben: the issues we've found are noted, above.  You may ship or not as you see fit.  I would suggest that comment 13 is addressed before shipping, though.
Thanks, Stephen. We're looking into what that would take on the development side.
Stephen: Do you have a list of characters you'd recommend excluding, which would never be used for any of these fields?
(In reply to Ben Simon from comment #16)
> Stephen: Do you have a list of characters you'd recommend excluding, which
> would never be used for any of these fields?

I can imagine that characters such as (but not limited to): @!#$%^*()-+_=<>?/;:{}?/ would be disallowed in name, country, street, ZIP/postal code fields, but, in talking with Web Development here, it's probably best to do a whitelist approach: what are the values that you anticipate being valid, for each field (given the list of supported continents/countries) -- start there, and ignore the rest.

I'd think that BSD has such a list (of course, I thought Web Dev did too, but it varies.)  Does this help?
Aren't there instances, though, where some of those characters could be used in names or addresses? Especially thinking about hashtags (unit numbers), hyphens, some math signs, parentheses, and slashes. Why don't we just exclude the nonsense characters that couldn't be in any of those fields? 

Seems to me like the risk of wrongly excluding a character is a bigger problem from an end-user perspective than allowing something extra in, right? So I'd think we'd just want to exclude, say:

$%^*_{}
Haven't heard anything more on this...are we ok not trying to limit these extra characters? Seems like it might be more trouble than it's worth, given the potential for wrongly excluding a submission.

thanks much
I reviewed the page, but did not find additional bugs.
Thanks, Rebecca; Ben, you can ship/link to this page now.  Sorry for the delay!
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Thanks all
You need to log in before you can comment on or make changes to this bug.