Status

www.mozilla.org
Pages & Content
3 years ago
3 years ago

People

(Reporter: Rene, Unassigned)

Tracking

Production

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [kb=1527755] )

Attachments

(3 attachments, 2 obsolete attachments)

11.49 KB, text/tab-separated-values
Details
25.81 KB, text/tab-separated-values
Details
22.54 KB, text/tab-separated-values
Details
(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140716183446

Steps to reproduce:

Old copy/paste Get Firefox-code should still be supported...

<a title="Get Firefox - The Browser, Reloaded" href="http://getfirefox.com/">
    <img width="178" height="60" border="0" alt="Get Firefox" src="http://www.mozilla.org/products/firefox/buttons/getfirefox_large.png"></img>
</a>

Looks bad on websites that don't actively update their code..


Please check also the error-text on the 404-errorpage:

If you typed in the address, check your spelling. Could just be a typo.
If you’ve found an issue with one of our websites, we’d appreciate it if you could report the problem in Bugzilla, our bug tracker. One of our developers will take a look at it as soon as possible.
If you followed a link, it’s probably broken.
If you’re not sure what you’re looking for, start at mozilla.org

The link to Bugzilla ends up on Mozilla.com, instead of ending up on bugzilla.mozilla.org


Actual results:

The image-source ends up on the mozilla.org 404-errorpage.

Please check the


Expected results:

The thumbnail should be available
We may probably need stats to see how many blogs are still using the button.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(garethcull.bugs)
(Reporter)

Comment 2

3 years ago
I think it's a wrong approach to rely on your logs, and to do a decision based on that. The "damage" has already happened when someone get's to a page and finds a broken link/image/etc.

I think the best way to solve similar issues is to maintain all links to buttons etc you ever have released. The point with such remote images is that you can update them to contain the latest version of whatever content you want people to share. These links should be there forever.

I think it's a really bad policy and ignorance against people browsing the web when webmasters abandon old links when redesigning a website or changing it's underlying engine. This breaks the history of a site. Now when storage is cheap, it's absolutely ridiculous to delete old content and blaim eg. the need to save space.

my 2 cents
Hey Kohei,

I don't have any data on what pages these buttons would appear on. But this is a good idea moving forward, especially for download buttons as it would let me better segment download conversion rates.

Thanks.

Gareth
Flags: needinfo?(garethcull.bugs)

Comment 4

3 years ago
I'm 99% I had IT pull apache logs for these old buttons, while there were some 404s to these URLs, I think they were almost none. This could have been another old URL, but these seem familiar. Let me see if I can dig them up.

Comment 5

3 years ago
I've investigated this further.

1) http://www.mozilla.org/products/firefox/* has been redirected to http://www.mozilla.org/firefox/* and passes along any sub directories via an htaccess redirect given that we no longer use the /products/firefox/ naming structure.

For example, http://www.mozilla.org/products/firefox/foo redirects to https://www.mozilla.org/en-US/firefox/foo

2) http://www.mozilla.org/products/firefox/buttons/getfirefox_large.png gets redirected to https://www.mozilla.org/en-US/firefox/buttons/getfirefox_large.png and that 404's.

3) We would have to check the apache log files to see how many requests are to URLs that contain /firefox/buttons/ as they won't be in Google Analytics because they are probably being requested via an img src.

4) On the legacy php 404 page, the link to bugzilla is https://bugzilla.mozilla.org/enter_bug.cgi?product=www.mozilla.org doesn't appear to be mozilla.com as described in comment 0. 

Here's what I did find in Google Analytics and the amount of monthly pageviews to those 404 URLS.

Page	Pageviews
/en-US/firefox/buttons/getfirefox_88x31.png	23
/en-US/firefox/buttons/firefox_80x15.png	16
/fr/firefox/buttons/firefox_80x15.png	14
/fr/firefox/buttons/getfirefox_88x31.png	12
/de/firefox/buttons/firefox_80x15.png	6
/pt-PT/firefox/buttons/firefox_80x15.png	5
/de/firefox/buttons/getfirefox_88x31.png	4
/el/firefox/buttons/getfirefox_88x31.png	4
/es-ES/firefox/buttons/header.png	2
/fr/firefox/buttons/	2
/fr/firefox/buttons/getfirefox_large2.png	2
/hu/firefox/buttons/firefox_80x15.png	2
/th/firefox/buttons/takebacktheweb_small.png	2
/de/firefox/buttons/getfirefox_large2.png	1
/en-US/firefox/buttons/getfirefox_large.png	1
/en-US/firefox/buttons/getfirefox_large2.png	1
/en-US/firefox/buttons/getfirefox_large3.png	1
/es-ES/firefox/buttons/getfirefox_88x31.png	1
/hu/firefox/buttons/getfirefox_88x31.png	1
/ru/firefox/buttons/getfirefox_88x31.png	1

