1189596 - Firefox for iOS page URL keeps getting rewritten like a zone

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: Wiki pages, defect)

Description

[Eric Shepherd [:sheppy]]

The Firefox for iOS page is located at https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_for_iOS. However, when you visit it, the URL in the URL bar gets rewritten to https://developer.mozilla.org/en-US/Firefox_for_iOS. Yes, the page loads, but that is not the correct URL.

I've checked and it's not a wiki-side redirect, so something on the server is doing it.

While https://developer.mozilla.org/en-US/docs/Mozilla/Firefox is a zone whose URL is remapped intentionally to https://developer.mozilla.org/en-US/Firefox, that shouldn't affect other content outside that hierarchy.

Please help figure out and fix this problem before this incorrect and inadvisable URL spreads.

Comment 1

[Jannis Leidel [:jezdez]]

This redirect works as intended, the document zone middleware checks for the prefix "/docs/Mozilla/Firefox" and replaces it with "/Firefox" here: https://github.com/mozilla/kuma/blob/42ee383820afcf506ef10ec699675d574d26db2f/kuma/wiki/middleware.py#L34

I guess what you're assuming is that only *subpages* of "/docs/Mozilla/Firefox" should be redirected. If that's the case let me know.

Comment 2

[Eric Shepherd [:sheppy]]

(In reply to Jannis Leidel [:jezdez] from comment #1)
> This redirect works as intended, the document zone middleware checks for the
> prefix "/docs/Mozilla/Firefox" and replaces it with "/Firefox" here:
> https://github.com/mozilla/kuma/blob/
> 42ee383820afcf506ef10ec699675d574d26db2f/kuma/wiki/middleware.py#L34
> 
> I guess what you're assuming is that only *subpages* of
> "/docs/Mozilla/Firefox" should be redirected. If that's the case let me know.

Yes, only subpages of /docs/Mozilla/Firefox/ should be getting redirected. The Firefox for iOS page is not part of that hierarchy so should not be treated as if it were part of the zone by the redirect.

Comment 3

[ali spivak]

I'm wondering what the problem with the (redirected) URL is? Where foes Firefox for Android sit? Should they all be part of the Firefox hierarchy?(e.g. firefox desktop, firefox for android, firefox for IOS), or do we intentionally treat them as totally separate top-level products for UX purposes?

Comment 4

[Eric Shepherd [:sheppy]]

(In reply to ali spivak from comment #3)
> I'm wondering what the problem with the (redirected) URL is? Where foes
> Firefox for Android sit? Should they all be part of the Firefox
> hierarchy?(e.g. firefox desktop, firefox for android, firefox for IOS), or
> do we intentionally treat them as totally separate top-level products for UX
> purposes?

Well, those currently get redirected to the top level too, but given that we're talking about killing off zones, it seems silly to start people off with the older URL form instead of just using docs/Mozilla/Firefox_iOS or whatever, since that's going to be the correct URL soon.

Comment 5

[Jean-Yves Perrier [:teoli]]

Sheppy is correct, the correct URL should be: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_for_iOS 

Note that we need to put a redirect for the wrong cases like https://developer.mozilla.org/en-US/Firefox_for_Android because else we lose links and it is the URL referenced in search engine.

We need to check if there are other similar cases, under Firefox but also other zones. Sheppy can you list all the problematic pages so we can open a redirect bug that lands before this one is fixed?

Comment 6

[Eric Shepherd [:sheppy]]

(In reply to Jean-Yves Perrier [:teoli] from comment #5)
> Sheppy is correct, the correct URL should be:
> https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_for_iOS 
> 
> Note that we need to put a redirect for the wrong cases like
> https://developer.mozilla.org/en-US/Firefox_for_Android because else we lose
> links and it is the URL referenced in search engine.
> 
> We need to check if there are other similar cases, under Firefox but also
> other zones. Sheppy can you list all the problematic pages so we can open a
> redirect bug that lands before this one is fixed?

Seems to me that it would be easier to simply code the Python code that does the rewrite so it checks for a slash after the base URL for the zone in the page being loaded, and if there isn't slash (or end-of-string), it's not in the zone. Isn't that literally all that has to be done here?

Comment 7

[Jean-Yves Perrier [:teoli]]

As it is not a recent regression, there are a few points to consider here before going forward.

1. How many current pages are impacted? Firefox_for_Android and Firefox_for_iOS are the only two listed for the moment.
2. Do these pages have external links to their wrong-since-2013 urls? If so we have to assess if we can afford to break these links. 

If we can afford killing these links, we may want to go ahead (unless zone killing is too near), if we can't, we will need to be sure we will have redirect in places from these old wrong urls to the new correct ones (at the same time we push the fix).

We need this information to go forward. Sheppy, can you do this research?

Also is this a problem if Firefox_for_iOS is at the wrong place for 3-4 months? 

Is it more work to add an http redirect then, or to fix this problem? (This third question is for Jannis)

Comment 8

[Luke Crouch [:groovecoder]]

Accord to last month of GA:

* Firefox_for_iOS was landing page for 224 pageviews, mostly from google, github.com, yahoo, direct, duckduckgo, bing, and MDN itself [1]

* Firefox_for_Android was landing page for 1,053 pageviews; mostly from mozilla.org, google, baidu, direct, yahoo, SUMO, blog.mozilla.org [2]

[1] https://www.google.com/analytics/web/?authuser=1#report/content-pages/a36116321w64965862p66726481/%3Fexplorer-segmentExplorer.segmentId%3Danalytics.landingPagePath%26explorer-table.plotKeys%3D[]%26explorer-table.advFilter%3D[[0%2C%22analytics.landingPagePath%22%2C%22RE%22%2C%22%2F[\\w-]{2%2C5}%2FFirefox_for_iOS%24%22%2C0]]%26explorer-table.secSegmentId%3Danalytics.source%26explorer-table.rowCount%3D25/

[2] https://www.google.com/analytics/web/?authuser=1#report/content-pages/a36116321w64965862p66726481/%3Fexplorer-segmentExplorer.segmentId%3Danalytics.landingPagePath%26explorer-table.plotKeys%3D[]%26explorer-table.advFilter%3D[[0%2C%22analytics.landingPagePath%22%2C%22RE%22%2C%22%2F[\\w-]{2%2C5}%2FFirefox_for_Android%22%2C0]]%26explorer-table.secSegmentId%3Danalytics.source%26explorer-table.rowCount%3D25/

Comment 9

[Eric Shepherd [:sheppy]]

Looks like Luke answered the questions that were asked of me.

Jannis still needs to look at comment #7 though.

It doesn't sound like we're breaking the world if we make this change, based on the stats Luke mentions in comment #8. I think we should go ahead and fix this.

Comment 10

[Luke Crouch [:groovecoder]]

:sheppy - we still need a list of all of the problematic zones like this before we can know the scope of the fix.

Comment 11

[Eric Shepherd [:sheppy]]

The only ones are the "Firefox" zone as far as I'm able to tell. It's all about having leading text that's the same. We just don't have many cases where a zone starts with a string that's a common start of other page slugs.

Comment 12

[John Whitlock [:jwhitlock]]

Zones are removed (bug 1462475). These page URLs are no longer redirects:

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_for_iOS
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_for_Android