Closed
Bug 556378
Opened 15 years ago
Closed 15 years ago
AMO: Add WebTrends Tags
Categories
(addons.mozilla.org Graveyard :: Statistics, defect, P3)
addons.mozilla.org Graveyard
Statistics
Tracking
(Not tracked)
VERIFIED
FIXED
5.10
People
(Reporter: bcutler, Assigned: clouserw)
References
()
Details
(Whiteboard: [z][r])
Attachments
(2 files, 4 obsolete files)
20.31 KB,
patch
|
jbalogh
:
review+
|
Details | Diff | Splinter Review |
723 bytes,
patch
|
jbalogh
:
review+
|
Details | Diff | Splinter Review |
We are now using WebTrends to track our web analytics. Please sample Addons.mozilla.org traffic at 50%. Below you'll find directions from Dan Bohling (WebTrend's Senior Solution Engineer):
"Attached are two documents. First one is the doc for the initial deploy across the discussed sites below. Second is the zip file of the actual tag to use.
I’ve only included one tag, we will use the SAME tag across all sites, only difference will be there are three “tokenized” items in the tag that has to be replaced prior to deploy. The solutions doc covers all of that.
I will be setting up the actual profiles shortly, datasources are already setup in your account to received the identified DCSID’s."
Reporter | ||
Comment 1•15 years ago
|
||
Reporter | ||
Updated•15 years ago
|
Summary: Remove SiteCatalyst Tags and Add WebTrends Tags → AMO: Remove SiteCatalyst Tags and Add WebTrends Tags
Comment 2•15 years ago
|
||
This should be in both [r] and [z]. We can also remove the Urchin tags.
OS: Mac OS X → All
Priority: -- → P3
Hardware: x86 → All
Target Milestone: --- → 5.9
Updated•15 years ago
|
Group: mozilla-confidential
Assignee | ||
Comment 3•15 years ago
|
||
From webtrends.html:
> <!-- Warning: The two script blocks below must remain inline. Moving them to an external -->
> <!-- JavaScript include file can cause serious problems with cross-domain tracking. -->
Please give us more details about what "serious problems" can occur and how we can avoid them. In order to follow CSP we aren't allowing any inline JS on AMO.
Comment 4•15 years ago
|
||
webtrends.js is running document.write and is mutating the global Function prototype: `Function.prototype.wtbind`. Calling document.write prevents us from making this script async. I don't know of a reason we need to stall page load to run the analytics code.
Reporter | ||
Comment 5•15 years ago
|
||
This is out of my realm, but shouldn't the JS go at the bottom of the page, before the close body tag? Will we still take a performance hit by making this change?
Reporter | ||
Comment 6•15 years ago
|
||
Wil, I'm looking into your questions.
Assignee | ||
Comment 7•15 years ago
|
||
(In reply to comment #6)
> Wil, I'm looking into your questions.
Thanks. https://wiki.mozilla.org/Security/CSP is what I'm talking about. It doesn't have wide (any?) use right now, so our objections are probably new.
Comment 8•15 years ago
|
||
(In reply to comment #5)
> This is out of my realm, but shouldn't the JS go at the bottom of the page,
> before the close body tag? Will we still take a performance hit by making this
> change?
From http://dev.w3.org/html5/spec/embedded-content-0.html#document.write:
> Unless called from the body of a script element while the document is being
> parsed, or called on a script-created document, calling this method will clear
> the current page first.
All of our javascript waits until the page is done loading. The use of document.write in webtrends.js forces it to run while the page is loading, which is going to delay our js (and we want our js to run first since it can affect the look and layout of the page).
Reporter | ||
Comment 9•15 years ago
|
||
okay, thanks Jeff. I'm checking with WebTrends and will let you know when I hear back.
Reporter | ||
Comment 10•15 years ago
|
||
Response from WebTrends:
"We’ve had similar requests. The warning is there to discourage the uninitiated (Here be dragons). You can combine all of the inline code into two include file example wtbase.js and wtcollect.js. You can see these in use on several sites (e.g www.depend.com).
The wtcollect.js just contains the call
_tag.dcsCollect();
The wtbase.js has the following lines added to the bottom
var _tag=new WebTrends();
_tag.dcsGetId();
Samples attached. I’m looking into the document.write question."
Reporter | ||
Comment 11•15 years ago
|
||
Reporter | ||
Comment 12•15 years ago
|
||
Assignee | ||
Updated•15 years ago
|
Target Milestone: 5.9 → 5.10
Updated•15 years ago
|
Summary: AMO: Remove SiteCatalyst Tags and Add WebTrends Tags → AMO: Remove Omniture Tags and Add WebTrends Tags
Comment 13•15 years ago
|
||
Thanks Ken for CCing me. As discussed, I am in need of collecting data from web trends about what are the "top searched for" add-ons that have received a response of add-on not available.
This data would be able to help boot strap jetpack add-ons eco system with most desired add-ons that are not yet available in AMO.
Thanks
Murali
Assignee | ||
Comment 14•15 years ago
|
||
The only thing we're waiting on here is the document.write question. We're scheduling the next AMO milestone on Tuesday. If we don't have this then it'll have to be bumped again.
Reporter | ||
Comment 15•15 years ago
|
||
WebTrends unfortunately doesn't have a ready fix for the document.write question.
Comment 16•15 years ago
|
||
Filed bug 558457 to remove the Omniture tags sooner to avoid hefty costs.
Summary: AMO: Remove Omniture Tags and Add WebTrends Tags → AMO: Add WebTrends Tags
Assignee | ||
Updated•15 years ago
|
Assignee: nobody → clouserw
Whiteboard: [z][r]
Assignee | ||
Updated•15 years ago
|
Attachment #436704 -
Attachment mime type: application/octet-stream → text/plain
Assignee | ||
Updated•15 years ago
|
Attachment #436705 -
Attachment mime type: application/octet-stream → text/plain
Assignee | ||
Comment 17•15 years ago
|
||
wtbase has a pile of hardcoded settings at the top of it. Where is the documentation for those?
One of the settings, mappings, requires us to hardcode all of our domains. I can't do this for our development domains because they vary and change too much, but if the JS is loaded on a domain that isn't specified it throws a JS error. If it's running on an unspecified domain it should fail silently. Error:
mappings[host] is undefined
Comment 18•15 years ago
|
||
(In reply to comment #17)
> wtbase has a pile of hardcoded settings at the top of it. Where is the
> documentation for those?
It's in the docx file. On mozilla.com, I replaced those by dropping an "options" JSON object into the analytics call. If AMO only has a single tracking tag, you can also just hardcode them in the JS file.
Code:
http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/includes/js_stats.inc.php?revision=66017&view=markup
http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/js/webtrends.js?revision=66017&view=markup
Assignee | ||
Comment 19•15 years ago
|
||
(In reply to comment #18)
> (In reply to comment #17)
> > wtbase has a pile of hardcoded settings at the top of it. Where is the
> > documentation for those?
> It's in the docx file. On mozilla.com, I replaced those by dropping an
> "options" JSON object into the analytics call. If AMO only has a single
> tracking tag, you can also just hardcode them in the JS file.
I'm talking about all the undocumented options in base.js. Like this.i18n is False - should it be True?
More importantly than all that, this bug is blocked on my question about mappings in comment 17.
Assignee | ||
Comment 20•15 years ago
|
||
Also, a minor concern, but what do you want the timezone set to? I'm assuming -8 and they'll take care of PDT on their end.
Assignee | ||
Comment 21•15 years ago
|
||
I'm waiting on files and or instructions for this. I can modify the files we have, but it sounds like they might not be the right ones now and I'm not sure why I would be modifying their code anyway.
Code freeze is in a few days, this needs to get done or I'll have to bump it to the next milestone.
Comment 22•15 years ago
|
||
Looking at the document.writes in the code:
The first one writes another script tag to include /wtid.js from our domain. We can concatenate that with wtbase.js and remove that document.write.
The second one creates an <img> tag if document.images isn't available. I don't know where document.images would be unavailable, but that can be changed to use document.createElement easy enough.
The third writes some debug stuff, which I don't really care about.
As Wil said, I'm not excited about modifying their code. Can we get them to fix this upstream?
Reporter | ||
Updated•15 years ago
|
Group: mozilla-confidential
Reporter | ||
Comment 23•15 years ago
|
||
Will, the files and instructions are in the 1st two attachments (Zip file of tag & Doc for initial deploy).
Assignee | ||
Comment 24•15 years ago
|
||
The first two attachments don't match the .js files you attached, so I guess I'm not understanding what we're doing here. The last .js files attached above will work, but they have some issues that we'd rather webtrends fix instead of us.
I'm in the office today in G - do you have time to come by?
Assignee | ||
Comment 25•15 years ago
|
||
r? jbalogh since he had the most comments about this stuff. Here is the patch for remora.
Attachment #436292 -
Attachment is obsolete: true
Attachment #436293 -
Attachment is obsolete: true
Attachment #436704 -
Attachment is obsolete: true
Attachment #436705 -
Attachment is obsolete: true
Attachment #441820 -
Flags: review?(jbalogh)
Assignee | ||
Comment 26•15 years ago
|
||
And here is zamboni's patch. Untested, because it will use the file after the remora patch is committed. I'm keeping it out of our bundle so it can execute deferred at the very end of the page.
Attachment #441824 -
Flags: review?(jbalogh)
Comment 27•15 years ago
|
||
Comment on attachment 441820 [details] [diff] [review]
patch for remora
I don't think you need DCSIMG on the alt tag.
I'm not excited about Function.prototype.wtbind, so I guess we'll see if that breaks anything.
Attachment #441820 -
Flags: review?(jbalogh) → review+
Comment 28•15 years ago
|
||
Comment on attachment 441824 [details] [diff] [review]
zamboni patch
>diff --git a/templates/base.html b/templates/base.html
>index 77275cf..353e7c3 100644
>--- a/templates/base.html
>+++ b/templates/base.html
>@@ -74,5 +74,14 @@
> <script async defer src="{{ url('addons.buttons.js') }}"></script>
> {% block js %}{% endblock %}
> {% include "footer.html" %}
>+ {# Webtrends Stats Tracking #}
>+ <script defer src="{{ MEDIA_URL }}js/webtrends/webtrends.js') }}"></script>
This should probably have async too. I don't remember what they do or why I have both, so let's just throw it all in there.
>+ <noscript>
>+ <div>
>+ <img alt="DCSIMG" id="DCSIMG" width="1" height="1"
>+ src="https://statse.webtrendslive.com/dcso6de4r0000082npfcmh4rf_4b1e/njs.gif?dcsuri=/nojavascript&WT.js=No&WT.tv=8.6.2" />
>+ </div>
The <div> and alt seem unnecessary.
Attachment #441824 -
Flags: review?(jbalogh) → review+
Assignee | ||
Comment 29•15 years ago
|
||
(In reply to comment #28)
> (From update of attachment 441824 [details] [diff] [review])
> >diff --git a/templates/base.html b/templates/base.html
> >index 77275cf..353e7c3 100644
> >--- a/templates/base.html
> >+++ b/templates/base.html
> >@@ -74,5 +74,14 @@
> > <script async defer src="{{ url('addons.buttons.js') }}"></script>
> > {% block js %}{% endblock %}
> > {% include "footer.html" %}
> >+ {# Webtrends Stats Tracking #}
> >+ <script defer src="{{ MEDIA_URL }}js/webtrends/webtrends.js') }}"></script>
>
> This should probably have async too. I don't remember what they do or why I
> have both, so let's just throw it all in there.
The way I read the first hit on google (http://www.quackit.com/html_5/tags/html_script_tag.cfm) is if async is in there it will run immediately, despite the defer, so I left it out.
>
> >+ <noscript>
> >+ <div>
> >+ <img alt="DCSIMG" id="DCSIMG" width="1" height="1"
> >+ src="https://statse.webtrendslive.com/dcso6de4r0000082npfcmh4rf_4b1e/njs.gif?dcsuri=/nojavascript&WT.js=No&WT.tv=8.6.2" />
> >+ </div>
>
> The <div> and alt seem unnecessary.
Comment 30•15 years ago
|
||
(In reply to comment #29)
> > This should probably have async too. I don't remember what they do or why I
> > have both, so let's just throw it all in there.
>
> The way I read the first hit on google
> (http://www.quackit.com/html_5/tags/html_script_tag.cfm) is if async is in
> there it will run immediately, despite the defer, so I left it out.
You're right, defer seems to be what we want here. Maybe we should remove defer from the button script and just have it async?
I'm using http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html as a reference.
Assignee | ||
Comment 31•15 years ago
|
||
Remora: r66512
Zamboni: http://github.com/jbalogh/zamboni/commit/6d86528e4549bb80948c740269cc45dbdfbc56c6 and http://github.com/jbalogh/zamboni/commit/de8817fe16dae6a81513f0bf059491241edd5bfd
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Verified FIXED on both Remora/Zamboni (same file/location/request):
Remora: GET webtrends.js
https://preview.addons.mozilla.org/js/webtrends/webtrends.js
304 Not Modified
preview.addons.mozilla.org
18.2 KB
Status: RESOLVED → VERIFIED
Updated•9 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•