Most people who have Firefox download banners have switched over to using https://affiliates.mozilla.org/. While a broken image is not ideal, we would have to look at logs to find out if many server requests are being made.

These old buttons weren't deleted to save space. They were on an old SVN repo that used the legacy php system and it made it difficult to convert over to the new python/django based system when maintaining two application frameworks and multiple code repositories.

Jgmize: Do you have access to the log files to see how many URLs are being requested that have "/firefox/buttons/" in them?
Flags: needinfo?(jmize)

Comment 6

3 years ago
:cmore yes, I have access and without diving too deep I did some quick grepping and it looks like we're getting a *lot* more than I expected. Part of this is because each request to the unlocalized path generates a 301 to the localized path, so I'm doing a quick filter for just the 404s, and I decided to look at just one day's worth of data in the interest of time:

[jmize@peach-gw.peach.metrics.scl3 ~]$ zgrep /firefox/buttons/ /mnt/stats_metrics-logger1/stats/logs/zlb1.ops.scl3.mozilla.com/www.mozilla.org.access_2014-09-15*.gz | grep -c '" 404 '
97218

[jmize@peach-gw.peach.metrics.scl3 ~]$ zgrep /firefox/buttons/ /mnt/stats_metrics-logger1/stats/logs/zlb12.ops.phx1.mozilla.com
/www.mozilla.org.access_2014-09-15*.gz | grep -c '" 404 '
88132


So on 9/15 we got over 185,000 404s containing "/firefox/buttons/" between the two datacenters.

I can do further analysis with a larger dataset, but these preliminary results suggest that we will probably want to prioritize getting these button images working again sooner rather than later.
Flags: needinfo?(jmize)

Comment 7

3 years ago
Interesting, Josh! Thanks for the insight.

Now the tricky part comes to decide what to do about those legacy buttons. 

I wonder if we were to 301 redirect all buttons to a button on affiliates.mozilla.org, if that would work suffice?

https://affiliates.mozilla.org/media/uploads/image_banners/b5193a506ded57870dea0b44b45e3092fab1b916.png

The only problem with a 301 is that it requires another HTTP request and then we are relying on affiliates. It may be easier to pick the top 80% of URLs being hit in /firefox/buttons/ and create images for those banners with updated branded and place them at those URLs on mozilla.org.

Josh: Can you provide the list of exact URLs with the count grouped by file named sorted in descending order?
Flags: needinfo?(jmize)

Comment 8

3 years ago
Created attachment 8494608 [details]
2014_button_404s.tsv
Flags: needinfo?(jmize)

Comment 9

3 years ago
Created attachment 8494609 [details]
sept_button_404s.tsv

Comment 10

3 years ago
Created attachment 8494610 [details]
aug_button_404s.tsv

Comment 11

3 years ago
> Josh: Can you provide the list of exact URLs with the count grouped by file
> named sorted in descending order?

:cmore I've attached the full files, and here is a gist of how I got them: https://gist.github.com/jgmize/a14140c203f4580724eb

These numbers are more in line with what I was expecting than what my quick grepping in comment #6 seemed to indicate, but are still pretty significant, I'd say:

