This is a WIP so expect lots of edits for a while

The following JS files still require unit tests:

Base

• media/js/base/mozilla-accordion-gatrack.js
• media/js/base/mozilla-input-placeholder.js
• media/js/base/mozilla-modal.js
• media/js/base/mozilla-share-cta.js
• media/js/base/mozilla-video-poster.js
• media/js/base/mozilla-video-tools.js
• media/js/base/nav-main-resp.js
• media/js/base/nav-main.js
• media/js/base/svg-animation-check.js

The following functional tests/checks have been identified as desirable to improve test coverage:

• Viewing Mozilla Spaces on a mobile viewport
• Viewing Mozilla Communities on a mobile viewport
• Checking page footer is displayed on at least one page
• Checking 404 page components are displayed
• Thunderbird download pages
• Firefox Desktop pages
• Firefox for iOS page
• Firefox channel page
• Firefox installer help page
• SmartOn pages
• Android page sent-to-device form test (blocked by #3534)
• Firefox Products page conditional messaging for Android, iOS, out-of-date Firefox.
• Plugincheck page tests for both none and one (or more) plugins using Firefox.
• Sync page conditional messaging for Android, iOS, out-of-date Firefox.
• Firefox family navigation scroll tests, plus mobile viewport test.
• Firefox OS 2.5 page news feed is displayed test (pending #3709)
• Add test for partnerships form (see: https://github.com/mozilla/mcom-tests/blob/master/tests/test_partnerships.py#L33)

If a page only exists on the en-US site, accessing it with any other locale should fallback to en-US.

For example: the /en-US/apps/ page exists, and only on en-US. /fr/apps should redirect to /en-US/apps.

So it is becoming pretty common for people to set all elements to box-sizing:border-box using the universal selector by default as it is awesome ;) and does not cause any particular performance overhead @see http://www.paulirish.com/2012/box-sizing-border-box-ftw/

The problem is though. if you do this on a page that includes tabzilla, the tabzilla layout breaks and the image and bullet list is stacked one on top of the other (This page currently shows the behavior http://oneanddone.balwiki.com/en-US/login/?next=/en-US/tasks/available/)

Not sure if this is something we want to fix inside of tabzilla or whether it is just a caveat we want to make people aware of in the docs.

In the past few weeks, the www-dev site started auto-prefix /b/ to links when the page is served up from /b/. If it's not served from /b/ it doesn't prepend /b/ to the links.

Magic.

And I hate magic! I want to know what's doing this. I had built in the auto-prefixing but it broke when this started happened (urls had TWO /b/ in them).

There's a helper function on the old PHP site that helps output screenshots for the platform you're currently browsing from. We'll need to port this over to Bedrock.

The current PHP function, buildPlatformImage() takes a filename and a list of (pre-set) platforms (mac, linux, xp). It then outputs inline javascript to write the image for the platform you are currently running.

If the platform can't be determined or doesn't match our pre-set list, we fall-back to the default screenshot, which is for Windows. The function also outputs a tag with the windows image tag.

The inline scripts and the document.write method is to ensure that visitors only load/see the image for their platform, rather than starting a default and interrupting (and maybe visually flashing in) with the detected platform image.

The other fanncy-ish thing the PHP function does is determine the mac/linux image filenames automatically based on the default image filename. The filenames work like this:

Default (win): filename.ext
Mac: filename-mac.ext
Linux: filename-linux.ext

The .ext can be any image extension (.png, .gif, .jpg, etc.).

We basically need a direct port of the existing PHP function.

An example of this function in use can be found on /en-US/firefox/security/

Note: test will be en-us only but hopefully bring us closer to a new version of this page that will work better for all locales.

https://www-demo4.allizom.org/en-US/contribute/signup/

The issue can be seen here:
https://www-dev.allizom.org/en-US/firefox/29.0beta/releasenotes/
"A set of new improvements to the Firefox user interface" has a priority of 3000 while the malay locale has a priority of 0. "A set of..." is still last in the new features.

A more general question, why do Mozilla implement input fields on their websites without associating a descriptive label?

On http://www.mozilla.org/en-US/ there are 4 input fields (including the one in tabzilla) 3 of them does not have a associated label!

It's a level A guideline of the WCAG 2.0 http://www.w3.org/TR/2008/REC-WCAG20-20081211/#minimize-error-cues and I cant see why it isn't followed

A very common use case of mozilla.org is to have top-level redirects like mozilla.org/b2g which would redirect to a b2g wiki page.

It would alleviate workload and help engagement if we could allow them to manage these redirects themselves. No idea how this should work, as speed is an issue. I doubt we want to load up all of django just to do a redirect, or do we? Zeus caches them anyway.

Commit a015130 introduced a downlevel-revealed conditional comment, which has caused a problem with our LinkChecker. I have raised this against LinkChecker (wummel/linkchecker#630), however @alexgibson suggests that we may be able to revert this change.

This says it's tri-licensed but shouldn't it be BSD? Otherwise you need to stick the pre-amble everywhere.

Item 1 in the Windows 10 welcome page [1] says "Click the button below", but the button is actually above the text.

[1] https://github.com/mozilla/bedrock/blob/master/bedrock/firefox/templates/firefox/win10-welcome.html#L54

Below is a list of all (well most) of the pages that make up mozilla.org

The intention here is to keep track of all of the pages and mark those that already have functional tests, written using Casperjs, and those still in need of functional tests.

Mozilla

• https://www.mozilla.org/en-US/
• https://www.mozilla.org/en-US/about/
• https://www.mozilla.org/en-US/mission/
• https://www.mozilla.org/en-US/newsletter/
• https://www.mozilla.org/en-US/contact/spaces/
• https://www.mozilla.org/en-US/about/history/
• https://www.mozilla.org/en-US/plugincheck/
• https://www.mozilla.org/en-US/styleguide/

Community

• https://www.mozilla.org/en-US/contribute/
• https://www.mozilla.org/en-US/contribute/friends/
• https://www.mozilla.org/en-US/contribute/events/
• https://www.mozilla.org/en-US/contribute/stories/
• https://www.mozilla.org/en-US/contribute/stories/faye/
• https://www.mozilla.org/en-US/contribute/signup/

Firefox OS

• https://www.mozilla.org/en-US/firefox/os/2.0/
• https://www.mozilla.org/en-US/firefox/os/devices/
• https://www.mozilla.org/en-US/firefox/os/devices/tv/
• https://www.mozilla.org/en-US/firefox/os/faq/

Firefox

• https://www.mozilla.org/en-US/firefox/tiles/
• https://www.mozilla.org/en-US/firefox/partners/
• https://www.mozilla.org/en-US/firefox/products/
• https://www.mozilla.org/en-US/firefox/personal/
• https://www.mozilla.org/en-US/firefox/new/
• https://www.mozilla.org/en-US/firefox/android/
• https://www.mozilla.org/en-US/firefox/sync/
• https://www.mozilla.org/en-US/firefox/hello/
• https://www.mozilla.org/en-US/firefox/dnt/
• https://www.mozilla.org/en-US/firefox/developer/
• https://www.mozilla.org/en-US/firefox/desktop/
• https://www.mozilla.org/en-US/firefox/desktop/trust/
• https://www.mozilla.org/en-US/firefox/desktop/customize/
• https://www.mozilla.org/en-US/firefox/desktop/fast/

Persona

• https://www.mozilla.org/en-US/persona/
• https://www.mozilla.org/en-US/persona/about/
• https://www.mozilla.org/en-US/persona/terms-of-service/

Governance

• https://www.mozilla.org/en-US/about/governance/
• https://www.mozilla.org/en-US/about/governance/roles/
• https://www.mozilla.org/en-US/about/governance/policies/
• https://www.mozilla.org/en-US/about/governance/organizations/
• https://www.mozilla.org/en-US/about/leadership/
• https://www.mozilla.org/en-US/about/partnerships/
• https://www.mozilla.org/en-US/about/forums/

Privacy

• https://www.mozilla.org/en-US/privacy/
• https://www.mozilla.org/en-US/privacy/firefox/
• https://www.mozilla.org/en-US/privacy/websites/
• https://www.mozilla.org/en-US/privacy/firefox/
• https://www.mozilla.org/en-US/privacy/firefox-os/
• https://www.mozilla.org/en-US/privacy/firefox-cloud/
• https://www.mozilla.org/en-US/privacy/firefox-hello/
• https://www.mozilla.org/en-US/persona/privacy-policy/

Legal

• https://www.mozilla.org/en-US/about/legal/
• https://www.mozilla.org/en-US/about/legal/terms/mozilla/
• https://www.mozilla.org/en-US/about/legal/terms/services/
• https://www.mozilla.org/en-US/about/legal/terms/firefox-hello/
• https://www.mozilla.org/en-US/about/legal/terms/firefox/
• https://www.mozilla.org/en-US/about/legal/terms/thunderbird/
• https://www.mozilla.org/en-US/about/legal/fraud-report/

Foundation

• https://www.mozilla.org/en-US/foundation/licensing/
• https://www.mozilla.org/en-US/foundation/trademarks/policy/

Thunderbird

• https://www.mozilla.org/en-US/thunderbird/
• https://www.mozilla.org/en-US/thunderbird/features/
• https://www.mozilla.org/en-US/thunderbird/organizations/

Components

• Family Navigation

Webtrends does a lot of inline JS and onclick="" handlers. All of this does not only violate CSP, this is also a huge mess and a maintainability nightmare.

We should pull out the tracking stuff into a separate file (webtrends.js, perhaps) and subject it to the same minification as all other JS.

For the click handlers, there's no reason why we can't just select elements by tagname and hook tracking up to the click event properly.

If we want more fine-grained control, use a class on the link to opt-in or out, or put data like a tracking token into a data attribute if necessary.

When browsing bedrock websites on a high density display (such as a retina MacBook) Tabzilla does not have a high density Mozilla logo. See screenshot below.

Perhaps an SVG can be used for this resource to prevent having to maintain different display density images.

I haven't looked at the download buttons in a long time, and I really need to flesh them out more and make sure the API is good before they are all over the place.

The download buttons output some markup if the platform is "other", meaning mac, linux, or windows was not detected. Currently this markup doesn't have good styles. Should be a quick thing to fix.

You can test this by setting site.platform to "other" in site.js.

Currently we're accumulating empty views for no great reason. In the urlconf, we could just use lambda req: render(req, 'mytemplate.html') instead of pointing to a separate view, but this is still quite a bit too wordy and inconvenient.

Two ideas so far:

• Make a shorthand notation for the lambda thing: t('mytemplate.html') would return a function doing the above.
• Make a function that will take a path stub and a template directory and will turn all templates it finds into URL patterns automatically:

templatedir_to_url(urlconf, '/firefox', 'mozorg/firefox')
would look for templates in mozorg/firefox and generate URL patterns for those, prepend them with /firefox, and append them to urlconf.

We can of course do both, or either.

Need to validate the following address that are in use as from addresses:

• [email protected]
• [email protected]

http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.mozilla.org%2Fen-US%2F

use required="required" or only required

Paul, would you mind sticking django_jobvite into vendor-local? (I assume that's how we do things in Playdoh, right @fwenzel?)

See these lines.

Looks like we have a github repo for Fira. I propose we update these links to be based off of the repo in order to keep the version linked by the styleguide up to date automatically.

Have a button with a property over, see there

I delete the property margin-top of the rule {.fxfamilynav-cta-wrapper .send-to} and this works, you need a pull-request or anyone can handle this.

To make it easy to show videos, we should have a video template tag.

In https://github.com/mozilla/bedrock/blob/e3f844ae8bb58aed6971db7316f2b2fd6e6b02c8/bedrock/firefox/firefox_details.py we say,

Android Honeycomb (3.x) was supported on Firefox 45 and below

    if int(self.latest_version(channel).split('.', 1)[0]) < 46:
        platforms['android'] = _('Modern devices\n(Android 3.0+)')

I just posted in release notes for 46 aurora that we don't support Honeycomb, but the download button still says "For Android Honeycomb+".

I'm implementing Tabzilla on the OpenNews site, and noticed that the word "innovations" is dropping the NS down to its own line. This is true in both Aurora (26.0a2) and Chrome (30.0) on a Mac

image below.

I've installed bedrock following this doc:

http://bedrock.readthedocs.org/en/latest/vagrant.html

And I have a functional installation, but the problem is that bedrock is redirecting me all the time to /en-US/es-ES/ urls, so it's impossible to test or work on localized pages.

Also if you try loading any locale page such us /fr/ manually, I always get a /en-US/fr/ and a 404.

Am I doing something wrong or it's a bug?

(My browser language preference order is es-ES, es, en-US, en)

Version 1 of the new signup landing page and task views has been completed and merged. This tracks the implementation of version 2.

The global site UI (header, footer, download buttons) will be served by gettext. We need to decide what to do about short L10n strings inside page templates. Gettext gives us the power of all its tools, but would divide this part of the page from the longer L10n content in L10n blocks.

mozilla.com currently uses a double underscore function for non-gettext strings, that are then looked up in a manifest file. It might be worth considering this for our purposes too. We could drop these strings into the same file as the l10n blocks (as an {% l10n_manifest %} block or something), but would need to write a home-grown toolchain to handle new/deprecated/changed strings.

gettext, in turn, has a mature toolchain, but suffers from the content split problem. Unless we drop the .po file content directly into a block inside the localizable template, as mentioned above. But then it can't directly be edited with .po tools anymore, just a text editor.

What to do? Discuss!

In

"10" > "7"
false
"10" < "7"
true

where as usually you'd get:

"9" > "7"
true
"9" < "7"
false

Maybe the function should add something like parseInt(a[i], 10) to the comparison.

Instead of <div id="strings" data-foo="bar"></div> you could do something like this:

{% block js %}
    {{ js('home') | {
        'close': {{_('Close')}},
        'share': {{_('Share')}}
      }
  }}
{% endblock %}

that generates something like this
<script id="home-js" data-close="Close" data-share="Share" src="//mozorg.cdn.mozilla.net/media/js/home-min.js?build=f446ab8"></script>

If you for example have:

{% extends "sand.html" %}

But you then do the following:

{% block body_class %}privacy{% endblock %}

The sandstone theme will not load and will only load the default stone theme. Not sure if this is intended behavior but seems like one should be able to add your own custom body classes even when using a theme other than the default.

It's difficult for many people to hear/see where long URL's is pointing at, espacially if you are using AT. Therefor, instead of linking the url it's better to link the text before it,

<tr>
  <td>Webtrends</td>
  <td>Website analytics</td>
  <td><a href="http://www.webtrends.com/AboutWebtrends/PrivacyPolicy.aspx">Webtrends Privacy Policy</a></td>
</tr>

As per #3772 we are now using Selenium client v2.49.0 for running tests locally in bedrock.

Quoting @davehunt:

To update the server versions used in the pipeline, we must change the value of SELENIUM_VERSION in the global configuration in Jenkins. Note that this will affect both Sauce Labs and Docker jobs, and it appears that 2.49 is not yet available in docker-selenium. To keep Docker pinned, we can set the SELENIUM_VERSION environment variable within the job configuration that uses Docker.

For what it's worth, the 2.49 client should be fully compatible with the 2.48.2 server, so there's no need to block merging this. If for some reason there is an incompatibility, we can simply revert this commit.

To make it easy to show feeds, we should have a feedparser template tag.

To point to a Django URL, you use URL reversal:

{{ url('myapp.page') }}

That won't work for URLs that are still on PHP, like the front page.

I suggest we make a helper that we can give a relative URL to, but that will auto-add the locale, so:

{{ mozorg_url('/') }}

would resolve to /en-US/.

Plus if we use that helper or old-style URLs, they are easier to find once we consider switching off PHP.

As @retornam noted in the bug, the es-* redirect is failing for the first image (phone screen).
ok: https://www-dev.allizom.org/es-ES/firefox/os/
not ok: https://www-dev.allizom.org/es-MX/firefox/os/

Currently the l10n_check commands parses out all the l10n blocks and blows away all the content outside of them in a localized template. If the localized template has other stuff outside the l10n blocks, it needs to keep it and only update the l10n blocks instead of rewriting the whole file.

This is mostly for my notes and TODOs as I encounter them for bug 1156344.

Other suggestions:

• previously
• currently

The modernizer script is inserted in base.html

<script src="/media/js/libs/modernizr-2.5.0.min.js"></script>

Where is this used?

It looks a bit silly when the rest of the page looks so good.

A little documentation after reviewing the mozilla.com source:

The download button is an absolute messy mix of PHP and javascript.

Every button calls getNoScriptBlockForLocale on the firefoxDetails object which dumps out markup for people with Javascript disabled.

For javascript users, there are two versions of the download button:

1. One that uses download.old.js, and simply dumps a block of javascript on the page to render the button (using a large template string and a bunch of document.write's). download.old.js depends on a big javascript object being dumped by the productDetails object containing details about the versions.
2. The other one uses download.js (which seems to be a newer version) and calls getDownloadBlockForLocale which dumps out javascript that calls into download.js functions. The difference seems to be that it dumps all the needed info into the js inline.

The productDetails class is 1000 lines long with a bunch of functions that mostly just dump HTML to render different ways of downloading Firefox.

This will be one of hardest things to migrate, I think. I don't think it will be possible to do this without cleaning up a lot of it. My hunch is to build a javascript library on top of the json files in product-details (that other projects use). The json can be dumped onto the page and the client-side javascript can take care of the rest. For the javascript disabled, we can build a light jinja helper which dumps out the markup that we do now.

I've noticed that the words on the Arabic page not looking good in (http://www.mozilla.org/ar/). I guess this because of using "letter-spacing" on the text.

Currently, LESS CSS files don't seem to work out of the box. When in DEBUG (development) mode, this should just work [TM]. Perhaps we need to add the appropriate script to the script block, only to be loaded if DEBUG = True. Or something.

Have a look at http://html5boilerplate.com/html5boilerplate-site/built/en_US/docs/html/#make-sure-the-latest-version-of-ie-is-used for more info regarding this.

Maybe this gist can help. https://gist.github.com/113635

This is probably something I have setup wrong in apps/mozorg/urls.py, but:

In the template (apps/mozorg/templates/mozorg/firefox/organizations/organizations.html) for the Firefox for Organizations page (http://www-dev.allizom.org/b/en-US/firefox/organizations), I've got this link on line #43:

{{ url('mozorg.firefox_organizations_faq') }}

but it seems to be outputting the leading /b twice:

href="/b/b/en-US/firefox/organizations/faq/"

Define basic data model for tasks data in JSON. This may or may not be used but it gives us a starting point and a more "codified", if you will, representation of the selected tasks.

Related User Story

STORY #1 As a person who has never contributed to Mozilla before, I see options for how I could contribute to Mozilla, so I can pick a thing to do that will help Mozilla and is the best fit for me.

mozorg is currently a catch-all for a ton of templates. As we're adding more and more pages, this is not sustainable.

Ideally:

• mozorg is the app that contains global things, for this app, such as helpers
• the app structure somewhat follows the feature distinction in this app. I think /firefox /b2g etc. would all qualify as separate apps.
  ** note that these apps can still hook up things to URLs that don't have the same prefix. If b2g has a page under /firefox, that's no problem.