726070 - [404] http://www.mozilla.org/unix/customizing.html

Status: RESOLVED WONTFIX

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

Description

[Terry R.]

This is a link in the file userContent-example.css, and userChrome-example.css, which are located in the Firefox profile, in the chrome folder.

Comment 1

[Terry R.]

I found the page here:
http://www-archive.mozilla.org/unix/customizing.html

Can a redirect be set?

Comment 2

[Alex Charis]

also found in prefs.js

Comment 3

[Chris Ilias [:cilias]]

wontfixing because:
* userdocs don't belong on www.mozilla.org
* Firefox, Thunderbird, and SeaMonkey no longer create a \chrome\ directory in the profile folder, and haven't for a few years now.

Unfortunately, prefs.js still links to that URL. It should be removed from the prefs.js file. I did some searching on bugzilla, and found/confirmed bug 701322.


Creating redirects to www-archive.mozilla.org doesn't make sense, because of what that site says on the top banner:
"You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug."

Comment 4

[Terry R.]

(In reply to Chris Ilias [:cilias] from comment #3)
> wontfixing because:
> * userdocs don't belong on www.mozilla.org
> * Firefox, Thunderbird, and SeaMonkey no longer create a \chrome\ directory
> in the profile folder, and haven't for a few years now.
> 

Meaningless.  Every user that was using Firefox prior DOES have the folder, unless a new profile was created since.  I'd bet more have the folder than not.

> Unfortunately, prefs.js still links to that URL. It should be removed from
> the prefs.js file. I did some searching on bugzilla, and found/confirmed bug
> 701322.
> 

Anyone wanting to configure FF, TB, or SM, via the CSS files will have that reference in the file, which is a 404.  

> 
> Creating redirects to www-archive.mozilla.org doesn't make sense, because of
> what that site says on the top banner:
> "You are currently viewing a snapshot of www.mozilla.org taken on April 21,
> 2008. Most of this content is highly out of date (some pages haven't been
> updated since the project began in 1998) and exists for historical purposes
> only. If there are any pages on this archive site that you think should be
> added back to www.mozilla.org, please file a bug."

I guess you didn't pay attention to, "If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug."  That's exactly what was done.

I believe this should be resolved and FIXED somehow, and hope someone else will come up with a better solution.

Comment 5

[Chris Ilias [:cilias]]

(In reply to Terry R. from comment #4)
> I believe this should be resolved and FIXED somehow, and hope someone else
> will come up with a better solution.

The fix is to remove references to it from the Mozilla code. Please don't re-open bugs, just because you disagree with the resolution.

Comment 6

[Terry R.]

Until I'm told you're the final word on this decision, I will reopen the bug since I filed it, as I feel a better resolution can be found that what you are doing.

Comment 7

[Chris Ilias [:cilias]]

Userdocs on www.mozilla.org are my jurisdiction. <https://wiki.mozilla.org/Mozilla.org/Owners_List>
When we were going through the site to choose what should stay on www.mozilla.org, I addressed this page at <http://groups.google.com/group/mozilla.dev.mozilla-org/browse_frm/thread/f901711458f18533>.

Comment 8

[David Tenser [:djst]]

Guys, we're on the same team here.

(In reply to Chris Ilias [:cilias] from comment #5)
> The fix is to remove references to it from the Mozilla code. Please don't
> re-open bugs, just because you disagree with the resolution.

If the fix is to remove references to this page from the Mozilla code, then a WONTFIX resolution is not correct -- it seems the bug then belongs in a different component. Maybe either if you could help figure out which one?

Like Terry said, for existing profiles, this 404 link will still exist in the .css file. However, it doesn't seem like too big of a deal to be honest -- most users never even look in this file, and those who do will not get too confused by an old reference. While linking to a 404 file for existing profile isn't great, it has surely happened before (users of old Phoenix profiles will most certainly have a link to my old texturizer.net/phoenix web site, which is a 404 today).

Comment 9

[Terry R.]

Sent to Mozilla webmaster:

Re: http://www.mozilla.org/unix/customizing.html

I know that it's dated to say the least, but that customization guide was handy information at one time, and I believe that userChrome.css tweaks are still relevant for people who don't want to install Stylish.

Comment 10

[Kevin Ernst]

I am the person who pointed out the 404 to [e-mail] because it still ranks very high in search engine results for "userChrome.css"--first for DuckDuckGo, in fact. And this same thing happened to me today when I searched for "movemail"--the top search result is http://www.mozilla.org/mailnews/movemail/, 404. So... this is a systemic problem, right?

It seems like bug #674282 is an effort to get at the heart of the issue by establishing reporting and metrics for *which* 404'd pages are getting lots of visitors... perhaps so that redirects can be created such that search engine results are not adversely affected? Resulting in fewer 404 bugs filed in bugzilla?

I understand not wanting user docs on www.mozilla.org, removing the URL from prefs.js, and the huge amount of effort it would take to cater to just one search engine's (Bing's) tendency to rank these non-existent pages high in its search results (by creating a bunch of redirects or whatever). But then I'm reminded of the advice from "Cool URIs Don't Change" (http://www.w3.org/Provider/Style/URI.html).

Yes, the original page is so old it's got whiskers. But by WONTFIXing this, or similar 404 bugs, you're eschewing high-ranking search results from one of two major SEs for a meaningful resource and potentially leaving dozens of linking forum posts and articles from sites like mozillaZine and Lifehacker high and dry. When presumably all it would take is a 301 redirect to preserve the resource and search engine ranking, even if it has to carry the "highly out of date" disclaimer.

Respectfully submitted.

Comment 11

[Kevin Ernst]

Guess I should've checked this before mouthing off, but Bing has recently updated the results for "userChrome.css" to point to the www-archive.mozilla.org document. So the DuckDuckGo/Bing no longer deliver a 404 as the top hit, but the rest of the issues remain.

Also agree with Terry re: the existence of the "chrome" folder in user profiles. If FF/TB still reads chrome/userChrome.css, and the multitude of userChrome.css "hacks" documented on the web still work (there was a resurgence of these around the release of FF4 due to the orange "Firefox" menu), then a canonical Mozilla reference for userChrome.css should probably still exist, somewhere. Even if it's just a 301 redirect to an article on MDN.

If you would like a separate bug report for "No definitive reference for userChrome.css anywhere on mozilla.org," I'll file it. I'll also get to work on creating a page for userChrome.css on MDN, if I'm able. There are existing articles migrated from mozilla.org (such as https://developer.mozilla.org/en/Thunderbird/Thunderbird_Configuration_Files) which can then link to it.

See also:
[1] http://support.mozilla.org/en-US/questions/798065 (user asking for location of userChrome.css reference)
[2] http://www.google.com/search?q=site%3Amozilla.org%20userchrome.css (hint: bug reports, forum posts [mostly pointing to the userChrome.css article on mozillaZine], and http://www-archive.mozilla.org/unix/customizing.html)
[3] https://developer.mozilla.org/en-US/search?q=userchrome.css
[4] https://developer.mozilla.org/Project:en/Needs_Redirect
[5] bug #308518 ("Need redirects added to Mozilla.org")


Respectfully submitted.

Comment 12

[Chris Ilias [:cilias]]

Hi Kevin,
If I understand you correctly, you're looking for a page that lists all userChrome.css tweaks. This page was not that. It was just a collection of tweaks a community member created in the year 2000. That person stopped maintaining it in 2003. There's nothing official about it. Don't let the URL fool you. :)

You could file a bug on MDN, if you want. I think what you're looking for is bug 230273.

Comment 13

[Kevin Ernst]

Really, appealing for a 301 redirect from the old "customizing.html"--be it the www-archive or the 404 version--to some bit of actively-maintained documentation, perhaps on MDN. Because as much as that page wants and needs to be laid to rest in the Great Bit Bucket in the Sky, it's *still* turning up at the top of search results in 2012, indicating to me that it's retained some quality of usefulness to this day that can't (yet) be found elsewhere on mozilla.org.

Something along these lines --> http://kb.mozillazine.org/UserChrome.css, including in particular the bits about where to *find* userChrome.css on various platforms, perhaps with a mention of Keyconfig (http://kb.mozillazine.org/Keyconfig_extension) so that the new MDN wiki article can completely replace the old document in terms of the still-useful parts.

I now know which two bugs (bug #308518, bug #230273) pertain specifically to what I'm asking for, so I'll go help with those two and not belabor the point here any further. I now have an MDN wiki account and I'm prepared to use it.

Thanks for pointing me in the right direction. :)