$ head 2014_button_404s.tsv aug_button_404s.tsv sept_button_404s.tsv | column -t
==>                                           2014_button_404s.tsv  <==
/fr/firefox/buttons/firefox_80x15.png         75749
/ko/firefox/buttons/getfirefox_small.png      11820
/en-US/firefox/buttons/firefox_80x15.png      8049
/fr/firefox/buttons/getfirefox_88x31.png      3366
/en-US/firefox/buttons/getfirefox_88x31.png   2568
/tr/firefox/buttons/firefox_80x15.png         2279
/it/firefox/buttons/firefox_80x15.png         1855
/en-US/firefox/buttons/getfirefox_small.png   1243
/de/firefox/buttons/firefox_80x15.png         1203
/en-US/firefox/buttons/getfirefox_large2.png  818
==>                                           aug_button_404s.tsv   <==
/fr/firefox/buttons/firefox_80x15.png         8932
/ko/firefox/buttons/getfirefox_small.png      1344
/en-US/firefox/buttons/firefox_80x15.png      934
/fr/firefox/buttons/getfirefox_88x31.png      499
/en-US/firefox/buttons/getfirefox_88x31.png   298
/tr/firefox/buttons/firefox_80x15.png         296
/it/firefox/buttons/firefox_80x15.png         196
/en-US/firefox/buttons/getfirefox_small.png   151
/de/firefox/buttons/firefox_80x15.png         130
/en-US/firefox/buttons/getfirefox_large2.png  91
==>                                           sept_button_404s.tsv  <==
/fr/firefox/buttons/firefox_80x15.png         66817
/ko/firefox/buttons/getfirefox_small.png      10476
/en-US/firefox/buttons/firefox_80x15.png      7115
/fr/firefox/buttons/getfirefox_88x31.png      2867
/en-US/firefox/buttons/getfirefox_88x31.png   2270
/tr/firefox/buttons/firefox_80x15.png         1983
/it/firefox/buttons/firefox_80x15.png         1659
/en-US/firefox/buttons/getfirefox_small.png   1092
/de/firefox/buttons/firefox_80x15.png         1073
/en-US/firefox/buttons/getfirefox_large2.png  727

Comment 12

3 years ago
I'd like to give a huge thanks to :tmary, he helped me out a lot with figuring out how to analyze our log files with hadoop, and the gist I mentioned in comment #11 was created based on an example he gave me.

Comment 13

3 years ago
Created attachment 8495303 [details]
aug_button_404s.tsv
Attachment #8494610 - Attachment is obsolete: true

Comment 14

3 years ago
Created attachment 8495304 [details]
sept_button_404s.tsv
Attachment #8494609 - Attachment is obsolete: true

Comment 15

3 years ago
I accidentally left in a filter from :tmary's example (which he helpfully pointed out this morning), so the analysis in comment #11 only had a sample of the data. I've rerun it with the full dataset for August and September and updated their attachments for this bug (2014 is just the sum of the data from those 2 months since the problem started in late August). I've also updated the gist. The results are now in alignment with what I was seeing in comment #6:

$ head aug_button_404s.tsv sept_button_404s.tsv | column -t
==>                                           aug_button_404s.tsv   <==
/fr/firefox/buttons/firefox_80x15.png         3740441
/ko/firefox/buttons/getfirefox_small.png      613009
/en-US/firefox/buttons/firefox_80x15.png      408765
/fr/firefox/buttons/getfirefox_88x31.png      211920
/tr/firefox/buttons/firefox_80x15.png         115892
/en-US/firefox/buttons/getfirefox_88x31.png   115465
/it/firefox/buttons/firefox_80x15.png         78040
/de/firefox/buttons/firefox_80x15.png         63393
/en-US/firefox/buttons/getfirefox_small.png   59424
/en-US/firefox/buttons/getfirefox_large2.png  39688
==>                                           sept_button_404s.tsv  <==
/fr/firefox/buttons/firefox_80x15.png         2942353
/ko/firefox/buttons/getfirefox_small.png      461530
/en-US/firefox/buttons/firefox_80x15.png      307212
/fr/firefox/buttons/getfirefox_88x31.png      121560
/en-US/firefox/buttons/getfirefox_88x31.png   99688
/tr/firefox/buttons/firefox_80x15.png         82360
/it/firefox/buttons/firefox_80x15.png         75923
/de/firefox/buttons/firefox_80x15.png         49338
/en-US/firefox/buttons/getfirefox_small.png   47482
/de/firefox/buttons/getfirefox_small.png      32462

Comment 16

3 years ago
Ok, great. It looks like there are only a few size buttons and languages to deal with.

I wonder if we could get away with the 100x72 banners on affiliates?

https://affiliates.mozilla.org/media/uploads/image_banners/b5193a506ded57870dea0b44b45e3092fab1b916.png

We also have this legacy 110x32 banner:

https://affiliates.mozilla.org/media/uploads/banners/5d3a43832c5233ce27da7b53e00b2ad1c6ccd87b.png

It looks like the locales are:

* fr
* ko
* en-US
* tr
* it
* de

I don't know if that download button is localized in the locales above.

Comment 17

3 years ago
(In reply to Chris More [:cmore] from comment #16)
> Ok, great. It looks like there are only a few size buttons and languages to
> deal with.

:cmore just to make sure we're on the same page, I'd like to point out that I only pasted the top URLs into my comments, the full list of 404s for August and September are attachments-- there are over 400 localized button URLs getting traffic, only a handful of which look like legitimate 404s. The majority of the traffic is of course concentrated on a subset of those, but we may want to broaden our scope of what buttons to restore beyond the top 10 urls for each month I showed in the output of my "head" command in comment #15

> I don't know if that download button is localized in the locales above.

I don't either, but I do know that in an old svn checkout of the mozilla.com repo on my laptop, I wasn't able to find any localized buttons, but I did find en-US versions of the buttons:

jgmize@x1c:~/mozilla.com/en-US/firefox/buttons$ ls -l
total 64
-rw-rw-r-- 1 jgmize jgmize  1063 Aug  8  2013 firefox_80x15.png
-rw-rw-r-- 1 jgmize jgmize  1027 Aug  8  2013 firefox_pixel.png
-rw-rw-r-- 1 jgmize jgmize  3691 Aug  8  2013 getfirefox_88x31.png
-rw-rw-r-- 1 jgmize jgmize  3919 Aug  8  2013 getfirefox_large2.png
-rw-rw-r-- 1 jgmize jgmize  4500 Aug  8  2013 getfirefox_large3.png
-rw-rw-r-- 1 jgmize jgmize  3958 Aug  8  2013 getfirefox_large.png
-rw-rw-r-- 1 jgmize jgmize  2396 Aug  8  2013 getfirefox_small.png
-rw-rw-r-- 1 jgmize jgmize 18842 Aug  8  2013 header.png
-rw-rw-r-- 1 jgmize jgmize  4271 Aug  8  2013 takebacktheweb_large.png
-rw-rw-r-- 1 jgmize jgmize  3309 Aug  8  2013 takebacktheweb_small.png

Perhaps we should copy those old buttons into bedrock and configure apache to serve them up for any locale?

Comment 18

3 years ago
> :cmore just to make sure we're on the same page, I'd like to point out that
> I only pasted the top URLs into my comments, the full list of 404s for
> August and September are attachments-- there are over 400 localized button
> URLs getting traffic, only a handful of which look like legitimate 404s. The
> majority of the traffic is of course concentrated on a subset of those, but
> we may want to broaden our scope of what buttons to restore beyond the top
> 10 urls for each month I showed in the output of my "head" command in
> comment #15

Yes, I knew that was just the top URLs and that there was a long-tail of URLs. The only concern is that we could spend valuable time handling all of those URLs, or we just focus on where 80% the requests are coming from. I'm sure the 80/20 rule is in here somewhere. i.e 80% of the requests are coming from 20% of the URLs. :)

I would probably focus on finding a good solution for the top URLs and then "good enough" for the rest of the URLs that don't contribute a ton of traffic. 

> Perhaps we should copy those old buttons into bedrock and configure apache
> to serve them up for any locale?

Actually, maybe that will be good enough to just serve up the en-US buttons for all locales. It is not 100% ideal given that French is #1 and en-US is #3 on the top 10.

I just realized that these buttons were deleted in bug https://bugzilla.mozilla.org/show_bug.cgi?id=946993#c4 opps! I guess we all assumed that they weren't getting many requests.
(Reporter)

Comment 19

3 years ago
Isn't the point with such banners that they can be managed by you guys, and all those sites who embed these images would always have a fresh set of buttons on their site?

Comment 20

3 years ago
(In reply to Rene from comment #19)
> Isn't the point with such banners that they can be managed by you guys, and
> all those sites who embed these images would always have a fresh set of
> buttons on their site?

These legacy and unsupported buttons were before affiliates.mozilla.org existed and we don't have a team outside of affiliates to manage such buttons. Also, affiliates.mozilla.org currently is on maintenance mode as it is not priority for Mozilla. We are just trying to find a low technical investment to restoring these buttons that don't consume a lot of bandwidth. We have higher impact development tasks that we need to focus on now.
Whiteboard: [kb=1527755]
(Reporter)

Comment 21

3 years ago
Unfortunately it gives a pretty unorganized picture when at some point Mozilla urges people to use buttons, and then abandons them more or less completely in a relatively short time.
You need to log in before you can comment on or make changes to this bug.